From syan at openjdk.org Wed Oct 1 00:56:00 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 1 Oct 2025 00:56:00 GMT Subject: RFR: 8354894: java/lang/Thread/virtual/Starvation.java timeout on server with high CPUs In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 08:52:04 GMT, SendaoYan wrote: > Hi all, > > We observed java/lang/Thread/virtual/Starvation.java intermittent timed out on server with many CPU core number. The more CPU core number the 'runTest' will create more pinned virtual threads. This PR compute an iteration count which divide the CPU core number will make test run passed steady on server with high CPUs. > > Before apply the proposed patch, test run finish 257 seconds, after apply the proposed patch test run finish 1.2 seconds on the 2 sockets system with Intel(R) Xeon(R) Platinum 8480+. So I remove the 'timeout=800', I think the default timeout 120 will be enough. GHA report [linux-x64-hs-zero](https://github.com/sendaoYan/jdk-ysd/actions/runs/18090989532/job/51471333067#logs) build fails during install toolchain and dependencies, it seems like test environmental issue, it's unrelated to this PR. Thanks @AlanBateman @jaikiran for the reviews and verify. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27543#issuecomment-3354281838 From syan at openjdk.org Wed Oct 1 00:56:01 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 1 Oct 2025 00:56:01 GMT Subject: Integrated: 8354894: java/lang/Thread/virtual/Starvation.java timeout on server with high CPUs In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 08:52:04 GMT, SendaoYan wrote: > Hi all, > > We observed java/lang/Thread/virtual/Starvation.java intermittent timed out on server with many CPU core number. The more CPU core number the 'runTest' will create more pinned virtual threads. This PR compute an iteration count which divide the CPU core number will make test run passed steady on server with high CPUs. > > Before apply the proposed patch, test run finish 257 seconds, after apply the proposed patch test run finish 1.2 seconds on the 2 sockets system with Intel(R) Xeon(R) Platinum 8480+. So I remove the 'timeout=800', I think the default timeout 120 will be enough. This pull request has now been integrated. Changeset: 0366d882 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/0366d8823bc844225ca24964e352ce0a57d01683 Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod 8354894: java/lang/Thread/virtual/Starvation.java timeout on server with high CPUs Co-authored-by: Alan Bateman Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/27543 From jpai at openjdk.org Wed Oct 1 01:57:01 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 1 Oct 2025 01:57:01 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v13] In-Reply-To: References: Message-ID: <3hUJWM9fAKkjWpNnZDRtMgEXZWpP-DyVMTrk1EK0wRQ=.a5ad5755-a0d5-4e15-9d97-d978cb803adc@github.com> On Tue, 30 Sep 2025 19:28:15 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. >> >> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. >> >> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Additional review feedback. > Updated to emphasize reading the data from the streams and calling waitFor > to allow for normal termination. Thank you Roger for the updates. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26649#pullrequestreview-3287319141 From darcy at openjdk.org Wed Oct 1 04:38:41 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Oct 2025 04:38:41 GMT Subject: RFR: 8368985: Small Float16 refactorings Message-ID: A few more small cleanups to Float16 and its tests. ------------- Commit messages: - JDK-8368985: Small Float16 refactorings Changes: https://git.openjdk.org/jdk/pull/27587/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27587&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368985 Stats: 20 lines in 2 files changed: 4 ins; 2 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27587.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27587/head:pull/27587 PR: https://git.openjdk.org/jdk/pull/27587 From jbhateja at openjdk.org Wed Oct 1 05:34:57 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 1 Oct 2025 05:34:57 GMT Subject: RFR: 8368985: Small Float16 refactorings In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 04:29:56 GMT, Joe Darcy wrote: > A few more small cleanups to Float16 and its tests. LGTM ------------- Marked as reviewed by jbhateja (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27587#pullrequestreview-3287615535 From eirbjo at openjdk.org Wed Oct 1 06:45:46 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 1 Oct 2025 06:45:46 GMT Subject: RFR: 8368985: Small Float16 refactorings In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 04:29:56 GMT, Joe Darcy wrote: > A few more small cleanups to Float16 and its tests. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 736: > 734: final short bits = float16ToRawShortBits(f16); > 735: // A NaN value has all ones in its exponent and a non-zero significand > 736: return ((bits & EXP_BIT_MASK) == 0x7c00 && (bits & SIGNIF_BIT_MASK) != 0); Should the leftover 0x7c00 also be replaced with the constant? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27587#discussion_r2393600002 From fandreuzzi at openjdk.org Wed Oct 1 08:11:58 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 1 Oct 2025 08:11:58 GMT Subject: RFR: 8368985: Small Float16 refactorings In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 04:29:56 GMT, Joe Darcy wrote: > A few more small cleanups to Float16 and its tests. test/jdk/jdk/incubator/vector/BasicFloat16ArithTests.java line 411: > 409: float arg = testCase[0]; > 410: float expected = testCase[1]; > 411: float result = (float)getExponent(valueOfExact(arg)); Suggestion: float result = (float) getExponent(valueOfExact(arg)); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27587#discussion_r2393785761 From asotona at openjdk.org Wed Oct 1 09:00:11 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 1 Oct 2025 09:00:11 GMT Subject: RFR: 8368831: ResourceParsingClassHierarchyResolver.getClassInfo(ClassDesc) throws unspecified UncheckedIOException [v4] In-Reply-To: References: Message-ID: <-X-9fSlE_DaHOrrXgzhPR4MzpUdBbhGE7Cwf5wclJCY=.1ff98822-dfee-4552-8712-78086b079dc5@github.com> On Tue, 30 Sep 2025 23:42:13 GMT, Chen Liang wrote: >> ClassHierarchyResolver provided by users may sporadically run into exceptions due to reasons out of control, such as UncheckedIOException caused by a bad zip header. We should specify that users are allowed to fail their CHR when they encounter a failure when they support a ClassDesc to avoid hiding errors. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/chr-exception > - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java > > Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com> > - Fix non-IAE propagation > - Allow ClassHierarchyResolver to throw RuntimeException Looks good to me. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27559#pullrequestreview-3288181770 From asotona at openjdk.org Wed Oct 1 09:17:27 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 1 Oct 2025 09:17:27 GMT Subject: RFR: 8367585: Move Utf8Entry length validation earlier In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 05:43:43 GMT, Chen Liang wrote: > John Rose suggests in https://github.com/openjdk/jdk/pull/26802#issuecomment-3201402304 that ClassFile API should validate Utf8Entry length eagerly upon construction. Currently we validate upon writing to bytes, which avoids validation overhead. However, given that most class file utf8 data are shorter than 1/3 of the max length, which is always an encodable length, the performance impact should be low. > > Preventing the creation of unrepresentable UTF8 entries can prevent passing such invalid instances around, making such problems easier to debug than a failure at building. > > Tier 1-3 seems clear. The performance impact to jdk.classfile.Write or any of the regularly run transformation benchmarks seems neutral, less than 5% perturbations. > > I will update docs to reflect this change, given how widespread this is across JDK - it seems the only exempt classes are Signature, ClassSignature, and MethodSignature. I'm not a fan of this kind of early validation. Signature, ClassSignature, and MethodSignature do not seem to have specified length limits and so we have nothing to refer to. Pulling the physical storage limit tests up to the chain into the symbols seems to me obsolete. There are several related issues: - The checks become very complex for the weak advantage of failing just a bit earlier in the process. - The explanation to users is very complicated and requires to explain relations between multiple specifications. - The direction where it goes is dangerous. What if we start to check every single String argument across the whole Class-File API for its potential of overflow somewhere down the chain? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27281#issuecomment-3355443898 From michal.gn at proton.me Wed Oct 1 09:56:02 2025 From: michal.gn at proton.me (=?utf-8?Q?Micha=C5=82_G=2E?=) Date: Wed, 01 Oct 2025 09:56:02 +0000 Subject: Proposal: Custom executor for CompletableFuture in HttpClientImpl Message-ID: Hi all, I recently ran into an issue withHttpClientImplwhere I wanted to handle the reply right after callingsendAsync. What surprised me is that the returnedCompletableFuturealready runs on thecommonPool, instead of using the executor I provided to theHttpClient. Looking into the implementation, I noticed this piece of code: // makes sure that any dependent actions happen in the CF default // executor. This is only needed for sendAsync(...), when // exchangeExecutor is non-null. if (exchangeExecutor != null) { res = res.whenCompleteAsync((r, t) -> { /* do nothing */}, ASYNC_POOL); } I understand that thisexchangeExecutoris meant to cover the request/response exchange itself, not necessarily theCompletableFuturechaining. But the fact that we always force the returned future back onto thecommonPool, without any way to change this, feels quite limiting. In environments where thecommonPoolis already heavily loaded, this can easily introduce performance issues or unpredictable behavior. And since private static final Executor ASYNC_POOL = new CompletableFuture().defaultExecutor(); is fixed and cannot be replaced, users don?t have any way around it. For comparison, the default executor for CompletableFuture.supplyAsync or for parallelStream() is also the commonPool, but in those cases it?s easy to override it with a custom executor. It would be nice if HttpClientImpl offered the same flexibility. This is why I?d like to propose a change: when creating anHttpClientImpl, it should be possible to specify not only the exchange executor, but also the executor used for the returnedCompletableFuture This would be backwards compatible (just an additional optional builder parameter), and it could bring several benefits: - reduced context switching for clients that care about which thread executes response handling, - more predictable performance in environments wherecommonPoolis shared with other workloads, - easier integration with frameworks that already manage their own executors, - clearer control and observability over where callbacks are executed. Would such a change make sense, or is there a strong reason why wemust always fallback to thecommonPool? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at gmail.com Wed Oct 1 10:14:01 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Wed, 1 Oct 2025 11:14:01 +0100 Subject: Proposal: Custom executor for CompletableFuture in HttpClientImpl In-Reply-To: References: Message-ID: This belongs to the net-dev mailing list, which I CC'ed. On Wed, Oct 1, 2025 at 10:56?AM Micha? G. wrote: > > Hi all, > > I recently ran into an issue with HttpClientImpl where I wanted to handle the reply right after calling sendAsync. What surprised me is that the returned CompletableFuture already runs on the commonPool, instead of using the executor I provided to the HttpClient. > > Looking into the implementation, I noticed this piece of code: > > // makes sure that any dependent actions happen in the CF default > // executor. This is only needed for sendAsync(...), when > // exchangeExecutor is non-null. > if (exchangeExecutor != null) { > res = res.whenCompleteAsync((r, t) -> { /* do nothing */}, ASYNC_POOL); > } > > I understand that this exchangeExecutor is meant to cover the request/response exchange itself, not necessarily the CompletableFuture chaining. But the fact that we always force the returned future back onto the commonPool, without any way to change this, feels quite limiting. > > In environments where the commonPool is already heavily loaded, this can easily introduce performance issues or unpredictable behavior. And since > > private static final Executor ASYNC_POOL = new CompletableFuture().defaultExecutor(); > > is fixed and cannot be replaced, users don?t have any way around it. For comparison, the default executor for CompletableFuture.supplyAsync or for parallelStream() is also the commonPool, but in those cases it?s easy to override it with a custom executor. It would be nice if HttpClientImpl offered the same flexibility. > > This is why I?d like to propose a change: when creating an HttpClientImpl, it should be possible to specify not only the exchange executor, but also the executor used for the returned CompletableFuture > > This would be backwards compatible (just an additional optional builder parameter), and it could bring several benefits: > > reduced context switching for clients that care about which thread executes response handling, > > more predictable performance in environments where commonPool is shared with other workloads, > > easier integration with frameworks that already manage their own executors, > > clearer control and observability over where callbacks are executed. > > Would such a change make sense, or is there a strong reason why we must always fallback to the commonPool? From aturbanov at openjdk.org Wed Oct 1 10:50:48 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 1 Oct 2025 10:50:48 GMT Subject: RFR: 8368985: Small Float16 refactorings In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 04:29:56 GMT, Joe Darcy wrote: > A few more small cleanups to Float16 and its tests. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1563: > 1561: int exp = getExponent(f16); > 1562: > 1563: return switch(exp) { Suggestion: return switch (exp) { test/jdk/jdk/incubator/vector/BasicFloat16ArithTests.java line 408: > 406: }; > 407: > 408: for(var testCase : testCases) { Suggestion: for (var testCase : testCases) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27587#discussion_r2394152274 PR Review Comment: https://git.openjdk.org/jdk/pull/27587#discussion_r2394151777 From prappo at openjdk.org Wed Oct 1 11:17:06 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 1 Oct 2025 11:17:06 GMT Subject: RFR: 8368856: Add a method to safely add duration to instant [v5] In-Reply-To: <8hPfwxOf_dDz25bT4yIdq323qfxF92YxxKbGoNX1t-Y=.dad7c2f0-48fa-4c16-a324-21ed23885f11@github.com> References: <8hPfwxOf_dDz25bT4yIdq323qfxF92YxxKbGoNX1t-Y=.dad7c2f0-48fa-4c16-a324-21ed23885f11@github.com> Message-ID: On Tue, 30 Sep 2025 23:06:39 GMT, Pavel Rappo wrote: >> We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR. >> >> I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`. >> >> My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`. >> >> Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`. >> >> [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Slightly improve corner case In 1fe394b I added a test case to exercise behaviour similar to the one discussed previously for `minus`. The test case ultimately does this: Instant.MAX.plus(Duration.between(Instant.MAX, Instant.MIN)) It looks like the result is `Instant.MIN`, but it isn't. It would be `Instant.MIN` if `plus` didn't overflow intermediately. --- Let me again explain what happens, if only for future reference for myself. `Instant.MAX` is 31556889864403199.999,999,999 seconds. `Duration.between(Instant.MAX, Instant.MIN)` is -63113904031622399.999,999,999 seconds. The sum of those is -31557014167219200 seconds, which is exactly `Instant.MIN`. However, the internal representation of `Duration` and `Instant` are not what one might think. While `seconds` can be of either sign, `nanos` are always non-negative, within this range 0 <= nanos <= 999,999,999. So, negative `Duration` -63113904031622399.999,999,999 is represented as -63113904031622200 seconds plus 1 nanosecond. That is, it's a value that is 1 nanosecond closer to 0 than -63113904031622200 is. When `Instant.plus(Duration)` is invoked, it first creates an `Instant` whose seconds are the sum of the seconds and whose nanoseconds are those of the original `Instant`. Any nanoseconds from `Duration` are then added to that `Instant` to produce yet another `Instant`, which holds the final result. The overflow happens in the first step of `plus`, because 31556889864403199 - 63113904031622200 is -31557014167219201, which is less than the -31556889864403200 seconds of `Instant.MIN`. If `plus` proceeded to the second step, which is nanos adjustment, it would get 999,999,999 + 1, which is equal to a whole positive second. It would then add it to -31557014167219201 and get -31557014167219200, which is `Instant.MIN`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27549#issuecomment-3355846946 From dclarke at openjdk.org Wed Oct 1 11:29:29 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Wed, 1 Oct 2025 11:29:29 GMT Subject: RFR: 8368877: Generate Jextract bindings for Kqueue Message-ID: This PR is based on #25546 , though it was suggested to split that PR into 2 for easier reviewing and to give better visibility in the git history. This PR contains all the JExtract generated code that will be needed for converting Java's KQueue implementation to use Panama features instead of JNI. The actual updates to KQueue to make use of these files will come in the second PR. The basic structure here has the different native structures and methods split into 3 different packages all preceded by `src/java.base/macosx/classes/jdk/internal/ffi/generated/` Included in each package is a file `package-info.java` which contains the script that was used to generate these files so that others can reproduce them in future. The only modifications that have been made to the files post-generation are: - Adding copyright headers - Adding warning suppression for using restricted methods Some further modifications to these files to cut down on code duplication and adding support for errno handling on the native calls will come in the 2nd PR alongside the KQueue changes mentioned. ------------- Commit messages: - added warning supression for restricted methods, fixed missing comma in copyright header - re-added the copyright headers - jextract generated code and the package-info.java files that describe how they were genereated Changes: https://git.openjdk.org/jdk/pull/27590/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27590&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368877 Stats: 1351 lines in 11 files changed: 1351 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27590.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27590/head:pull/27590 PR: https://git.openjdk.org/jdk/pull/27590 From liach at openjdk.org Wed Oct 1 11:52:46 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 1 Oct 2025 11:52:46 GMT Subject: RFR: 8367585: Move Utf8Entry length validation earlier In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 05:43:43 GMT, Chen Liang wrote: > John Rose suggests in https://github.com/openjdk/jdk/pull/26802#issuecomment-3201402304 that ClassFile API should validate Utf8Entry length eagerly upon construction. Currently we validate upon writing to bytes, which avoids validation overhead. However, given that most class file utf8 data are shorter than 1/3 of the max length, which is always an encodable length, the performance impact should be low. > > Preventing the creation of unrepresentable UTF8 entries can prevent passing such invalid instances around, making such problems easier to debug than a failure at building. > > Tier 1-3 seems clear. The performance impact to jdk.classfile.Write or any of the regularly run transformation benchmarks seems neutral, less than 5% perturbations. > > I will update docs to reflect this change, given how widespread this is across JDK - it seems the only exempt classes are Signature, ClassSignature, and MethodSignature. I think you misunderstood this patch. All classfile API strings eventually go to the constant pool except ones going into the signatures. So the CP size check are absent on signature model's strings and nominal descriptor strings. What I did was I noted these strings are edge cases that we intentionally don't length check (we really can't). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27281#issuecomment-3355959636 From duke at openjdk.org Wed Oct 1 12:25:22 2025 From: duke at openjdk.org (Jason Mehrens) Date: Wed, 1 Oct 2025 12:25:22 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v13] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 19:28:15 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. >> >> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. >> >> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Additional review feedback. > Updated to emphasize reading the data from the streams and calling waitFor > to allow for normal termination. src/java.base/share/classes/java/lang/Process.java line 205: > 203: * On some platforms, {@linkplain #supportsNormalTermination() normal termination} > 204: * is not available and the process is forcibly terminated. > 205: * The {@linkplain #waitFor() waitFor} method SHOULD NOT be called after Calling waitFor with a timeout is a must for escalation of process termination. E.G. TWR + finally waitFor with timeout. Then destroy with force. Optionally waitFor again if we need to know process is terminated. It is not waitFor that should not be used. It is the result of exitValue or waitFor may or may not be a normal value from the process after any destroy method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2394385338 From rriggs at openjdk.org Wed Oct 1 13:03:42 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 1 Oct 2025 13:03:42 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v13] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 12:21:58 GMT, Jason Mehrens wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Additional review feedback. >> Updated to emphasize reading the data from the streams and calling waitFor >> to allow for normal termination. > > src/java.base/share/classes/java/lang/Process.java line 205: > >> 203: * On some platforms, {@linkplain #supportsNormalTermination() normal termination} >> 204: * is not available and the process is forcibly terminated. >> 205: * The {@linkplain #waitFor() waitFor} method SHOULD NOT be called after > > Calling waitFor with a timeout is a must for escalation of process termination. E.G. TWR + finally waitFor with timeout. Then destroy with force. Optionally waitFor again if we need to know process is terminated. > > It is not waitFor that should not be used. It is the result of exitValue or waitFor may or may not be a normal value from the process after any destroy method. @jmehrens I think I understand your point. Does this capture it: * Calling {@linkplain #waitFor() waitFor} after * {@linkplain #close() close} or after the try-with-resources block exits * can verify that the process has been terminated. * The status returned may be from normal termination or the result of * {@link #destroy() destroying the process}. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2394495843 From prappo at openjdk.org Wed Oct 1 13:26:52 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 1 Oct 2025 13:26:52 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v8] In-Reply-To: References: Message-ID: > Please review this documentation-only change, which I believe does **NOT** require CSR. > > The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: > > * used a comma separator for some big integer values, to improve readability; > * fixed a few typos and grammar. > > While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. > > * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? > > Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) > > Are there any cases here where that distinction matters? > > * In many cases, the following phrase is used throughout documentation: > > > positive or negative > > While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? > > * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". 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 11 additional commits since the last revision: - Merge remote-tracking branch 'jdk/master' into java.time - Revert this tiny change "Should" still feels out of place, but it's the same text copied across multiple packages. So it's better to leave it as is. - Remove CSR-triggering changes - An empty commit to kick GHA - Update src/java.base/share/classes/java/time/temporal/ChronoField.java Co-authored-by: Justin Lu - Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update src/java.base/share/classes/java/time/package-info.java due to e58c5a4c023 + update src/java.base/share/classes/java/time/temporal/ChronoField.java due to 4d8aadf8754 - A few more typos - Extra typos and decimal separator - Use comma as a decimal separator - Fix Duration.abs - ... and 1 more: https://git.openjdk.org/jdk/compare/6e4fc3db...47c0d45f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27296/files - new: https://git.openjdk.org/jdk/pull/27296/files/7c4cc716..47c0d45f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=06-07 Stats: 153876 lines in 1576 files changed: 128305 ins; 14999 del; 10572 mod Patch: https://git.openjdk.org/jdk/pull/27296.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27296/head:pull/27296 PR: https://git.openjdk.org/jdk/pull/27296 From prappo at openjdk.org Wed Oct 1 13:26:54 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 1 Oct 2025 13:26:54 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v7] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:28:06 GMT, Roger Riggs wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove CSR-triggering changes > > Keeping the change to typos removes the necessity of the the CSR. @RogerRiggs, @naotoj, please re-review this PR. If you are okay with that latest trivial change, I will integrate the PR today. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3356302262 From rriggs at openjdk.org Wed Oct 1 13:30:50 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 1 Oct 2025 13:30:50 GMT Subject: RFR: 8368825: Use switch expression for DateTimeFormatterBuilder pattern character lookup [v4] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 23:21:32 GMT, Shaojin Wen wrote: >> The DateTimeFormatterBuilder::FIELD_MAP previously used a Map for mapping pattern characters to TemporalField >> instances. This PR refactors that implementation to use a switch expression instead, which eliminates the need to hold a Map in >> memory. >> >> The switch expression approach offers these advantages: >> - No memory overhead for maintaining a HashMap structure >> - More direct character-to-field mapping without hash computation >> - Better code readability and maintainability >> >> This change maintains the same functionality while improving the memory efficiency of pattern character lookup in >> DateTimeFormatterBuilder by eliminating the static Map that was previously used for character-to-field mapping. >> >> * before >> image > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > revert comment @liach Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26634#pullrequestreview-3289145865 From fbredberg at openjdk.org Wed Oct 1 13:35:52 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 1 Oct 2025 13:35:52 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References: Message-ID: > Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need: > - `_held_monitor_count` > - `_parent_held_monitor_count` > - `_jni_monitor_count` > > This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`. > They are not present in other platforms. > > Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change. > `PowerPC` and `RISC-V` has been sanity checked using QEMU. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Update after review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27570/files - new: https://git.openjdk.org/jdk/pull/27570/files/f05981b1..a3f09e85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27570&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27570&range=00-01 Stats: 16 lines in 4 files changed: 0 ins; 6 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27570.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27570/head:pull/27570 PR: https://git.openjdk.org/jdk/pull/27570 From fbredberg at openjdk.org Wed Oct 1 13:39:56 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 1 Oct 2025 13:39:56 GMT Subject: RFR: 8367601: Remove held_monitor_count In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 13:32:24 GMT, Martin Doerr wrote: >> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need: >> - `_held_monitor_count` >> - `_parent_held_monitor_count` >> - `_jni_monitor_count` >> >> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`. >> They are not present in other platforms. >> >> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change. >> `PowerPC` and `RISC-V` has been sanity checked using QEMU. > > Looks correct (PPC64 and shared code changes) and tier1 has passed. Would be nice to clean up unused temp registers > > diff --git a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp > index 0bcc24a23bf..9fe7e1f22ff 100644 > --- a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp > +++ b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp > @@ -1639,7 +1639,6 @@ static void fill_continuation_entry(MacroAssembler* masm, Register reg_cont_obj, > assert_different_registers(reg_cont_obj, reg_flags); > Register zero = R8_ARG6; > Register tmp2 = R9_ARG7; > - Register tmp3 = R10_ARG8; > > DEBUG_ONLY(__ block_comment("fill {")); > #ifdef ASSERT > @@ -1678,7 +1677,6 @@ static void fill_continuation_entry(MacroAssembler* masm, Register reg_cont_obj, > static void continuation_enter_cleanup(MacroAssembler* masm) { > Register tmp1 = R8_ARG6; > Register tmp2 = R9_ARG7; > - Register tmp3 = R10_ARG8; > > #ifdef ASSERT > __ block_comment("clean {"); > @@ -1689,8 +1687,8 @@ static void continuation_enter_cleanup(MacroAssembler* masm) { > > __ ld_ptr(tmp1, ContinuationEntry::parent_cont_fastpath_offset(), R1_SP); > __ st_ptr(tmp1, JavaThread::cont_fastpath_offset(), R16_thread); > - __ ld_ptr(tmp3, ContinuationEntry::parent_offset(), R1_SP); > - __ st_ptr(tmp3, JavaThread::cont_entry_offset(), R16_thread); > + __ ld_ptr(tmp2, ContinuationEntry::parent_offset(), R1_SP); > + __ st_ptr(tmp2, JavaThread::cont_entry_offset(), R16_thread); > DEBUG_ONLY(__ block_comment("} clean")); > } > > > Thanks for doing it for all platforms! @TheRealMDoerr > Would be nice to clean up unused temp registers Fixed those. > Thanks for doing it for all platforms! The same ways as eating different types of food enriches your life, so does programming for different CPUs. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3356372605 From fbredberg at openjdk.org Wed Oct 1 13:40:00 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 1 Oct 2025 13:40:00 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 15:51:14 GMT, Patricio Chilano Mateo wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after review > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1742: > >> 1740: log_develop_debug(continuations)("PINNED due to critical section"); >> 1741: verify_continuation(cont.continuation()); >> 1742: freeze_result res = entry->is_pinned() ? freeze_pinned_cs : freeze_pinned_monitor; > > We can remove this and always return freeze_pinned_cs. We should remove freeze_pinned_monitor (there is a matching definition in Continuation.java). Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27570#discussion_r2394622676 From rriggs at openjdk.org Wed Oct 1 13:50:29 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 1 Oct 2025 13:50:29 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v8] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 13:26:52 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > 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 11 additional commits since the last revision: > > - Merge remote-tracking branch 'jdk/master' into java.time > - Revert this tiny change > > "Should" still feels out of place, but it's the same text > copied across multiple packages. So it's better to leave > it as is. > - Remove CSR-triggering changes > - An empty commit to kick GHA > - Update src/java.base/share/classes/java/time/temporal/ChronoField.java > > Co-authored-by: Justin Lu > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update src/java.base/share/classes/java/time/package-info.java due to e58c5a4c023 > + update src/java.base/share/classes/java/time/temporal/ChronoField.java due to 4d8aadf8754 > - A few more typos > - Extra typos and decimal separator > - Use comma as a decimal separator > - Fix Duration.abs > - ... and 1 more: https://git.openjdk.org/jdk/compare/1bf00fe7...47c0d45f Thanks for the updates. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27296#pullrequestreview-3289252250 From duke at openjdk.org Wed Oct 1 14:02:51 2025 From: duke at openjdk.org (craigraw) Date: Wed, 1 Oct 2025 14:02:51 GMT Subject: RFR: 8345810: Custom launchers must be linked with pthread to avoid dynamic linker issues [v2] In-Reply-To: References: Message-ID: <3wmTc01gqlZgKbHbolEjymrkTN0ONFgmSLlfTjHvKfI=.9c3b4fcd-79b0-4702-8dd0-a8c7b8257bf7@github.com> On Thu, 28 Aug 2025 15:10:03 GMT, Aleksey Shipilev wrote: >> See the bug for more investigation. >> >> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able to debug it to older glibc issue, which makes `dlerror` not thread-safe when pthreads are not yet loaded. This bug seems to uniquely affect custom launchers. We figured this is because custom launchers are not linked with `pthread`. JLI seems to be avoiding this issue, because it does link with `pthread`. Therefore the fix on the JDK side is to always link custom launchers with `pthread`. >> >> Reproducing the issue is a bit awkward. It requires compiling with older GCC (7.3.1 in my case), so that `libsimdsort` would not expose `avx2_sort` symbol, so that compiler stub initialization sequence would get its own erroneous `dlerror`, which would conflict inside of glibc. The compilations with newer GCC (10, at very least) are not exposed to this. This is why the issue is so elusive. But now that we understand it, we know this is a ticking time bomb that can fire at any time in the future, once any concurrent thread inside of VM gets a non-zero `dlerror` for whatever reason. >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `sun/management/jmxremote`, 100x, no failures >> - [x] Linux AArch64 server fastdebug, `tools/jpackage`, 20x, no failures >> - [x] Linux AArch64 server fastdebug, `jdk_all`, no failures > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Broader pthread linkage for all JDK jtreg executables, similar to how Hotspot jtreg executables do it > - Merge branch 'master' into JDK-8345810-custom-launcher-dlerror > - Change to LIB* variables > - Fix It really feels like the bug is serious enough to warrant backporting this fix into Java 25 LTS. Currently it is not safe to create a multithreaded jpackaged app that may be run on older Linux distro releases, including Ubuntu 20.04. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26978#issuecomment-3355948391 From fbredberg at openjdk.org Wed Oct 1 14:13:35 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 1 Oct 2025 14:13:35 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 14:01:57 GMT, Martin Doerr wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after review > > I guess you want to update the Copyright headers eventually. @TheRealMDoerr > I guess you want to update the Copyright headers eventually. Think I updated all the years to 2025. `grep -i 'copyright' $(git diff --name-only master) | grep -i oracle` Did you see something I missed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3356537891 From mdoerr at openjdk.org Wed Oct 1 14:04:52 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Oct 2025 14:04:52 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 13:35:52 GMT, Fredrik Bredberg wrote: >> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need: >> - `_held_monitor_count` >> - `_parent_held_monitor_count` >> - `_jni_monitor_count` >> >> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`. >> They are not present in other platforms. >> >> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change. >> `PowerPC` and `RISC-V` has been sanity checked using QEMU. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Update after review PPC64 and shared code changes look good. Thanks! I guess you want to update the Copyright headers eventually. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27570#pullrequestreview-3289324176 PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3356501843 From mdoerr at openjdk.org Wed Oct 1 14:20:13 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Oct 2025 14:20:13 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References: Message-ID: <2HZuTvrbG5DED7c-r-MBu-itrFiIzJiy4B2WCjXxdiw=.cb10434a-3390-4c48-b27f-ad0ac7e6092f@github.com> On Wed, 1 Oct 2025 14:01:57 GMT, Martin Doerr wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after review > > I guess you want to update the Copyright headers eventually. > @TheRealMDoerr > > > I guess you want to update the Copyright headers eventually. > > Think I updated all the years to 2025. `grep -i 'copyright' $(git diff --name-only master) | grep -i oracle` > > Did you see something I missed? I thought I had seen 2024 somewhere. But, I can't find it again. I guess I had looked at the wrong file. Your Copyright updates look fine. Sorry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3356572661 From asotona at openjdk.org Wed Oct 1 15:03:16 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 1 Oct 2025 15:03:16 GMT Subject: RFR: 8367585: Move Utf8Entry length validation earlier In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 05:43:43 GMT, Chen Liang wrote: > John Rose suggests in https://github.com/openjdk/jdk/pull/26802#issuecomment-3201402304 that ClassFile API should validate Utf8Entry length eagerly upon construction. Currently we validate upon writing to bytes, which avoids validation overhead. However, given that most class file utf8 data are shorter than 1/3 of the max length, which is always an encodable length, the performance impact should be low. > > Preventing the creation of unrepresentable UTF8 entries can prevent passing such invalid instances around, making such problems easier to debug than a failure at building. > > Tier 1-3 seems clear. The performance impact to jdk.classfile.Write or any of the regularly run transformation benchmarks seems neutral, less than 5% perturbations. > > I will update docs to reflect this change, given how widespread this is across JDK - it seems the only exempt classes are Signature, ClassSignature, and MethodSignature. I still see no benefits, just drawbacks of this PR. src/java.base/share/classes/java/lang/classfile/ClassSignature.java line 42: > 40: * ClassSignature} can represent generic signatures that cannot be represented in > 41: * classfile. There is no classfile representation checks for string or nominal > 42: * descriptor arguments passed to static factory methods in this class. I think this information is misleading. I've read it multiple times and still not sure what is the key takeaway for user. src/java.base/share/classes/java/lang/classfile/ClassSignature.java line 113: > 111: /** > 112: * Parses a raw class signature string into a {@linkplain Signature}. > 113: * The string may be unrepresentable by a {@link Utf8Entry}. This also seems to me misleading. What does it mean for user? src/java.base/share/classes/java/lang/classfile/attribute/SignatureAttribute.java line 111: > 109: * @param classSignature the class signature > 110: * @throws IllegalArgumentException if the raw signature string is not > 111: * representable by a {@link Utf8Entry} I think adding this paragraph potentially to every place where a String is converted to Utf8Entry is polluting the javadoc. General paragraph about throwing IAE from Class-File API should cover that situations. We are not shadowing the specs here, we just need to say an IAE may happen if the class file is not possible to construct for any reason. src/java.base/share/classes/java/lang/constant/package-info.java line 105: > 103: * may result in errors. Consumers of nominal descriptors, such as bytecode > 104: * reading and writing APIs, should define the behaviors when such descriptors > 105: * are passed. This seems to me unrelated to j.l.constant package and very confusing. src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 160: > 158: if (!ModifiedUtf.isValidLengthInConstantPool(s)) { > 159: throw new IllegalArgumentException("utf8 length out of range of u2: " + ModifiedUtf.utfLen(s)); > 160: } There might be multiple Utf8EntryImpl instances created and later reduced into a single entry to write, so the check performed here might be redundant. ------------- PR Review: https://git.openjdk.org/jdk/pull/27281#pullrequestreview-3289656770 PR Review Comment: https://git.openjdk.org/jdk/pull/27281#discussion_r2394915306 PR Review Comment: https://git.openjdk.org/jdk/pull/27281#discussion_r2394916642 PR Review Comment: https://git.openjdk.org/jdk/pull/27281#discussion_r2394920101 PR Review Comment: https://git.openjdk.org/jdk/pull/27281#discussion_r2394922383 PR Review Comment: https://git.openjdk.org/jdk/pull/27281#discussion_r2394924423 From duke at openjdk.org Wed Oct 1 15:03:28 2025 From: duke at openjdk.org (Sean Gilligan) Date: Wed, 1 Oct 2025 15:03:28 GMT Subject: RFR: 8345810: Custom launchers must be linked with pthread to avoid dynamic linker issues [v2] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 15:10:03 GMT, Aleksey Shipilev wrote: >> See the bug for more investigation. >> >> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able to debug it to older glibc issue, which makes `dlerror` not thread-safe when pthreads are not yet loaded. This bug seems to uniquely affect custom launchers. We figured this is because custom launchers are not linked with `pthread`. JLI seems to be avoiding this issue, because it does link with `pthread`. Therefore the fix on the JDK side is to always link custom launchers with `pthread`. >> >> Reproducing the issue is a bit awkward. It requires compiling with older GCC (7.3.1 in my case), so that `libsimdsort` would not expose `avx2_sort` symbol, so that compiler stub initialization sequence would get its own erroneous `dlerror`, which would conflict inside of glibc. The compilations with newer GCC (10, at very least) are not exposed to this. This is why the issue is so elusive. But now that we understand it, we know this is a ticking time bomb that can fire at any time in the future, once any concurrent thread inside of VM gets a non-zero `dlerror` for whatever reason. >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `sun/management/jmxremote`, 100x, no failures >> - [x] Linux AArch64 server fastdebug, `tools/jpackage`, 20x, no failures >> - [x] Linux AArch64 server fastdebug, `jdk_all`, no failures > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Broader pthread linkage for all JDK jtreg executables, similar to how Hotspot jtreg executables do it > - Merge branch 'master' into JDK-8345810-custom-launcher-dlerror > - Change to LIB* variables > - Fix It looks like the back port is here: https://github.com/openjdk/jdk25u/pull/257 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26978#issuecomment-3356859483 From naoto at openjdk.org Wed Oct 1 15:57:00 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 1 Oct 2025 15:57:00 GMT Subject: RFR: 8368825: Use switch expression for DateTimeFormatterBuilder pattern character lookup [v4] In-Reply-To: References: Message-ID: <03DIrJA3CcONrHoKW1eji6ri8XydMjwxuaDb8Eu8ix4=.a95d8913-2c41-4d02-b53e-63d761fd5966@github.com> On Tue, 30 Sep 2025 23:21:32 GMT, Shaojin Wen wrote: >> The DateTimeFormatterBuilder::FIELD_MAP previously used a Map for mapping pattern characters to TemporalField >> instances. This PR refactors that implementation to use a switch expression instead, which eliminates the need to hold a Map in >> memory. >> >> The switch expression approach offers these advantages: >> - No memory overhead for maintaining a HashMap structure >> - More direct character-to-field mapping without hash computation >> - Better code readability and maintainability >> >> This change maintains the same functionality while improving the memory efficiency of pattern character lookup in >> DateTimeFormatterBuilder by eliminating the static Map that was previously used for character-to-field mapping. >> >> * before >> image > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > revert comment @liach Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26634#pullrequestreview-3289923824 From naoto at openjdk.org Wed Oct 1 16:02:32 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 1 Oct 2025 16:02:32 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v8] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 13:26:52 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > 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 11 additional commits since the last revision: > > - Merge remote-tracking branch 'jdk/master' into java.time > - Revert this tiny change > > "Should" still feels out of place, but it's the same text > copied across multiple packages. So it's better to leave > it as is. > - Remove CSR-triggering changes > - An empty commit to kick GHA > - Update src/java.base/share/classes/java/time/temporal/ChronoField.java > > Co-authored-by: Justin Lu > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update src/java.base/share/classes/java/time/package-info.java due to e58c5a4c023 > + update src/java.base/share/classes/java/time/temporal/ChronoField.java due to 4d8aadf8754 > - A few more typos > - Extra typos and decimal separator > - Use comma as a decimal separator > - Fix Duration.abs > - ... and 1 more: https://git.openjdk.org/jdk/compare/8c55a4b1...47c0d45f Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27296#pullrequestreview-3289939501 From prappo at openjdk.org Wed Oct 1 16:05:07 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 1 Oct 2025 16:05:07 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v8] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 13:26:52 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > 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 11 additional commits since the last revision: > > - Merge remote-tracking branch 'jdk/master' into java.time > - Revert this tiny change > > "Should" still feels out of place, but it's the same text > copied across multiple packages. So it's better to leave > it as is. > - Remove CSR-triggering changes > - An empty commit to kick GHA > - Update src/java.base/share/classes/java/time/temporal/ChronoField.java > > Co-authored-by: Justin Lu > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update src/java.base/share/classes/java/time/package-info.java due to e58c5a4c023 > + update src/java.base/share/classes/java/time/temporal/ChronoField.java due to 4d8aadf8754 > - A few more typos > - Extra typos and decimal separator > - Use comma as a decimal separator > - Fix Duration.abs > - ... and 1 more: https://git.openjdk.org/jdk/compare/6e72c19e...47c0d45f Okay, thanks. Since java.time is not covered by tier1, which is what GHA runs, I did this additionally on my machine: % make test TEST="test/jdk/java/time/" ... ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR SKIP jtreg:test/jdk/java/time 187 187 0 0 0 ============================== TEST SUCCESS ------------- PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3357097001 From darcy at openjdk.org Wed Oct 1 16:06:45 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Oct 2025 16:06:45 GMT Subject: RFR: 8368985: Small Float16 refactorings [v2] In-Reply-To: References: Message-ID: > A few more small cleanups to Float16 and its tests. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27587/files - new: https://git.openjdk.org/jdk/pull/27587/files/9263189f..5a96376e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27587&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27587&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27587.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27587/head:pull/27587 PR: https://git.openjdk.org/jdk/pull/27587 From darcy at openjdk.org Wed Oct 1 16:06:46 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Oct 2025 16:06:46 GMT Subject: RFR: 8368985: Small Float16 refactorings [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 06:43:25 GMT, Eirik Bj?rsn?s wrote: > Should the leftover 0x7c00 also be replaced with the constant? Good catch; I meant to do that too. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27587#discussion_r2395116573 From prappo at openjdk.org Wed Oct 1 16:08:41 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 1 Oct 2025 16:08:41 GMT Subject: Integrated: 8367704: Fix minor documentation issues in java.time.** In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 15:17:29 GMT, Pavel Rappo wrote: > Please review this documentation-only change, which I believe does **NOT** require CSR. > > The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: > > * used a comma separator for some big integer values, to improve readability; > * fixed a few typos and grammar. > > While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. > > * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? > > Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) > > Are there any cases here where that distinction matters? > > * In many cases, the following phrase is used throughout documentation: > > > positive or negative > > While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? > > * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". This pull request has now been integrated. Changeset: e44ef0c3 Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/e44ef0c32b3c2fcd0a6293838d9185b6d0719219 Stats: 36 lines in 8 files changed: 0 ins; 0 del; 36 mod 8367704: Fix minor documentation issues in java.time.** Reviewed-by: naoto, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/27296 From pchilanomate at openjdk.org Wed Oct 1 16:10:30 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 1 Oct 2025 16:10:30 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 13:35:52 GMT, Fredrik Bredberg wrote: >> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need: >> - `_held_monitor_count` >> - `_parent_held_monitor_count` >> - `_jni_monitor_count` >> >> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`. >> They are not present in other platforms. >> >> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change. >> `PowerPC` and `RISC-V` has been sanity checked using QEMU. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Update after review Looks good to me, thanks! ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27570#pullrequestreview-3289970713 From alexey.semenyuk at oracle.com Wed Oct 1 16:34:18 2025 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 1 Oct 2025 12:34:18 -0400 Subject: JDK-8333664: icon path not resolved relatively from .properties file any more In-Reply-To: References: Message-ID: <73999856-6585-46b8-81f7-0f5786eac455@oracle.com> Hi Oliver, Thank you for reporting the issue. You hit the right person with it. I filed https://bugs.openjdk.org/browse/JDK-8369008 on your behalf. Should you have another jpackage question/bug report, please write to core-libs-dev at openjdk.org mail list. This way you will get prompt response even if one of jpackage maintainers is not available. - Alexey On 10/1/2025 2:37 AM, Oliver Kopp wrote: > Dear Alexey, > > I am one of the maintainers of JabRef, an open source JavaFX > application aiming to educate newcomers on Java. > > I am writing you since I think, I have an issue introduced via > https://bugs.openjdk.org/browse/JDK-8333664. > > In JDK24, when on macOS, using jpackage, and building a DMG, there is > the possibility to provide a .properties file using > "--file-associations". There I have "icon=jabref.icns". When building > with JDK24, everything works fine. With JDK25, I get > "java.nio.file.NoSuchFileException: jabref.icns". > > In JDK25, when giving a relative path from the directory where > jpackage is called, it works. > > The icon file is placed in the same directory as the ".properties" > file. - I think, the path given in the .properties file should be > resolved relatively from the path of that file - and not from the > directory where jpackage is started. > > Are you the right person to ask for support or should I mail this to > another place? > > TYIA and greetings, > > Oliver > > --- > > https://github.com/koppor/ 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 kfarrell at openjdk.org Wed Oct 1 16:50:24 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Wed, 1 Oct 2025 16:50:24 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v17] In-Reply-To: References: Message-ID: > With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ? 10.932 ns/op > - higher-precision 149.651 ? 8.438 ns/op > - counter-based 245.036 ? 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/fa1d2b26..409bbbfd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=15-16 Stats: 110 lines in 2 files changed: 22 ins; 57 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303 From rgiulietti at openjdk.org Wed Oct 1 16:59:18 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Oct 2025 16:59:18 GMT Subject: RFR: 8368985: Small Float16 refactorings [v2] In-Reply-To: References: Message-ID: <-7H4fKLBHM_RZ5E3Po9dGcpT9Kw50zCcrYMDzFFMpcA=.bc661f6d-6c55-471a-b724-0c93d19dbcb9@github.com> On Wed, 1 Oct 2025 16:06:45 GMT, Joe Darcy wrote: >> A few more small cleanups to Float16 and its tests. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 756: > 754: public static boolean isInfinite(Float16 f16) { > 755: return ((float16ToRawShortBits(f16) ^ float16ToRawShortBits(POSITIVE_INFINITY)) & > 756: (EXP_BIT_MASK | SIGNIF_BIT_MASK)) == 0; IMHO, `isNan()` and `isInfinite()` should look almost identical, except for the significand bits. Maybe for another time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27587#discussion_r2395223913 From duke at openjdk.org Wed Oct 1 17:01:18 2025 From: duke at openjdk.org (Jason Mehrens) Date: Wed, 1 Oct 2025 17:01:18 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v13] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 13:00:41 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/lang/Process.java line 205: >> >>> 203: * On some platforms, {@linkplain #supportsNormalTermination() normal termination} >>> 204: * is not available and the process is forcibly terminated. >>> 205: * The {@linkplain #waitFor() waitFor} method SHOULD NOT be called after >> >> Calling waitFor with a timeout is a must for escalation of process termination. E.G. TWR + finally waitFor with timeout. Then destroy with force. Optionally waitFor again if we need to know process is terminated. >> >> It is not waitFor that should not be used. It is the result of exitValue or waitFor may or may not be a normal value from the process after any destroy method. > > @jmehrens I think I understand your point. Does this capture it: > > * Calling {@linkplain #waitFor() waitFor} after > * {@linkplain #close() close} or after the try-with-resources block exits > * can verify that the process has been terminated. > * The status returned may be from normal termination or the result of > * {@link #destroy() destroying the process}. Looks good. Thanks for update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2395260463 From darcy at openjdk.org Wed Oct 1 17:22:17 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Oct 2025 17:22:17 GMT Subject: RFR: 8368985: Small Float16 refactorings [v3] In-Reply-To: References: Message-ID: <51-xEz43o2zWyWoagMw74aG1hbVdwwVOtEESDJ_Fn4Q=.52d9039b-d11c-4667-84f5-bda9dc4bf9c0@github.com> > A few more small cleanups to Float16 and its tests. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27587/files - new: https://git.openjdk.org/jdk/pull/27587/files/5a96376e..db0613ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27587&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27587&range=01-02 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27587.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27587/head:pull/27587 PR: https://git.openjdk.org/jdk/pull/27587 From darcy at openjdk.org Wed Oct 1 17:22:19 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Oct 2025 17:22:19 GMT Subject: RFR: 8368985: Small Float16 refactorings [v2] In-Reply-To: <-7H4fKLBHM_RZ5E3Po9dGcpT9Kw50zCcrYMDzFFMpcA=.bc661f6d-6c55-471a-b724-0c93d19dbcb9@github.com> References: <-7H4fKLBHM_RZ5E3Po9dGcpT9Kw50zCcrYMDzFFMpcA=.bc661f6d-6c55-471a-b724-0c93d19dbcb9@github.com> Message-ID: <8_g4x4SLBPHJAPoDgCkU4ikhfk5kjIqzPJBek8sFA1g=.6b1b5a18-3869-4fe0-94a5-3c28ca2a06f1@github.com> On Wed, 1 Oct 2025 16:46:26 GMT, Raffaello Giulietti wrote: > IMHO, `isNan()` and `isInfinite()` should look almost identical, except for the significand bits. Maybe for another time. Fair point; updated. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27587#discussion_r2395304400 From kfarrell at openjdk.org Wed Oct 1 17:22:39 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Wed, 1 Oct 2025 17:22:39 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v18] In-Reply-To: References: Message-ID: > With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ? 10.932 ns/op > - higher-precision 149.651 ? 8.438 ns/op > - counter-based 245.036 ? 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: remove old test case reference ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/409bbbfd..ae7e2f27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=16-17 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303 From rriggs at openjdk.org Wed Oct 1 17:45:41 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 1 Oct 2025 17:45:41 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v14] In-Reply-To: References: Message-ID: > The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. > > The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. > > The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Clarify the use of waitFor after close() or T-W-R exit. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26649/files - new: https://git.openjdk.org/jdk/pull/26649/files/aadb11db..18637975 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=12-13 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26649.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26649/head:pull/26649 PR: https://git.openjdk.org/jdk/pull/26649 From rgiulietti at openjdk.org Wed Oct 1 18:00:42 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Oct 2025 18:00:42 GMT Subject: RFR: 8368985: Small Float16 refactorings [v3] In-Reply-To: <51-xEz43o2zWyWoagMw74aG1hbVdwwVOtEESDJ_Fn4Q=.52d9039b-d11c-4667-84f5-bda9dc4bf9c0@github.com> References: <51-xEz43o2zWyWoagMw74aG1hbVdwwVOtEESDJ_Fn4Q=.52d9039b-d11c-4667-84f5-bda9dc4bf9c0@github.com> Message-ID: On Wed, 1 Oct 2025 17:22:17 GMT, Joe Darcy wrote: >> A few more small cleanups to Float16 and its tests. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27587#pullrequestreview-3290358763 From jlu at openjdk.org Wed Oct 1 18:02:49 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Oct 2025 18:02:49 GMT Subject: Integrated: 6177299: [Fmt-Nu] NumberFormat.getPercentInstance() does not work correctly In-Reply-To: References: Message-ID: <7QqLWmbtCXGPM5tYbAacAJekA1DCZ7Mx7L8zJXp6alc=.383938b5-9fe8-479e-a0da-67c95d2c7d02@github.com> On Mon, 29 Sep 2025 21:38:28 GMT, Justin Lu wrote: > Please review this PR which corrects an edge case bug for `DecimalFormat` parsing when a multiplier is applied. > > This issue applies to any parsed Strings whose resultant double value is rounded to _9.223372036854776E18_ after the multiplier is applied. The returned value is incorrectly given as `Long.MAX_VALUE` when it should be returned as the double _9.223372036854776E18_. > > For example, the String _"922,337,203,685,477,600,000%"_ is first parsed as _9.223372036854776E20_, after which the multiplier is then applied to give _9.223372036854776E18_. The original code evaluates `9.223372036854776E18 == (double)(long)9.223372036854776E18` as true, leading to the long representation returned. > > The double value should first be checked if it is within the long min/max range before being checked if it can be represented as a long. Note that the check should be inclusive, as during the comparison, `Long.MAX_VALUE` is promoted to _9.223372036854776E18_. Thus _9.223372036854775E18_ correctly compares as false, and all doubles above compare as true. This pull request has now been integrated. Changeset: 6b72b778 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/6b72b778039afce0e25986114d15dd29a6786529 Stats: 44 lines in 2 files changed: 40 ins; 0 del; 4 mod 6177299: [Fmt-Nu] NumberFormat.getPercentInstance() does not work correctly Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/27563 From eirbjo at openjdk.org Wed Oct 1 18:34:03 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 1 Oct 2025 18:34:03 GMT Subject: RFR: 8368985: Small Float16 refactorings [v3] In-Reply-To: <51-xEz43o2zWyWoagMw74aG1hbVdwwVOtEESDJ_Fn4Q=.52d9039b-d11c-4667-84f5-bda9dc4bf9c0@github.com> References: <51-xEz43o2zWyWoagMw74aG1hbVdwwVOtEESDJ_Fn4Q=.52d9039b-d11c-4667-84f5-bda9dc4bf9c0@github.com> Message-ID: <_9cWhFYDxgq2lb_TPCsyiuQDHha-Gf9jLQKBaBIohJ4=.d0d97447-e64b-458f-ac00-baf557cadf26@github.com> On Wed, 1 Oct 2025 17:22:17 GMT, Joe Darcy wrote: >> A few more small cleanups to Float16 and its tests. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Just an observation: Constants in this class are some times qualified using the class name, in other cases not. This was probably the case before this PR, but the PR seems itself to be a bit inconsistent. Since the class uses constants from other classes, would it perhaps be beneficial to always use qualified constants? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27587#issuecomment-3357615652 From bchristi at openjdk.org Wed Oct 1 18:38:55 2025 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 1 Oct 2025 18:38:55 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v3] In-Reply-To: References: Message-ID: <5jy7TESrdbKHEh9oS_BZHjUh-mvL5lhoMlihE1XCXIY=.98295122-bc66-4b80-810d-47cbf3197fc3@github.com> On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao wrote: >> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip) >> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory. >> >> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE. >> >> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java. >> >> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference. > > Weibing Xiao has updated the pull request incrementally with two additional commits since the last revision: > > - remove unused code > - removed the commented out code src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 688: > 686: > 687: flushAndCloseOutputStream(); > 688: // 8313657 socket is not closed until GC is run Would it be worth keeping a comment here about why `sock` is not closed, or at least mentioning 8362268? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2395496537 From duke at openjdk.org Wed Oct 1 19:20:56 2025 From: duke at openjdk.org (duke) Date: Wed, 1 Oct 2025 19:20:56 GMT Subject: RFR: 8368968: FloatingDecimal: Clean up unused code [v2] In-Reply-To: References: Message-ID: <8wMk52nQ4lhHxDHN3xVJwnW5QVzFC8iJ9xmw3h37XEY=.80cd7146-26b1-428f-b21d-1626749c3884@github.com> On Tue, 30 Sep 2025 18:42:59 GMT, Johannes Graham wrote: >> This is a followup to https://github.com/openjdk/jdk/pull/27118, to clean up resulting unused code. >> - remove `getChars`, `isExceptional` and `isNegative` >> - remove `ExceptionalBinaryToASCIIBuffer`; throws `IllegalArgumentException` instead of returning an instance of that.(Caller already asserts non-exceptional arg) > > Johannes Graham has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java > > Co-authored-by: Raffaello Giulietti @j3graham Your change (at version d7d4938e375ca3fd4bd40a9501f9f396bd6478d5) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27581#issuecomment-3357803578 From prappo at openjdk.org Wed Oct 1 19:42:23 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 1 Oct 2025 19:42:23 GMT Subject: RFR: 8368856: Add a method to safely add duration to instant [v6] In-Reply-To: References: Message-ID: > We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR. > > I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`. > > My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`. > > Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`. > > [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Add Instant.minusSaturating(Duration) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27549/files - new: https://git.openjdk.org/jdk/pull/27549/files/49655050..35537856 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27549&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27549&range=04-05 Stats: 87 lines in 2 files changed: 86 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27549.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27549/head:pull/27549 PR: https://git.openjdk.org/jdk/pull/27549 From darcy at openjdk.org Wed Oct 1 19:59:48 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Oct 2025 19:59:48 GMT Subject: RFR: 8368985: Small Float16 refactorings [v3] In-Reply-To: <_9cWhFYDxgq2lb_TPCsyiuQDHha-Gf9jLQKBaBIohJ4=.d0d97447-e64b-458f-ac00-baf557cadf26@github.com> References: <51-xEz43o2zWyWoagMw74aG1hbVdwwVOtEESDJ_Fn4Q=.52d9039b-d11c-4667-84f5-bda9dc4bf9c0@github.com> <_9cWhFYDxgq2lb_TPCsyiuQDHha-Gf9jLQKBaBIohJ4=.d0d97447-e64b-458f-ac00-baf557cadf26@github.com> Message-ID: On Wed, 1 Oct 2025 18:30:25 GMT, Eirik Bj?rsn?s wrote: > Just an observation: Constants in this class are some times qualified using the class name, in other cases not. > > This was probably the case before this PR, but the PR seems itself to be a bit inconsistent. > > Since the class uses constants from other classes, would it perhaps be beneficial to always use qualified constants? Hmm. There is a static import of selected individual constants from the companion Float16Consts helper class, which is analagous to {Float, Double}Consts package access helper classes in java.lang. There are several other constant from that helper class that are _not_ static imported. I'll be this PR as is and we can consider regularizing how constant access is phrased in a future refactoring. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27587#issuecomment-3357911298 From darcy at openjdk.org Wed Oct 1 19:59:50 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Oct 2025 19:59:50 GMT Subject: Integrated: 8368985: Small Float16 refactorings In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 04:29:56 GMT, Joe Darcy wrote: > A few more small cleanups to Float16 and its tests. This pull request has now been integrated. Changeset: ef724f40 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/ef724f40c1f3cdddd215d50edf512bb06825085d Stats: 21 lines in 2 files changed: 5 ins; 2 del; 14 mod 8368985: Small Float16 refactorings Reviewed-by: rgiulietti, jbhateja ------------- PR: https://git.openjdk.org/jdk/pull/27587 From jgraham at openjdk.org Wed Oct 1 20:04:00 2025 From: jgraham at openjdk.org (Johannes Graham) Date: Wed, 1 Oct 2025 20:04:00 GMT Subject: Integrated: 8368968: FloatingDecimal: Clean up unused code In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 15:35:03 GMT, Johannes Graham wrote: > This is a followup to https://github.com/openjdk/jdk/pull/27118, to clean up resulting unused code. > - remove `getChars`, `isExceptional` and `isNegative` > - remove `ExceptionalBinaryToASCIIBuffer`; throws `IllegalArgumentException` instead of returning an instance of that.(Caller already asserts non-exceptional arg) This pull request has now been integrated. Changeset: db6320df Author: Johannes Graham Committer: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/db6320df980ebe7cf2a1c727970cc937ab549b97 Stats: 160 lines in 1 file changed: 0 ins; 158 del; 2 mod 8368968: FloatingDecimal: Clean up unused code Reviewed-by: rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/27581 From prappo at openjdk.org Wed Oct 1 20:17:00 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 1 Oct 2025 20:17:00 GMT Subject: RFR: 8368856: Add a method to safely add duration to instant [v7] In-Reply-To: References: Message-ID: > We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR. > > I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`. > > My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`. > > Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`. > > [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Fix copy-paste typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27549/files - new: https://git.openjdk.org/jdk/pull/27549/files/35537856..e7207a08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27549&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27549&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27549.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27549/head:pull/27549 PR: https://git.openjdk.org/jdk/pull/27549 From rriggs at openjdk.org Wed Oct 1 20:19:34 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 1 Oct 2025 20:19:34 GMT Subject: RFR: 8368172: Make java.time.format.DateTimePrintContext immutable [v4] In-Reply-To: References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com> Message-ID: On Fri, 26 Sep 2025 04:04:40 GMT, Shaojin Wen wrote: >> I propose to make j.t.f.DateTimePrintContext immutable. >> >> Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method. >> >> Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > add DateTimePrinterParser#withOptional, from @RogerRiggs The necessity to replace the nested PrinterParsers in CompositPrinterParser.withOptional is an ugly feature of the design. At some point, someone will complain about that waste of memory and overhead. Only the composite printer has the static optional attribute. The rest are due to the nesting and it is a reasonable design choice to pass explicitly to each formatter as in cac20038d26a6e836cf427deee8a0942a23acc4d. It would be good to keep the design optional in parsing to be aligned with the PrinterParser design to avoid the designs drifting apart. And the documentation should more completely describe how the static and nested optionality cases are complementary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26913#issuecomment-3357981670 From jlu at openjdk.org Wed Oct 1 21:17:37 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Oct 2025 21:17:37 GMT Subject: RFR: 8368981: Case Fold Locale Legacy Tags On Demand Message-ID: Please review this PR which case folds grandfathered BCP47 tags on demand. (Instead of keeping the case compliant versions stored.) This facilitates the cleanup of the `LEGACY` map (which contains a String to String Array mapping). The 2D String array, creation and populating of the `LEGACY` map, as well as lower case folding of the legacy tags can now be removed from the static block of _sun.util.locale.LanguageTag_. Legacy tags are a small subset compared to the entire set of valid BCP47 tags. Reducing the cost for supporting them would be ideal. Instead, legacy tags can now be checked against and folded on demand via a switch statement. The commented grandfathered syntax is removed because the values themselves already exist as code, and the exact case can be found in the provided RFC link. ------------- Commit messages: - Bolstering case folding test cases for legacy tags - inline 'potentialLegacy' and 'modern' - init Changes: https://git.openjdk.org/jdk/pull/27596/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27596&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368981 Stats: 208 lines in 2 files changed: 100 ins; 90 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/27596.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27596/head:pull/27596 PR: https://git.openjdk.org/jdk/pull/27596 From naoto at openjdk.org Wed Oct 1 22:05:47 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 1 Oct 2025 22:05:47 GMT Subject: RFR: 8368981: Case Fold Locale Legacy Tags On Demand In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 21:11:53 GMT, Justin Lu wrote: > Please review this PR which case folds grandfathered BCP47 tags on demand. (Instead of keeping the case compliant versions stored.) > > This facilitates the cleanup of the `LEGACY` map (which contains a String to String Array mapping). The 2D String array, creation and populating of the `LEGACY` map, as well as lower case folding of the legacy tags can now be removed from the static block of _sun.util.locale.LanguageTag_. > > Legacy tags are a small subset compared to the entire set of valid BCP47 tags. Reducing the cost for supporting them would be ideal. Instead, legacy tags can now be checked against and folded on demand via a switch statement. > > The commented grandfathered syntax is removed because the values themselves already exist as code, and the exact case can be found in the provided RFC link. Looks good. Some minor comments follow src/java.base/share/classes/sun/util/locale/LanguageTag.java line 111: > 109: > 110: // Check if the tag is a legacy tag > 111: var modern = legacyToModern(LocaleUtils.toLowerString(languageTag)); I'd use "preferred" instead of "modern", as it is used in the RFC. test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 112: > 110: "zh-guoyu", > 111: "i-pwn", > 112: "i-mingo" Is this intentionally randomized? Otherwise I would like it to be sorted. ------------- PR Review: https://git.openjdk.org/jdk/pull/27596#pullrequestreview-3291289066 PR Review Comment: https://git.openjdk.org/jdk/pull/27596#discussion_r2396010744 PR Review Comment: https://git.openjdk.org/jdk/pull/27596#discussion_r2396013611 From jlu at openjdk.org Wed Oct 1 22:51:30 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Oct 2025 22:51:30 GMT Subject: RFR: 8368981: Case Fold Locale Legacy Tags On Demand [v2] In-Reply-To: References: Message-ID: > Please review this PR which case folds grandfathered BCP47 tags on demand. (Instead of keeping the case compliant versions stored.) > > This facilitates the cleanup of the `LEGACY` map (which contains a String to String Array mapping). The 2D String array, creation and populating of the `LEGACY` map, as well as lower case folding of the legacy tags can now be removed from the static block of _sun.util.locale.LanguageTag_. > > Legacy tags are a small subset compared to the entire set of valid BCP47 tags. Reducing the cost for supporting them would be ideal. Instead, legacy tags can now be checked against and folded on demand via a switch statement. > > The commented grandfathered syntax is removed because the values themselves already exist as code, and the exact case can be found in the provided RFC link. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: implemenet Naoto's review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27596/files - new: https://git.openjdk.org/jdk/pull/27596/files/710d7737..3720e24a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27596&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27596&range=00-01 Stats: 40 lines in 2 files changed: 15 ins; 15 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27596.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27596/head:pull/27596 PR: https://git.openjdk.org/jdk/pull/27596 From jlu at openjdk.org Wed Oct 1 22:51:30 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Oct 2025 22:51:30 GMT Subject: RFR: 8368981: Case Fold Locale Legacy Tags On Demand [v2] In-Reply-To: References: Message-ID: <0ERKiGbLdQe_k6CuJMiS877HpgA1gAQ1nyOwXEybFCo=.a6837f5f-c6ad-4f81-9196-0c5ea2cf858c@github.com> On Wed, 1 Oct 2025 22:02:11 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> implemenet Naoto's review > > test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 112: > >> 110: "zh-guoyu", >> 111: "i-pwn", >> 112: "i-mingo" > > Is this intentionally randomized? Otherwise I would like it to be sorted. No reason, just the order of what `entrySet()` gave me. It is now sorted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27596#discussion_r2396112656 From naoto at openjdk.org Wed Oct 1 23:06:49 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 1 Oct 2025 23:06:49 GMT Subject: RFR: 8368981: Case Fold Locale Legacy Tags On Demand [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 22:51:30 GMT, Justin Lu wrote: >> Please review this PR which case folds grandfathered BCP47 tags on demand. (Instead of keeping the case compliant versions stored.) >> >> This facilitates the cleanup of the `LEGACY` map (which contains a String to String Array mapping). The 2D String array, creation and populating of the `LEGACY` map, as well as lower case folding of the legacy tags can now be removed from the static block of _sun.util.locale.LanguageTag_. >> >> Legacy tags are a small subset compared to the entire set of valid BCP47 tags. Reducing the cost for supporting them would be ideal. Instead, legacy tags can now be checked against and folded on demand via a switch statement. >> >> The commented grandfathered syntax is removed because the values themselves already exist as code, and the exact case can be found in the provided RFC link. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > implemenet Naoto's review LGTM. Thanks for removing the (almost) unnecessary static initialization ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27596#pullrequestreview-3291472147 From swen at openjdk.org Thu Oct 2 02:17:31 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 2 Oct 2025 02:17:31 GMT Subject: RFR: 8368172: Make java.time.format.DateTimePrintContext immutable [v5] In-Reply-To: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com> References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com> Message-ID: > I propose to make j.t.f.DateTimePrintContext immutable. > > Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method. > > Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Revert "add DateTimePrinterParser#withOptional, from @RogerRiggs" This reverts commit 558fa46fa30093ff07e05e30a44ca0a86472e72e. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26913/files - new: https://git.openjdk.org/jdk/pull/26913/files/558fa46f..5a7e2316 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26913&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26913&range=03-04 Stats: 322 lines in 2 files changed: 2 ins; 242 del; 78 mod Patch: https://git.openjdk.org/jdk/pull/26913.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26913/head:pull/26913 PR: https://git.openjdk.org/jdk/pull/26913 From almatvee at openjdk.org Thu Oct 2 02:26:33 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 2 Oct 2025 02:26:33 GMT Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v2] In-Reply-To: References: Message-ID: > - Added test for custom info plist to cover app image including embedded runtime and runtime installer. > - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8362598: [macos] Add tests for custom info plist files [v3] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27509/files - new: https://git.openjdk.org/jdk/pull/27509/files/50011dad..f1e99130 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27509&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27509&range=00-01 Stats: 212 lines in 6 files changed: 117 ins; 52 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/27509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27509/head:pull/27509 PR: https://git.openjdk.org/jdk/pull/27509 From almatvee at openjdk.org Thu Oct 2 02:26:33 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 2 Oct 2025 02:26:33 GMT Subject: RFR: 8362598: [macos] Add tests for custom info plist files In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 02:54:32 GMT, Alexander Matveev wrote: > - Added test for custom info plist to cover app image including embedded runtime and runtime installer. > - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string. 8362598: [macos] Add tests for custom info plist files [v3] - Test updated to address all comments above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27509#issuecomment-3358769796 From swen at openjdk.org Thu Oct 2 03:08:32 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 2 Oct 2025 03:08:32 GMT Subject: RFR: 8368172: Make java.time.format.DateTimePrintContext immutable [v6] In-Reply-To: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com> References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com> Message-ID: <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com> > I propose to make j.t.f.DateTimePrintContext immutable. > > Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method. > > Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Improve javadoc for optional parameter in DateTimePrinterParser#format method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26913/files - new: https://git.openjdk.org/jdk/pull/26913/files/5a7e2316..6b35ea29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26913&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26913&range=04-05 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26913.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26913/head:pull/26913 PR: https://git.openjdk.org/jdk/pull/26913 From serb at openjdk.org Thu Oct 2 03:25:56 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 2 Oct 2025 03:25:56 GMT Subject: RFR: 8369027: Apply java.io.Serial annotations in java.scripting Message-ID: Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.scripting module to enable stricter compile-time checking of serialization-related declarations. The patch is trivial, only one class needs to be updated. Example of a similar change https://github.com/openjdk/jdk/pull/26208. ------------- Commit messages: - 8369027: Apply java.io.Serial annotations in java.scripting Changes: https://git.openjdk.org/jdk/pull/27599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27599&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369027 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27599.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27599/head:pull/27599 PR: https://git.openjdk.org/jdk/pull/27599 From henryjen at openjdk.org Thu Oct 2 05:40:49 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 2 Oct 2025 05:40:49 GMT Subject: RFR: 8347007: --strip-debug removes parameter names included with -parameters [v3] In-Reply-To: References: Message-ID: > Since parameters is an opt-in choice, it's more reasonable to consider that's desired information and make strip parameter names an opt-in choice as well. > > This PR changes the default behavior of --strip-debug to keep parameter names when it's available. Add opt-in mechanism, > via the strip-java-debug-attributes plugin by using argument `--strip-java-debug-attributes=+parameter-names`. > > The --strip-debug option is a little bit odd, as it's a main option as well as a plugin option to enable the DefaultStripDebugPlugin, which strip native debug information on platform support the feature, and strip java debug information. In this PR, we chose to support only one mechanism to enable strip parameter names, so we would disable the embed StripJavaDebugAttributesPlugin when StripJavaDebugAttributesPlugin is enabled. > > The StripParameterNamesTest illustrate and verify parameter names use cases, mainly focus on argument processing and the parameter names. We didn't verify the regular debug info as that's covered by existing test. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: MethodParameters attribute should not be removed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27566/files - new: https://git.openjdk.org/jdk/pull/27566/files/8b5a6c12..766dc01e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27566&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27566&range=01-02 Stats: 126 lines in 5 files changed: 1 ins; 108 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/27566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27566/head:pull/27566 PR: https://git.openjdk.org/jdk/pull/27566 From duke at openjdk.org Thu Oct 2 05:42:05 2025 From: duke at openjdk.org (ExE Boss) Date: Thu, 2 Oct 2025 05:42:05 GMT Subject: RFR: 8356022: Migrate descriptor parsing from generics to BytecodeDescriptor [v2] In-Reply-To: <8HZBxhhTi-z6Dj7grgPJy_zh1Ss2YFLQBJMuA6Rs8Jk=.f1c2a5a3-abc9-4430-980d-e318b8927f25@github.com> References: <8HZBxhhTi-z6Dj7grgPJy_zh1Ss2YFLQBJMuA6Rs8Jk=.f1c2a5a3-abc9-4430-980d-e318b8927f25@github.com> Message-ID: On Wed, 27 Aug 2025 19:18:17 GMT, Chen Liang wrote: >> As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types. >> >> In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported. >> >> These behaviors are already covered by the tests added in JDK-8350704 #23788. >> >> Testing: reflect/annotation/Class, running tier 1+2 > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/generic-desc-parse > - Roll back wrapper, test for BytecodeDescriptor > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/generic-desc-parse > - 8356022: Migrate descriptor parsing from generics to BytecodeDescriptor Such?cases would?have previously?thrown `ClassCastException` from?the?old `AnnotationParser?::toClass(?)`?method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24978#issuecomment-3359210847 From scolebourne at openjdk.org Thu Oct 2 06:57:51 2025 From: scolebourne at openjdk.org (Stephen Colebourne) Date: Thu, 2 Oct 2025 06:57:51 GMT Subject: RFR: 8368825: Use switch expression for DateTimeFormatterBuilder pattern character lookup [v4] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 23:21:32 GMT, Shaojin Wen wrote: >> The DateTimeFormatterBuilder::FIELD_MAP previously used a Map for mapping pattern characters to TemporalField >> instances. This PR refactors that implementation to use a switch expression instead, which eliminates the need to hold a Map in >> memory. >> >> The switch expression approach offers these advantages: >> - No memory overhead for maintaining a HashMap structure >> - More direct character-to-field mapping without hash computation >> - Better code readability and maintainability >> >> This change maintains the same functionality while improving the memory efficiency of pattern character lookup in >> DateTimeFormatterBuilder by eliminating the static Map that was previously used for character-to-field mapping. >> >> * before >> image > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > revert comment @liach Marked as reviewed by scolebourne (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/26634#pullrequestreview-3292808879 From rgiulietti at openjdk.org Thu Oct 2 07:19:56 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 2 Oct 2025 07:19:56 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v15] In-Reply-To: References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: On Thu, 25 Sep 2025 17:37:34 GMT, fabioromano1 wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Comments > > Master branch results: > > Benchmark Mode Cnt Score Error Units > BigDecimalDivide.testExactDivideL avgt 15 109800.570 ? 4612.510 ns/op > BigDecimalDivide.testExactDivideM avgt 15 18786.818 ? 725.330 ns/op > BigDecimalDivide.testExactDivideS avgt 15 9764.192 ? 98.841 ns/op > BigDecimalDivide.testExactDivideXL avgt 15 976249.610 ? 194313.150 ns/op > BigDecimalDivide.testExactDivideXS avgt 15 7782.170 ? 209.999 ns/op > ``` > > PR branch results: > > Benchmark Mode Cnt Score Error Units > BigDecimalDivide.testExactDivideL avgt 15 9323.939 ? 302.617 ns/op > BigDecimalDivide.testExactDivideM avgt 15 5367.752 ? 87.323 ns/op > BigDecimalDivide.testExactDivideS avgt 15 4514.351 ? 79.579 ns/op > BigDecimalDivide.testExactDivideXL avgt 15 37474.101 ? 601.947 ns/op > BigDecimalDivide.testExactDivideXS avgt 15 3983.560 ? 60.067 ns/op @fabioromano1 While the main algorithm seems correct, probably during next week I'd like to take another look at the code to see whether there are other cases at the extremes of the scale range that could lead to ?1 errors in the scale, or inadvertent overflows. Are there other small enhancements to this PR you'd like to add, both in the main code and in the tests? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27271#issuecomment-3359536382 From bkilambi at openjdk.org Thu Oct 2 09:25:46 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 2 Oct 2025 09:25:46 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: <-Ei1bFBHQvpeD3n7j8WuhV572oNW1b9X8FI488DMigI=.d1f9c421-b0f5-49e0-9ac5-97732ca82c4f@github.com> On Mon, 29 Sep 2025 07:18:42 GMT, Xiaohong Gong wrote: >> This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species. >> >> Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets - >> >> **For AddReduction :** >> On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction. >> >> On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order. >> >> **For MulReduction :** >> Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported. >> >> Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` - >> >> Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch. >> Ratio > 1 indicates the performance with this patch is better than the master branch. >> >> **N1 (UseSVE = 0, max vector length = 16B):** >> >> Benchmark vectorDim Mode Cnt 8B 16B >> ReductionAddFP16 256 thrpt 9 1.41 1.40 >> ReductionAddFP16 512 thrpt 9 1.41 1.41 >> ReductionAddFP16 1024 thrpt 9 1.43 1.40 >> ReductionAddFP16 2048 thrpt 9 1.43 1.40 >> ReductionMulFP16 256 thrpt 9 1.22 1.22 >> ReductionMulFP16 512 thrpt 9 1.21 1.23 >> ReductionMulFP16 1024 thrpt 9 1.21 1.22 >> ReductionMulFP16 2048 thrpt 9 1.20 1.22 >> >> >> On N1, the scalarized sequence of `fadd/fmul` are gener... > > src/hotspot/cpu/aarch64/aarch64_vector.ad line 272: > >> 270: if (length_in_bytes > 16 || !is_feat_fp16_supported()) { >> 271: return false; >> 272: } > > Reductions with `length_in_bytes < 8` should also be skipped. Because such operations are not supported now, while the IRs with 32-bit vector size might exist, right? Hi @XiaohongGong, yes `length_in_bytes < 8` is also not supported and currently we support only for vector lengths of 8B and 16B. IRs with 32-bit vector size might exist but we do not have an optimized implementation for 32B vector lengths and thus I have disabled it. Instead of that, it generates the 16B scalarized Neon instruction sequence for a 32B vector length. Is this what you were asking? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2397961057 From duke at openjdk.org Thu Oct 2 10:14:50 2025 From: duke at openjdk.org (fabioromano1) Date: Thu, 2 Oct 2025 10:14:50 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v22] In-Reply-To: References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: <6GSnA_2G7jXB6-yfQlj6WdSaI17PMkjFdcwCTHUVaZM=.15fa382f-0ba1-43f7-9104-4629721b42a3@github.com> On Mon, 29 Sep 2025 16:12:20 GMT, fabioromano1 wrote: >> A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. > > fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: > > - Simplification > - Update DivideTests.java src/java.base/share/classes/java/math/BigDecimal.java line 4294: > 4292: } > 4293: > 4294: return BigInteger.TEN.pow(n); Suggestion: return fiveTo(n).shiftLeft(n); @rgiulietti I had thought about replacing the instruction on L. 4294 with the one above, but the `AddTests.java` of `BigDecimal` tests raises a timeout error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27271#discussion_r2398167757 From bkilambi at openjdk.org Thu Oct 2 10:23:46 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 2 Oct 2025 10:23:46 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: <4VXHOCR1YSoMVbDbB8j-j18Z-_VbO0y5fJfyp3IjQ9c=.19485011-9cb3-4016-a642-61cee81adcd1@github.com> On Mon, 29 Sep 2025 08:04:06 GMT, Xiaohong Gong wrote: >> This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species. >> >> Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets - >> >> **For AddReduction :** >> On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction. >> >> On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order. >> >> **For MulReduction :** >> Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported. >> >> Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` - >> >> Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch. >> Ratio > 1 indicates the performance with this patch is better than the master branch. >> >> **N1 (UseSVE = 0, max vector length = 16B):** >> >> Benchmark vectorDim Mode Cnt 8B 16B >> ReductionAddFP16 256 thrpt 9 1.41 1.40 >> ReductionAddFP16 512 thrpt 9 1.41 1.41 >> ReductionAddFP16 1024 thrpt 9 1.43 1.40 >> ReductionAddFP16 2048 thrpt 9 1.43 1.40 >> ReductionMulFP16 256 thrpt 9 1.22 1.22 >> ReductionMulFP16 512 thrpt 9 1.21 1.23 >> ReductionMulFP16 1024 thrpt 9 1.21 1.22 >> ReductionMulFP16 2048 thrpt 9 1.20 1.22 >> >> >> On N1, the scalarized sequence of `fadd/fmul` are gener... > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1900: > >> 1898: fmulh(dst, dst, vtmp); >> 1899: ins(vtmp, H, vsrc, 0, 7); >> 1900: fmulh(dst, dst, vtmp); > > Do you know why the performance is not improved significantly for multiply reduction? Seems instructions between different `ins` instructions will have a data-dependence, which is not expected? Could you please use other instructions instead or clear the register `vtmp` before `ins` and check the performance changes? > > Note that a clear of `mov` such as `MOVI Vd.2D, #0` has zero cost from V2's guide. Are you referring to the N1 numbers? The add reduction operation has gains around ~40% while the mul reduction is around ~20% on N1. On V1 and V2 they look comparable (not considering the cases where we generate `fadda` instructions). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2398197879 From alanb at openjdk.org Thu Oct 2 10:32:47 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Oct 2025 10:32:47 GMT Subject: RFR: 8368877: Generate Jextract bindings for Kqueue In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 11:22:34 GMT, Darragh Clarke wrote: > This PR is based on #25546 , though it was suggested to split that PR into 2 for easier reviewing and to give better visibility in the git history. > This PR contains all the JExtract generated code that will be needed for converting Java's KQueue implementation to use Panama features instead of JNI. The actual updates to KQueue to make use of these files will come in the second PR. > > The basic structure here has the different native structures and methods split into 3 different packages all preceded by > `src/java.base/macosx/classes/jdk/internal/ffi/generated/` > Included in each package is a file `package-info.java` which contains the script that was used to generate these files so that others can reproduce them in future. > > The only modifications that have been made to the files post-generation are: > - Adding copyright headers > - Adding warning suppression for using restricted methods > > Some further modifications to these files to cut down on code duplication and adding support for errno handling on the native calls will come in the 2nd PR alongside the KQueue changes mentioned. Thanks for doing this, it gives a baseline for the follow-on changes so it's clear what is modified. The package name looks good. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27590#pullrequestreview-3293849365 From vklang at openjdk.org Thu Oct 2 10:34:52 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 2 Oct 2025 10:34:52 GMT Subject: RFR: 8362123: ClassLoader Leak via Executors.newSingleThreadExecutor(...) [v2] In-Reply-To: References: <_RSrJDqgl9UDaKCwPK31uetZp7TEzY4VzkC00P7TKaQ=.fca60c93-cae5-43db-879a-0b63cd2e5d77@github.com> Message-ID: On Fri, 26 Sep 2025 16:42:49 GMT, Chris Dennis wrote: >> Executors shutdown via `shutdownNow()` should have their cleanables cleaned to prevent a classloader leak. This can happen if a classloader exists that both references the wrapped executor and is referenced by the delegate executor. >> >> To quote @Martin-Buchholz: >>> BTW: I find Cleaners much harder to use than old finalize, and it looks like I'm not the only one! > > Chris Dennis 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 one additional commit since the last revision: > > 8362123: ClassLoader Leak via Executors.newSingleThreadExecutor(...) > > Executors shutdown via `shutdownNow()` should have their cleanables cleaned to > prevent a classloader leak. This can happen if a classloader exists that both > references the wrapped executor and is referenced by the delegate executor. Looks good, thanks for addressing this! ------------- Marked as reviewed by vklang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26296#pullrequestreview-3293857262 From alanb at openjdk.org Thu Oct 2 10:43:26 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Oct 2025 10:43:26 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v6] In-Reply-To: References: Message-ID: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - Merge branch 'master' into JDK-8353835 - Improve CommandLineTest.testWarn - More test cleanup - Merge branch 'master' into JDK-8353835 - Expand jni/JNIAttachMutatorTest to final fields in named modules - Merge branch 'master' into JDK-8353835 - Test updates based on reviewer feedback - RemoveFields(duration) and filter internal frames - Merge branch 'master' into JDK-8353835 - Merge branch 'master' into JDK-8353835 - ... and 21 more: https://git.openjdk.org/jdk/compare/5251405c...234bc924 ------------- Changes: https://git.openjdk.org/jdk/pull/25115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=05 Stats: 4816 lines in 66 files changed: 4639 ins; 54 del; 123 mod Patch: https://git.openjdk.org/jdk/pull/25115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115 PR: https://git.openjdk.org/jdk/pull/25115 From rgiulietti at openjdk.org Thu Oct 2 10:47:11 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 2 Oct 2025 10:47:11 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v22] In-Reply-To: <6GSnA_2G7jXB6-yfQlj6WdSaI17PMkjFdcwCTHUVaZM=.15fa382f-0ba1-43f7-9104-4629721b42a3@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> <6GSnA_2G7jXB6-yfQlj6WdSaI17PMkjFdcwCTHUVaZM=.15fa382f-0ba1-43f7-9104-4629721b42a3@github.com> Message-ID: On Thu, 2 Oct 2025 10:12:01 GMT, fabioromano1 wrote: >> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: >> >> - Simplification >> - Update DivideTests.java > > src/java.base/share/classes/java/math/BigDecimal.java line 4294: > >> 4292: } >> 4293: >> 4294: return BigInteger.TEN.pow(n); > > Suggestion: > > return fiveTo(n).shiftLeft(n); > > @rgiulietti I had thought about replacing the instruction on L. 4294 with the one above, but the `AddTests.java` of `BigDecimal` tests raises a timeout error. I have not clue why this would cause a timeout, but I didn't investigate deeper. But how would this change help with _this_ PR? Performance is already much better, and as long as the results are correct, I would postpone other performance enhancements to a followup PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27271#discussion_r2398274810 From kfarrell at openjdk.org Thu Oct 2 10:58:52 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 2 Oct 2025 10:58:52 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v18] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 17:22:39 GMT, Kieran Farrell wrote: >> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ? 10.932 ns/op >> - higher-precision 149.651 ? 8.438 ns/op >> - counter-based 245.036 ? 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > remove old test case reference As Bokken highlighted, I think it might be worth adding a method (similar to the below) to extract the timestamp from v7 UUIDs? public long epochMilliTimestamp() { if (version() != 7) { throw new UnsupportedOperationException("Not a version 7 UUID"); } return (mostSigBits >>> 16) & 0xFFFFFFFFFFFFL; } Regarding, the issues around comparison, as mentioned I think would it would be worth updating the current `compareTo` doc to identify that the implmentation uses signed long comparison and may not provide lexographical sorting in align with the rfc which can be problmetaic for time based UUIDs and also to add a seperate instance method but with lexographical sorting using unsigned comparrsion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3360534618 From duke at openjdk.org Thu Oct 2 11:27:54 2025 From: duke at openjdk.org (Lars Bruun-Hansen) Date: Thu, 2 Oct 2025 11:27:54 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v18] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 17:22:39 GMT, Kieran Farrell wrote: >> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ? 10.932 ns/op >> - higher-precision 149.651 ? 8.438 ns/op >> - counter-based 245.036 ? 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > remove old test case reference public long epochMilliTimestamp() { ... } Honestly, such methods do not belong in the UUID class. A UUID is an _opaque object_. With the exception of `version()` and `variant()` there is nothing you should be able to extract from it. The whole idea of an UUID is that it does not carry any information. I fully recognize that methods `node()`, `clockSequence()` and `timestamp()` already exists in the class. But I believe that is a historical mistake. If anything, those methods should be deprecated. The JDK should not encourage this by adding yet another method. Also, it will be an endless game if the JDK tries to keep up with all sorts of things that potentially _could_ be extracted from an UUID (but shouldn't) Just my 2c. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3360690499 From mdonovan at openjdk.org Thu Oct 2 11:31:47 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 2 Oct 2025 11:31:47 GMT Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms [v2] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 13:46:36 GMT, Artur Barashev wrote: > I think we should either implement a public API to provide those signature schemes or not display them at all to avoid any confusion. If someone sets `jdk.tls.client.SignatureSchemes` system property they would sure know about it. That property overrides all other signature schemes for both "signature_algorithms" and "signature_algorithms_cert" extensions. I removed the signature algorithms from this output. If accurate lists aren't generated until TLS handshake, then I don't think there's any reason to print a list here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3360709304 From alanb at openjdk.org Thu Oct 2 11:37:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Oct 2025 11:37:50 GMT Subject: RFR: 8362123: ClassLoader Leak via Executors.newSingleThreadExecutor(...) [v2] In-Reply-To: References: <_RSrJDqgl9UDaKCwPK31uetZp7TEzY4VzkC00P7TKaQ=.fca60c93-cae5-43db-879a-0b63cd2e5d77@github.com> Message-ID: On Fri, 26 Sep 2025 16:42:49 GMT, Chris Dennis wrote: >> Executors shutdown via `shutdownNow()` should have their cleanables cleaned to prevent a classloader leak. This can happen if a classloader exists that both references the wrapped executor and is referenced by the delegate executor. >> >> To quote @Martin-Buchholz: >>> BTW: I find Cleaners much harder to use than old finalize, and it looks like I'm not the only one! > > Chris Dennis 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 one additional commit since the last revision: > > 8362123: ClassLoader Leak via Executors.newSingleThreadExecutor(...) > > Executors shutdown via `shutdownNow()` should have their cleanables cleaned to > prevent a classloader leak. This can happen if a classloader exists that both > references the wrapped executor and is referenced by the delegate executor. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26296#pullrequestreview-3294136271 From bkilambi at openjdk.org Thu Oct 2 12:46:48 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 2 Oct 2025 12:46:48 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: <8jnLugyioePdrnVuu9GRZ7VBgVGw9c8Hg00YTQRQAoQ=.d8677216-3330-49b6-a72c-b8e8ae454a34@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> <8jnLugyioePdrnVuu9GRZ7VBgVGw9c8Hg00YTQRQAoQ=.d8677216-3330-49b6-a72c-b8e8ae454a34@github.com> Message-ID: On Fri, 26 Sep 2025 16:21:35 GMT, Marc Chevalier wrote: > I seem to have a failure on `compiler/vectorization/TestFloat16VectorOperations.java` on aarch64 in `C2_MacroAssembler::neon_reduce_add_fp16(FloatRegister, FloatRegister, FloatRegister, unsigned int, FloatRegister)` at `src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp:1930`: > > ``` > assert(vector_length_in_bytes == 8 || vector_length_in_bytes == 16) failed: unsupported > ``` Hi, thanks for letting me know. However, I am unable to reproduce it on any of my machines. Would it be possible to share the JVM options used and also machines details. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3361062146 From aefimov at openjdk.org Thu Oct 2 13:16:56 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Thu, 2 Oct 2025 13:16:56 GMT Subject: RFR: 8368877: Generate Jextract bindings for Kqueue In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 11:22:34 GMT, Darragh Clarke wrote: > This PR is based on #25546 , though it was suggested to split that PR into 2 for easier reviewing and to give better visibility in the git history. > This PR contains all the JExtract generated code that will be needed for converting Java's KQueue implementation to use Panama features instead of JNI. The actual updates to KQueue to make use of these files will come in the second PR. > > The basic structure here has the different native structures and methods split into 3 different packages all preceded by > `src/java.base/macosx/classes/jdk/internal/ffi/generated/` > Included in each package is a file `package-info.java` which contains the script that was used to generate these files so that others can reproduce them in future. > > The only modifications that have been made to the files post-generation are: > - Adding copyright headers > - Adding warning suppression for using restricted methods > > Some further modifications to these files to cut down on code duplication and adding support for errno handling on the native calls will come in the 2nd PR alongside the KQueue changes mentioned. Marked as reviewed by aefimov (Reviewer). src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/package-info.java line 36: > 34: * > 35: * > 36: * jextract --target-package jdk.internal.natives.net.kqueue \ Should the target package be `jdk.internal.ffi.generated.kqueue`? ------------- PR Review: https://git.openjdk.org/jdk/pull/27590#pullrequestreview-3294562382 PR Review Comment: https://git.openjdk.org/jdk/pull/27590#discussion_r2398800276 From jpai at openjdk.org Thu Oct 2 13:21:05 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 2 Oct 2025 13:21:05 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v14] In-Reply-To: References: Message-ID: <_Huph1orV4PKtvcCC32PVK13D4oxCazAp7FsypWD6lQ=.a8b931fb-4a55-4bf4-a8b4-fccfac865a0b@github.com> On Wed, 1 Oct 2025 17:45:41 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. >> >> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. >> >> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarify the use of waitFor after close() or T-W-R exit. Latest update to the API doc looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26649#pullrequestreview-3294588009 From mchevalier at openjdk.org Thu Oct 2 13:24:01 2025 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 2 Oct 2025 13:24:01 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: <98jWF_NhAAB1WHHsotReB6SYIVSRIWNO0rmhxnNMJM8=.f21f3406-f3b3-4ce5-b009-6e50e2ebe1f1@github.com> On Fri, 26 Sep 2025 12:00:31 GMT, Bhavana Kilambi wrote: > This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species. > > Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets - > > **For AddReduction :** > On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction. > > On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order. > > **For MulReduction :** > Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported. > > Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` - > > Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch. > Ratio > 1 indicates the performance with this patch is better than the master branch. > > **N1 (UseSVE = 0, max vector length = 16B):** > > Benchmark vectorDim Mode Cnt 8B 16B > ReductionAddFP16 256 thrpt 9 1.41 1.40 > ReductionAddFP16 512 thrpt 9 1.41 1.41 > ReductionAddFP16 1024 thrpt 9 1.43 1.40 > ReductionAddFP16 2048 thrpt 9 1.43 1.40 > ReductionMulFP16 256 thrpt 9 1.22 1.22 > ReductionMulFP16 512 thrpt 9 1.21 1.23 > ReductionMulFP16 1024 thrpt 9 1.21 1.22 > ReductionMulFP16 2048 thrpt 9 1.20 1.22 > > > On N1, the scalarized sequence of `fadd/fmul` are generated for both `MaxVectorSize` of 8B and 16B for add reduction ... I see now the flags are not triviall: -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressArrayCopyMacroNode -XX:+StressLCM -XX:+StressGCM -XX:+StressIGVN -XX:+StressCCP -XX:+StressMacroExpansion -XX:+StressMethodHandleLinkerInlining -XX:+StressCompiledExceptionHandlers -XX:VerifyConstraintCasts=1 -XX:+StressLoopPeeling a lot of stress file. It's likely that many runs might be needed to reproduce. The machine is a VM.Standard.A1.Flex shape, as described in https://docs.oracle.com/en-us/iaas/Content/Compute/References/computeshapes.htm Backtrace at the failure: Current CompileTask: C2:1523 346 % b compiler.vectorization.TestFloat16VectorOperations::vectorAddReductionFloat16 @ 4 (39 bytes) Stack: [0x0000ffff84799000,0x0000ffff84997000], sp=0x0000ffff849920d0, free space=2020k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x7da724] C2_MacroAssembler::neon_reduce_add_fp16(FloatRegister, FloatRegister, FloatRegister, unsigned int, FloatRegister)+0x2b4 (c2_MacroAssembler_aarch64.cpp:1930) V [libjvm.so+0x154492c] PhaseOutput::scratch_emit_size(Node const*)+0x2ec (output.cpp:3171) V [libjvm.so+0x153d4a4] PhaseOutput::shorten_branches(unsigned int*)+0x2e4 (output.cpp:528) V [libjvm.so+0x154dcdc] PhaseOutput::Output()+0x95c (output.cpp:328) V [libjvm.so+0x9be070] Compile::Code_Gen()+0x7f0 (compile.cpp:3127) V [libjvm.so+0x9c21c0] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1774 (compile.cpp:894) V [libjvm.so+0x7eec64] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x2e0 (c2compiler.cpp:147) V [libjvm.so+0x9d0f8c] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb08 (compileBroker.cpp:2345) V [libjvm.so+0x9d1eb8] CompileBroker::compiler_thread_loop()+0x638 (compileBroker.cpp:1989) V [libjvm.so+0xed25a8] JavaThread::thread_main_inner()+0x108 (javaThread.cpp:775) V [libjvm.so+0x18466dc] Thread::call_run()+0xac (thread.cpp:243) V [libjvm.so+0x152349c] thread_native_entry(Thread*)+0x12c (os_linux.cpp:895) C [libc.so.6+0x80b50] start_thread+0x300 I've attached the replay file in the JBS issue, if it can help. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3361203842 From rriggs at openjdk.org Thu Oct 2 13:26:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Oct 2025 13:26:52 GMT Subject: RFR: 8368172: Make java.time.format.DateTimePrintContext immutable [v6] In-Reply-To: <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com> References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com> <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com> Message-ID: On Thu, 2 Oct 2025 03:08:32 GMT, Shaojin Wen wrote: >> I propose to make j.t.f.DateTimePrintContext immutable. >> >> Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method. >> >> Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Improve javadoc for optional parameter in DateTimePrinterParser#format method And one more thought/question: The optionality of formatting is a parameter used in the traversal of the formatting and parsing and affect nested formatting calls. The DateTimePrintContext previously counts the depth of the nesting with >0 indicating optional. It is the component that determines (based on optional:true) whether an absent value throws. Was it considered to change DateTimePrinterContext.optional to `final boolean optional` and create a second instance with optional=true. Only the CompositePrinterParser changes the state to indicate that nested PrinterParsers are optional. CompositePrinterParser could substitute the optional DateTimePrintContext. That would be closer to the current design and if allow it to be immutable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26913#issuecomment-3361215508 From swen at openjdk.org Thu Oct 2 13:35:14 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 2 Oct 2025 13:35:14 GMT Subject: Integrated: 8368825: Use switch expression for DateTimeFormatterBuilder pattern character lookup In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 01:42:53 GMT, Shaojin Wen wrote: > The DateTimeFormatterBuilder::FIELD_MAP previously used a Map for mapping pattern characters to TemporalField > instances. This PR refactors that implementation to use a switch expression instead, which eliminates the need to hold a Map in > memory. > > The switch expression approach offers these advantages: > - No memory overhead for maintaining a HashMap structure > - More direct character-to-field mapping without hash computation > - Better code readability and maintainability > > This change maintains the same functionality while improving the memory efficiency of pattern character lookup in > DateTimeFormatterBuilder by eliminating the static Map that was previously used for character-to-field mapping. > > * before > image This pull request has now been integrated. Changeset: 2c7f7380 Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/2c7f7380ea828e5ec928e1cb05b13806646ecb3d Stats: 49 lines in 1 file changed: 7 ins; 0 del; 42 mod 8368825: Use switch expression for DateTimeFormatterBuilder pattern character lookup Reviewed-by: rriggs, naoto, scolebourne ------------- PR: https://git.openjdk.org/jdk/pull/26634 From bkilambi at openjdk.org Thu Oct 2 13:39:50 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 2 Oct 2025 13:39:50 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: <98jWF_NhAAB1WHHsotReB6SYIVSRIWNO0rmhxnNMJM8=.f21f3406-f3b3-4ce5-b009-6e50e2ebe1f1@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> <98jWF_NhAAB1WHHsotReB6SYIVSRIWNO0rmhxnNMJM8=.f21f3406-f3b3-4ce5-b009-6e50e2ebe1f1@github.com> Message-ID: On Thu, 2 Oct 2025 13:21:32 GMT, Marc Chevalier wrote: >> This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species. >> >> Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets - >> >> **For AddReduction :** >> On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction. >> >> On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order. >> >> **For MulReduction :** >> Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported. >> >> Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` - >> >> Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch. >> Ratio > 1 indicates the performance with this patch is better than the master branch. >> >> **N1 (UseSVE = 0, max vector length = 16B):** >> >> Benchmark vectorDim Mode Cnt 8B 16B >> ReductionAddFP16 256 thrpt 9 1.41 1.40 >> ReductionAddFP16 512 thrpt 9 1.41 1.41 >> ReductionAddFP16 1024 thrpt 9 1.43 1.40 >> ReductionAddFP16 2048 thrpt 9 1.43 1.40 >> ReductionMulFP16 256 thrpt 9 1.22 1.22 >> ReductionMulFP16 512 thrpt 9 1.21 1.23 >> ReductionMulFP16 1024 thrpt 9 1.21 1.22 >> ReductionMulFP16 2048 thrpt 9 1.20 1.22 >> >> >> On N1, the scalarized sequence of `fadd/fmul` are gener... > > I see now the flags are not triviall: > > -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressArrayCopyMacroNode -XX:+StressLCM -XX:+StressGCM -XX:+StressIGVN -XX:+StressCCP -XX:+StressMacroExpansion -XX:+StressMethodHandleLinkerInlining -XX:+StressCompiledExceptionHandlers -XX:VerifyConstraintCasts=1 -XX:+StressLoopPeeling > > a lot of stress file. It's likely that many runs might be needed to reproduce. > > The machine is a VM.Standard.A1.Flex shape, as described in > https://docs.oracle.com/en-us/iaas/Content/Compute/References/computeshapes.htm > > Backtrace at the failure: > > Current CompileTask: > C2:1523 346 % b compiler.vectorization.TestFloat16VectorOperations::vectorAddReductionFloat16 @ 4 (39 bytes) > > Stack: [0x0000ffff84799000,0x0000ffff84997000], sp=0x0000ffff849920d0, free space=2020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x7da724] C2_MacroAssembler::neon_reduce_add_fp16(FloatRegister, FloatRegister, FloatRegister, unsigned int, FloatRegister)+0x2b4 (c2_MacroAssembler_aarch64.cpp:1930) > V [libjvm.so+0x154492c] PhaseOutput::scratch_emit_size(Node const*)+0x2ec (output.cpp:3171) > V [libjvm.so+0x153d4a4] PhaseOutput::shorten_branches(unsigned int*)+0x2e4 (output.cpp:528) > V [libjvm.so+0x154dcdc] PhaseOutput::Output()+0x95c (output.cpp:328) > V [libjvm.so+0x9be070] Compile::Code_Gen()+0x7f0 (compile.cpp:3127) > V [libjvm.so+0x9c21c0] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1774 (compile.cpp:894) > V [libjvm.so+0x7eec64] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x2e0 (c2compiler.cpp:147) > V [libjvm.so+0x9d0f8c] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb08 (compileBroker.cpp:2345) > V [libjvm.so+0x9d1eb8] CompileBroker::compiler_thread_loop()+0x638 (compileBroker.cpp:1989) > V [libjvm.so+0xed25a8] JavaThread::thread_main_inner()+0x108 (javaThread.cpp:775) > V [libjvm.so+0x18466dc] Thread::call_run()+0xac (thread.cpp:243) > V [libjvm.so+0x152349c] thread_native_entry(Thread*)+0x12c (os_linux.cpp:895) > C [libc.so.6+0x80b50] start_thread+0x300 > > > I've attached the replay file in the JBS issue, if it can help. @marc-chevalier Thanks! I have now been able to reproduce it using the flags you shared. Will update my patch soon with a fix for this along with addressing other review comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3361263768 From swen at openjdk.org Thu Oct 2 13:39:52 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 2 Oct 2025 13:39:52 GMT Subject: RFR: 8368172: Make java.time.format.DateTimePrintContext immutable [v6] In-Reply-To: References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com> <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com> Message-ID: <2vNtq03FnpQvKBx4QnRGZGyilEoIcgHRv_SoxPneE3U=.6e1c2c8f-8a89-482c-b2c6-8484ac6cd64b@github.com> On Thu, 2 Oct 2025 13:24:25 GMT, Roger Riggs wrote: > And one more thought/question: The optionality of formatting is a parameter used in the traversal of the formatting and parsing and affect nested formatting calls. The DateTimePrintContext previously counts the depth of the nesting with >0 indicating optional. It is the component that determines (based on optional:true) whether an absent value throws. Was it considered to change DateTimePrinterContext.optional to `final boolean optional` and create a second instance with optional=true. > > Only the CompositePrinterParser changes the state to indicate that nested PrinterParsers are optional. CompositePrinterParser could substitute the optional DateTimePrintContext. That would be closer to the current design and if allow it to be immutable. It seems strange that the formatting process creates a new DateTimePrintContext object. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26913#issuecomment-3361262924 From abarashev at openjdk.org Thu Oct 2 13:45:57 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 2 Oct 2025 13:45:57 GMT Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 11:29:12 GMT, Matthew Donovan wrote: > > I think we should either implement a public API to provide those signature schemes or not display them at all to avoid any confusion. If someone sets `jdk.tls.client.SignatureSchemes` system property they would sure know about it. That property overrides all other signature schemes for both "signature_algorithms" and "signature_algorithms_cert" extensions. > > I removed the signature algorithms from this output. If accurate lists aren't generated until TLS handshake, then I don't think there's any reason to print a list here. Sounds good. I've created [JDK-8366364](https://bugs.openjdk.org/browse/JDK-8366364) to address this problem. Once it's done we can include signature algorithms in the output. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3361286352 From rriggs at openjdk.org Thu Oct 2 14:24:23 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Oct 2025 14:24:23 GMT Subject: RFR: 8368172: Make java.time.format.DateTimePrintContext immutable [v6] In-Reply-To: <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com> References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com> <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com> Message-ID: On Thu, 2 Oct 2025 03:08:32 GMT, Shaojin Wen wrote: >> I propose to make j.t.f.DateTimePrintContext immutable. >> >> Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method. >> >> Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Improve javadoc for optional parameter in DateTimePrinterParser#format method The DateTimePrintContext is exactly that, providing the context for the formatting. It holds the references to the Temporal that has the value and the appendable that is the destination. And in the committed implementation holds the current optional count/flag. If its is to be immutable, then you need to create a second one and pass it down to/through format(). It will be a small, short lived object. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26913#issuecomment-3361450548 From myankelevich at openjdk.org Thu Oct 2 14:31:30 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 2 Oct 2025 14:31:30 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao wrote: >> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip) >> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory. >> >> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE. >> >> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java. >> >> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference. > > Weibing Xiao has updated the pull request incrementally with two additional commits since the last revision: > > - remove unused code > - removed the commented out code test/jdk/com/sun/jndi/ldap/SocketCloseTest.java line 143: > 141: } > 142: > 143: private static class CustomSocket extends Socket { minor: could you please cleanup unused imports after this change? test/jdk/com/sun/jndi/ldap/SocketCloseTest.java line 144: > 142: private static class CustomSocket extends Socket { > 143: private int closeMethodCalled = 0; > 144: private LdapOutputStream output = new LdapOutputStream(); I believe these are local objects which are no longer used after removal of this. I'd personally remove the `private static class LdapInputStream extends InputStream {` and `private static class LdapOutputStream extends OutputStream {` further down the file ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2399024192 PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2399032966 From swen at openjdk.org Thu Oct 2 14:36:17 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 2 Oct 2025 14:36:17 GMT Subject: RFR: 8368172: Make java.time.format.DateTimePrintContext immutable [v6] In-Reply-To: <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com> References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com> <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com> Message-ID: On Thu, 2 Oct 2025 03:08:32 GMT, Shaojin Wen wrote: >> I propose to make j.t.f.DateTimePrintContext immutable. >> >> Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method. >> >> Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Improve javadoc for optional parameter in DateTimePrinterParser#format method Creating a DateTimePrintContext during the formatting process also has a disadvantage: it is difficult to perform manual unrolling performance optimizations like the draft PR #26807 I submitted, and it also makes automatic unrolling by the C2 JIT more difficult. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26913#issuecomment-3361498045 From rriggs at openjdk.org Thu Oct 2 14:45:03 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Oct 2025 14:45:03 GMT Subject: RFR: 8369027: Apply java.io.Serial annotations in java.scripting In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 22:31:42 GMT, Sergey Bylokhov wrote: > Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.scripting module to enable stricter compile-time checking of serialization-related declarations. > > The patch is trivial, only one class needs to be updated. > > Example of a similar change https://github.com/openjdk/jdk/pull/26208. Looks good. And trivial. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27599#pullrequestreview-3294984069 From rriggs at openjdk.org Thu Oct 2 15:05:59 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Oct 2025 15:05:59 GMT Subject: RFR: 8368981: Case Fold Locale Legacy Tags On Demand [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 22:51:30 GMT, Justin Lu wrote: >> Please review this PR which case folds grandfathered BCP47 tags on demand. (Instead of keeping the case compliant versions stored.) >> >> This facilitates the cleanup of the `LEGACY` map (which contains a String to String Array mapping). The 2D String array, creation and populating of the `LEGACY` map, as well as lower case folding of the legacy tags can now be removed from the static block of _sun.util.locale.LanguageTag_. >> >> Legacy tags are a small subset compared to the entire set of valid BCP47 tags. Reducing the cost for supporting them would be ideal. Instead, legacy tags can now be checked against and folded on demand via a switch statement. >> >> The commented grandfathered syntax is removed because the values themselves already exist as code, and the exact case can be found in the provided RFC link. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > implemenet Naoto's review src/java.base/share/classes/sun/util/locale/LanguageTag.java line 345: > 343: } > 344: } > 345: bldr.deleteCharAt(bldr.length() - 1); // Remove trailing '-' `bldr.setLength(bldr.length() - 1)` might be better? src/java.base/share/classes/sun/util/locale/LanguageTag.java line 516: > 514: if (tag.length() > 11 || tag.length() < 5) { > 515: return null; > 516: } I can see the < 5 having some saving if most of the tags are short. I doubt the > 11 saves anything and it creates a maintenance gotcha, if a tag is added that is longer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27596#discussion_r2399143786 PR Review Comment: https://git.openjdk.org/jdk/pull/27596#discussion_r2399105662 From rriggs at openjdk.org Thu Oct 2 15:13:24 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Oct 2025 15:13:24 GMT Subject: RFR: 8368172: Make java.time.format.DateTimePrintContext immutable [v6] In-Reply-To: <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com> References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com> <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com> Message-ID: On Thu, 2 Oct 2025 03:08:32 GMT, Shaojin Wen wrote: >> I propose to make j.t.f.DateTimePrintContext immutable. >> >> Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method. >> >> Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Improve javadoc for optional parameter in DateTimePrinterParser#format method I beginning to get concerned about the bloat in code cache created by this line of inquiry in the quest for microbenchmark performance. In cloud deployments, extra memory costs money. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26913#issuecomment-3361663586 From henryjen at openjdk.org Thu Oct 2 15:40:46 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 2 Oct 2025 15:40:46 GMT Subject: RFR: 8347007: --strip-debug removes parameter names included with -parameters [v2] In-Reply-To: <6sINPIjIQYrD8qnU5q_meoNELGlIYNLdQ1Va3lbXwSY=.4b5e4086-c4b0-4320-a27f-7d0c90b1a5dd@github.com> References: <6sINPIjIQYrD8qnU5q_meoNELGlIYNLdQ1Va3lbXwSY=.4b5e4086-c4b0-4320-a27f-7d0c90b1a5dd@github.com> Message-ID: On Tue, 30 Sep 2025 06:28:18 GMT, Hannes Greule wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Support optional argument for PluginOptions > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripJavaDebugAttributesPlugin.java line 113: > >> 111: MethodTransform mt; >> 112: if (isDroppingMethodNames) { >> 113: mt = MethodTransform.dropping(me -> me instanceof MethodParametersAttribute) > > I know this is already existing behavior, but removing the attribute doesn't just remove the parameter names but also the parameter flags. This results in the same bug that was fixed by https://bugs.openjdk.org/browse/JDK-8292275 (or for a more compact description, see the CSR https://bugs.openjdk.org/browse/JDK-8292467). > > But that should be addressed separately. Thank you for bring in this up. Do not support removal of MethodParameters attribute for now. If there is a need to support that, we can add a separate plugin to address optional attributes for JVM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2399249922 From alanb at openjdk.org Thu Oct 2 15:45:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Oct 2025 15:45:53 GMT Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work as expected [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 20:00:09 GMT, Chen Liang wrote: >> Xueming Shen 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: >> >> 8365588: defineClass that accepts a ByteBuffer does not work as expected > > src/java.base/share/classes/java/lang/ClassLoader.java line 1069: > >> 1067: try (var arena = Arena.ofConfined()) { >> 1068: ByteBuffer bb = arena.allocate(len).asByteBuffer(); >> 1069: bb.put(0, b, b.position(), len); > > Do we need to acquire/release session on the base buffer too? Good question but no, this buffer comes from a thread confined arena so it can't be closed asynchronously. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2399261537 From rriggs at openjdk.org Thu Oct 2 15:47:02 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Oct 2025 15:47:02 GMT Subject: RFR: 8356202: Cleanup Source code in String Implementation Classes Message-ID: Code cleanup in java.lang.StringLatin1 and StringUTF16. Remove the `public` qualifier from methods where it is not needed. Remove an unused toBytes method. Remove unused codePointXXX methods. Remove unnecessary casts of primitive types. Some of these are suggested by IntelliJ, if the advice should not be taken, I'll revert and update the IDE settings. ------------- Commit messages: - Remove unnecessary casts. - 8356202: Cleanup public modifiers in String implementation classes Changes: https://git.openjdk.org/jdk/pull/27609/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27609&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356202 Stats: 149 lines in 2 files changed: 0 ins; 31 del; 118 mod Patch: https://git.openjdk.org/jdk/pull/27609.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27609/head:pull/27609 PR: https://git.openjdk.org/jdk/pull/27609 From liach at openjdk.org Thu Oct 2 16:03:27 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 2 Oct 2025 16:03:27 GMT Subject: RFR: 8356202: Cleanup Source code in String Implementation Classes In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 15:39:51 GMT, Roger Riggs wrote: > Code cleanup in java.lang.StringLatin1 and StringUTF16. > Remove the `public` qualifier from methods where it is not needed. > Remove an unused toBytes method. > Remove unused codePointXXX methods. > Remove unnecessary casts of primitive types. > > Some of these are suggested by IntelliJ, if the advice should not be taken, I'll revert and update the IDE settings. src/java.base/share/classes/java/lang/StringLatin1.java line 367: > 365: } > 366: > 367: // case in-sensitive I think we use insensitive without a dash: https://www.dictionary.com/browse/insensitive ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2399313326 From naoto at openjdk.org Thu Oct 2 16:08:33 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 2 Oct 2025 16:08:33 GMT Subject: RFR: 8368981: Case Fold Locale Legacy Tags On Demand [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 14:52:20 GMT, Roger Riggs wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> implemenet Naoto's review > > src/java.base/share/classes/sun/util/locale/LanguageTag.java line 516: > >> 514: if (tag.length() > 11 || tag.length() < 5) { >> 515: return null; >> 516: } > > I can see the < 5 having some saving if most of the tags are short. > I doubt the > 11 saves anything and it creates a maintenance gotcha, if a tag is added that is longer. Per RFC, it is guaranteed that the list of the grandfathered (=legacy) tags will never change (https://datatracker.ietf.org/doc/html/rfc5646#section-2.1) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27596#discussion_r2399329170 From rriggs at openjdk.org Thu Oct 2 16:17:32 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Oct 2025 16:17:32 GMT Subject: RFR: 8356202: Cleanup Source code in String Implementation Classes [v2] In-Reply-To: References: Message-ID: > Code cleanup in java.lang.StringLatin1 and StringUTF16. > Remove the `public` qualifier from methods where it is not needed. > Remove an unused toBytes method. > Remove unused codePointXXX methods. > Remove unnecessary casts of primitive types. > > Some of these are suggested by IntelliJ, if the advice should not be taken, I'll revert and update the IDE settings. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Revert to insensitive. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27609/files - new: https://git.openjdk.org/jdk/pull/27609/files/c5099b86..06822b94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27609&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27609&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27609.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27609/head:pull/27609 PR: https://git.openjdk.org/jdk/pull/27609 From rgiulietti at openjdk.org Thu Oct 2 16:17:35 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 2 Oct 2025 16:17:35 GMT Subject: RFR: 8356202: Cleanup Source code in String Implementation Classes [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 16:14:45 GMT, Roger Riggs wrote: >> Code cleanup in java.lang.StringLatin1 and StringUTF16. >> Remove the `public` qualifier from methods where it is not needed. >> Remove an unused toBytes method. >> Remove unused codePointXXX methods. >> Remove unnecessary casts of primitive types. >> >> Some of these are suggested by IntelliJ, if the advice should not be taken, I'll revert and update the IDE settings. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert to insensitive. src/java.base/share/classes/java/lang/StringLatin1.java line 217: > 215: > 216: @IntrinsicCandidate > 217: static int indexOf(byte[] value, int valueCount, byte[] str, int strCount, int fromIndex) { I guess that removing `public` needs no changes in the intrinsic implementation? src/java.base/share/classes/java/lang/StringLatin1.java line 367: > 365: } > 366: > 367: // case in-sensitive What's wrong with the original `case insensitive`? I checked in online dictionaries, "insensitive" is correct, despite what the IDE reports. src/java.base/share/classes/java/lang/StringUTF16.java line 542: > 540: } > 541: > 542: // Case in-sensitive comparison of two code points Same as above ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2399322327 PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2399323804 PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2399340946 From wxiao at openjdk.org Thu Oct 2 16:19:56 2025 From: wxiao at openjdk.org (Weibing Xiao) Date: Thu, 2 Oct 2025 16:19:56 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v4] In-Reply-To: References: Message-ID: <18wOsB1ycd6JEaIieaDFcDhoJMedcBTokO6gowhWLGA=.2098adf5-96b3-41fa-a9c3-6cc7d1af7398@github.com> > [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip) > NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory. > > When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE. > > The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java. > > No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference. Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: update the code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26566/files - new: https://git.openjdk.org/jdk/pull/26566/files/dd21da3e..77b418d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26566&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26566&range=02-03 Stats: 35 lines in 3 files changed: 4 ins; 31 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26566/head:pull/26566 PR: https://git.openjdk.org/jdk/pull/26566 From rriggs at openjdk.org Thu Oct 2 16:23:45 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Oct 2025 16:23:45 GMT Subject: RFR: 8356202: Cleanup Source code in String Implementation Classes [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 16:02:56 GMT, Raffaello Giulietti wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert to insensitive. > > src/java.base/share/classes/java/lang/StringLatin1.java line 217: > >> 215: >> 216: @IntrinsicCandidate >> 217: static int indexOf(byte[] value, int valueCount, byte[] str, int strCount, int fromIndex) { > > I guess that removing `public` needs no changes in the intrinsic implementation? The linkage is based on the signature, not the access. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2399361294 From darcy at openjdk.org Thu Oct 2 16:29:05 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Oct 2025 16:29:05 GMT Subject: RFR: 8369051: More small Float16 refactorings Message-ID: As a follow-up to https://git.openjdk.org/jdk/pull/27587, I went through the code of Float16.java and found a few more cases where hex integer constants could be replaced by symbolic constants. A few other small changes included too. ------------- Commit messages: - JDK-8369051: More small Float16 refactorings Changes: https://git.openjdk.org/jdk/pull/27610/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27610&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369051 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27610.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27610/head:pull/27610 PR: https://git.openjdk.org/jdk/pull/27610 From rgiulietti at openjdk.org Thu Oct 2 16:29:35 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 2 Oct 2025 16:29:35 GMT Subject: RFR: 8356202: Cleanup Source code in String Implementation Classes [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 16:17:32 GMT, Roger Riggs wrote: >> Code cleanup in java.lang.StringLatin1 and StringUTF16. >> Remove the `public` qualifier from methods where it is not needed. >> Remove an unused toBytes method. >> Remove unused codePointXXX methods. >> Remove unnecessary casts of primitive types. >> >> Some of these are suggested by IntelliJ, if the advice should not be taken, I'll revert and update the IDE settings. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert to insensitive. Cleanups are always nice. Thanks Roger! ------------- Marked as reviewed by rgiulietti (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27609#pullrequestreview-3295419229 From rgiulietti at openjdk.org Thu Oct 2 16:38:34 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 2 Oct 2025 16:38:34 GMT Subject: RFR: 8369051: More small Float16 refactorings In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 16:22:56 GMT, Joe Darcy wrote: > As a follow-up to https://git.openjdk.org/jdk/pull/27587, I went through the code of Float16.java and found a few more cases where hex integer constants could be replaced by symbolic constants. A few other small changes included too. Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27610#pullrequestreview-3295444438 From darcy at openjdk.org Thu Oct 2 16:45:51 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Oct 2025 16:45:51 GMT Subject: Integrated: 8369051: More small Float16 refactorings In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 16:22:56 GMT, Joe Darcy wrote: > As a follow-up to https://git.openjdk.org/jdk/pull/27587, I went through the code of Float16.java and found a few more cases where hex integer constants could be replaced by symbolic constants. A few other small changes included too. This pull request has now been integrated. Changeset: 3d113af9 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/3d113af9e33ddf3d80452cb72f1b47b4936ec6a0 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8369051: More small Float16 refactorings Reviewed-by: rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/27610 From jlu at openjdk.org Thu Oct 2 16:58:41 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 2 Oct 2025 16:58:41 GMT Subject: RFR: 8368981: Case Fold Locale Legacy Tags On Demand [v3] In-Reply-To: References: Message-ID: > Please review this PR which case folds grandfathered BCP47 tags on demand. (Instead of keeping the case compliant versions stored.) > > This facilitates the cleanup of the `LEGACY` map (which contains a String to String Array mapping). The 2D String array, creation and populating of the `LEGACY` map, as well as lower case folding of the legacy tags can now be removed from the static block of _sun.util.locale.LanguageTag_. > > Legacy tags are a small subset compared to the entire set of valid BCP47 tags. Reducing the cost for supporting them would be ideal. Instead, legacy tags can now be checked against and folded on demand via a switch statement. > > The commented grandfathered syntax is removed because the values themselves already exist as code, and the exact case can be found in the provided RFC link. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Implement Roger's review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27596/files - new: https://git.openjdk.org/jdk/pull/27596/files/3720e24a..fb6b1dcc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27596&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27596&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27596.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27596/head:pull/27596 PR: https://git.openjdk.org/jdk/pull/27596 From jlu at openjdk.org Thu Oct 2 16:58:43 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 2 Oct 2025 16:58:43 GMT Subject: RFR: 8368981: Case Fold Locale Legacy Tags On Demand [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 16:06:07 GMT, Naoto Sato wrote: >> src/java.base/share/classes/sun/util/locale/LanguageTag.java line 516: >> >>> 514: if (tag.length() > 11 || tag.length() < 5) { >>> 515: return null; >>> 516: } >> >> I can see the < 5 having some saving if most of the tags are short. >> I doubt the > 11 saves anything and it creates a maintenance gotcha, if a tag is added that is longer. > > Per RFC, it is guaranteed that the list of the grandfathered (=legacy) tags will never change (https://datatracker.ietf.org/doc/html/rfc5646#section-2.1) Right, the reason we can have confidence in this shortcut check is that the list is specified to be stable. However, if there is likely no save on cost, then we can remove it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27596#discussion_r2399453184 From liach at openjdk.org Thu Oct 2 17:08:18 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 2 Oct 2025 17:08:18 GMT Subject: RFR: 8356202: Cleanup Source code in String Implementation Classes [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 16:17:32 GMT, Roger Riggs wrote: >> Code cleanup in java.lang.StringLatin1 and StringUTF16. >> Remove the `public` qualifier from methods where it is not needed. >> Remove an unused toBytes method. >> Remove unused codePointXXX methods. >> Remove unnecessary casts of primitive types. >> >> Some of these are suggested by IntelliJ, if the advice should not be taken, I'll revert and update the IDE settings. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert to insensitive. Looks good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27609#pullrequestreview-3295577519 From bpb at openjdk.org Thu Oct 2 17:35:58 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 2 Oct 2025 17:35:58 GMT Subject: RFR: 8191963: Path.equals() and File.equals() return true for two different files on Windows In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 13:26:54 GMT, Alan Bateman wrote: > [...] changing File means working through the compatibility impact [...] It's probably not enough, but: - `java.io.WinNTFileSystem.compare(File,File)` is invoked only by `File.equals`. - Tier 1-3 tests passed in the mainline CI with this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25788#issuecomment-3362293619 From rriggs at openjdk.org Thu Oct 2 19:49:47 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Oct 2025 19:49:47 GMT Subject: RFR: 8368981: Case Fold Locale Legacy Tags On Demand [v3] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 16:58:41 GMT, Justin Lu wrote: >> Please review this PR which case folds grandfathered BCP47 tags on demand. (Instead of keeping the case compliant versions stored.) >> >> This facilitates the cleanup of the `LEGACY` map (which contains a String to String Array mapping). The 2D String array, creation and populating of the `LEGACY` map, as well as lower case folding of the legacy tags can now be removed from the static block of _sun.util.locale.LanguageTag_. >> >> Legacy tags are a small subset compared to the entire set of valid BCP47 tags. Reducing the cost for supporting them would be ideal. Instead, legacy tags can now be checked against and folded on demand via a switch statement. >> >> The commented grandfathered syntax is removed because the values themselves already exist as code, and the exact case can be found in the provided RFC link. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Implement Roger's review LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27596#pullrequestreview-3296165026 From bpb at openjdk.org Thu Oct 2 20:13:38 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 2 Oct 2025 20:13:38 GMT Subject: RFR: 8191963: Path.equals() and File.equals() return true for two different files on Windows [v2] In-Reply-To: References: Message-ID: > Replace logic in `java.io.WinNTFileSystems.compare(File,File)` with that from `sun.nio.fs.WindowsPath.compareTo(Path)`. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - 8191963: Add system property to enable legacy behavior - Merge - 8191963: Path.equals() and File.equals() return true for two different files on Windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25788/files - new: https://git.openjdk.org/jdk/pull/25788/files/cc4cef65..a63e13e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25788&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25788&range=00-01 Stats: 344119 lines in 5510 files changed: 239196 ins; 69265 del; 35658 mod Patch: https://git.openjdk.org/jdk/pull/25788.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25788/head:pull/25788 PR: https://git.openjdk.org/jdk/pull/25788 From bpb at openjdk.org Thu Oct 2 20:13:39 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 2 Oct 2025 20:13:39 GMT Subject: RFR: 8191963: Path.equals() and File.equals() return true for two different files on Windows In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 13:26:54 GMT, Alan Bateman wrote: > [...] system property to restore long standing behavior. Added in a63e13e. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25788#issuecomment-3362756138 From joehw at openjdk.org Fri Oct 3 03:53:05 2025 From: joehw at openjdk.org (Joe Wang) Date: Fri, 3 Oct 2025 03:53:05 GMT Subject: RFR: 8336695: Update Commons BCEL to Version 6.10.0 In-Reply-To: References: Message-ID: <6UL10SYr5G890rfretlI_p9x6bldmb5M962iEkmEnnk=.375cc226-b76a-4a89-9d6f-92b4946c623f@github.com> On Tue, 23 Sep 2025 21:11:07 GMT, Joe Wang wrote: > Update Commons BCEL to Version 6.10.0. > > Test: T1-3 passed Thanks all for reviewing the changes. Re-run Tier 1-3 and JCK, all tests passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27459#issuecomment-3364152492 From joehw at openjdk.org Fri Oct 3 03:53:07 2025 From: joehw at openjdk.org (Joe Wang) Date: Fri, 3 Oct 2025 03:53:07 GMT Subject: Integrated: 8336695: Update Commons BCEL to Version 6.10.0 In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 21:11:07 GMT, Joe Wang wrote: > Update Commons BCEL to Version 6.10.0. > > Test: T1-3 passed This pull request has now been integrated. Changeset: 3790965d Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/3790965df3e7cba3b9792b8719d1e2ead046da15 Stats: 2579 lines in 122 files changed: 1451 ins; 118 del; 1010 mod 8336695: Update Commons BCEL to Version 6.10.0 Reviewed-by: lancea, naoto, iris ------------- PR: https://git.openjdk.org/jdk/pull/27459 From jpai at openjdk.org Fri Oct 3 05:52:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 3 Oct 2025 05:52:46 GMT Subject: RFR: 8356202: Cleanup Source code in String Implementation Classes [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 16:17:32 GMT, Roger Riggs wrote: >> Code cleanup in java.lang.StringLatin1 and StringUTF16. >> Remove the `public` qualifier from methods where it is not needed. >> Remove an unused toBytes method. >> Remove unused codePointXXX methods. >> Remove unnecessary casts of primitive types. >> >> Some of these are suggested by IntelliJ, if the advice should not be taken, I'll revert and update the IDE settings. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert to insensitive. Hello Roger, it looks like in `StringUTF16` the `public` from `public static String newString(byte[] val, int index, int len)` can be removed too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27609#issuecomment-3364353805 From thartmann at openjdk.org Fri Oct 3 08:41:54 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 3 Oct 2025 08:41:54 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v11] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 20:44:54 GMT, Jatin Bhateja wrote: >> This patch optimizes PopCount value transforms using KnownBits information. >> Following are the results of the micro-benchmark included with the patch >> >> >> >> System: 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark Mode Cnt Score Error Units >> PopCountValueTransform.LogicFoldingKerenLong thrpt 2 215460.670 ops/s >> PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 294014.826 ops/s >> >> Withopt: >> Benchmark Mode Cnt Score Error Units >> PopCountValueTransform.LogicFoldingKerenLong thrpt 2 389978.082 ops/s >> PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 417261.583 ops/s >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Update countbitsnode.cpp I submitted testing for this and will report back once it finished. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27075#issuecomment-3364792311 From swen at openjdk.org Fri Oct 3 09:10:46 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 3 Oct 2025 09:10:46 GMT Subject: RFR: 8368172: Make java.time.format.DateTimePrintContext immutable [v6] In-Reply-To: References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com> <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com> Message-ID: <_6CJOczFmBqEl2qBXgJEYoj3jc9RxAfhN-ieR92zRAw=.0fc6f1e5-5653-4ca4-8db5-58a860002e04@github.com> On Thu, 2 Oct 2025 15:11:05 GMT, Roger Riggs wrote: > I beginning to get concerned about the bloat in code cache created by this line of inquiry in the quest for microbenchmark performance. In cloud deployments, extra memory costs money. When the CodeCache memory space is insufficient, the JIT will discard the oldest compiled methods that are not currently in the execution stack; I think we don't need to worry about this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26913#issuecomment-3364888865 From prappo at openjdk.org Fri Oct 3 09:50:23 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 3 Oct 2025 09:50:23 GMT Subject: RFR: 8366829: Add constants for the Duration MIN/MAX values [v3] In-Reply-To: References: Message-ID: > We have [recently discussed][] a possibility of adding the `Duration.MIN` and `Duration.MAX` constants. Can we now start implementation? If and when we are in agreement on this PR, I will file a CSR. > > I drafted a minimal specification and added some tests. I tried to phrase the spec for `Duration.MIN` in a way that makes it clear that `Duration.MIN` is the most negative value and not the least positive. > > [recently discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Respond to feedback Apply Stephen's suggestion on wording, although modified. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27534/files - new: https://git.openjdk.org/jdk/pull/27534/files/c5a3f228..abe01ff5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27534&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27534&range=01-02 Stats: 18 lines in 1 file changed: 2 ins; 1 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/27534.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27534/head:pull/27534 PR: https://git.openjdk.org/jdk/pull/27534 From qamai at openjdk.org Fri Oct 3 12:17:51 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 3 Oct 2025 12:17:51 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v11] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 20:44:54 GMT, Jatin Bhateja wrote: >> This patch optimizes PopCount value transforms using KnownBits information. >> Following are the results of the micro-benchmark included with the patch >> >> >> >> System: 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark Mode Cnt Score Error Units >> PopCountValueTransform.LogicFoldingKerenLong thrpt 2 215460.670 ops/s >> PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 294014.826 ops/s >> >> Withopt: >> Benchmark Mode Cnt Score Error Units >> PopCountValueTransform.LogicFoldingKerenLong thrpt 2 389978.082 ops/s >> PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 417261.583 ops/s >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Update countbitsnode.cpp src/hotspot/share/opto/countbitsnode.cpp line 145: > 143: } > 144: KnownBits bits = t->isa_int()->_bits; > 145: return TypeInt::make(population_count(bits._ones), population_count(~bits._zeros), Type::WidenMax); The `widen` of the output should be the same as the `widen` of the input, not `WidenMax` here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27075#discussion_r2401703583 From aturbanov at openjdk.org Fri Oct 3 13:08:02 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 3 Oct 2025 13:08:02 GMT Subject: RFR: 8356202: Cleanup Source code in String Implementation Classes [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 16:17:32 GMT, Roger Riggs wrote: >> Code cleanup in java.lang.StringLatin1 and StringUTF16. >> Remove the `public` qualifier from methods where it is not needed. >> Remove an unused toBytes method. >> Remove unused codePointXXX methods. >> Remove unnecessary casts of primitive types. >> >> Some of these are suggested by IntelliJ, if the advice should not be taken, I'll revert and update the IDE settings. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert to insensitive. src/java.base/share/classes/java/lang/StringLatin1.java line 240: > 238: > 239: static int lastIndexOf(byte[] src, int srcCount, > 240: byte[] tgt, int tgtCount, int fromIndex) { let's fix alignment src/java.base/share/classes/java/lang/StringLatin1.java line 318: > 316: > 317: static String replace(byte[] value, int valLen, byte[] targ, > 318: int targLen, byte[] repl, int replLen) let's align parameters src/java.base/share/classes/java/lang/StringLatin1.java line 369: > 367: // case insensitive > 368: static boolean regionMatchesCI(byte[] value, int toffset, > 369: byte[] other, int ooffset, int len) { let's align parameters src/java.base/share/classes/java/lang/StringLatin1.java line 383: > 381: > 382: static boolean regionMatchesCI_UTF16(byte[] value, int toffset, > 383: byte[] other, int ooffset, int len) { let's align parameters src/java.base/share/classes/java/lang/StringUTF16.java line 734: > 732: // srcCoder == UTF16 && tgtCoder == UTF16 > 733: static int lastIndexOf(byte[] src, int srcCount, > 734: byte[] tgt, int tgtCount, int fromIndex) { let's align parameters src/java.base/share/classes/java/lang/StringUTF16.java line 833: > 831: > 832: static String replace(byte[] value, int valLen, boolean valLat1, > 833: byte[] targ, int targLen, boolean targLat1, let's align parameters src/java.base/share/classes/java/lang/StringUTF16.java line 948: > 946: > 947: static boolean regionMatchesCI(byte[] value, int toffset, > 948: byte[] other, int ooffset, int len) { let's align parameters src/java.base/share/classes/java/lang/StringUTF16.java line 953: > 951: > 952: static boolean regionMatchesCI_Latin1(byte[] value, int toffset, > 953: byte[] other, int ooffset, let's align parameters ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2401838339 PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2401840513 PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2401841641 PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2401841514 PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2401843867 PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2401844148 PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2401844348 PR Review Comment: https://git.openjdk.org/jdk/pull/27609#discussion_r2401844493 From rriggs at openjdk.org Fri Oct 3 13:48:20 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Oct 2025 13:48:20 GMT Subject: RFR: 8356202: Cleanup Source code in String Implementation Classes [v3] In-Reply-To: References: Message-ID: > Code cleanup in java.lang.StringLatin1 and StringUTF16. > Remove the `public` qualifier from methods where it is not needed. > Remove an unused toBytes method. > Remove unused codePointXXX methods. > Remove unnecessary casts of primitive types. > > Some of these are suggested by IntelliJ, if the advice should not be taken, I'll revert and update the IDE settings. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Remove a unnecessary `public` access in StringUTF16.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27609/files - new: https://git.openjdk.org/jdk/pull/27609/files/06822b94..13b00f15 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27609&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27609&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27609.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27609/head:pull/27609 PR: https://git.openjdk.org/jdk/pull/27609 From swen at openjdk.org Fri Oct 3 14:01:49 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 3 Oct 2025 14:01:49 GMT Subject: RFR: 8368831: ResourceParsingClassHierarchyResolver.getClassInfo(ClassDesc) throws unspecified UncheckedIOException [v4] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 23:42:13 GMT, Chen Liang wrote: >> ClassHierarchyResolver provided by users may sporadically run into exceptions due to reasons out of control, such as UncheckedIOException caused by a bad zip header. We should specify that users are allowed to fail their CHR when they encounter a failure when they support a ClassDesc to avoid hiding errors. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/chr-exception > - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java > > Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com> > - Fix non-IAE propagation > - Allow ClassHierarchyResolver to throw RuntimeException src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 80: > 78: throw iae; > 79: } catch (RuntimeException ex) { > 80: throw new IllegalArgumentException("Could not resolve class " + classDesc.displayName(), ex); Suggestion: throw new IllegalArgumentException("Could not resolve class ".concat(classDesc.displayName()), ex); Avoid using StringBuilder for string concatenation to reduce code size. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27559#discussion_r2402036492 From swen at openjdk.org Fri Oct 3 14:10:50 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 3 Oct 2025 14:10:50 GMT Subject: RFR: 8366424: Missing type profiling in generated Record Object methods In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 22:13:00 GMT, Chen Liang wrote: > Hotspot profiles by bytecode; as a result, some shared methods become polluted and suffer in type profiling, as described in depth in [this essay](https://cr.openjdk.org/~jrose/jvm/equals-profile.html) by John Rose. The record methods generated by `ObjectMethods::bootstrap` just proved itself another victim in this RFE. > > To bypass this issue, I naively generated distinct bytecode to allow distinct profiles for now. If hotspot adds any kind of split profiles exposed via internal APIs, we can migrate to such split profile and throw away these extra copies of bytecode. > > In particular, in a method handle tree, each leaf method handle seems not separately profiled - for example, all DMH to Object.hashCode share the same profile regardless of their position in a MH tree, making MH trees less useful than explicitly rolled bytecode, unfortunately. > > The attached benchmark should be a good demonstration of the effect of type profiling. src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 327: > 325: .aload(0) // arg0.hashCode() - bytecode subject to customized profiling > 326: .invoke(isInterface ? Opcode.INVOKEINTERFACE : Opcode.INVOKEVIRTUAL, typeDesc, "hashCode", MethodTypeDesc.of(CD_int), isInterface) > 327: .ireturn(); Suggestion: cob.aload(0) .ifnonnull(nonNullPath) .iconst_0() // null hash is 0 .ireturn() .labelBinding(nonNullPath) .aload(0) // arg0.hashCode() - bytecode subject to customized profiling .invoke(isInterface ? Opcode.INVOKEINTERFACE : Opcode.INVOKEVIRTUAL, typeDesc, "hashCode", MethodTypeDesc.of(CD_int), isInterface) .ireturn(); code style ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27533#discussion_r2402073613 From msheppar at openjdk.org Fri Oct 3 14:35:21 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Fri, 3 Oct 2025 14:35:21 GMT Subject: RFR: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 04:22:24 GMT, Johny Jose wrote: >> Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6 > > Johny Jose has updated the pull request incrementally with one additional commit since the last revision: > > Review changes LGTM Thanks for taking on board the feedback. changes look fine -- we note we're changing the lease threshold to 2, rather than the existing 4 let's see how that works out please oblige and run a test repeat job for the jdk_rmi group and also run a tier3 job ------------- Marked as reviewed by msheppar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26815#pullrequestreview-3299324402 PR Comment: https://git.openjdk.org/jdk/pull/26815#issuecomment-3365935742 From rriggs at openjdk.org Fri Oct 3 14:51:39 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Oct 2025 14:51:39 GMT Subject: RFR: 8356202: Cleanup Source code in String Implementation Classes [v4] In-Reply-To: References: Message-ID: > Code cleanup in java.lang.StringLatin1 and StringUTF16. > Remove the `public` qualifier from methods where it is not needed. > Remove an unused toBytes method. > Remove unused codePointXXX methods. > Remove unnecessary casts of primitive types. > > Some of these are suggested by IntelliJ, if the advice should not be taken, I'll revert and update the IDE settings. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Fix indentation on method declarations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27609/files - new: https://git.openjdk.org/jdk/pull/27609/files/13b00f15..5c8b1827 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27609&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27609&range=02-03 Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27609.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27609/head:pull/27609 PR: https://git.openjdk.org/jdk/pull/27609 From asemenyuk at openjdk.org Fri Oct 3 15:00:36 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 3 Oct 2025 15:00:36 GMT Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 02:26:33 GMT, Alexander Matveev wrote: >> - Added test for custom info plist to cover app image including embedded runtime and runtime installer. >> - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8362598: [macos] Add tests for custom info plist files [v3] test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 29: > 27: import java.util.stream.Stream; > 28: > 29: import base.SigningBase; This should result in the following error: open\test\jdk\tools\jpackage\macosx\SigningRuntimeImagePackageTest.java:29: error: package base does not exist import base.SigningBase; ^ 1 error ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27509#discussion_r2402275207 From jpai at openjdk.org Fri Oct 3 15:45:09 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 3 Oct 2025 15:45:09 GMT Subject: RFR: 8356202: Cleanup Source code in String Implementation Classes [v4] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 14:51:39 GMT, Roger Riggs wrote: >> Code cleanup in java.lang.StringLatin1 and StringUTF16. >> Remove the `public` qualifier from methods where it is not needed. >> Remove an unused toBytes method. >> Remove unused codePointXXX methods. >> Remove unnecessary casts of primitive types. >> >> Some of these are suggested by IntelliJ, if the advice should not be taken, I'll revert and update the IDE settings. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation on method declarations Thank you Roger, the updated changes look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27609#pullrequestreview-3299647588 From jlu at openjdk.org Fri Oct 3 16:28:56 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 3 Oct 2025 16:28:56 GMT Subject: RFR: 8368981: Case Fold Locale Legacy Tags On Demand [v3] In-Reply-To: References: Message-ID: <8vPRllD5nujUmTtZsCiC-AhlBVi1G_DCFuXVQT4biTo=.e39d8ddf-9ba5-4447-bfbb-c10c60c61b69@github.com> On Thu, 2 Oct 2025 16:58:41 GMT, Justin Lu wrote: >> Please review this PR which case folds grandfathered BCP47 tags on demand. (Instead of keeping the case compliant versions stored.) >> >> This facilitates the cleanup of the `LEGACY` map (which contains a String to String Array mapping). The 2D String array, creation and populating of the `LEGACY` map, as well as lower case folding of the legacy tags can now be removed from the static block of _sun.util.locale.LanguageTag_. >> >> Legacy tags are a small subset compared to the entire set of valid BCP47 tags. Reducing the cost for supporting them would be ideal. Instead, legacy tags can now be checked against and folded on demand via a switch statement. >> >> The commented grandfathered syntax is removed because the values themselves already exist as code, and the exact case can be found in the provided RFC link. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Implement Roger's review Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27596#issuecomment-3366355891 From jlu at openjdk.org Fri Oct 3 16:28:57 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 3 Oct 2025 16:28:57 GMT Subject: Integrated: 8368981: Case Fold Locale Legacy Tags On Demand In-Reply-To: References: Message-ID: <2t4pwt6e4uOa9YOGmOoNeUmM0vmxrwSq5gatLH2lKMM=.eea1f7b4-504d-4891-95d9-05e8fca18eea@github.com> On Wed, 1 Oct 2025 21:11:53 GMT, Justin Lu wrote: > Please review this PR which case folds grandfathered BCP47 tags on demand. (Instead of keeping the case compliant versions stored.) > > This facilitates the cleanup of the `LEGACY` map (which contains a String to String Array mapping). The 2D String array, creation and populating of the `LEGACY` map, as well as lower case folding of the legacy tags can now be removed from the static block of _sun.util.locale.LanguageTag_. > > Legacy tags are a small subset compared to the entire set of valid BCP47 tags. Reducing the cost for supporting them would be ideal. Instead, legacy tags can now be checked against and folded on demand via a switch statement. > > The commented grandfathered syntax is removed because the values themselves already exist as code, and the exact case can be found in the provided RFC link. This pull request has now been integrated. Changeset: 23a65644 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/23a65644ae63b271ca99c55a2a60a192c4e4dfb8 Stats: 208 lines in 2 files changed: 100 ins; 90 del; 18 mod 8368981: Case Fold Locale Legacy Tags On Demand Reviewed-by: rriggs, naoto ------------- PR: https://git.openjdk.org/jdk/pull/27596 From darcy at openjdk.org Fri Oct 3 16:41:16 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 3 Oct 2025 16:41:16 GMT Subject: RFR: 8369123: Still more small Float16 refactorings Message-ID: Upon further inspection, found a few more opportunities to refine the use of constants in the Float16 implementation. ------------- Commit messages: - JDK-8369123: Still more small Float16 refactorings Changes: https://git.openjdk.org/jdk/pull/27625/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27625&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369123 Stats: 11 lines in 1 file changed: 2 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27625/head:pull/27625 PR: https://git.openjdk.org/jdk/pull/27625 From mchhipa at openjdk.org Fri Oct 3 17:34:24 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Fri, 3 Oct 2025 17:34:24 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v2] In-Reply-To: References: Message-ID: > Update SimpleHttpServer class to use SimpleFileServer. Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27608/files - new: https://git.openjdk.org/jdk/pull/27608/files/15e71bba..64cad93a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=00-01 Stats: 187 lines in 5 files changed: 28 ins; 138 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/27608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27608/head:pull/27608 PR: https://git.openjdk.org/jdk/pull/27608 From mchhipa at openjdk.org Fri Oct 3 17:40:47 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Fri, 3 Oct 2025 17:40:47 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v2] In-Reply-To: <0wdfY8mtBcpaQQx0GmUu2iGyvqYRVQlpKZjVyo770fY=.8cd2fb63-b204-405d-bd4a-7150f7f688b0@github.com> References: <0wdfY8mtBcpaQQx0GmUu2iGyvqYRVQlpKZjVyo770fY=.8cd2fb63-b204-405d-bd4a-7150f7f688b0@github.com> Message-ID: On Fri, 3 Oct 2025 05:33:41 GMT, Jaikiran Pai wrote: > Hello Mahendra, it's good that we are moving to use the `com.sun.net.httpserver.SimpleFileServer` in this test library class. However, it looks like before this change, this test library class was using a `Executor` which allowed it to handle multiple requests concurrently and thus serve the files concurrently. With this change, the requests will now be handled serially because the lack of any executor being configured on the internal `HttpServer` instance backing the `SimpleFileServer` instance. > > Looking at the references of this `jdk.test.lib.net.SimpleHttpServer` test library class, I see only 3 tests using it. I wonder if we should just delete this class altogether and instead using the the `SimpleFileServer` at the call sites as and how necessary. Thanks. Now SimpleFileServer is being used in tests and jdk.test.lib.net.SimpleHttpServer is deleted now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27608#issuecomment-3366616592 From mchhipa at openjdk.org Fri Oct 3 17:44:46 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Fri, 3 Oct 2025 17:44:46 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 05:41:58 GMT, Jaikiran Pai wrote: >> Update SimpleHttpServer class to use SimpleFileServer. > > Interestingly, there's even a `test/jdk/com/sun/net/httpserver/SimpleFileServer.java` class which is neither a test nor a test library class. As far as I can see, it's not being used anywhere. Maybe we should remove that one too. These similarly named classes add to confusion. > The SimpleHttpServer class that Mahendra is updating is used by multi-relase jars and jaxp catalog tests. It could be prudent to update the class first, check that everything remains stable, and then replace usage in a followup issue. It seems this class is only being used by three tests however - so maybe updating those three tests to use the SimpleFileServer directly won't be too bad. If we do that then make sure we keep the same behaviour = keep the executor as @jaikiran suggested. > > Good find about `test/jdk/com/sun/net/httpserver/SimpleFileServer.java` - let's attempt to remove it - it does not appear to be used anywhere. Thanks, Now test/jdk/com/sun/net/httpserver/SimpleFileServer.java is removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27608#issuecomment-3366628509 From dfuchs at openjdk.org Fri Oct 3 17:54:49 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 3 Oct 2025 17:54:49 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 17:34:24 GMT, Mahendra Chhipa wrote: >> Update SimpleHttpServer class to use SimpleFileServer. > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments. test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java line 103: > 101: httpserver.start(); > 102: remoteFilePath = "http:" + jdk.test.lib.net.URIBuilder.newBuilder().host(httpserver.getAddress().getAddress()). > 103: port(httpserver.getAddress().getPort()).build().toString() + REMOTE_FILE_LOCATION; Suggestion: remoteFilePath = jdk.test.lib.net.URIBuilder.newBuilder() .scheme("http") .host(httpserver.getAddress().getAddress()) .port(httpserver.getAddress().getPort()) .build().toString() + REMOTE_FILE_LOCATION; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27608#discussion_r2402805191 From dfuchs at openjdk.org Fri Oct 3 17:54:49 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 3 Oct 2025 17:54:49 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 17:47:08 GMT, Daniel Fuchs wrote: >> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented review comments. > > test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java line 103: > >> 101: httpserver.start(); >> 102: remoteFilePath = "http:" + jdk.test.lib.net.URIBuilder.newBuilder().host(httpserver.getAddress().getAddress()). >> 103: port(httpserver.getAddress().getPort()).build().toString() + REMOTE_FILE_LOCATION; > > Suggestion: > > remoteFilePath = jdk.test.lib.net.URIBuilder.newBuilder() > .scheme("http") > .host(httpserver.getAddress().getAddress()) > .port(httpserver.getAddress().getPort()) > .build().toString() + REMOTE_FILE_LOCATION; Is there another URIBuilder that prevents importing `jdk.test.lib.net.URIBuilder`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27608#discussion_r2402812037 From naoto at openjdk.org Fri Oct 3 17:55:52 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 3 Oct 2025 17:55:52 GMT Subject: RFR: 8366829: Add java.time.Duration constants MIN and MAX [v3] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 09:50:23 GMT, Pavel Rappo wrote: >> We have [recently discussed][] a possibility of adding the `Duration.MIN` and `Duration.MAX` constants. Can we now start implementation? If and when we are in agreement on this PR, I will file a CSR. >> >> I drafted a minimal specification and added some tests. I tried to phrase the spec for `Duration.MIN` in a way that makes it clear that `Duration.MIN` is the most negative value and not the least positive. >> >> [recently discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Respond to feedback > > Apply Stephen's suggestion on wording, although modified. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27534#pullrequestreview-3300200546 From rriggs at openjdk.org Fri Oct 3 18:37:48 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Oct 2025 18:37:48 GMT Subject: RFR: 8366829: Add java.time.Duration constants MIN and MAX [v3] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 09:50:23 GMT, Pavel Rappo wrote: >> We have [recently discussed][] a possibility of adding the `Duration.MIN` and `Duration.MAX` constants. Can we now start implementation? If and when we are in agreement on this PR, I will file a CSR. >> >> I drafted a minimal specification and added some tests. I tried to phrase the spec for `Duration.MIN` in a way that makes it clear that `Duration.MIN` is the most negative value and not the least positive. >> >> [recently discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Respond to feedback > > Apply Stephen's suggestion on wording, although modified. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27534#pullrequestreview-3300388900 From rriggs at openjdk.org Fri Oct 3 18:48:57 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Oct 2025 18:48:57 GMT Subject: Integrated: 8356202: Cleanup Source code in String Implementation Classes In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 15:39:51 GMT, Roger Riggs wrote: > Code cleanup in java.lang.StringLatin1 and StringUTF16. > Remove the `public` qualifier from methods where it is not needed. > Remove an unused toBytes method. > Remove unused codePointXXX methods. > Remove unnecessary casts of primitive types. > > Some of these are suggested by IntelliJ, if the advice should not be taken, I'll revert and update the IDE settings. This pull request has now been integrated. Changeset: 012e079d Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/012e079d11b629ddda8d5f687fd43ef21d210466 Stats: 158 lines in 2 files changed: 0 ins; 31 del; 127 mod 8356202: Cleanup Source code in String Implementation Classes Reviewed-by: jpai, rgiulietti, liach ------------- PR: https://git.openjdk.org/jdk/pull/27609 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
     * }
* * @param str the {@code String} to be compared. * @return a negative integer, zero, or a positive integer as the specified * String is greater than, equal to, or less than this String, * ignoring case considerations by case folding. * @see #equalsFoldCase(String) * @see #compareToIgnoreCase(String) * @see java.text.Collator * @since 26 */ public int compareToFoldCase(String str) /** * A Comparator that orders {@code String} objects as by * {@link #compareToFoldCase(String) compareToFoldCase()}. * * @see #compareToFoldCase(String) * @since 26 */ public static final Comparator UNICODE_CASEFOLD_ORDER; ### Usage Examples Sharp s (U+00DF) case-folds to "ss" "stra?e".equalsIgnoreCase("strasse"); // false "stra?e".compareToIgnoreCase("strasse"); // != 0 "stra?e".equalsFoldCase("strasse"); // true ### Performance The JMH microbenchmark StringCompareToIgnoreCase has been updated to compare performance of compareToFoldCase with the existing compareToIgnoreCase(). Benchmark Mode Cnt Score Error Units StringCompareToIgnoreCase.asciiGreekLower avgt 15 20.195 ? 0.300 ns/op StringCompareToIgnoreCase.asciiGreekLowerCF avgt 15 11.051 ? 0.254 ns/op StringCompareToIgnoreCase.asciiGreekUpperLower avgt 15 6.035 ? 0.047 ns/op StringCompareToIgnoreCase.asciiGreekUpperLowerCF avgt 15 14.786 ? 0.382 ns/op StringCompareToIgnoreCase.asciiLower avgt 15 17.688 ? 1.396 ns/op StringCompareToIgnoreCase.asciiLowerCF avgt 15 44.552 ? 0.155 ns/op StringCompareToIgnoreCase.asciiUpperLower avgt 15 13.069 ? 0.487 ns/op StringCompareToIgnoreCase.asciiUpperLowerCF avgt 15 58.684 ? 0.274 ns/op StringCompareToIgnoreCase.greekLower avgt 15 20.642 ? 0.082 ns/op StringCompareToIgnoreCase.greekLowerCF avgt 15 7.255 ? 0.271 ns/op StringCompareToIgnoreCase.greekUpperLower avgt 15 5.737 ? 0.013 ns/op StringCompareToIgnoreCase.greekUpperLowerCF avgt 15 11.100 ? 1.147 ns/op StringCompareToIgnoreCase.lower avgt 15 20.192 ? 0.044 ns/op StringCompareToIgnoreCase.lowerrCF avgt 15 11.257 ? 0.259 ns/op StringCompareToIgnoreCase.supLower avgt 15 54.801 ? 0.415 ns/op StringCompareToIgnoreCase.supLowerCF avgt 15 15.207 ? 0.418 ns/op StringCompareToIgnoreCase.supUpperLower avgt 15 14.431 ? 0.188 ns/op StringCompareToIgnoreCase.supUpperLowerCF avgt 15 19.149 ? 0.985 ns/op StringCompareToIgnoreCase.upperLower avgt 15 5.650 ? 0.051 ns/op StringCompareToIgnoreCase.upperLowerCF avgt 15 14.338 ? 0.352 ns/op StringCompareToIgnoreCase.utf16SubLower avgt 15 14.774 ? 0.200 ns/op StringCompareToIgnoreCase.utf16SubLowerCF avgt 15 2.669 ? 0.041 ns/op StringCompareToIgnoreCase.utf16SupUpperLower avgt 15 16.250 ? 0.099 ns/op StringCompareToIgnoreCase.utf16SupUpperLowerCF avgt 15 11.524 ? 0.327 ns/op ### Refs [Unicode Standard 5.18.4 Caseless Matching](https://www.unicode.org/versions/latest/core-spec/chapter-5/#G21790) [Unicode? Standard Annex #44: 5.6 Case and Case Mapping](https://www.unicode.org/reports/tr44/#Casemapping) [Unicode Technical Standard #18: Unicode Regular Expressions RL1.5: Simple Loose Matches](https://www.unicode.org/reports/tr18/#Simple_Loose_Matches) [Unicode SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt) [Unicode CaseFolding.txt](https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt) ### Other Languages **Python string.casefold()** The str.casefold() method in Python returns a casefolded version of a string. Casefolding is a more aggressive form of lowercasing, designed to remove all case distinctions in a string, particularly for the purpose of caseless string comparisons. **Perl?s fc()** Returns the casefolded version of EXPR. This is the internal function implementing the \F escape in double-quoted strings. Casefolding is the process of mapping strings to a form where case differences are erased; comparing two strings in their casefolded form is effectively a way of asking if two strings are equal, regardless of case. Perl only implements the full form of casefolding, but you can access the simple folds using "casefold()" in Unicode::UCD] ad "prop_invmap()" in Unicode::UCD]. **ICU4J UCharacter.foldCase (Java)** Purpose: Provides extensions to the standard Java Character class, including support for more Unicode properties and handling of supplementary characters (code points beyond U+FFFF). Method Signature (String based): public static String foldCase(String str, int options) Method Signature (CharSequence & Appendable based): public static A foldCase(CharSequence src, A dest, int options, Edits edits) Key Features: Case Folding: Converts a string to its case-folded equivalent. Locale Independent: Case folding in UCharacter.foldCase is generally not dependent on locale settings. Context Insensitive: The mapping of a character is not affected by surrounding characters. Turkic Option: An option exists to include or exclude special mappings for Turkish/Azerbaijani text. Result Length: The resulting string can be longer or shorter than the original. Edits Recording: Allows for recording of edits for index mapping, styled text, and getting only changes. **u_strFoldCase (C/C++)** A lower-level C API function for case folding a string. Case Folding Options: Similar options as UCharacter.foldCase for controlling case folding behavior. Availability: Found in the ustring.h and unistr.h headers in the ICU4C library. ------------- Commit messages: - 8365675: Add String Unicode Case-Folding Support Changes: https://git.openjdk.org/jdk/pull/26892/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26892&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365675 Stats: 1279 lines in 12 files changed: 1116 ins; 137 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/26892.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26892/head:pull/26892 PR: https://git.openjdk.org/jdk/pull/26892 From sherman at openjdk.org Fri Oct 3 19:41:20 2025 From: sherman at openjdk.org (Xueming Shen) Date: Fri, 3 Oct 2025 19:41:20 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2] In-Reply-To: References: 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 thi... Xueming Shen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8365675 - 8365675: Add String Unicode Case-Folding Support to update api ------------- Changes: https://git.openjdk.org/jdk/pull/26892/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26892&range=01 Stats: 1282 lines in 12 files changed: 1119 ins; 137 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/26892.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26892/head:pull/26892 PR: https://git.openjdk.org/jdk/pull/26892 From rriggs at openjdk.org Fri Oct 3 19:54:22 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Oct 2025 19:54:22 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 19:41:20 GMT, Xueming Shen wrote: >> ### 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 pass... > > Xueming Shen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8365675 > - 8365675: Add String Unicode Case-Folding Support > > to update api src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 1: > 1: /* We're going to need to find a more compact format for the data, individual 1 or 2 entry char arrays have a large overhead. Plus the map entries take a lot of space for the data and indexing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26892#discussion_r2403194785 From sherman at openjdk.org Fri Oct 3 19:54:23 2025 From: sherman at openjdk.org (Xueming Shen) Date: Fri, 3 Oct 2025 19:54:23 GMT Subject: Withdrawn: 8365675: Add String Unicode Case-Folding Support In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 03:50:03 GMT, Xueming Shen wrote: > ### 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 thi... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26892 From sherman at openjdk.org Fri Oct 3 20:09:21 2025 From: sherman at openjdk.org (Xueming Shen) Date: Fri, 3 Oct 2025 20:09:21 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support Message-ID: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> ### 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
     * }
* * @param str the {@code String} to be compared. * @return a negative integer, zero, or a positive integer as the specified * String is greater than, equal to, or less than this String, * ignoring case considerations by case folding. * @see #equalsFoldCase(String) * @see #compareToIgnoreCase(String) * @see java.text.Collator * @since 26 */ public int compareToFoldCase(String str) /** * A Comparator that orders {@code String} objects as by * {@link #compareToFoldCase(String) compareToFoldCase()}. * * @see #compareToFoldCase(String) * @since 26 */ public static final Comparator UNICODE_CASEFOLD_ORDER; ### Usage Examples Sharp s (U+00DF) case-folds to "ss" "stra?e".equalsIgnoreCase("strasse"); // false "stra?e".compareToIgnoreCase("strasse"); // != 0 "stra?e".equalsFoldCase("strasse"); // true ### Performance The JMH microbenchmark StringCompareToIgnoreCase has been updated to compare performance of compareToFoldCase with the existing compareToIgnoreCase(). Benchmark Mode Cnt Score Error Units StringCompareToIgnoreCase.asciiGreekLower avgt 15 20.195 ? 0.300 ns/op StringCompareToIgnoreCase.asciiGreekLowerCF avgt 15 11.051 ? 0.254 ns/op StringCompareToIgnoreCase.asciiGreekUpperLower avgt 15 6.035 ? 0.047 ns/op StringCompareToIgnoreCase.asciiGreekUpperLowerCF avgt 15 14.786 ? 0.382 ns/op StringCompareToIgnoreCase.asciiLower avgt 15 17.688 ? 1.396 ns/op StringCompareToIgnoreCase.asciiLowerCF avgt 15 44.552 ? 0.155 ns/op StringCompareToIgnoreCase.asciiUpperLower avgt 15 13.069 ? 0.487 ns/op StringCompareToIgnoreCase.asciiUpperLowerCF avgt 15 58.684 ? 0.274 ns/op StringCompareToIgnoreCase.greekLower avgt 15 20.642 ? 0.082 ns/op StringCompareToIgnoreCase.greekLowerCF avgt 15 7.255 ? 0.271 ns/op StringCompareToIgnoreCase.greekUpperLower avgt 15 5.737 ? 0.013 ns/op StringCompareToIgnoreCase.greekUpperLowerCF avgt 15 11.100 ? 1.147 ns/op StringCompareToIgnoreCase.lower avgt 15 20.192 ? 0.044 ns/op StringCompareToIgnoreCase.lowerrCF avgt 15 11.257 ? 0.259 ns/op StringCompareToIgnoreCase.supLower avgt 15 54.801 ? 0.415 ns/op StringCompareToIgnoreCase.supLowerCF avgt 15 15.207 ? 0.418 ns/op StringCompareToIgnoreCase.supUpperLower avgt 15 14.431 ? 0.188 ns/op StringCompareToIgnoreCase.supUpperLowerCF avgt 15 19.149 ? 0.985 ns/op StringCompareToIgnoreCase.upperLower avgt 15 5.650 ? 0.051 ns/op StringCompareToIgnoreCase.upperLowerCF avgt 15 14.338 ? 0.352 ns/op StringCompareToIgnoreCase.utf16SubLower avgt 15 14.774 ? 0.200 ns/op StringCompareToIgnoreCase.utf16SubLowerCF avgt 15 2.669 ? 0.041 ns/op StringCompareToIgnoreCase.utf16SupUpperLower avgt 15 16.250 ? 0.099 ns/op StringCompareToIgnoreCase.utf16SupUpperLowerCF avgt 15 11.524 ? 0.327 ns/op ### Refs [Unicode Standard 5.18.4 Caseless Matching](https://www.unicode.org/versions/latest/core-spec/chapter-5/#G21790) [Unicode? Standard Annex #44: 5.6 Case and Case Mapping](https://www.unicode.org/reports/tr44/#Casemapping) [Unicode Technical Standard #18: Unicode Regular Expressions RL1.5: Simple Loose Matches](https://www.unicode.org/reports/tr18/#Simple_Loose_Matches) [Unicode SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt) [Unicode CaseFolding.txt](https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt) ### Other Languages **Python string.casefold()** The str.casefold() method in Python returns a casefolded version of a string. Casefolding is a more aggressive form of lowercasing, designed to remove all case distinctions in a string, particularly for the purpose of caseless string comparisons. **Perl?s fc()** Returns the casefolded version of EXPR. This is the internal function implementing the \F escape in double-quoted strings. Casefolding is the process of mapping strings to a form where case differences are erased; comparing two strings in their casefolded form is effectively a way of asking if two strings are equal, regardless of case. Perl only implements the full form of casefolding, but you can access the simple folds using "casefold()" in Unicode::UCD] ad "prop_invmap()" in Unicode::UCD]. **ICU4J UCharacter.foldCase (Java)** Purpose: Provides extensions to the standard Java Character class, including support for more Unicode properties and handling of supplementary characters (code points beyond U+FFFF). Method Signature (String based): public static String foldCase(String str, int options) Method Signature (CharSequence & Appendable based): public static A foldCase(CharSequence src, A dest, int options, Edits edits) Key Features: Case Folding: Converts a string to its case-folded equivalent. Locale Independent: Case folding in UCharacter.foldCase is generally not dependent on locale settings. Context Insensitive: The mapping of a character is not affected by surrounding characters. Turkic Option: An option exists to include or exclude special mappings for Turkish/Azerbaijani text. Result Length: The resulting string can be longer or shorter than the original. Edits Recording: Allows for recording of edits for index mapping, styled text, and getting only changes. **u_strFoldCase (C/C++)** A lower-level C API function for case folding a string. Case Folding Options: Similar options as UCharacter.foldCase for controlling case folding behavior. Availability: Found in the ustring.h and unistr.h headers in the ICU4C library. ------------- Commit messages: - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8365675 - 8365675: Add String Unicode Case-Folding Support Changes: https://git.openjdk.org/jdk/pull/27628/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365675 Stats: 1282 lines in 12 files changed: 1119 ins; 137 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/27628.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27628/head:pull/27628 PR: https://git.openjdk.org/jdk/pull/27628 From almatvee at openjdk.org Fri Oct 3 20:19:04 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 3 Oct 2025 20:19:04 GMT Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v3] In-Reply-To: References: Message-ID: > - Added test for custom info plist to cover app image including embedded runtime and runtime installer. > - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8362598: [macos] Add tests for custom info plist files [v4] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27509/files - new: https://git.openjdk.org/jdk/pull/27509/files/f1e99130..af103a66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27509&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27509&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27509/head:pull/27509 PR: https://git.openjdk.org/jdk/pull/27509 From almatvee at openjdk.org Fri Oct 3 20:19:06 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 3 Oct 2025 20:19:06 GMT Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 14:57:21 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8362598: [macos] Add tests for custom info plist files [v3] > > test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 29: > >> 27: import java.util.stream.Stream; >> 28: >> 29: import base.SigningBase; > > This should result in the following error: > > open\test\jdk\tools\jpackage\macosx\SigningRuntimeImagePackageTest.java:29: error: package base does not exist > import base.SigningBase; > ^ > 1 error Removed. Not sure why it was added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27509#discussion_r2403248860 From almatvee at openjdk.org Fri Oct 3 20:23:28 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 3 Oct 2025 20:23:28 GMT Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v4] In-Reply-To: References: Message-ID: > - Added test for custom info plist to cover app image including embedded runtime and runtime installer. > - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string. Alexander Matveev 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 'upstream/master' into JDK-8362598 - 8362598: [macos] Add tests for custom info plist files [v4] - 8362598: [macos] Add tests for custom info plist files [v3] - 8362598: [macos] Add tests for custom info plist files [v2] - 8362598: [macos] Add tests for custom info plist files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27509/files - new: https://git.openjdk.org/jdk/pull/27509/files/af103a66..267bd365 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27509&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27509&range=02-03 Stats: 11234 lines in 552 files changed: 5424 ins; 2593 del; 3217 mod Patch: https://git.openjdk.org/jdk/pull/27509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27509/head:pull/27509 PR: https://git.openjdk.org/jdk/pull/27509 From serb at openjdk.org Fri Oct 3 20:36:07 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 3 Oct 2025 20:36:07 GMT Subject: RFR: 8369027: Apply java.io.Serial annotations in java.scripting [v2] In-Reply-To: References: Message-ID: > Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.scripting module to enable stricter compile-time checking of serialization-related declarations. > > The patch is trivial, only one class needs to be updated. > > Example of a similar change https://github.com/openjdk/jdk/pull/26208. Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8369027 - 8369027: Apply java.io.Serial annotations in java.scripting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27599/files - new: https://git.openjdk.org/jdk/pull/27599/files/d936251c..655176e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27599&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27599&range=00-01 Stats: 5366 lines in 322 files changed: 2449 ins; 1441 del; 1476 mod Patch: https://git.openjdk.org/jdk/pull/27599.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27599/head:pull/27599 PR: https://git.openjdk.org/jdk/pull/27599 From almatvee at openjdk.org Fri Oct 3 21:12:35 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 3 Oct 2025 21:12:35 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v6] In-Reply-To: References: Message-ID: > - Removed pre- and post- installation PKG scripts. > - This code is not needed and PKG should create destination folder and set correct permissions. > - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. > - Users will have ability to provide pre- and post- installation PKG scripts if needed. > - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. > - I think code in these scripts are some legacy leftovers. > - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8356047 - 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v4] - 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v3] - Merge remote-tracking branch 'upstream/master' into JDK-8356047 - 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v2] - Merge remote-tracking branch 'upstream/master' into JDK-8356047 - 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25510/files - new: https://git.openjdk.org/jdk/pull/25510/files/38da308c..17d948c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=04-05 Stats: 11234 lines in 552 files changed: 5424 ins; 2593 del; 3217 mod Patch: https://git.openjdk.org/jdk/pull/25510.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25510/head:pull/25510 PR: https://git.openjdk.org/jdk/pull/25510 From darcy at openjdk.org Fri Oct 3 22:12:19 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 3 Oct 2025 22:12:19 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v2] In-Reply-To: References: Message-ID: > Upon further inspection, found a few more opportunities to refine the use of constants in the Float16 implementation. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Remove unneeded use of "Float16.". ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27625/files - new: https://git.openjdk.org/jdk/pull/27625/files/761f16f1..be2b4ab8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27625&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27625&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27625/head:pull/27625 PR: https://git.openjdk.org/jdk/pull/27625 From serb at openjdk.org Fri Oct 3 23:20:54 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 3 Oct 2025 23:20:54 GMT Subject: Integrated: 8369027: Apply java.io.Serial annotations in java.scripting In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 22:31:42 GMT, Sergey Bylokhov wrote: > Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.scripting module to enable stricter compile-time checking of serialization-related declarations. > > The patch is trivial, only one class needs to be updated. > > Example of a similar change https://github.com/openjdk/jdk/pull/26208. This pull request has now been integrated. Changeset: c3fbbfab Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/c3fbbfabcc9a9535a3b422c1c9afaa8e092a5da0 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8369027: Apply java.io.Serial annotations in java.scripting Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/27599 From almatvee at openjdk.org Fri Oct 3 23:50:07 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 3 Oct 2025 23:50:07 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v7] In-Reply-To: References: Message-ID: > - Removed pre- and post- installation PKG scripts. > - This code is not needed and PKG should create destination folder and set correct permissions. > - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. > - Users will have ability to provide pre- and post- installation PKG scripts if needed. > - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. > - I think code in these scripts are some legacy leftovers. > - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v5] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25510/files - new: https://git.openjdk.org/jdk/pull/25510/files/17d948c2..bcd26fed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=05-06 Stats: 26 lines in 1 file changed: 14 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25510.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25510/head:pull/25510 PR: https://git.openjdk.org/jdk/pull/25510 From almatvee at openjdk.org Fri Oct 3 23:50:09 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 3 Oct 2025 23:50:09 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v6] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 21:12:35 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8356047 > - 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v4] > - 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v3] > - Merge remote-tracking branch 'upstream/master' into JDK-8356047 > - 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v2] > - Merge remote-tracking branch 'upstream/master' into JDK-8356047 > - 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v5] - Updated test to check for executable permissions for scripts when package is unpacked and for install case to check that scripts where executed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-3367561421 From almatvee at openjdk.org Sat Oct 4 01:01:37 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 4 Oct 2025 01:01:37 GMT Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v5] In-Reply-To: References: Message-ID: > - Added test for custom info plist to cover app image including embedded runtime and runtime installer. > - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8362598: [macos] Add tests for custom info plist files [v5] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27509/files - new: https://git.openjdk.org/jdk/pull/27509/files/267bd365..01e41f1f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27509&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27509&range=03-04 Stats: 23 lines in 1 file changed: 21 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27509/head:pull/27509 PR: https://git.openjdk.org/jdk/pull/27509 From almatvee at openjdk.org Sat Oct 4 01:01:40 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 4 Oct 2025 01:01:40 GMT Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v4] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 20:23:28 GMT, Alexander Matveev wrote: >> - Added test for custom info plist to cover app image including embedded runtime and runtime installer. >> - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string. > > Alexander Matveev 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 'upstream/master' into JDK-8362598 > - 8362598: [macos] Add tests for custom info plist files [v4] > - 8362598: [macos] Add tests for custom info plist files [v3] > - 8362598: [macos] Add tests for custom info plist files [v2] > - 8362598: [macos] Add tests for custom info plist files 8362598: [macos] Add tests for custom info plist files [v5] - Test updated after latest merge. It started failing since `plistFile.queryValue` did not able to find keys stored as value of `CustomInfoPListFA`. FA extension is xml stored as value of `CustomInfoPListFA`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27509#issuecomment-3367710324 From jbhateja at openjdk.org Sat Oct 4 04:12:50 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sat, 4 Oct 2025 04:12:50 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v11] In-Reply-To: References: Message-ID: <3RQawTRzXt6NAE5TM7mjgw0JjdqSWLnx_NE_flDRgDU=.b0d4b3e0-1a80-4309-90c4-6ca4e4946304@github.com> On Fri, 3 Oct 2025 12:14:46 GMT, Quan Anh Mai wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Update countbitsnode.cpp > > src/hotspot/share/opto/countbitsnode.cpp line 145: > >> 143: } >> 144: KnownBits bits = t->isa_int()->_bits; >> 145: return TypeInt::make(population_count(bits._ones), population_count(~bits._zeros), Type::WidenMax); > > The `widen` of the output should be the same as the `widen` of the input, not `WidenMax` here. Thanks @merykitty, widen is mainly used for optimistic data flow analysis pass like CCP where type analysis begins with TOP and progressively grows the value range till convergence / fixed point. it's good to preserve the widen of input to delay eager convergence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27075#discussion_r2403728728 From alanb at openjdk.org Sat Oct 4 05:09:27 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Oct 2025 05:09:27 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v7] In-Reply-To: References: Message-ID: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Merge branch 'master' into JDK-8353835 - Add test for -Xlog:jni=debug - Merge branch 'master' into JDK-8353835 - Merge branch 'master' into JDK-8353835 - Improve CommandLineTest.testWarn - More test cleanup - Merge branch 'master' into JDK-8353835 - Expand jni/JNIAttachMutatorTest to final fields in named modules - Merge branch 'master' into JDK-8353835 - Test updates based on reviewer feedback - ... and 24 more: https://git.openjdk.org/jdk/compare/72319167...eed7ec4a ------------- Changes: https://git.openjdk.org/jdk/pull/25115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=06 Stats: 4858 lines in 66 files changed: 4681 ins; 54 del; 123 mod Patch: https://git.openjdk.org/jdk/pull/25115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115 PR: https://git.openjdk.org/jdk/pull/25115 From alanb at openjdk.org Sat Oct 4 05:11:31 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Oct 2025 05:11:31 GMT Subject: RFR: 8367857: Implement JEP 525: Structured Concurrency (Sixth Preview) [v2] In-Reply-To: References: Message-ID: > Updates for JEP 525. > > - The join method is changed to invoke `Joiner::onTimeout` if a timeout is configured and the timeout expires before or while waiting. > - `Joiner.allUntil(Predicate`) is changed to allow join return the stream of all forked subtasks when the timeout expires. > - The `join` method is now specified to allow it be called again if interrupted. > - The configFunction parameter to the 3-arg open is changed from `Function` to `UnaryOperator`. > - Joiner is no longer a `@FunctionalInterface`. > > Most of the changes are to API docs and tests. Some links are changed to use double hash mark. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Sync up from loom repo - Merge branch 'master' into JDK-8367857 - Merge branch 'master' into JDK-8367857 - Improve docs and review feedback - Merge branch 'master' into JDK-8367857 - Add JEP number - Merge branch 'master' into JDK-8367857 - Update - Merge branch 'master' into JDK-8367857 - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27392/files - new: https://git.openjdk.org/jdk/pull/27392/files/66aca21e..c487fd60 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27392&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27392&range=00-01 Stats: 23912 lines in 785 files changed: 12848 ins; 6356 del; 4708 mod Patch: https://git.openjdk.org/jdk/pull/27392.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27392/head:pull/27392 PR: https://git.openjdk.org/jdk/pull/27392 From jbhateja at openjdk.org Sat Oct 4 06:01:07 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sat, 4 Oct 2025 06:01:07 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v12] In-Reply-To: References: Message-ID: > This patch optimizes PopCount value transforms using KnownBits information. > Following are the results of the micro-benchmark included with the patch > > > > System: 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark Mode Cnt Score Error Units > PopCountValueTransform.LogicFoldingKerenLong thrpt 2 215460.670 ops/s > PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 294014.826 ops/s > > Withopt: > Benchmark Mode Cnt Score Error Units > PopCountValueTransform.LogicFoldingKerenLong thrpt 2 389978.082 ops/s > PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 417261.583 ops/s > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolution ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27075/files - new: https://git.openjdk.org/jdk/pull/27075/files/e206ccc3..85b10e88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27075&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27075&range=10-11 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27075.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27075/head:pull/27075 PR: https://git.openjdk.org/jdk/pull/27075 From alanb at openjdk.org Sat Oct 4 06:17:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Oct 2025 06:17:55 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v14] In-Reply-To: References: Message-ID: <7310DxCtF6ucI5sLtpsA9mBgST_WlOs-MNNX3DEXXS8=.b47250ca-e3e6-4d84-96a0-e5e53d916375@github.com> On Wed, 1 Oct 2025 17:45:41 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. >> >> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. >> >> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarify the use of waitFor after close() or T-W-R exit. src/java.base/share/classes/java/lang/Process.java line 182: > 180: * Close all writer and reader streams and terminate the process. > 181: * The streams are closed immediately and the process is terminated without waiting. > 182: * This method is idempotent, if the process has already been closed I think make this `{@code Process}` as that is the handle to the process (the process has terminated, it hasn't been closed, if you see what I mean). src/java.base/share/classes/java/lang/Process.java line 185: > 183: * invoking this method has no effect. > 184: *

> 185: * If the data from the process streams is needed, it must be read before calling this method. The process streams includes the output stream so it might be a bit better to say ".. data from the input or error streams are needed". src/java.base/share/classes/java/lang/Process.java line 186: > 184: *

> 185: * If the data from the process streams is needed, it must be read before calling this method. > 186: * The contents of streams that have not been read fully are lost, they are discarded or ignored. "read fully", have you considered read to end of stream? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2403783569 PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2403783966 PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2403784104 From alanb at openjdk.org Sat Oct 4 06:21:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Oct 2025 06:21:49 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v14] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 17:45:41 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. >> >> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. >> >> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarify the use of waitFor after close() or T-W-R exit. src/java.base/share/classes/java/lang/Process.java line 190: > 188: * If the process should be allowed to run to completion or the exit value of the process > 189: * is of interest, then the caller must {@linkplain #waitFor() wait} for the process > 190: * to complete before calling this method. I understand there is a follow-up JBS issue created to get the terminology in the Process API docs consistent. On this one, I think we should say it must wait until the process has terminated as that is how waitFor is specified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2403786352 From alanb at openjdk.org Sat Oct 4 06:24:48 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Oct 2025 06:24:48 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v14] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 17:45:41 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. >> >> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. >> >> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarify the use of waitFor after close() or T-W-R exit. src/java.base/share/classes/java/lang/Process.java line 197: > 195: * Closing an already closed stream usually has no effect but is specific to the stream. > 196: * If an {@code IOException} occurs when closing a stream it is > 197: * re-thrown after the process is terminated. Additional {@code IOExceptions} "re-thrown", by what/who? Maybe use "this method" or "the close method" to make it clearer? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2403787162 From alanb at openjdk.org Sat Oct 4 06:29:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Oct 2025 06:29:46 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v14] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 17:45:41 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. >> >> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. >> >> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarify the use of waitFor after close() or T-W-R exit. src/java.base/share/classes/java/lang/Process.java line 202: > 200: *

> 201: * The process may already have terminated or be in the process of terminating; > 202: * if it is {@linkplain #isAlive() alive}, it is {@linkplain #destroy destroyed}. The compound sentence is hard to read. It might be clear to say that the process is destroyed. This is no-op if the process has already terminated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2403788667 From alanb at openjdk.org Sat Oct 4 06:50:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Oct 2025 06:50:50 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v14] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 17:45:41 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. >> >> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. >> >> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarify the use of waitFor after close() or T-W-R exit. src/java.base/share/classes/java/lang/Process.java line 207: > 205: * Calling {@linkplain #waitFor() waitFor} after > 206: * {@linkplain #close() close} or after the try-with-resources block exits > 207: * can verify that the process has been terminated. "can verify that the process has been terminated". I think this section is a bit confusing to read. It puts doubt into the reader's mind that the process may not have terminated and call waitFor after close to be sure. It's okay for the all powerful destroyForcibly to speak about the possibility that the process may not terminate immediately but the "close" method is more user facing and users will expect the process to have terminated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2403804363 From eirbjo at openjdk.org Sat Oct 4 07:06:45 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sat, 4 Oct 2025 07:06:45 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 22:12:19 GMT, Joe Darcy wrote: >> Upon further inspection, found a few more opportunities to refine the use of constants in the Float16 implementation. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded use of "Float16.". // Currently Float16 is a value-based class and in future it is in _the_ future // IEEEremainder / remainder operator remainder Would one remainder suffice for this remainder reminder? private final short value; Consider adding a field comment to align with Float, Double and friends. private static final Float16 ZERO = valueOf(0); Other private implementation constants in this class have comments. These would be rather obvious, but perheps we can consider adding them just for consistency? Should we consider ordering private vs. public constructors? Now they seem a bit mingled, making it harder for the eye to scan the public API of the class. Line 372: return new Float16((short)(sign_bit | 0x7c00)); `0x7c00` here is `EXP_BIT_MASK`, right? // toHexString, line 288: return s.replaceFirst("p-1022$", "p-14"); Are we okay to invoke regex from such low level code? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27625#issuecomment-3367978726 From alanb at openjdk.org Sat Oct 4 07:37:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Oct 2025 07:37:49 GMT Subject: RFR: 8191963: Path.equals() and File.equals() return true for two different files on Windows [v2] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 20:13:38 GMT, Brian Burkhalter wrote: >> Replace logic in `java.io.WinNTFileSystems.compare(File,File)` with that from `sun.nio.fs.WindowsPath.compareTo(Path)`. > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - 8191963: Add system property to enable legacy behavior > - Merge > - 8191963: Path.equals() and File.equals() return true for two different files on Windows > > [...] system property to restore long standing behavior. > > Added in [a63e13e](https://github.com/openjdk/jdk/commit/a63e13e1e086d299a4e1326606f3322a42cb5977). @naotoj, @xuemingshen-oracle, do you have any thoughts on the compatibility impact? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25788#issuecomment-3367995346 From duke at openjdk.org Sat Oct 4 13:15:48 2025 From: duke at openjdk.org (Jason Mehrens) Date: Sat, 4 Oct 2025 13:15:48 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v14] In-Reply-To: References: Message-ID: <8e40qtmHhNynhb5DabWgdCPuZG9KeAWiwBnxnRwQ1Tw=.9c3f6add-27b1-4eeb-a793-923b3299391a@github.com> On Sat, 4 Oct 2025 06:48:18 GMT, Alan Bateman wrote: >... It puts doubt into the reader's mind that the process may not have terminated and call waitFor after close to be sure. Process::isAlive may be true or false after Process::destroy. The API docs shouldn't forbid nor require a call to waitFor after close/destroy. If process is holding a lock on input file (Windows) and that caller want to delete after exit, the caller waitFor after close/destroy before calling File::delete. Destroy/close not waiting on exit is correct behavior. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2403969226 From alanb at openjdk.org Sat Oct 4 13:41:48 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Oct 2025 13:41:48 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v14] In-Reply-To: <8e40qtmHhNynhb5DabWgdCPuZG9KeAWiwBnxnRwQ1Tw=.9c3f6add-27b1-4eeb-a793-923b3299391a@github.com> References: <8e40qtmHhNynhb5DabWgdCPuZG9KeAWiwBnxnRwQ1Tw=.9c3f6add-27b1-4eeb-a793-923b3299391a@github.com> Message-ID: On Sat, 4 Oct 2025 13:12:37 GMT, Jason Mehrens wrote: > Destroy/close not waiting on exit is correct behavior. Yes, for destroy (and clearly documented in the case destroyForcibly). It's surprising and problematic for close. It creates a usability issue when using try-with-resources as the resource (the Process in this case) is not in scope after the t-w-r statement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2403979329 From dl at openjdk.org Sat Oct 4 13:59:23 2025 From: dl at openjdk.org (Doug Lea) Date: Sat, 4 Oct 2025 13:59:23 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v12] In-Reply-To: References: Message-ID: > This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally. Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Reduce deactivate/reactivate and cancelled timeout rates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26479/files - new: https://git.openjdk.org/jdk/pull/26479/files/2c3565b5..cc61c5b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=10-11 Stats: 61 lines in 1 file changed: 7 ins; 13 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/26479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479 PR: https://git.openjdk.org/jdk/pull/26479 From duke at openjdk.org Sat Oct 4 17:23:47 2025 From: duke at openjdk.org (Jason Mehrens) Date: Sat, 4 Oct 2025 17:23:47 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v14] In-Reply-To: References: <8e40qtmHhNynhb5DabWgdCPuZG9KeAWiwBnxnRwQ1Tw=.9c3f6add-27b1-4eeb-a793-923b3299391a@github.com> Message-ID: On Sat, 4 Oct 2025 13:39:08 GMT, Alan Bateman wrote: >>>... It puts doubt into the reader's mind that the process may not have terminated and call waitFor after close to be sure. >> >> Process::isAlive may be true or false after Process::destroy. The API docs shouldn't forbid nor require a call to waitFor after close/destroy. If process is holding a lock on input file (Windows) and that caller want to delete after exit, the caller waitFor after close/destroy before calling File::delete. Destroy/close not waiting on exit is correct behavior. > >> Destroy/close not waiting on exit is correct behavior. > > Yes, for destroy (and clearly documented in the case destroyForcibly). It's surprising and problematic for close. It creates a usability issue when using try-with-resources as the resource (the Process in this case) is not in scope after the t-w-r statement. Understood. Is the implication that close should waitFor exit? That gets tricky with forever wait, timeout, or if should escalate to destroyForcibly. With regards to scope, I would have to nest try blocks which is far from ideal. If there is no preference on when streams must be closed it is a bit cleaner nesting. If I step back, the pain point with process was closing three streams which may never be accessed other than close call. In t-w-r generates a compiler warning about the local var if I recall correctly. For fire and forget processes, I don't want close call destroy. At a minimum close should close the streams. The only other thing would be to add a method to ProcessBuilder that holds close Consumer to set behavior on close, but I haven't thought that through. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2404103980 From duke at openjdk.org Sun Oct 5 00:38:55 2025 From: duke at openjdk.org (Tatsunori Uchino) Date: Sun, 5 Oct 2025 00:38:55 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v3] In-Reply-To: References: Message-ID: On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino wrote: >> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks. >> >> >> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) { >> throw new Exception("exceeding length"); >> } >> >> >> Is a CSR required to this change? > > Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision: > > - Update `@bug` in correct file > - Add default implementation on codePointCount in CharSequence > - Update `@bug` entries in test class doc comments > - Discard changes on code whose form is not `str.codePointCount(0, str.length())` > Character.codePointCount(CharSequence) > CharSequence.codePointCount I think that the problem is which of both should be _canonical_ (the other is just a call for the canonical one). public class Character { public static int codePointCount(CharSequence s) { return s.codePointCount(); } } I expect that an inline expansion is applied there. > Do we need codePointCount(int start, int end) in CharSequence too? IMO it is fine either way. It is OK to postpone/defer it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3368632586 From duke at openjdk.org Sun Oct 5 04:09:50 2025 From: duke at openjdk.org (ExE Boss) Date: Sun, 5 Oct 2025 04:09:50 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v2] In-Reply-To: References: Message-ID: On Sat, 4 Oct 2025 07:04:03 GMT, Eirik Bj?rsn?s wrote: > ``` > // IEEEremainder / remainder operator remainder > ``` > Would one remainder suffice for this remainder reminder? `IEEEremainder` differs?from the?Java?language remainder?operator, due?to?the?difference in?rounding?policy. -------------------------------------------------------------------------------- Refs: - https://docs.oracle.com/javase/specs/jvms/se25/html/jvms-6.html#jvms-6.5.drem - https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Math.html#IEEEremainder(double,double) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27625#issuecomment-3368730414 From dholmes at openjdk.org Sun Oct 5 04:52:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 5 Oct 2025 04:52:53 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 15:06:11 GMT, Alan Bateman wrote: >> I've read the JEP, and reviewed the tests. I hope I manage to contribute meaningfully. >> >> A common theme I've struggled with: While JEP explicitly mentions of `static` fields, and `MethodHandle`s, they are not always exercised in tests. It very well might be unnecessary given the context, but dropped some comments anyway. >> >> For those who were about to jump the gun after seeing no mentions of `VarHandle`s: _"The 2 APIs that are changed by the JEP are `Field.setXXX` and `Lookup.unreflectSetter`. A `VarHandle` produced by `Lookup.unreflectVarHandle` has never been allowed write access to final fields, so no change there, `UOE` will continue to be thrown."_ ? @AlanBateman > >> I've read the JEP, and reviewed the tests. I hope I manage to contribute meaningfully. > > @vy Thank you very much for your thorough review and walk through of all of the tests. You clearly spent a lot of time on this. I went through your comments and pushed an update [5acb1d727c5e0feee52c7a1f47665264eb534489]( > https://github.com/openjdk/jdk/pull/25115/commits/5acb1d727c5e0feee52c7a1f47665264eb534489) to add more tests, improves some comments, and remove the unused setInt methods that you spotted in the x-module test. Many of the tests are focused on specific parts of the solution (APIs, access checks, CLI options, JAR file manifest, JNI, ...) and I've resisted going further with some of these tests to avoid too much overlap. You have rightly identified a few opportunities for more tests, e.g. JNI attached thread doing upcall to mutate a final field in named module as the tests only checks the unnamed module case right now. This are good suggestions but they require a good bit of setup, I'll try to get to it (or find someone) so that we have more tests before we are done. @AlanBateman - Sorry should have realized this sooner. This is only the preparatory step so writing to final fields is still allowed at the moment, in which case -Xcheck:jni should only be issuing a warning, otherwise code that still writes to finals (but which knows it has to stop before final-really-means-final) won't be able to use -Xcheck:jni to watch for other problems. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3368748448 From yujige at gmail.com Sun Oct 5 05:10:46 2025 From: yujige at gmail.com (Jige Yu) Date: Sat, 4 Oct 2025 22:10:46 -0700 Subject: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees In-Reply-To: References: Message-ID: Hi, Viktor. I recently suggested mapConcurrent() for a concurrent web crawling use case. But I was presented with a test case that showed surprising results. Basically, the current behavior may look like mapConcurrent() doesn't fail fast, and doesn't cancel in-flight tasks when a task has already failed. What actually happens in the following example is that the first two tasks are sleeping, while the 3rd task has already failed. But mapConcurrent() doesn't yet know that the 3rd task has failed until the first two tasks have successfully finished sleeping. Here's the test case: int work(int input) { if (input <= 2) { try { IO.println(input + " sleeping "); Thread.sleep(2000); IO.println("Returning " + (input * 2)); return input * 2; } catch (InterruptedException e) { println("Interrupted!"); throw new RuntimeException(e); } } else { IO.println(input + " Throwing"); throw new RuntimeException(); } } @Test public void mainTest() { var start = System.currentTimeMillis(); try { List results = Stream.of(1, 2, 3).gather(mapConcurrent(3, this ::work)).toList(); println("Results = " + results); } finally { println("Took " + (System.currentTimeMillis() - start) + " ms"); } } On Mon, Jul 14, 2025 at 12:25?AM Viktor Klang wrote: > Hi Jige, > > The current behavior is what's currently achievable within the constraints > of the Gatherer-model, if that changes in the future it would also mean > that there could be stronger "guarantees" made. > > In the mean time, the good news is that if you're not satisfied with the > behavior offered by mapConcurrent()?you can create your own which does what > you want it to do! > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Sunday, 13 July 2025 05:54 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: Question about mapConcurrent() Behavior > and Happens-Before Guarantees > > Thanks for pressing on that, Viktor! > > I think I was fooled by my quick-and-dirty test. As I tried to harden it, > I failed to deduce consistent behavior about what parallel stream does when > unchecked exceptions happen. And in fact, it seems like it does *not* > interrupt pending threads (?). > > With this in mind, do you consider this behavior of mapConcurrent() > cancelling and joining the virtual threads on a best-effort basis > acceptable trade-off? > > I wonder then if it's even worth it for mapConcurrent() to try to join the > threads at all? If it can sometimes join and sometimes not, why not just > always fail fast? At least then you get consistent fail-fast behavior: if a > thread fails to respond to interruption and hangs, the main thread would > still be able to respond to the exception. > > Cheers, > > > > On Tue, Jul 8, 2025 at 2:34?AM Viktor Klang > wrote: > > >I understand that explicit API contracts are what matters. My concern, > however, is that even if the API contract explicitly states *no* happens-before > guarantee upon an unchecked exception, this behavior would still be a > significant deviation from established visibility standards in other JDK > APIs. > > Would you mind clariying *exactly* what you mean here?*what* happens-before > completion/exception? > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > ------------------------------ > *From:* Jige Yu > *Sent:* Tuesday, 8 July 2025 04:26 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* [External] : Re: Question about mapConcurrent() Behavior and > Happens-Before Guarantees > > Thanks for the quick reply, Viktor! > > On Mon, Jul 7, 2025 at 2:35?AM Viktor Klang > wrote: > > Hi Jige, > > >Initially, I thought this design choice might provide a strong > happens-before guarantee. My assumption was that an application catching a > RuntimeException would be able to *observe all side effects* from the > virtual threads, even though this practice is generally discouraged. This > seemed like a potentially significant advantage, outweighing the risk of a > virtual thread failing to respond to interruption or responding slowly. > > Unless explicitly stated in the API contract, no such guarantees should be > presumed to exist. > > > I understand that explicit API contracts are what matters. My concern, > however, is that even if the API contract explicitly states *no* happens-before > guarantee upon an unchecked exception, this behavior would still be a > significant deviation from established visibility standards in other JDK > APIs. > > For instance, both *parallel streams* and Future.get() provide a > happens-before guarantee upon completion (or exceptional completion in the > case of Future.get()). So users will most likely take it for granted. If > mapConcurrent() were to *not* offer this, it would potentially be the *first > blocking JDK API that doesn't honor happens-before* in such a scenario. > This inconsistency would likely be surprising and potentially confusing to > users who have come to expect this behavior in concurrent programming > constructs within the JDK. > > > > As for general resource-management in Stream, I have contemplated designs > for Gatherer (and Collector) to be able to participate in the onClose > actions, but there's a lot of ground to cover to ensure correct ordering > and sufficiently-encompassing of cleanup action execution. > > > Yeah. I agree that hooking into onClose() could provide a more reliable > mechanism for cleanup. > > My primary concern though, is the change it imposes on the call-site > contract. Requiring all users of mapConcurrent() to adopt a > try-with-resources syntax, while ideal for correctness, introduces a > burden and is more subject to users forgetting to do so, potentially > leading to resource leaks. > > My previously proposed collectingAndThen(toList(), list -> > list.stream().gather(mapConcurrent())) idea, on the other hand, avoids > this call-site contract change. Being a collector, it needs to first > consume the input, similar to how most Collectors operate. So it might be > a less intrusive path to ensure proper resource handling without altering > usage patterns. > > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* core-libs-dev on behalf of Jige > Yu > *Sent:* Thursday, 3 July 2025 16:36 > *To:* core-libs-dev at openjdk.org > *Subject:* Question about mapConcurrent() Behavior and Happens-Before > Guarantees > > > Hi JDK Core Devs, > > I'm writing to you today with a question about the behavior of > mapConcurrent() and its interaction with unchecked exceptions. I've been > experimenting with the API and observed that mapConcurrent() blocks and > joins all virtual threads upon an unchecked exception before propagating it. > > Initially, I thought this design choice might provide a strong > happens-before guarantee. My assumption was that an application catching a > RuntimeException would be able to *observe all side effects* from the > virtual threads, even though this practice is generally discouraged. This > seemed like a potentially significant advantage, outweighing the risk of a > virtual thread failing to respond to interruption or responding slowly. > > However, I've since realized that mapConcurrent() cannot fully guarantee > a strong happens-before relationship when an unchecked exception occurs > *somewhere* in the stream pipeline. While it can block and wait for > exceptions thrown by the mapper function or downstream operations, it > appears unable to intercept unchecked exceptions *thrown by an upstream* > source. > > Consider a scenario with two input elements: if the first element starts a > virtual thread, and then the second element causes an unchecked exception > from the upstream *before* reaching the gather() call, the virtual thread > initiated by the first element would not be interrupted. This makes the > "happens-before" guarantee quite nuanced in practice. > > This brings me to my core questions: > > 1. > > Is providing a happens-before guarantee upon an unchecked exception a > design goal for mapConcurrent()? > 2. > > If not, would it be more desirable to *not* join on virtual threads > when unchecked exceptions occur? This would allow the application code to > catch the exception sooner and avoid the risk of being blocked indefinitely. > > Thank you for your time and insights. > > Best regards, > > Ben Yu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Sun Oct 5 06:35:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 5 Oct 2025 06:35:49 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v14] In-Reply-To: References: <8e40qtmHhNynhb5DabWgdCPuZG9KeAWiwBnxnRwQ1Tw=.9c3f6add-27b1-4eeb-a793-923b3299391a@github.com> Message-ID: On Sat, 4 Oct 2025 17:21:09 GMT, Jason Mehrens wrote: > Understood. Is the implication that close should waitFor exit? That gets tricky with forever wait, timeout, or if should escalate to destroyForcibly. We retrofitted ExecutorService to implement AutoCloseable in JDK 19 and I think the effort on Process may be able to get some inspiration from [ExecutorService::close](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/ExecutorService.html#close()). The equivalent for Process could be destroy + untimed waitFor, with destroyForcibly and continue waiting if interrupted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2404309276 From viktor.klang at oracle.com Sun Oct 5 09:13:48 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Sun, 5 Oct 2025 09:13:48 +0000 Subject: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees In-Reply-To: References: Message-ID: Hi Jige, Thanks for your question! It is important to acknowledge that Gatherers.mapConcurrent() does not specify fail-fast behavior. From https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function) "In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements." This does not refer to failed tasks "If a result of the function is to be pushed downstream but instead the function completed exceptionally then the corresponding exception will instead be rethrown by this method as an instance of RuntimeException, after which any remaining tasks are canceled." Since mapConcurrent is in-order, "is to be pushed downstream" means that it is next in line. Now, I'm not saying that fail-fast wouldn't be desirable behavior, but it would require research into how to implement it without breaking observable behavior. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle Confidential ? Oracle Internal ________________________________ From: Jige Yu Sent: Sunday, 5 October 2025 07:10 To: Viktor Klang Cc: core-libs-dev at openjdk.org Subject: Re: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees Hi, Viktor. I recently suggested mapConcurrent() for a concurrent web crawling use case. But I was presented with a test case that showed surprising results. Basically, the current behavior may look like mapConcurrent() doesn't fail fast, and doesn't cancel in-flight tasks when a task has already failed. What actually happens in the following example is that the first two tasks are sleeping, while the 3rd task has already failed. But mapConcurrent() doesn't yet know that the 3rd task has failed until the first two tasks have successfully finished sleeping. Here's the test case: int work(int input) { if (input <= 2) { try { IO.println(input + " sleeping "); Thread.sleep(2000); IO.println("Returning " + (input * 2)); return input * 2; } catch (InterruptedException e) { println("Interrupted!"); throw new RuntimeException(e); } } else { IO.println(input + " Throwing"); throw new RuntimeException(); } } @Test public void mainTest() { var start = System.currentTimeMillis(); try { List results = Stream.of(1, 2, 3).gather(mapConcurrent(3, this::work)).toList(); println("Results = " + results); } finally { println("Took " + (System.currentTimeMillis() - start) + " ms"); } } On Mon, Jul 14, 2025 at 12:25?AM Viktor Klang > wrote: Hi Jige, The current behavior is what's currently achievable within the constraints of the Gatherer-model, if that changes in the future it would also mean that there could be stronger "guarantees" made. In the mean time, the good news is that if you're not satisfied with the behavior offered by mapConcurrent()?you can create your own which does what you want it to do! Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Sunday, 13 July 2025 05:54 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees Thanks for pressing on that, Viktor! I think I was fooled by my quick-and-dirty test. As I tried to harden it, I failed to deduce consistent behavior about what parallel stream does when unchecked exceptions happen. And in fact, it seems like it does *not* interrupt pending threads (?). With this in mind, do you consider this behavior of mapConcurrent() cancelling and joining the virtual threads on a best-effort basis acceptable trade-off? I wonder then if it's even worth it for mapConcurrent() to try to join the threads at all? If it can sometimes join and sometimes not, why not just always fail fast? At least then you get consistent fail-fast behavior: if a thread fails to respond to interruption and hangs, the main thread would still be able to respond to the exception. Cheers, On Tue, Jul 8, 2025 at 2:34?AM Viktor Klang > wrote: >I understand that explicit API contracts are what matters. My concern, however, is that even if the API contract explicitly states no happens-before guarantee upon an unchecked exception, this behavior would still be a significant deviation from established visibility standards in other JDK APIs. Would you mind clariying exactly what you mean here?what happens-before completion/exception? Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Tuesday, 8 July 2025 04:26 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees Thanks for the quick reply, Viktor! On Mon, Jul 7, 2025 at 2:35?AM Viktor Klang > wrote: Hi Jige, >Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a RuntimeException would be able to observe all side effects from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing to respond to interruption or responding slowly. Unless explicitly stated in the API contract, no such guarantees should be presumed to exist. I understand that explicit API contracts are what matters. My concern, however, is that even if the API contract explicitly states no happens-before guarantee upon an unchecked exception, this behavior would still be a significant deviation from established visibility standards in other JDK APIs. For instance, both parallel streams and Future.get() provide a happens-before guarantee upon completion (or exceptional completion in the case of Future.get()). So users will most likely take it for granted. If mapConcurrent() were to not offer this, it would potentially be the first blocking JDK API that doesn't honor happens-before in such a scenario. This inconsistency would likely be surprising and potentially confusing to users who have come to expect this behavior in concurrent programming constructs within the JDK. As for general resource-management in Stream, I have contemplated designs for Gatherer (and Collector) to be able to participate in the onClose actions, but there's a lot of ground to cover to ensure correct ordering and sufficiently-encompassing of cleanup action execution. Yeah. I agree that hooking into onClose() could provide a more reliable mechanism for cleanup. My primary concern though, is the change it imposes on the call-site contract. Requiring all users of mapConcurrent() to adopt a try-with-resources syntax, while ideal for correctness, introduces a burden and is more subject to users forgetting to do so, potentially leading to resource leaks. My previously proposed collectingAndThen(toList(), list -> list.stream().gather(mapConcurrent())) idea, on the other hand, avoids this call-site contract change. Being a collector, it needs to first consume the input, similar to how most Collectors operate. So it might be a less intrusive path to ensure proper resource handling without altering usage patterns. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev > on behalf of Jige Yu > Sent: Thursday, 3 July 2025 16:36 To: core-libs-dev at openjdk.org > Subject: Question about mapConcurrent() Behavior and Happens-Before Guarantees Hi JDK Core Devs, I'm writing to you today with a question about the behavior of mapConcurrent() and its interaction with unchecked exceptions. I've been experimenting with the API and observed that mapConcurrent() blocks and joins all virtual threads upon an unchecked exception before propagating it. Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a RuntimeException would be able to observe all side effects from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing to respond to interruption or responding slowly. However, I've since realized that mapConcurrent() cannot fully guarantee a strong happens-before relationship when an unchecked exception occurs somewhere in the stream pipeline. While it can block and wait for exceptions thrown by the mapper function or downstream operations, it appears unable to intercept unchecked exceptions thrown by an upstream source. Consider a scenario with two input elements: if the first element starts a virtual thread, and then the second element causes an unchecked exception from the upstream before reaching the gather() call, the virtual thread initiated by the first element would not be interrupted. This makes the "happens-before" guarantee quite nuanced in practice. This brings me to my core questions: 1. Is providing a happens-before guarantee upon an unchecked exception a design goal for mapConcurrent()? 2. If not, would it be more desirable to not join on virtual threads when unchecked exceptions occur? This would allow the application code to catch the exception sooner and avoid the risk of being blocked indefinitely. Thank you for your time and insights. Best regards, Ben Yu -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at openjdk.org Sun Oct 5 09:29:47 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 5 Oct 2025 09:29:47 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v2] In-Reply-To: References: Message-ID: <5K7SH3l1fa6Hbfl4sMrpdpf96tJgOsxNI_jZ5n9oso4=.32c6c675-dba7-4cdb-8eee-e5b88e336062@github.com> On Fri, 3 Oct 2025 22:12:19 GMT, Joe Darcy wrote: >> Upon further inspection, found a few more opportunities to refine the use of constants in the Float16 implementation. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded use of "Float16.". > > ``` > > // IEEEremainder / remainder operator remainder > > ``` > `IEEEremainder` differs?from the?Java?language remainder?operator, due?to?the?difference in?rounding?policy. Thanks for providing context, it makes the sentence easier to understand. I now parse "remainder operator remainder" as "the remainder function as defined by JVM drem/frem bytecodes". The comment seems a bit terse in its current form, more of a note-to-self reminder of future implementation ideas. Usually comments refer to current functionality, so this was sticking out to me as somewhat unusual. @jddarcy may have an opinion here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27625#issuecomment-3368894135 From alanb at openjdk.org Sun Oct 5 13:52:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 5 Oct 2025 13:52:50 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: <1Ed3XduxQZKSVBUng2-sUeD1ib9ZZqRQBN18n0SrAwY=.496748d7-01f9-4b9f-a184-d364f3d7d0f2@github.com> On Tue, 30 Sep 2025 15:06:11 GMT, Alan Bateman wrote: >> I've read the JEP, and reviewed the tests. I hope I manage to contribute meaningfully. >> >> A common theme I've struggled with: While JEP explicitly mentions of `static` fields, and `MethodHandle`s, they are not always exercised in tests. It very well might be unnecessary given the context, but dropped some comments anyway. >> >> For those who were about to jump the gun after seeing no mentions of `VarHandle`s: _"The 2 APIs that are changed by the JEP are `Field.setXXX` and `Lookup.unreflectSetter`. A `VarHandle` produced by `Lookup.unreflectVarHandle` has never been allowed write access to final fields, so no change there, `UOE` will continue to be thrown."_ ? @AlanBateman > >> I've read the JEP, and reviewed the tests. I hope I manage to contribute meaningfully. > > @vy Thank you very much for your thorough review and walk through of all of the tests. You clearly spent a lot of time on this. I went through your comments and pushed an update [5acb1d727c5e0feee52c7a1f47665264eb534489]( > https://github.com/openjdk/jdk/pull/25115/commits/5acb1d727c5e0feee52c7a1f47665264eb534489) to add more tests, improves some comments, and remove the unused setInt methods that you spotted in the x-module test. Many of the tests are focused on specific parts of the solution (APIs, access checks, CLI options, JAR file manifest, JNI, ...) and I've resisted going further with some of these tests to avoid too much overlap. You have rightly identified a few opportunities for more tests, e.g. JNI attached thread doing upcall to mutate a final field in named module as the tests only checks the unnamed module case right now. This are good suggestions but they require a good bit of setup, I'll try to get to it (or find someone) so that we have more tests before we are done. > @AlanBateman - Sorry should have realized this sooner. This is only the preparatory step so writing to final fields is still allowed at the moment, in which case -Xcheck:jni should only be issuing a warning, otherwise code that still writes to finals (but which knows it has to stop before final-really-means-final) won't be able to use -Xcheck:jni to watch for other problems. JEP 500 is about using deep reflection to mutate final instance fields. It defines the CLI option to enable final field mutation for specific modules and the CLI option to determine the action when illegal final field mutation is attempted. The proposal is to start with the the action "warn" as the default, some future JEP will propose to change it to "deny" and drop the "allow" action. The JEP does not propose to change JNI. Native code that uses JNI to mutate final instance or final static fields will work as before and in the future. So JNI is outside of the fold and the CLI option to allow/warn/deny does not apply to JNI. The roadmap to move to "deny" by default does not include JNI. The change to the JNI implementation is limited to logging with -Xlog:jni=debug and a fatal error when running with -Xcheck:jni. I think what you are suggesting is that the JEP could instead have -Xcheck:jni emit a warning when JNI setter functions mutate final fields, and maybe change it to be a fatal error in the future, maybe as part of the future JEP that proposes to move "deny" the default. I don't see any issue with changing that section of the JEP but only if Ron/Alex agree. TBH, aside from the write-protected fields that are System.in/out/errr, it should be very rare to encounter native code mutating final fields. A more gentle transition for -Xcheck:jni users might not make any difference. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3369072100 From yujige at gmail.com Sun Oct 5 17:06:24 2025 From: yujige at gmail.com (Jige Yu) Date: Sun, 5 Oct 2025 10:06:24 -0700 Subject: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees In-Reply-To: References: Message-ID: Hi Viktor, Thanks again for explaining the current in-order contract. While I understand the implementation is currently compliant with the Javadoc, I have a few additional concerns about the practical consequences of this delayed exception propagation. Potential for Starvation While in theory it's also a lack of fail fast, it may show up more like a *starvation or system hangs* in certain concurrent architectures. Imagine a scenario where the virtual threads are consuming work items from a shared, blocking queue (like what's being discussed in the other thread, the virtual threads could themselves be producing data into the queue): 1. Task 3 successfully takes an item from the queue and then immediately fails with an exception, without producing any data into the queue. 2. Tasks 1 and 2 block on the queue to get their work items, *indefinitely*. 3. Because the exception from Task 3 is not propagated until Tasks 1 and 2 finish, the main thread or stream pipeline is blocked indefinitely if Tasks 1 or 2 hang. 4. The work item consumed by Task 3 is lost, and the system is effectively halted, as the failure isn't reported and cleanup/cancellation is delayed. So, except performance hit; it creates stability and liveness issues. ------------------------------ Ambiguity in Current Javadoc Regarding the Javadoc, while I did read it, I found the lack of an explicit fail-fast guarantee and the precise timing of exception propagation to be subtle. The phrase, *"If a result of the function is to be pushed downstream,"* seems to leave ample room for interpretation, and it was not immediately clear whether the lack of fail-fast was an intentional design choice versus a side effect of the in-order implementation. Clarifying this timing can probably improve the API's contract clarity. ------------------------------ Re-evaluating the "In-Order" Contract Apologies for circling back to the same "in-order" question that has already been discussed. But from a usability perspective, I suggest we also bring the *"in-order" contract itself* up for discussion. I believe that the issues we've identified?the potential for starvation/hanging and the earlier discussed concurrency throughput concerns?are significant, realistic downsides of requiring strict in-order processing. These drawbacks should be carefully weighed against the benefits of the "in-order" contract, especially for concurrent processing APIs intended for I/O-bound tasks where strict ordering often has minimal value compared to resilience and performance. If it's a trade off between having *in-order or fail-fast* (but not both simultaneously), it may warrant some more consideration about which is more useful. Particularly, Java users have traditionally been educated that parallel streams don't necessarily retain encounter order. Cheers, On Sun, Oct 5, 2025 at 2:13?AM Viktor Klang wrote: > Hi Jige, > > Thanks for your question! > > It is important to acknowledge that Gatherers.mapConcurrent() does not > specify fail-fast behavior. > > From > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function) > > *"In progress tasks will be attempted to be cancelled, on a best-effort > basis, in situations where the downstream no longer wants to receive any > more elements."* > > This does not refer to failed tasks > > *"If a result of the function is to be pushed downstream but instead the > function completed exceptionally then the corresponding exception will > instead be rethrown by this method as an instance of **RuntimeException > **, > after which any remaining tasks are canceled."* > > Since mapConcurrent is in-order, "is to be pushed downstream" means that > it is next in line. > > > > Now, I'm not saying that fail-fast wouldn't be desirable behavior, but it > would require research into how to implement it without breaking observable > behavior. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > Confidential ? Oracle Internal > ------------------------------ > *From:* Jige Yu > *Sent:* Sunday, 5 October 2025 07:10 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: Question about mapConcurrent() Behavior > and Happens-Before Guarantees > > Hi, Viktor. > > I recently suggested mapConcurrent() for a concurrent web crawling use > case. But I was presented with a test case that showed surprising results. > Basically, the current behavior may look like mapConcurrent() doesn't fail > fast, and doesn't cancel in-flight tasks when a task has already failed. > > What actually happens in the following example is that the first two tasks > are sleeping, while the 3rd task has already failed. But mapConcurrent() > doesn't yet know that the 3rd task has failed until the first two tasks > have successfully finished sleeping. > > Here's the test case: > > int work(int input) { > > if (input <= 2) { > > try { > > IO.println(input + " sleeping "); > > Thread.sleep(2000); > > IO.println("Returning " + (input * 2)); > > return input * 2; > > } catch (InterruptedException e) { > > println("Interrupted!"); > > throw new RuntimeException(e); > > } > > } else { > > IO.println(input + " Throwing"); > > throw new RuntimeException(); > > } > > } > > > @Test public void mainTest() { > > var start = System.currentTimeMillis(); > > try { > > List results = Stream.of(1, 2, 3).gather(mapConcurrent(3, this > ::work)).toList(); > > println("Results = " + results); > > } finally { > > println("Took " + (System.currentTimeMillis() - start) + " ms"); > > } > > } > > > > > On Mon, Jul 14, 2025 at 12:25?AM Viktor Klang > wrote: > > Hi Jige, > > The current behavior is what's currently achievable within the constraints > of the Gatherer-model, if that changes in the future it would also mean > that there could be stronger "guarantees" made. > > In the mean time, the good news is that if you're not satisfied with the > behavior offered by mapConcurrent()?you can create your own which does what > you want it to do! > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Sunday, 13 July 2025 05:54 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: Question about mapConcurrent() Behavior > and Happens-Before Guarantees > > Thanks for pressing on that, Viktor! > > I think I was fooled by my quick-and-dirty test. As I tried to harden it, > I failed to deduce consistent behavior about what parallel stream does when > unchecked exceptions happen. And in fact, it seems like it does *not* > interrupt pending threads (?). > > With this in mind, do you consider this behavior of mapConcurrent() > cancelling and joining the virtual threads on a best-effort basis > acceptable trade-off? > > I wonder then if it's even worth it for mapConcurrent() to try to join the > threads at all? If it can sometimes join and sometimes not, why not just > always fail fast? At least then you get consistent fail-fast behavior: if a > thread fails to respond to interruption and hangs, the main thread would > still be able to respond to the exception. > > Cheers, > > > > On Tue, Jul 8, 2025 at 2:34?AM Viktor Klang > wrote: > > >I understand that explicit API contracts are what matters. My concern, > however, is that even if the API contract explicitly states *no* happens-before > guarantee upon an unchecked exception, this behavior would still be a > significant deviation from established visibility standards in other JDK > APIs. > > Would you mind clariying *exactly* what you mean here?*what* happens-before > completion/exception? > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > ------------------------------ > *From:* Jige Yu > *Sent:* Tuesday, 8 July 2025 04:26 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* [External] : Re: Question about mapConcurrent() Behavior and > Happens-Before Guarantees > > Thanks for the quick reply, Viktor! > > On Mon, Jul 7, 2025 at 2:35?AM Viktor Klang > wrote: > > Hi Jige, > > >Initially, I thought this design choice might provide a strong > happens-before guarantee. My assumption was that an application catching a > RuntimeException would be able to *observe all side effects* from the > virtual threads, even though this practice is generally discouraged. This > seemed like a potentially significant advantage, outweighing the risk of a > virtual thread failing to respond to interruption or responding slowly. > > Unless explicitly stated in the API contract, no such guarantees should be > presumed to exist. > > > I understand that explicit API contracts are what matters. My concern, > however, is that even if the API contract explicitly states *no* happens-before > guarantee upon an unchecked exception, this behavior would still be a > significant deviation from established visibility standards in other JDK > APIs. > > For instance, both *parallel streams* and Future.get() provide a > happens-before guarantee upon completion (or exceptional completion in the > case of Future.get()). So users will most likely take it for granted. If > mapConcurrent() were to *not* offer this, it would potentially be the *first > blocking JDK API that doesn't honor happens-before* in such a scenario. > This inconsistency would likely be surprising and potentially confusing to > users who have come to expect this behavior in concurrent programming > constructs within the JDK. > > > > As for general resource-management in Stream, I have contemplated designs > for Gatherer (and Collector) to be able to participate in the onClose > actions, but there's a lot of ground to cover to ensure correct ordering > and sufficiently-encompassing of cleanup action execution. > > > Yeah. I agree that hooking into onClose() could provide a more reliable > mechanism for cleanup. > > My primary concern though, is the change it imposes on the call-site > contract. Requiring all users of mapConcurrent() to adopt a > try-with-resources syntax, while ideal for correctness, introduces a > burden and is more subject to users forgetting to do so, potentially > leading to resource leaks. > > My previously proposed collectingAndThen(toList(), list -> > list.stream().gather(mapConcurrent())) idea, on the other hand, avoids > this call-site contract change. Being a collector, it needs to first > consume the input, similar to how most Collectors operate. So it might be > a less intrusive path to ensure proper resource handling without altering > usage patterns. > > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* core-libs-dev on behalf of Jige > Yu > *Sent:* Thursday, 3 July 2025 16:36 > *To:* core-libs-dev at openjdk.org > *Subject:* Question about mapConcurrent() Behavior and Happens-Before > Guarantees > > > Hi JDK Core Devs, > > I'm writing to you today with a question about the behavior of > mapConcurrent() and its interaction with unchecked exceptions. I've been > experimenting with the API and observed that mapConcurrent() blocks and > joins all virtual threads upon an unchecked exception before propagating it. > > Initially, I thought this design choice might provide a strong > happens-before guarantee. My assumption was that an application catching a > RuntimeException would be able to *observe all side effects* from the > virtual threads, even though this practice is generally discouraged. This > seemed like a potentially significant advantage, outweighing the risk of a > virtual thread failing to respond to interruption or responding slowly. > > However, I've since realized that mapConcurrent() cannot fully guarantee > a strong happens-before relationship when an unchecked exception occurs > *somewhere* in the stream pipeline. While it can block and wait for > exceptions thrown by the mapper function or downstream operations, it > appears unable to intercept unchecked exceptions *thrown by an upstream* > source. > > Consider a scenario with two input elements: if the first element starts a > virtual thread, and then the second element causes an unchecked exception > from the upstream *before* reaching the gather() call, the virtual thread > initiated by the first element would not be interrupted. This makes the > "happens-before" guarantee quite nuanced in practice. > > This brings me to my core questions: > > 1. > > Is providing a happens-before guarantee upon an unchecked exception a > design goal for mapConcurrent()? > 2. > > If not, would it be more desirable to *not* join on virtual threads > when unchecked exceptions occur? This would allow the application code to > catch the exception sooner and avoid the risk of being blocked indefinitely. > > Thank you for your time and insights. > > Best regards, > > Ben Yu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.org Mon Oct 6 02:56:45 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 6 Oct 2025 02:56:45 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v2] In-Reply-To: <5K7SH3l1fa6Hbfl4sMrpdpf96tJgOsxNI_jZ5n9oso4=.32c6c675-dba7-4cdb-8eee-e5b88e336062@github.com> References: <5K7SH3l1fa6Hbfl4sMrpdpf96tJgOsxNI_jZ5n9oso4=.32c6c675-dba7-4cdb-8eee-e5b88e336062@github.com> Message-ID: On Sun, 5 Oct 2025 09:27:23 GMT, Eirik Bj?rsn?s wrote: > > > ``` > > > // IEEEremainder / remainder operator remainder > > > ``` > > > `IEEEremainder` differs from the Java language remainder operator, due to the difference in rounding policy. > > Thanks for providing context, it makes the sentence easier to understand. I now parse "remainder operator remainder" as "the remainder function as defined by JVM drem/frem bytecodes". > > The comment seems a bit terse in its current form, more of a note-to-self reminder of future implementation ideas. Usually comments refer to current functionality, so this was sticking out to me as somewhat unusual. @jddarcy may have an opinion here. You are correct that the comment is a note-to-self/note-to-future maintainers. I'll expand the note to give some more details on IEEE remainder vs % remainder. I think occasional comments like this, which are only visible to readers of the source code of course, are acceptable in production code and also acceptable in incubating code like this. Thanks for the careful reading. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27625#issuecomment-3369755566 From darcy at openjdk.org Mon Oct 6 03:33:48 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 6 Oct 2025 03:33:48 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v2] In-Reply-To: References: Message-ID: On Sat, 4 Oct 2025 07:04:03 GMT, Eirik Bj?rsn?s wrote: > ``` > // Currently Float16 is a value-based class and in future it is > ``` > > in _the_ future > > ``` > // IEEEremainder / remainder operator remainder > ``` > > Would one remainder suffice for this remainder reminder? > > ``` > private final short value; > ``` > > Consider adding a field comment to align with Float, Double and friends. > > ``` > private static final Float16 ZERO = valueOf(0); > ``` > > Other private implementation constants in this class have comments. These would be rather obvious, but perheps we can consider adding them just for consistency? > > Should we consider ordering private vs. public constants? Now they seem a bit mingled, making it harder for the eye to scan the public API of the class. > > Line 372: > > ``` > return new Float16((short)(sign_bit | 0x7c00)); > ``` > > `0x7c00` here is `EXP_BIT_MASK`, right? > > ``` > // toHexString, line 288: > return s.replaceFirst("p-1022$", "p-14"); > ``` > > Are we okay to invoke regex from such low level code? I'll push an update to address most of these points. For the use of regex, is it an aesthetics question or a JDK bootstrapping question? For aesthetics, I think it is fine --the code concisely conveys the intention of the desired transform and is shorter than writing out the needed state machine by hand. If this code turned out to be high duty cycle and the regex overhead was a problem, it would be reasonable to re-implement the functionality more directly. For bootstrapping that isn't a direct concern here in an incubating type, but this code was ported over from java.lang.Float so I'll address the comment. Even it use of regex in the wrapper classes would be a problem in theory, this particular use doesn't seem to be a problem in practice since the code in Float has been stable for at least 18 years, and probably a few years longer going to back to JDK 5 when hex floating-point literals were introduced. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27625#issuecomment-3369801040 From darcy at openjdk.org Mon Oct 6 03:51:37 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 6 Oct 2025 03:51:37 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v3] In-Reply-To: References: Message-ID: <53TQElZXlK-Rwj-NwOl-noceHQ5AwuZTcNbXy5okGcs=.356ee1d6-5d14-44f5-b8a7-e4a16d89ba0d@github.com> > Upon further inspection, found a few more opportunities to refine the use of constants in the Float16 implementation. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8369123 - Remove unneeded use of "Float16.". - JDK-8369123: Still more small Float16 refactorings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27625/files - new: https://git.openjdk.org/jdk/pull/27625/files/be2b4ab8..458bf671 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27625&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27625&range=01-02 Stats: 6331 lines in 282 files changed: 3820 ins; 1144 del; 1367 mod Patch: https://git.openjdk.org/jdk/pull/27625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27625/head:pull/27625 PR: https://git.openjdk.org/jdk/pull/27625 From thartmann at openjdk.org Mon Oct 6 07:52:54 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 6 Oct 2025 07:52:54 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v12] In-Reply-To: References: Message-ID: <3hRTOJiGlZXrFqy7m3loXdorkRmyL3zb7hwyrwi8b6w=.0c159d31-bab3-4ed1-94a5-23b33bad457d@github.com> On Sat, 4 Oct 2025 06:01:07 GMT, Jatin Bhateja wrote: >> This patch optimizes PopCount value transforms using KnownBits information. >> Following are the results of the micro-benchmark included with the patch >> >> >> >> System: 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark Mode Cnt Score Error Units >> PopCountValueTransform.LogicFoldingKerenLong thrpt 2 215460.670 ops/s >> PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 294014.826 ops/s >> >> Withopt: >> Benchmark Mode Cnt Score Error Units >> PopCountValueTransform.LogicFoldingKerenLong thrpt 2 389978.082 ops/s >> PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 417261.583 ops/s >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolution Testing all passed. I'll pass the review to someone else. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27075#issuecomment-3370347366 From eirbjo at openjdk.org Mon Oct 6 08:04:47 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 6 Oct 2025 08:04:47 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v2] In-Reply-To: References: Message-ID: <4k8Zz0BSEO6C25i0EVTjFv8LAqmfNJsi9q--Z0blU4Y=.a3bd3711-789c-4740-97e6-1df03d27c1ef@github.com> On Mon, 6 Oct 2025 03:31:14 GMT, Joe Darcy wrote: > For the use of regex, is it an aesthetics question or a JDK bootstrapping question? Thanks for your consideration. This particular regex seems fine aesthetically. Having been bitten by performance suprises in the past, it raises my eyebrows when regex-dependent String functions are used in platform, library or otherwise low-level code. This looks like an edge-case, and as you note it is pre-existing. So yes, probably fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27625#issuecomment-3370383011 From eirbjo at openjdk.org Mon Oct 6 08:09:51 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 6 Oct 2025 08:09:51 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v12] In-Reply-To: References: Message-ID: <9EL8Kg6tW9JVZHrelcP7bLCRHpoEd1l6YH_0eLe8U5Y=.a9db2c93-7a94-46a5-b90e-c104eddf6bc3@github.com> On Sat, 4 Oct 2025 06:01:07 GMT, Jatin Bhateja wrote: >> This patch optimizes PopCount value transforms using KnownBits information. >> Following are the results of the micro-benchmark included with the patch >> >> >> >> System: 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark Mode Cnt Score Error Units >> PopCountValueTransform.LogicFoldingKerenLong thrpt 2 215460.670 ops/s >> PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 294014.826 ops/s >> >> Withopt: >> Benchmark Mode Cnt Score Error Units >> PopCountValueTransform.LogicFoldingKerenLong thrpt 2 389978.082 ops/s >> PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 417261.583 ops/s >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolution Is the `core-libs` label appropriate for this PR? Looks hotspot specific? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27075#issuecomment-3370399830 From fbredberg at openjdk.org Mon Oct 6 08:13:03 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 6 Oct 2025 08:13:03 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 13:35:52 GMT, Fredrik Bredberg wrote: >> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need: >> - `_held_monitor_count` >> - `_parent_held_monitor_count` >> - `_jni_monitor_count` >> >> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`. >> They are not present in other platforms. >> >> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change. >> `PowerPC` and `RISC-V` has been sanity checked using QEMU. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Update after review Thank you all for the reviews. Now let's... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3370402267 From fbredberg at openjdk.org Mon Oct 6 08:13:04 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 6 Oct 2025 08:13:04 GMT Subject: Integrated: 8367601: Remove held_monitor_count In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 09:43:51 GMT, Fredrik Bredberg wrote: > Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need: > - `_held_monitor_count` > - `_parent_held_monitor_count` > - `_jni_monitor_count` > > This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`. > They are not present in other platforms. > > Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change. > `PowerPC` and `RISC-V` has been sanity checked using QEMU. This pull request has now been integrated. Changeset: e6781fd9 Author: Fredrik Bredberg URL: https://git.openjdk.org/jdk/commit/e6781fd9497723a7baab38d6bfb958ba1b1c24ff Stats: 401 lines in 27 files changed: 0 ins; 384 del; 17 mod 8367601: Remove held_monitor_count Reviewed-by: mdoerr, pchilanomate, fyang ------------- PR: https://git.openjdk.org/jdk/pull/27570 From hgreule at openjdk.org Mon Oct 6 08:14:50 2025 From: hgreule at openjdk.org (Hannes Greule) Date: Mon, 6 Oct 2025 08:14:50 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v12] In-Reply-To: <9EL8Kg6tW9JVZHrelcP7bLCRHpoEd1l6YH_0eLe8U5Y=.a9db2c93-7a94-46a5-b90e-c104eddf6bc3@github.com> References: <9EL8Kg6tW9JVZHrelcP7bLCRHpoEd1l6YH_0eLe8U5Y=.a9db2c93-7a94-46a5-b90e-c104eddf6bc3@github.com> Message-ID: <0n629aakXFsODeKAbtRtvDTbaCHEt18Mc9LFlAb-G2o=.8be1175e-cebc-4395-b44e-973df41507cf@github.com> On Mon, 6 Oct 2025 08:07:14 GMT, Eirik Bj?rsn?s wrote: > Is the `core-libs` label appropriate for this PR? Looks hotspot specific? That label was added automatically, closely after https://mail.openjdk.org/pipermail/jdk-dev/2025-September/010486.html. Not sure why, but the change is definitely hotspot specific. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27075#issuecomment-3370417585 From shade at openjdk.org Mon Oct 6 09:04:01 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 6 Oct 2025 09:04:01 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 13:35:52 GMT, Fredrik Bredberg wrote: >> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need: >> - `_held_monitor_count` >> - `_parent_held_monitor_count` >> - `_jni_monitor_count` >> >> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`. >> They are not present in other platforms. >> >> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change. >> `PowerPC` and `RISC-V` has been sanity checked using QEMU. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Update after review Good cleanup, thanks! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27570#pullrequestreview-3303476645 From mchhipa at openjdk.org Mon Oct 6 10:13:21 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Mon, 6 Oct 2025 10:13:21 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v3] In-Reply-To: References: Message-ID: > Update SimpleHttpServer class to use SimpleFileServer. Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Added jdk.test.lib.net.URIBuilder import. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27608/files - new: https://git.openjdk.org/jdk/pull/27608/files/64cad93a..53e6a665 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27608/head:pull/27608 PR: https://git.openjdk.org/jdk/pull/27608 From dclarke at openjdk.org Mon Oct 6 10:18:50 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Mon, 6 Oct 2025 10:18:50 GMT Subject: RFR: 8368877: Generate Jextract bindings for Kqueue [v2] In-Reply-To: References: Message-ID: > This PR is based on #25546 , though it was suggested to split that PR into 2 for easier reviewing and to give better visibility in the git history. > This PR contains all the JExtract generated code that will be needed for converting Java's KQueue implementation to use Panama features instead of JNI. The actual updates to KQueue to make use of these files will come in the second PR. > > The basic structure here has the different native structures and methods split into 3 different packages all preceded by > `src/java.base/macosx/classes/jdk/internal/ffi/generated/` > Included in each package is a file `package-info.java` which contains the script that was used to generate these files so that others can reproduce them in future. > > The only modifications that have been made to the files post-generation are: > - Adding copyright headers > - Adding warning suppression for using restricted methods > > Some further modifications to these files to cut down on code duplication and adding support for errno handling on the native calls will come in the 2nd PR alongside the KQueue changes mentioned. Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision: Addressed comment and fixed newlines at end of files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27590/files - new: https://git.openjdk.org/jdk/pull/27590/files/53c387e4..d7b43cbc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27590&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27590&range=00-01 Stats: 13 lines in 11 files changed: 0 ins; 8 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27590.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27590/head:pull/27590 PR: https://git.openjdk.org/jdk/pull/27590 From cushon at google.com Mon Oct 6 11:10:18 2025 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 6 Oct 2025 13:10:18 +0200 Subject: HDR image support Message-ID: Hi, Are there any plans around HDR image support in the JDK? My colleague Alec Mouri provides the following background: Advancements in display and imaging technology have enabled HDR (High Dynamic Range) content, which allows for displaying content at a greater luminance than SDR (Standard Dynamic Range) content. Google and Adobe have informative blog posts explaining this new technology. HDR images are part of intentional standards ISO 22028-5 and ISO 21496-1 . ISO 21496-1 in particular is heavily used by the mobile ecosystem to generate high-quality images. See the UltraHDR image format as an example. Every major operating system now has support for rendering HDR GUIs. See: Android?s ExtendedRangeBrightness and COLOR_MODE_HDR , Apple?s EDR , and Wayland?s HDR Protocol , and Window?s Advanced Color . Platforms built on top of these OSs are accordingly adding support for HDR. See: QT and CSS . Support in the JDK would involve decoding and display support. Decoding support could be added to Image I/O. For ISO 22028-5, this means that ICC_ColorSpace could support CICPs as described in ITU-T H.273 to represent HLG and PQ encodings. For ISO 21496-1, this means that BufferedImage could be decorated with a gainmap representation. Display support could be added to Swing and JavaFX. This would involve interacting with each major OS?s capabilities to color manage and draw HDR images through ImageIcon or JComponent. Note that SDR content should not be colorimetrically affected when there is no HDR on screen. I.e., the rest of the UI should not ?flicker?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prappo at openjdk.org Mon Oct 6 11:32:51 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 6 Oct 2025 11:32:51 GMT Subject: RFR: 8366829: Add java.time.Duration constants MIN and MAX [v3] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 09:50:23 GMT, Pavel Rappo wrote: >> We have [recently discussed][] a possibility of adding the `Duration.MIN` and `Duration.MAX` constants. Can we now start implementation? If and when we are in agreement on this PR, I will file a CSR. >> >> I drafted a minimal specification and added some tests. I tried to phrase the spec for `Duration.MIN` in a way that makes it clear that `Duration.MIN` is the most negative value and not the least positive. >> >> [recently discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Respond to feedback > > Apply Stephen's suggestion on wording, although modified. Thanks for the reviews. I'll draft the CSR shortly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27534#issuecomment-3371166113 From alan.bateman at oracle.com Mon Oct 6 11:52:48 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Mon, 6 Oct 2025 12:52:48 +0100 Subject: HDR image support In-Reply-To: References: Message-ID: It would be better to bring this to client-dev as this is where the image APIs are maintained. -Alan On 06/10/2025 12:10, Liam Miller-Cushon wrote: > > Hi, > > > Are there any plans around HDR image support in the JDK? > > > My colleague Alec Mouri provides the following background: > > > Advancements in display and imaging technology have enabled HDR (High > Dynamic Range) content, which allows for displaying content at a > greater luminance than SDR (Standard Dynamic Range) content. Google > and > Adobe have > informative blog posts explaining this new technology. > > > HDR images are part of intentional standards ISO 22028-5 > and ISO 21496-1 > . ISO 21496-1 in particular > is heavily used by the mobile ecosystem to generate high-quality > images. See the UltraHDR > image > format as an example. > > > Every major operating system now has support for rendering HDR GUIs. > See: Android?s ExtendedRangeBrightness > and > COLOR_MODE_HDR > , > Apple?s EDR > , > and Wayland?s HDR Protocol > , and Window?s > Advanced Color > . > > > Platforms built on top of these OSs are accordingly adding support for > HDR. See: QT and CSS > . > > > Support in the JDK would involve decoding and display support. > > > Decoding support could be added to Image I/O. For ISO 22028-5, this > means that ICC_ColorSpace > could > support CICPs as described in ITU-T H.273 > to represent HLG and PQ > encodings. For ISO 21496-1, this means that BufferedImage > could > be decorated with a gainmap representation. > > > Display support could be added to Swing and JavaFX. This would involve > interacting with each major OS?s capabilities to color manage and draw > HDR images through ImageIcon or JComponent. Note that SDR content > should not be colorimetrically affected when there is no HDR on > screen. I.e., the rest of the UI should not ?flicker?. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Mon Oct 6 11:57:02 2025 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 6 Oct 2025 13:57:02 +0200 Subject: HDR image support In-Reply-To: References: Message-ID: Thanks, I will start a thread on client-libs-dev@ instead. On Mon, Oct 6, 2025 at 1:53?PM Alan Bateman wrote: > > It would be better to bring this to client-dev as this is where the image > APIs are maintained. > > -Alan > > > On 06/10/2025 12:10, Liam Miller-Cushon wrote: > > Hi, > > Are there any plans around HDR image support in the JDK? > > My colleague Alec Mouri provides the following background: > > Advancements in display and imaging technology have enabled HDR (High > Dynamic Range) content, which allows for displaying content at a greater > luminance than SDR (Standard Dynamic Range) content. Google > and > Adobe have > informative blog posts explaining this new technology. > > HDR images are part of intentional standards ISO 22028-5 > and ISO 21496-1 > . ISO 21496-1 in particular is > heavily used by the mobile ecosystem to generate high-quality images. See > the UltraHDR > image > format as an example. > > Every major operating system now has support for rendering HDR GUIs. See: > Android?s ExtendedRangeBrightness > > and COLOR_MODE_HDR > , > Apple?s EDR > , > and Wayland?s HDR Protocol > , and Window?s Advanced > Color > > . > > Platforms built on top of these OSs are accordingly adding support for > HDR. See: QT and CSS > . > > Support in the JDK would involve decoding and display support. > > Decoding support could be added to Image I/O. For ISO 22028-5, this means > that ICC_ColorSpace > > could support CICPs as described in ITU-T H.273 > to represent HLG and PQ encodings. > For ISO 21496-1, this means that BufferedImage > > could be decorated with a gainmap representation. > > Display support could be added to Swing and JavaFX. This would involve > interacting with each major OS?s capabilities to color manage and draw HDR > images through ImageIcon or JComponent. Note that SDR content should not be > colorimetrically affected when there is no HDR on screen. I.e., the rest of > the UI should not ?flicker?. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dl at openjdk.org Mon Oct 6 12:15:42 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 6 Oct 2025 12:15:42 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v13] In-Reply-To: References: Message-ID: <6_5G2_UpoiFvpFpge3WzeB0UaV5ibaEPM1zU17_UIXg=.a8835ab8-321e-4cc1-9b55-96404e2facfc@github.com> > This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally. Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Use absolute timed waits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26479/files - new: https://git.openjdk.org/jdk/pull/26479/files/cc61c5b2..cf5f844e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=11-12 Stats: 33 lines in 1 file changed: 15 ins; 2 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/26479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479 PR: https://git.openjdk.org/jdk/pull/26479 From ihse at openjdk.org Mon Oct 6 12:38:41 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 6 Oct 2025 12:38:41 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Fri, 3 Oct 2025 19:56:22 GMT, Xueming Shen wrote: > ### 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 thi... Build changes look fine. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3304307032 From mullan at openjdk.org Mon Oct 6 13:14:38 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 6 Oct 2025 13:14:38 GMT Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 19:35:27 GMT, Matthew Donovan wrote: >> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read. > > Matthew Donovan 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: > > - I removed signature algorithms output because the information is created during TLS handshake > - Merge branch 'master' into secsettings > - removed unused import, updated tools/launcher/Settings.java test > - Merge branch 'master' into secsettings > - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms Please add a release note for this change and update the bug title and description to note that you are not including signature algorithms now - thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3371568610 From weijun at openjdk.org Mon Oct 6 13:23:05 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 6 Oct 2025 13:23:05 GMT Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 19:35:27 GMT, Matthew Donovan wrote: >> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read. > > Matthew Donovan 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: > > - I removed signature algorithms output because the information is created during TLS handshake > - Merge branch 'master' into secsettings > - removed unused import, updated tools/launcher/Settings.java test > - Merge branch 'master' into secsettings > - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms The ciphersuites are different for TLS <=1.2 and 1.3. Do we just mix them in the same list? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3371618738 From dfuchs at openjdk.org Mon Oct 6 13:30:57 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 6 Oct 2025 13:30:57 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v3] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 10:13:21 GMT, Mahendra Chhipa wrote: >> Update SimpleHttpServer class to use SimpleFileServer. > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Added jdk.test.lib.net.URIBuilder import. test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java line 104: > 102: httpserver.start(); > 103: remoteFilePath = "http:" + URIBuilder.newBuilder().host(httpserver.getAddress().getAddress()). > 104: port(httpserver.getAddress().getPort()).build().toString() + REMOTE_FILE_LOCATION; Suggestion: remoteFilePath = URIBuilder.newBuilder() .scheme("http") .host(httpserver.getAddress().getAddress()) .port(httpserver.getAddress().getPort()) .build().toString() + REMOTE_FILE_LOCATION; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27608#discussion_r2406311037 From alanb at openjdk.org Mon Oct 6 14:10:34 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 6 Oct 2025 14:10:34 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: <7cSeWafk5WIAtnmaDBStH8a3bqx0PwecHIdPv0gK62c=.2eff8fb5-ec8e-4d8c-9d4b-305dabdd57ec@github.com> On Mon, 29 Sep 2025 10:19:48 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 100: > >> 98: testExecutableJar(jarFile, "testUnreflectSetter") >> 99: .shouldNotContain(WARNING_LINE1) >> 100: .shouldNotContain(WARNING_UNREFLECTED) > > We test > > * `manifest={mutation=allow}` & `cliOpts={}`, and > * `manifest={mutation=allow}` & `cliOpts={mutation=deny}`. > > Shall we also add a test with `manifest={}` & `cliOpts={mutation=allow}`? That is, in the absence of a manifest entry, do command line arguments still apply? The test is to check that `Enable-Final-Field-Mutation: ALL-UNNAMED` works like -`-enable-final-field-mutation=ALL-UNNAMED`. cli/CommandLineTest.java will test the CLI option. So I think we have reasonable coverage here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2406550210 From mchhipa at openjdk.org Mon Oct 6 14:30:00 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Mon, 6 Oct 2025 14:30:00 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v4] In-Reply-To: References: Message-ID: > Update SimpleHttpServer class to use SimpleFileServer. Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Used scheme() method to set protocol. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27608/files - new: https://git.openjdk.org/jdk/pull/27608/files/53e6a665..2aabe05c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=02-03 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27608/head:pull/27608 PR: https://git.openjdk.org/jdk/pull/27608 From aefimov at openjdk.org Mon Oct 6 14:45:52 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Mon, 6 Oct 2025 14:45:52 GMT Subject: RFR: 8368877: Generate Jextract bindings for Kqueue [v2] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 10:18:50 GMT, Darragh Clarke wrote: >> This PR is based on #25546 , though it was suggested to split that PR into 2 for easier reviewing and to give better visibility in the git history. >> This PR contains all the JExtract generated code that will be needed for converting Java's KQueue implementation to use Panama features instead of JNI. The actual updates to KQueue to make use of these files will come in the second PR. >> >> The basic structure here has the different native structures and methods split into 3 different packages all preceded by >> `src/java.base/macosx/classes/jdk/internal/ffi/generated/` >> Included in each package is a file `package-info.java` which contains the script that was used to generate these files so that others can reproduce them in future. >> >> The only modifications that have been made to the files post-generation are: >> - Adding copyright headers >> - Adding warning suppression for using restricted methods >> >> Some further modifications to these files to cut down on code duplication and adding support for errno handling on the native calls will come in the 2nd PR alongside the KQueue changes mentioned. > > Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision: > > Addressed comment and fixed newlines at end of files LGTM ------------- Marked as reviewed by aefimov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27590#pullrequestreview-3305150054 From viktor.klang at oracle.com Mon Oct 6 14:58:44 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Mon, 6 Oct 2025 14:58:44 +0000 Subject: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees In-Reply-To: References: Message-ID: Hi Jige, I'm not sure it's productive to discuss the in-order behavior of mapConcurrent() further, as it is specified to be in-order, so changing that would be an incompatible change regardless of whether the change itself would be beneficial or not. For potential future Gatherer-implementations made available from the Gatherers class, there'd need to be new implementations made available which over time prove themselves to be candidates for inclusion (also taking into consideration everything which comes with contributing code to OpenJDK). Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle Confidential ? Oracle Internal ________________________________ From: Jige Yu Sent: Sunday, 5 October 2025 19:06 To: Viktor Klang Cc: core-libs-dev at openjdk.org Subject: Re: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees Hi Viktor, Thanks again for explaining the current in-order contract. While I understand the implementation is currently compliant with the Javadoc, I have a few additional concerns about the practical consequences of this delayed exception propagation. Potential for Starvation While in theory it's also a lack of fail fast, it may show up more like a starvation or system hangs in certain concurrent architectures. Imagine a scenario where the virtual threads are consuming work items from a shared, blocking queue (like what's being discussed in the other thread, the virtual threads could themselves be producing data into the queue): 1. Task 3 successfully takes an item from the queue and then immediately fails with an exception, without producing any data into the queue. 2. Tasks 1 and 2 block on the queue to get their work items, indefinitely. 3. Because the exception from Task 3 is not propagated until Tasks 1 and 2 finish, the main thread or stream pipeline is blocked indefinitely if Tasks 1 or 2 hang. 4. The work item consumed by Task 3 is lost, and the system is effectively halted, as the failure isn't reported and cleanup/cancellation is delayed. So, except performance hit; it creates stability and liveness issues. ________________________________ Ambiguity in Current Javadoc Regarding the Javadoc, while I did read it, I found the lack of an explicit fail-fast guarantee and the precise timing of exception propagation to be subtle. The phrase, "If a result of the function is to be pushed downstream," seems to leave ample room for interpretation, and it was not immediately clear whether the lack of fail-fast was an intentional design choice versus a side effect of the in-order implementation. Clarifying this timing can probably improve the API's contract clarity. ________________________________ Re-evaluating the "In-Order" Contract Apologies for circling back to the same "in-order" question that has already been discussed. But from a usability perspective, I suggest we also bring the "in-order" contract itself up for discussion. I believe that the issues we've identified?the potential for starvation/hanging and the earlier discussed concurrency throughput concerns?are significant, realistic downsides of requiring strict in-order processing. These drawbacks should be carefully weighed against the benefits of the "in-order" contract, especially for concurrent processing APIs intended for I/O-bound tasks where strict ordering often has minimal value compared to resilience and performance. If it's a trade off between having in-order or fail-fast (but not both simultaneously), it may warrant some more consideration about which is more useful. Particularly, Java users have traditionally been educated that parallel streams don't necessarily retain encounter order. Cheers, On Sun, Oct 5, 2025 at 2:13?AM Viktor Klang > wrote: Hi Jige, Thanks for your question! It is important to acknowledge that Gatherers.mapConcurrent() does not specify fail-fast behavior. From https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function) "In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements." This does not refer to failed tasks "If a result of the function is to be pushed downstream but instead the function completed exceptionally then the corresponding exception will instead be rethrown by this method as an instance of RuntimeException, after which any remaining tasks are canceled." Since mapConcurrent is in-order, "is to be pushed downstream" means that it is next in line. Now, I'm not saying that fail-fast wouldn't be desirable behavior, but it would require research into how to implement it without breaking observable behavior. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle Confidential ? Oracle Internal ________________________________ From: Jige Yu > Sent: Sunday, 5 October 2025 07:10 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees Hi, Viktor. I recently suggested mapConcurrent() for a concurrent web crawling use case. But I was presented with a test case that showed surprising results. Basically, the current behavior may look like mapConcurrent() doesn't fail fast, and doesn't cancel in-flight tasks when a task has already failed. What actually happens in the following example is that the first two tasks are sleeping, while the 3rd task has already failed. But mapConcurrent() doesn't yet know that the 3rd task has failed until the first two tasks have successfully finished sleeping. Here's the test case: int work(int input) { if (input <= 2) { try { IO.println(input + " sleeping "); Thread.sleep(2000); IO.println("Returning " + (input * 2)); return input * 2; } catch (InterruptedException e) { println("Interrupted!"); throw new RuntimeException(e); } } else { IO.println(input + " Throwing"); throw new RuntimeException(); } } @Test public void mainTest() { var start = System.currentTimeMillis(); try { List results = Stream.of(1, 2, 3).gather(mapConcurrent(3, this::work)).toList(); println("Results = " + results); } finally { println("Took " + (System.currentTimeMillis() - start) + " ms"); } } On Mon, Jul 14, 2025 at 12:25?AM Viktor Klang > wrote: Hi Jige, The current behavior is what's currently achievable within the constraints of the Gatherer-model, if that changes in the future it would also mean that there could be stronger "guarantees" made. In the mean time, the good news is that if you're not satisfied with the behavior offered by mapConcurrent()?you can create your own which does what you want it to do! Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Sunday, 13 July 2025 05:54 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees Thanks for pressing on that, Viktor! I think I was fooled by my quick-and-dirty test. As I tried to harden it, I failed to deduce consistent behavior about what parallel stream does when unchecked exceptions happen. And in fact, it seems like it does *not* interrupt pending threads (?). With this in mind, do you consider this behavior of mapConcurrent() cancelling and joining the virtual threads on a best-effort basis acceptable trade-off? I wonder then if it's even worth it for mapConcurrent() to try to join the threads at all? If it can sometimes join and sometimes not, why not just always fail fast? At least then you get consistent fail-fast behavior: if a thread fails to respond to interruption and hangs, the main thread would still be able to respond to the exception. Cheers, On Tue, Jul 8, 2025 at 2:34?AM Viktor Klang > wrote: >I understand that explicit API contracts are what matters. My concern, however, is that even if the API contract explicitly states no happens-before guarantee upon an unchecked exception, this behavior would still be a significant deviation from established visibility standards in other JDK APIs. Would you mind clariying exactly what you mean here?what happens-before completion/exception? Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Tuesday, 8 July 2025 04:26 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees Thanks for the quick reply, Viktor! On Mon, Jul 7, 2025 at 2:35?AM Viktor Klang > wrote: Hi Jige, >Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a RuntimeException would be able to observe all side effects from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing to respond to interruption or responding slowly. Unless explicitly stated in the API contract, no such guarantees should be presumed to exist. I understand that explicit API contracts are what matters. My concern, however, is that even if the API contract explicitly states no happens-before guarantee upon an unchecked exception, this behavior would still be a significant deviation from established visibility standards in other JDK APIs. For instance, both parallel streams and Future.get() provide a happens-before guarantee upon completion (or exceptional completion in the case of Future.get()). So users will most likely take it for granted. If mapConcurrent() were to not offer this, it would potentially be the first blocking JDK API that doesn't honor happens-before in such a scenario. This inconsistency would likely be surprising and potentially confusing to users who have come to expect this behavior in concurrent programming constructs within the JDK. As for general resource-management in Stream, I have contemplated designs for Gatherer (and Collector) to be able to participate in the onClose actions, but there's a lot of ground to cover to ensure correct ordering and sufficiently-encompassing of cleanup action execution. Yeah. I agree that hooking into onClose() could provide a more reliable mechanism for cleanup. My primary concern though, is the change it imposes on the call-site contract. Requiring all users of mapConcurrent() to adopt a try-with-resources syntax, while ideal for correctness, introduces a burden and is more subject to users forgetting to do so, potentially leading to resource leaks. My previously proposed collectingAndThen(toList(), list -> list.stream().gather(mapConcurrent())) idea, on the other hand, avoids this call-site contract change. Being a collector, it needs to first consume the input, similar to how most Collectors operate. So it might be a less intrusive path to ensure proper resource handling without altering usage patterns. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev > on behalf of Jige Yu > Sent: Thursday, 3 July 2025 16:36 To: core-libs-dev at openjdk.org > Subject: Question about mapConcurrent() Behavior and Happens-Before Guarantees Hi JDK Core Devs, I'm writing to you today with a question about the behavior of mapConcurrent() and its interaction with unchecked exceptions. I've been experimenting with the API and observed that mapConcurrent() blocks and joins all virtual threads upon an unchecked exception before propagating it. Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a RuntimeException would be able to observe all side effects from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing to respond to interruption or responding slowly. However, I've since realized that mapConcurrent() cannot fully guarantee a strong happens-before relationship when an unchecked exception occurs somewhere in the stream pipeline. While it can block and wait for exceptions thrown by the mapper function or downstream operations, it appears unable to intercept unchecked exceptions thrown by an upstream source. Consider a scenario with two input elements: if the first element starts a virtual thread, and then the second element causes an unchecked exception from the upstream before reaching the gather() call, the virtual thread initiated by the first element would not be interrupted. This makes the "happens-before" guarantee quite nuanced in practice. This brings me to my core questions: 1. Is providing a happens-before guarantee upon an unchecked exception a design goal for mapConcurrent()? 2. If not, would it be more desirable to not join on virtual threads when unchecked exceptions occur? This would allow the application code to catch the exception sooner and avoid the risk of being blocked indefinitely. Thank you for your time and insights. Best regards, Ben Yu -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfuchs at openjdk.org Mon Oct 6 15:01:44 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 6 Oct 2025 15:01:44 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v4] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 14:30:00 GMT, Mahendra Chhipa wrote: >> Update SimpleHttpServer class to use SimpleFileServer. > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Used scheme() method to set protocol. Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27608#pullrequestreview-3305272280 From duke at openjdk.org Mon Oct 6 15:21:19 2025 From: duke at openjdk.org (Johny Jose) Date: Mon, 6 Oct 2025 15:21:19 GMT Subject: RFR: 8368500: ContextClassLoader cannot be reset on threads in ForkJoinPool.commonPool() Message-ID: The permanent disabling of the Security Manager in JDK 24 allow setCCL to set the CCL to a custom class loader. However, it doesn't allow it to be set to a custom class loader and then "reset" back to the system class loader before executing further code in the task. The changes are made to relax the restriction in setCCL to reset back to system class loader ------------- Commit messages: - 8368500: ContextClassLoader cannot be reset on threads in ForkJoinPool.commonPool() Changes: https://git.openjdk.org/jdk/pull/27648/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27648&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368500 Stats: 80 lines in 2 files changed: 76 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27648.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27648/head:pull/27648 PR: https://git.openjdk.org/jdk/pull/27648 From mchhipa at openjdk.org Mon Oct 6 15:29:45 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Mon, 6 Oct 2025 15:29:45 GMT Subject: Integrated: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer In-Reply-To: References: Message-ID: <85z9dtDbHuYDhentadql7zs5mWsic8Jzn4ehUI5iAso=.88ff8bda-8ed3-4991-89dc-2bad532f9ee4@github.com> On Thu, 2 Oct 2025 13:12:07 GMT, Mahendra Chhipa wrote: > Update SimpleHttpServer class to use SimpleFileServer. This pull request has now been integrated. Changeset: b6a4cfec Author: Mahendra Chhipa URL: https://git.openjdk.org/jdk/commit/b6a4cfecb731615b6ef70828ac10fae4b2264cdc Stats: 283 lines in 5 files changed: 32 ins; 230 del; 21 mod 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer Reviewed-by: dfuchs, vyazici ------------- PR: https://git.openjdk.org/jdk/pull/27608 From archie.cobbs at gmail.com Mon Oct 6 15:41:37 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Mon, 6 Oct 2025 10:41:37 -0500 Subject: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees In-Reply-To: References: Message-ID: Just a drive-by comment... I agree with Victor about being careful about making any API/semantic changes. However, I also have a lot of sympathy for what is being asked for. A common pattern is to want to say, "Try doing these N things in parallel; if any of them fails, just bail out - immediately cancel all of them and throw an exception". In other words, in a particular scenario you are expecting perfection, and if anything less occurs, it's preferable to just completely give up. Trying to salvage it is not worth it. So it would be nice if there were some parallel stream map() variant with those semantics (it could also preserve order, but that seems orthogonal). -Archie On Mon, Oct 6, 2025 at 9:59?AM Viktor Klang wrote: > Hi Jige, > > I'm not sure it's productive to discuss the in-order behavior of > mapConcurrent() further, as it is specified to be in-order, so changing > that would be an incompatible change regardless of whether the change > itself would be beneficial or not. > > For potential future Gatherer-implementations made available from the > Gatherers class, there'd need to be new implementations made available > which over time prove themselves to be candidates for inclusion (also > taking into consideration everything which comes with contributing code to > OpenJDK). > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > Confidential ? Oracle Internal > ------------------------------ > *From:* Jige Yu > *Sent:* Sunday, 5 October 2025 19:06 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: Question about mapConcurrent() Behavior > and Happens-Before Guarantees > > > Hi Viktor, > > Thanks again for explaining the current in-order contract. While I > understand the implementation is currently compliant with the Javadoc, I > have a few additional concerns about the practical consequences of this > delayed exception propagation. > > Potential for Starvation > > While in theory it's also a lack of fail fast, it may show up more like a *starvation > or system hangs* in certain concurrent architectures. > > Imagine a scenario where the virtual threads are consuming work items from > a shared, blocking queue (like what's being discussed in the other thread, > the virtual threads could themselves be producing data into the queue): > > 1. > > Task 3 successfully takes an item from the queue and then immediately > fails with an exception, without producing any data into the queue. > 2. > > Tasks 1 and 2 block on the queue to get their work items, > *indefinitely*. > 3. > > Because the exception from Task 3 is not propagated until Tasks 1 and > 2 finish, the main thread or stream pipeline is blocked indefinitely if > Tasks 1 or 2 hang. > 4. > > The work item consumed by Task 3 is lost, and the system is > effectively halted, as the failure isn't reported and cleanup/cancellation > is delayed. > > So, except performance hit; it creates stability and liveness issues. > ------------------------------ > > Ambiguity in Current Javadoc > > Regarding the Javadoc, while I did read it, I found the lack of an > explicit fail-fast guarantee and the precise timing of exception > propagation to be subtle. The phrase, *"If a result of the function is to > be pushed downstream,"* seems to leave ample room for interpretation, and > it was not immediately clear whether the lack of fail-fast was an > intentional design choice versus a side effect of the in-order > implementation. Clarifying this timing can probably improve the API's > contract clarity. > ------------------------------ > > Re-evaluating the "In-Order" Contract > > Apologies for circling back to the same "in-order" question that has > already been discussed. > > But from a usability perspective, I suggest we also bring the *"in-order" > contract itself* up for discussion. > > I believe that the issues we've identified?the potential for > starvation/hanging and the earlier discussed concurrency throughput > concerns?are significant, realistic downsides of requiring strict in-order > processing. These drawbacks should be carefully weighed against the > benefits of the "in-order" contract, especially for concurrent processing > APIs intended for I/O-bound tasks where strict ordering often has minimal > value compared to resilience and performance. > > If it's a trade off between having *in-order or fail-fast* (but not both > simultaneously), it may warrant some more consideration about which is more > useful. Particularly, Java users have traditionally been educated that > parallel streams don't necessarily retain encounter order. > > Cheers, > > On Sun, Oct 5, 2025 at 2:13?AM Viktor Klang > wrote: > > Hi Jige, > > Thanks for your question! > > It is important to acknowledge that Gatherers.mapConcurrent() does not > specify fail-fast behavior. > > From > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function) > > *"In progress tasks will be attempted to be cancelled, on a best-effort > basis, in situations where the downstream no longer wants to receive any > more elements."* > > This does not refer to failed tasks > > *"If a result of the function is to be pushed downstream but instead the > function completed exceptionally then the corresponding exception will > instead be rethrown by this method as an instance of **RuntimeException > **, > after which any remaining tasks are canceled."* > > Since mapConcurrent is in-order, "is to be pushed downstream" means that > it is next in line. > > > > Now, I'm not saying that fail-fast wouldn't be desirable behavior, but it > would require research into how to implement it without breaking observable > behavior. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > Confidential ? Oracle Internal > ------------------------------ > *From:* Jige Yu > *Sent:* Sunday, 5 October 2025 07:10 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: Question about mapConcurrent() Behavior > and Happens-Before Guarantees > > Hi, Viktor. > > I recently suggested mapConcurrent() for a concurrent web crawling use > case. But I was presented with a test case that showed surprising results. > Basically, the current behavior may look like mapConcurrent() doesn't fail > fast, and doesn't cancel in-flight tasks when a task has already failed. > > What actually happens in the following example is that the first two tasks > are sleeping, while the 3rd task has already failed. But mapConcurrent() > doesn't yet know that the 3rd task has failed until the first two tasks > have successfully finished sleeping. > > Here's the test case: > > int work(int input) { > > if (input <= 2) { > > try { > > IO.println(input + " sleeping "); > > Thread.sleep(2000); > > IO.println("Returning " + (input * 2)); > > return input * 2; > > } catch (InterruptedException e) { > > println("Interrupted!"); > > throw new RuntimeException(e); > > } > > } else { > > IO.println(input + " Throwing"); > > throw new RuntimeException(); > > } > > } > > > @Test public void mainTest() { > > var start = System.currentTimeMillis(); > > try { > > List results = Stream.of(1, 2, 3).gather(mapConcurrent(3, this > ::work)).toList(); > > println("Results = " + results); > > } finally { > > println("Took " + (System.currentTimeMillis() - start) + " ms"); > > } > > } > > > > > On Mon, Jul 14, 2025 at 12:25?AM Viktor Klang > wrote: > > Hi Jige, > > The current behavior is what's currently achievable within the constraints > of the Gatherer-model, if that changes in the future it would also mean > that there could be stronger "guarantees" made. > > In the mean time, the good news is that if you're not satisfied with the > behavior offered by mapConcurrent()?you can create your own which does what > you want it to do! > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Sunday, 13 July 2025 05:54 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: Question about mapConcurrent() Behavior > and Happens-Before Guarantees > > Thanks for pressing on that, Viktor! > > I think I was fooled by my quick-and-dirty test. As I tried to harden it, > I failed to deduce consistent behavior about what parallel stream does when > unchecked exceptions happen. And in fact, it seems like it does *not* > interrupt pending threads (?). > > With this in mind, do you consider this behavior of mapConcurrent() > cancelling and joining the virtual threads on a best-effort basis > acceptable trade-off? > > I wonder then if it's even worth it for mapConcurrent() to try to join the > threads at all? If it can sometimes join and sometimes not, why not just > always fail fast? At least then you get consistent fail-fast behavior: if a > thread fails to respond to interruption and hangs, the main thread would > still be able to respond to the exception. > > Cheers, > > > > On Tue, Jul 8, 2025 at 2:34?AM Viktor Klang > wrote: > > >I understand that explicit API contracts are what matters. My concern, > however, is that even if the API contract explicitly states *no* happens-before > guarantee upon an unchecked exception, this behavior would still be a > significant deviation from established visibility standards in other JDK > APIs. > > Would you mind clariying *exactly* what you mean here?*what* happens-before > completion/exception? > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > ------------------------------ > *From:* Jige Yu > *Sent:* Tuesday, 8 July 2025 04:26 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* [External] : Re: Question about mapConcurrent() Behavior and > Happens-Before Guarantees > > Thanks for the quick reply, Viktor! > > On Mon, Jul 7, 2025 at 2:35?AM Viktor Klang > wrote: > > Hi Jige, > > >Initially, I thought this design choice might provide a strong > happens-before guarantee. My assumption was that an application catching a > RuntimeException would be able to *observe all side effects* from the > virtual threads, even though this practice is generally discouraged. This > seemed like a potentially significant advantage, outweighing the risk of a > virtual thread failing to respond to interruption or responding slowly. > > Unless explicitly stated in the API contract, no such guarantees should be > presumed to exist. > > > I understand that explicit API contracts are what matters. My concern, > however, is that even if the API contract explicitly states *no* happens-before > guarantee upon an unchecked exception, this behavior would still be a > significant deviation from established visibility standards in other JDK > APIs. > > For instance, both *parallel streams* and Future.get() provide a > happens-before guarantee upon completion (or exceptional completion in the > case of Future.get()). So users will most likely take it for granted. If > mapConcurrent() were to *not* offer this, it would potentially be the *first > blocking JDK API that doesn't honor happens-before* in such a scenario. > This inconsistency would likely be surprising and potentially confusing to > users who have come to expect this behavior in concurrent programming > constructs within the JDK. > > > > As for general resource-management in Stream, I have contemplated designs > for Gatherer (and Collector) to be able to participate in the onClose > actions, but there's a lot of ground to cover to ensure correct ordering > and sufficiently-encompassing of cleanup action execution. > > > Yeah. I agree that hooking into onClose() could provide a more reliable > mechanism for cleanup. > > My primary concern though, is the change it imposes on the call-site > contract. Requiring all users of mapConcurrent() to adopt a > try-with-resources syntax, while ideal for correctness, introduces a > burden and is more subject to users forgetting to do so, potentially > leading to resource leaks. > > My previously proposed collectingAndThen(toList(), list -> > list.stream().gather(mapConcurrent())) idea, on the other hand, avoids > this call-site contract change. Being a collector, it needs to first > consume the input, similar to how most Collectors operate. So it might be > a less intrusive path to ensure proper resource handling without altering > usage patterns. > > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* core-libs-dev on behalf of Jige > Yu > *Sent:* Thursday, 3 July 2025 16:36 > *To:* core-libs-dev at openjdk.org > *Subject:* Question about mapConcurrent() Behavior and Happens-Before > Guarantees > > > Hi JDK Core Devs, > > I'm writing to you today with a question about the behavior of > mapConcurrent() and its interaction with unchecked exceptions. I've been > experimenting with the API and observed that mapConcurrent() blocks and > joins all virtual threads upon an unchecked exception before propagating it. > > Initially, I thought this design choice might provide a strong > happens-before guarantee. My assumption was that an application catching a > RuntimeException would be able to *observe all side effects* from the > virtual threads, even though this practice is generally discouraged. This > seemed like a potentially significant advantage, outweighing the risk of a > virtual thread failing to respond to interruption or responding slowly. > > However, I've since realized that mapConcurrent() cannot fully guarantee > a strong happens-before relationship when an unchecked exception occurs > *somewhere* in the stream pipeline. While it can block and wait for > exceptions thrown by the mapper function or downstream operations, it > appears unable to intercept unchecked exceptions *thrown by an upstream* > source. > > Consider a scenario with two input elements: if the first element starts a > virtual thread, and then the second element causes an unchecked exception > from the upstream *before* reaching the gather() call, the virtual thread > initiated by the first element would not be interrupted. This makes the > "happens-before" guarantee quite nuanced in practice. > > This brings me to my core questions: > > 1. > > Is providing a happens-before guarantee upon an unchecked exception a > design goal for mapConcurrent()? > 2. > > If not, would it be more desirable to *not* join on virtual threads > when unchecked exceptions occur? This would allow the application code to > catch the exception sooner and avoid the risk of being blocked indefinitely. > > Thank you for your time and insights. > > Best regards, > > Ben Yu > > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From msheppar at openjdk.org Mon Oct 6 15:52:44 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 6 Oct 2025 15:52:44 GMT Subject: RFR: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 04:22:24 GMT, Johny Jose wrote: >> Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6 > > Johny Jose has updated the pull request incrementally with one additional commit since the last revision: > > Review changes Marked as reviewed by msheppar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26815#pullrequestreview-3305611335 From mdonovan at openjdk.org Mon Oct 6 16:00:34 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Mon, 6 Oct 2025 16:00:34 GMT Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms [v3] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 13:20:36 GMT, Weijun Wang wrote: > The ciphersuites are very different for TLS <=1.2 and 1.3. Do we just mix them in the same list? Ciphersuites are printed in the order that `SSLContext.getEnabledCipherSuites()` returns them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3372460873 From naoto at openjdk.org Mon Oct 6 16:15:46 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 6 Oct 2025 16:15:46 GMT Subject: RFR: 8191963: Path.equals() and File.equals() return true for two different files on Windows [v2] In-Reply-To: References: Message-ID: On Sat, 4 Oct 2025 07:35:12 GMT, Alan Bateman wrote: > > > [...] system property to restore long standing behavior. > > > > > > Added in [a63e13e](https://github.com/openjdk/jdk/commit/a63e13e1e086d299a4e1326606f3322a42cb5977). > > @naotoj, @xuemingshen-oracle, do you have any thoughts on the compatibility impact? Would it be safer to make the new behavior as opt-in, as well as making the system property to be windows specific `windowsCompatibleEquals` or something? Making it as the default might be a bit risky to me. Also, IIUC the test is comparing cases between 'I', '\u0130' and '\u0131'. Probably we need to cross test with 'i' too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25788#issuecomment-3372554382 From mdonovan at openjdk.org Mon Oct 6 16:25:11 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Mon, 6 Oct 2025 16:25:11 GMT Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms [v3] In-Reply-To: References: Message-ID: <4ycc76TzINSAAFMg07kE9TYNlnDGZsnZZ6V5VH3BGbo=.aeb09e4f-114d-4c1a-9dde-bad2dad68f5b@github.com> On Mon, 6 Oct 2025 13:11:05 GMT, Sean Mullan wrote: > Please add a release note for this change and update the bug title and description to note that you are not including signature algorithms now - thanks. I updated the bug and added a release note https://bugs.openjdk.org/browse/JDK-8369225. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3372622369 From alanb at openjdk.org Mon Oct 6 17:47:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 6 Oct 2025 17:47:10 GMT Subject: RFR: 8368500: ContextClassLoader cannot be reset on threads in ForkJoinPool.commonPool() In-Reply-To: References: Message-ID: <-RX79hkWEvsdGczO0FYrSzkv3nxNDbL2po8F44599sg=.e28eec6d-39b1-40c8-a950-77eee23805e1@github.com> On Mon, 6 Oct 2025 15:13:35 GMT, Johny Jose wrote: > The permanent disabling of the Security Manager in JDK 24 allow setCCL to set the CCL to a custom class loader. However, it doesn't allow it to be set to a custom class loader and then "reset" back to the system class loader before executing further code in the task. The changes are made to relax the restriction in setCCL to reset back to system class loader The src change looks okay but the test isn't quire right at this time. test/jdk/java/util/concurrent/forkjoin/ContextClassLoaderTest.java line 46: > 44: @Test > 45: void testContextClassLoaderIsSetAndRestored() throws InterruptedException { > 46: CountDownLatch latch = new CountDownLatch(1); It looks like latch.await() is missing from the test. test/jdk/java/util/concurrent/forkjoin/ContextClassLoaderTest.java line 70: > 68: ((URLClassLoader) customCCL).close(); > 69: } > 70: } catch (Exception ignored) {} You can remove the customCCL.close, there are no JAR/other resources to close. ------------- PR Review: https://git.openjdk.org/jdk/pull/27648#pullrequestreview-3306265822 PR Review Comment: https://git.openjdk.org/jdk/pull/27648#discussion_r2407655983 PR Review Comment: https://git.openjdk.org/jdk/pull/27648#discussion_r2407659208 From rgiulietti at openjdk.org Mon Oct 6 18:04:59 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 6 Oct 2025 18:04:59 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v3] In-Reply-To: <53TQElZXlK-Rwj-NwOl-noceHQ5AwuZTcNbXy5okGcs=.356ee1d6-5d14-44f5-b8a7-e4a16d89ba0d@github.com> References: <53TQElZXlK-Rwj-NwOl-noceHQ5AwuZTcNbXy5okGcs=.356ee1d6-5d14-44f5-b8a7-e4a16d89ba0d@github.com> Message-ID: On Mon, 6 Oct 2025 03:51:37 GMT, Joe Darcy wrote: >> Upon further inspection, found a few more opportunities to refine the use of constants in the Float16 implementation. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8369123 > - Remove unneeded use of "Float16.". > - JDK-8369123: Still more small Float16 refactorings Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27625#pullrequestreview-3306359661 From duke at openjdk.org Mon Oct 6 18:24:01 2025 From: duke at openjdk.org (Larry Cable) Date: Mon, 6 Oct 2025 18:24:01 GMT Subject: RFR: JDK-8365400: add JFR event to capture location (if available) of class files loaded Message-ID: while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint. therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined. this association can be used for various "applications" such as basic auditing etc ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8365400 - JDK-8365400: add JFR event to capture location (if available) of class files loaded Changes: https://git.openjdk.org/jdk/pull/27656/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27656&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365400 Stats: 111 lines in 6 files changed: 103 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27656/head:pull/27656 PR: https://git.openjdk.org/jdk/pull/27656 From asemenyuk at openjdk.org Mon Oct 6 18:33:22 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 6 Oct 2025 18:33:22 GMT Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v5] In-Reply-To: References: Message-ID: On Sat, 4 Oct 2025 01:01:37 GMT, Alexander Matveev wrote: >> - Added test for custom info plist to cover app image including embedded runtime and runtime installer. >> - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8362598: [macos] Add tests for custom info plist files [v5] I took the liberty of using your patch as a baseline to improve testing of plist properties, including file associations. Here - https://github.com/openjdk/jdk/pull/27658. Would you consider pulling it into your PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27509#issuecomment-3373279398 From lmesnik at openjdk.org Mon Oct 6 18:39:50 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 6 Oct 2025 18:39:50 GMT Subject: RFR: 8365400: enhance JFR to emit file and module metadata for class loading In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 18:15:51 GMT, Larry Cable wrote: > while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint. > > therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined. > > this association can be used for various "applications" such as basic auditing etc Can you please a new test for the added functionality? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27656#issuecomment-3373312592 From naoto at openjdk.org Mon Oct 6 18:48:55 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 6 Oct 2025 18:48:55 GMT Subject: RFR: 8368856: Add a method to safely add duration to instant [v7] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 20:17:00 GMT, Pavel Rappo wrote: >> We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR. >> >> I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`. >> >> My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`. >> >> Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`. >> >> [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Fix copy-paste typos LGTM, but probably it would need more +1s from others. The PR and issue title need to be modified ("Add a method" -> "Add methods") ------------- PR Review: https://git.openjdk.org/jdk/pull/27549#pullrequestreview-3306601496 From asemenyuk at openjdk.org Mon Oct 6 19:04:53 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 6 Oct 2025 19:04:53 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v7] In-Reply-To: References: Message-ID: <5fx_OibRR1qTOb9f-1wHut4y5XRnhLReWh4eGlTi_so=.22f5c038-db1e-446e-a529-f6e334d858e1@github.com> On Fri, 3 Oct 2025 23:50:07 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v5] test/jdk/tools/jpackage/macosx/PkgScriptsTest.java line 108: > 106: }).orElseGet(() -> { > 107: return false; > 108: }); You can simplify it down to: return Optional.ofNullable(cmd.getArgumentValue("--resource-dir")) .filter(resourceDir -> { return Files.exists(Path.of(resourceDir).resolve(name)); }).isPresent(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2408026370 From scolebourne at openjdk.org Mon Oct 6 19:07:48 2025 From: scolebourne at openjdk.org (Stephen Colebourne) Date: Mon, 6 Oct 2025 19:07:48 GMT Subject: RFR: 8366829: Add java.time.Duration constants MIN and MAX [v3] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 09:50:23 GMT, Pavel Rappo wrote: >> We have [recently discussed][] a possibility of adding the `Duration.MIN` and `Duration.MAX` constants. Can we now start implementation? If and when we are in agreement on this PR, I will file a CSR. >> >> I drafted a minimal specification and added some tests. I tried to phrase the spec for `Duration.MIN` in a way that makes it clear that `Duration.MIN` is the most negative value and not the least positive. >> >> [recently discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Respond to feedback > > Apply Stephen's suggestion on wording, although modified. Marked as reviewed by scolebourne (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27534#pullrequestreview-3306703205 From asemenyuk at openjdk.org Mon Oct 6 19:15:57 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 6 Oct 2025 19:15:57 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v7] In-Reply-To: References: Message-ID: <6Jj1u3czY-odsmofM56H00-WzZNGTI3oC3Od51-3qo4=.4334a660-1ebd-41a0-ab47-9a929373d7ec@github.com> On Fri, 3 Oct 2025 23:50:07 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v5] test/jdk/tools/jpackage/macosx/PkgScriptsTest.java line 62: > 60: @Parameter({"TRUE", "FALSE"}) > 61: @Parameter({"FALSE", "TRUE"}) > 62: @Parameter({"FALSE", "FALSE"}) Why do we want to run the test without a custom installation script? test/jdk/tools/jpackage/macosx/PkgScriptsTest.java line 80: > 78: .forTypes(PackageType.MAC_PKG) > 79: .configureHelloApp() > 80: .addInitializer(cmd -> { I'd add `.addInitializer(JPackageCommand::setFakeRuntime)` call to save time building and packaging the full Java runtime. test/jdk/tools/jpackage/macosx/PkgScriptsTest.java line 86: > 84: }) > 85: .addInstallVerifier(PkgScriptsTest::verifyPKG) > 86: .setExpectedExitCode(0) This call is redundant test/jdk/tools/jpackage/macosx/PkgScriptsTest.java line 99: > 97: } catch (IOException ex) { > 98: throw new UncheckedIOException(ex); > 99: } Can be simplified down to: TKit.createTextFile(scriptOutputFile, Stream.of( "#!/usr/bin/env sh", String.format("touch "%s"", scriptOutputFile), "exit 0" )); With the benefit of adding the contents of the script file to the test log ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2408066556 PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2408062858 PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2408055617 PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2408049612 From asemenyuk at openjdk.org Mon Oct 6 19:21:51 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 6 Oct 2025 19:21:51 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v7] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 23:50:07 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v5] test/jdk/tools/jpackage/macosx/PkgScriptsTest.java line 130: > 128: } > 129: > 130: private static void verifyPKG(JPackageCommand cmd) { `verifyPKG()` is implemented so that if custom install scripts are missing in the .pkg file, the test will pass even if they were in the resource directory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2408087776 From asemenyuk at openjdk.org Mon Oct 6 19:38:52 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 6 Oct 2025 19:38:52 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v7] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 23:50:07 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v5] test/jdk/tools/jpackage/macosx/PkgScriptsTest.java line 114: > 112: if (exists) { > 113: TKit.assertFileExists(scriptPath); > 114: TKit.assertTrue(Files.isExecutable(scriptPath), String.format Should we check that the owner can execute the file instead of checking if the JVM can execute it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2408162200 From darcy at openjdk.org Mon Oct 6 19:39:21 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 6 Oct 2025 19:39:21 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v4] In-Reply-To: References: Message-ID: > Upon further inspection, found a few more opportunities to refine the use of constants in the Float16 implementation. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27625/files - new: https://git.openjdk.org/jdk/pull/27625/files/458bf671..197dbfed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27625&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27625&range=02-03 Stats: 17 lines in 1 file changed: 13 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27625/head:pull/27625 PR: https://git.openjdk.org/jdk/pull/27625 From darcy at openjdk.org Mon Oct 6 20:29:46 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 6 Oct 2025 20:29:46 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v2] In-Reply-To: <4k8Zz0BSEO6C25i0EVTjFv8LAqmfNJsi9q--Z0blU4Y=.a3bd3711-789c-4740-97e6-1df03d27c1ef@github.com> References: <4k8Zz0BSEO6C25i0EVTjFv8LAqmfNJsi9q--Z0blU4Y=.a3bd3711-789c-4740-97e6-1df03d27c1ef@github.com> Message-ID: <9tf2cj5SXOK1UJxnqjC3hpuGJPt1ueQ_LuElE7qQaa8=.089f9981-8c02-4c39-9850-d7a8ae9d489d@github.com> On Mon, 6 Oct 2025 08:02:24 GMT, Eirik Bj?rsn?s wrote: > > For the use of regex, is it an aesthetics question or a JDK bootstrapping question? > > Thanks for your consideration. This particular regex seems fine aesthetically. > > Having been bitten by performance suprises in the past, it raises my eyebrows when regex-dependent String functions are used in platform, library or otherwise low-level code. This looks like an edge-case, and as you note it is pre-existing. So yes, probably fine. Use of regex does merit some scrutiny, easy to write a regex that can run in exponential time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27625#issuecomment-3373929950 From naoto at openjdk.org Mon Oct 6 21:43:21 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 6 Oct 2025 21:43:21 GMT Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values Message-ID: Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/27660/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27660&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369184 Stats: 96 lines in 2 files changed: 89 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27660.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27660/head:pull/27660 PR: https://git.openjdk.org/jdk/pull/27660 From naoto at openjdk.org Mon Oct 6 21:49:31 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 6 Oct 2025 21:49:31 GMT Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values [v2] In-Reply-To: References: Message-ID: > Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: fixed typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27660/files - new: https://git.openjdk.org/jdk/pull/27660/files/ad1e8be6..a2c988d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27660&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27660&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27660.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27660/head:pull/27660 PR: https://git.openjdk.org/jdk/pull/27660 From almatvee at openjdk.org Mon Oct 6 22:19:49 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 6 Oct 2025 22:19:49 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v7] In-Reply-To: <6Jj1u3czY-odsmofM56H00-WzZNGTI3oC3Od51-3qo4=.4334a660-1ebd-41a0-ab47-9a929373d7ec@github.com> References: <6Jj1u3czY-odsmofM56H00-WzZNGTI3oC3Od51-3qo4=.4334a660-1ebd-41a0-ab47-9a929373d7ec@github.com> Message-ID: On Mon, 6 Oct 2025 19:13:33 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v5] > > test/jdk/tools/jpackage/macosx/PkgScriptsTest.java line 62: > >> 60: @Parameter({"TRUE", "FALSE"}) >> 61: @Parameter({"FALSE", "TRUE"}) >> 62: @Parameter({"FALSE", "FALSE"}) > > Why do we want to run the test without a custom installation script? I do not see any benefits for it. I will remove it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2408832491 From pchilanomate at openjdk.org Mon Oct 6 22:34:29 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 6 Oct 2025 22:34:29 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v4] In-Reply-To: References: Message-ID: > Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. > This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. > > These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Move test to RetryMonitorEnterWhenPinned.java and add timed-variants ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27597/files - new: https://git.openjdk.org/jdk/pull/27597/files/e60c375f..bf3613e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=02-03 Stats: 160 lines in 2 files changed: 95 ins; 56 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27597.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27597/head:pull/27597 PR: https://git.openjdk.org/jdk/pull/27597 From pchilanomate at openjdk.org Mon Oct 6 22:34:30 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 6 Oct 2025 22:34:30 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v3] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 16:48:35 GMT, Alan Bateman wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> make MAX_RECHECK_INTERVAL global static > > test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java line 645: > >> 643: /** >> 644: * Test no deadlock happens when Object.wait is called from a mix of pinned and non-pinned >> 645: * paths and notification is done using notifyAll. > > At some point then maybe we should combine this with RetryMonitorEnterWhenPinned. I'm not suggesting we do this now but some of the expanded description might be useful to include here as a passing reader might not immediately know what this test is doing. I wasn?t sure where to put the extra test and missed `RetryMonitorEnterWhenPinned.java`. I agree it makes more sense to have it here. Moved now, let me know what you think. > test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java line 648: > >> 646: */ >> 647: @Test >> 648: void testMixedPinnedUnmounted() throws Exception { > > What would you think of testing timed-wait too? Some of the other tests are paramerized with a value source and some time values to test both untimed and timed waits. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2408849669 PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2408850049 From egahlin at openjdk.org Mon Oct 6 22:38:45 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 6 Oct 2025 22:38:45 GMT Subject: RFR: 8365400: enhance JFR to emit file and module metadata for class loading In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 18:15:51 GMT, Larry Cable wrote: > while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint. > > therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined. > > this association can be used for various "applications" such as basic auditing etc I have not reviewed SecureClassLoader, as this is better done by people who are more knowledgeable in the area. That said, toExternalForm() appears to be a somewhat expensive function, so you may want to add a guard. Also check for null. ClassFileDefineEvent event = new ClassFileDefineEvent(); if (event.isEnabled()) { event.definedClass = cls; if (cs != null) { URL location = cs.getLocation(); if (location != null) { event.path = location.toExternalForm(); } } event.commit(); } Could you also add the event to profile.jfc? Please remove "Name" from the label "Defined Class Name," as the whole class is serialized, and add a test to test/jdk/jdk/jfr/event/runtime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27656#issuecomment-3374488908 From duke at openjdk.org Mon Oct 6 22:42:45 2025 From: duke at openjdk.org (Larry Cable) Date: Mon, 6 Oct 2025 22:42:45 GMT Subject: RFR: 8365400: enhance JFR to emit file and module metadata for class loading In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 18:15:51 GMT, Larry Cable wrote: > while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint. > > therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined. > > this association can be used for various "applications" such as basic auditing etc sounds good, will do so! thx On 10/6/25 3:33 PM, Erik Gahlin wrote: > *egahlin* left a comment (openjdk/jdk#27656) > > > I have not reviewed SecureClassLoader, as this is better done by > people who are more knowledgeable in the area. That said, > toExternalForm() appears to be a somewhat expensive function, so you > may want to add a guard. Also check for null. > > |ClassFileDefineEvent evt = new ClassFileDefineEvent(); if > (event.shouldCommit()) { event.definedClass = cls; if (cs != null) { > URL location = cs.getLocation(); if (location != null) { event = > location.toExternalForm(); } } event.commit(); } | > > Could you also add the event to profile.jfc? Please remove "Name" from > the label "Defined Class Name," as the whole class is serialized, and > add a test to test/jdk/jdk/jfr/event/runtime. > > ? > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > --------------H8Nh870r73JozTO7kRSnjvm6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit sounds good, will do so!

thx


On 10/6/25 3:33 PM, Erik Gahlin wrote:

I have not reviewed SecureClassLoader, as this is better done by people who are more knowledgeable in the area. That said, toExternalForm() appears to be a somewhat expensive function, so you may want to add a guard. Also check for null.

    ClassFileDefineEvent evt = new ClassFileDefineEvent();
    if (event.shouldCommit()) {
        event.definedClass = cls;
        if (cs != null) {
            URL location = cs.getLocation();
            if (location != null) {
                event = location.toExternalForm();
            }
        }
        event.commit();   
    }

Could you also add the event to profile.jfc? Please remove "Name" from the label "Defined Class Name," as the whole class is serialized, and add a test to test/jdk/jdk/jfr/event/runtime.

?
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: <openjdk/jdk/pull/27656/c3374488908@github.com>


--------------H8Nh870r73JozTO7kRSnjvm6-- ------------- PR Comment: https://git.openjdk.org/jdk/pull/27656#issuecomment-3374507982 From egahlin at openjdk.org Mon Oct 6 22:50:44 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 6 Oct 2025 22:50:44 GMT Subject: RFR: 8365400: enhance JFR to emit file and module metadata for class loading In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 18:15:51 GMT, Larry Cable wrote: > while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint. > > therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined. > > this association can be used for various "applications" such as basic auditing etc What is the scope of the event? I assume it will not work for all classes. Could more be added, or could the limitation be stated somewhere, e.g. Label("Secure Class File Define")? The event name can still be generic. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27656#issuecomment-3374538971 From almatvee at openjdk.org Mon Oct 6 23:27:51 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 6 Oct 2025 23:27:51 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v7] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 19:18:40 GMT, Alexey Semenyuk wrote: > verifyPKG() is implemented so that if custom install scripts are missing in the .pkg file, the test will pass even if they were in the resource directory. I tried this case by disabling packaging scripts to pkg in jpackage and test failed as expected. Can you elaborate more on this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2408959571 From almatvee at openjdk.org Mon Oct 6 23:38:51 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 6 Oct 2025 23:38:51 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v7] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 19:36:03 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v5] > > test/jdk/tools/jpackage/macosx/PkgScriptsTest.java line 114: > >> 112: if (exists) { >> 113: TKit.assertFileExists(scriptPath); >> 114: TKit.assertTrue(Files.isExecutable(scriptPath), String.format > > Should we check that the owner can execute the file instead of checking if the JVM can execute it? When file is extracted it will be created under current user, but `pkg` will be installed under `root`. I do not know who owns file while inside `pkg`. So, checking that file has execution permission is what we can do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2408970561 From asemenyuk at openjdk.org Mon Oct 6 23:52:49 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 6 Oct 2025 23:52:49 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v7] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 23:35:39 GMT, Alexander Matveev wrote: > When file is extracted it will be created under current user Oh, right. Then `Files.isExecutable()` is the right choice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2408985592 From dholmes at openjdk.org Tue Oct 7 00:46:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 00:46:57 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: <1Ed3XduxQZKSVBUng2-sUeD1ib9ZZqRQBN18n0SrAwY=.496748d7-01f9-4b9f-a184-d364f3d7d0f2@github.com> References: <1Ed3XduxQZKSVBUng2-sUeD1ib9ZZqRQBN18n0SrAwY=.496748d7-01f9-4b9f-a184-d364f3d7d0f2@github.com> Message-ID: On Sun, 5 Oct 2025 13:49:53 GMT, Alan Bateman wrote: > I think what you are suggesting is that the JEP could instead have -Xcheck:jni emit a warning when JNI setter functions mutate final fields, and maybe change it to be a fatal error in the future, maybe as part of the future JEP that proposes to move "deny" the default. @AlanBateman yes that is exactly what I am suggesting. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3374751322 From yujige at gmail.com Tue Oct 7 01:25:21 2025 From: yujige at gmail.com (Jige Yu) Date: Mon, 6 Oct 2025 18:25:21 -0700 Subject: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees In-Reply-To: References: Message-ID: To put it into context, it came up from the discussion thread regarding the web crawler use case (still being discussed in "Problem report on the usage of Structured Concurrency"). The use case of crawled page spawning more urls to be further crawled would seem pretty trivial to implement using mapConcurrent(): int maxConcurrency = 10; Set seen = new HashSet<>(); seen.add(root); for (List toCrawl = List.of(root); toCrawl.size() > 0; ) { toCrawl = toCrawl.stream() .gather(mapConcurrent(maxConcurrency, url -> loadWebPage(url))) .flatMap(page -> page.getLinks().stream()) .filter(seen::add) .toList(); } It's a breadth-first traversal, where each round it crawls all remaining urls concurrently with a max concurrency. The potential power of mapConcurrent() is very appealing to me. It can solve rather complicated concurrency problems elegantly. And then someone brought it up that mapConcurrent() doesn't cancel when it should have. And it turned out not to be a cancellation issue, but about the missing fail-fast. Just fwiw. Thanks again for patiently explaining the design rationale, Viktor! On Mon, Oct 6, 2025 at 8:41?AM Archie Cobbs wrote: > Just a drive-by comment... > > I agree with Victor about being careful about making any API/semantic > changes. However, I also have a lot of sympathy for what is being asked for. > > A common pattern is to want to say, "Try doing these N things in parallel; > if any of them fails, just bail out - immediately cancel all of them and > throw an exception". > > In other words, in a particular scenario you are expecting perfection, and > if anything less occurs, it's preferable to just completely give up. Trying > to salvage it is not worth it. > > So it would be nice if there were some parallel stream map() variant with > those semantics (it could also preserve order, but that seems orthogonal). > > -Archie > > On Mon, Oct 6, 2025 at 9:59?AM Viktor Klang > wrote: > >> Hi Jige, >> >> I'm not sure it's productive to discuss the in-order behavior of >> mapConcurrent() further, as it is specified to be in-order, so changing >> that would be an incompatible change regardless of whether the change >> itself would be beneficial or not. >> >> For potential future Gatherer-implementations made available from the >> Gatherers class, there'd need to be new implementations made available >> which over time prove themselves to be candidates for inclusion (also >> taking into consideration everything which comes with contributing code to >> OpenJDK). >> >> Cheers, >> ? >> >> >> *Viktor Klang* >> Software Architect, Java Platform Group >> Oracle >> >> Confidential ? Oracle Internal >> ------------------------------ >> *From:* Jige Yu >> *Sent:* Sunday, 5 October 2025 19:06 >> *To:* Viktor Klang >> *Cc:* core-libs-dev at openjdk.org >> *Subject:* Re: [External] : Re: Question about mapConcurrent() Behavior >> and Happens-Before Guarantees >> >> >> Hi Viktor, >> >> Thanks again for explaining the current in-order contract. While I >> understand the implementation is currently compliant with the Javadoc, I >> have a few additional concerns about the practical consequences of this >> delayed exception propagation. >> >> Potential for Starvation >> >> While in theory it's also a lack of fail fast, it may show up more like a *starvation >> or system hangs* in certain concurrent architectures. >> >> Imagine a scenario where the virtual threads are consuming work items >> from a shared, blocking queue (like what's being discussed in the other >> thread, the virtual threads could themselves be producing data into the >> queue): >> >> 1. >> >> Task 3 successfully takes an item from the queue and then immediately >> fails with an exception, without producing any data into the queue. >> 2. >> >> Tasks 1 and 2 block on the queue to get their work items, >> *indefinitely*. >> 3. >> >> Because the exception from Task 3 is not propagated until Tasks 1 and >> 2 finish, the main thread or stream pipeline is blocked indefinitely if >> Tasks 1 or 2 hang. >> 4. >> >> The work item consumed by Task 3 is lost, and the system is >> effectively halted, as the failure isn't reported and cleanup/cancellation >> is delayed. >> >> So, except performance hit; it creates stability and liveness issues. >> ------------------------------ >> >> Ambiguity in Current Javadoc >> >> Regarding the Javadoc, while I did read it, I found the lack of an >> explicit fail-fast guarantee and the precise timing of exception >> propagation to be subtle. The phrase, *"If a result of the function is >> to be pushed downstream,"* seems to leave ample room for interpretation, >> and it was not immediately clear whether the lack of fail-fast was an >> intentional design choice versus a side effect of the in-order >> implementation. Clarifying this timing can probably improve the API's >> contract clarity. >> ------------------------------ >> >> Re-evaluating the "In-Order" Contract >> >> Apologies for circling back to the same "in-order" question that has >> already been discussed. >> >> But from a usability perspective, I suggest we also bring the *"in-order" >> contract itself* up for discussion. >> >> I believe that the issues we've identified?the potential for >> starvation/hanging and the earlier discussed concurrency throughput >> concerns?are significant, realistic downsides of requiring strict in-order >> processing. These drawbacks should be carefully weighed against the >> benefits of the "in-order" contract, especially for concurrent processing >> APIs intended for I/O-bound tasks where strict ordering often has minimal >> value compared to resilience and performance. >> >> If it's a trade off between having *in-order or fail-fast* (but not both >> simultaneously), it may warrant some more consideration about which is more >> useful. Particularly, Java users have traditionally been educated that >> parallel streams don't necessarily retain encounter order. >> >> Cheers, >> >> On Sun, Oct 5, 2025 at 2:13?AM Viktor Klang >> wrote: >> >> Hi Jige, >> >> Thanks for your question! >> >> It is important to acknowledge that Gatherers.mapConcurrent() does not >> specify fail-fast behavior. >> >> From >> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function) >> >> *"In progress tasks will be attempted to be cancelled, on a best-effort >> basis, in situations where the downstream no longer wants to receive any >> more elements."* >> >> This does not refer to failed tasks >> >> *"If a result of the function is to be pushed downstream but instead the >> function completed exceptionally then the corresponding exception will >> instead be rethrown by this method as an instance of **RuntimeException >> **, >> after which any remaining tasks are canceled."* >> >> Since mapConcurrent is in-order, "is to be pushed downstream" means that >> it is next in line. >> >> >> >> Now, I'm not saying that fail-fast wouldn't be desirable behavior, but it >> would require research into how to implement it without breaking observable >> behavior. >> >> Cheers, >> ? >> >> >> *Viktor Klang* >> Software Architect, Java Platform Group >> Oracle >> >> Confidential ? Oracle Internal >> ------------------------------ >> *From:* Jige Yu >> *Sent:* Sunday, 5 October 2025 07:10 >> *To:* Viktor Klang >> *Cc:* core-libs-dev at openjdk.org >> *Subject:* Re: [External] : Re: Question about mapConcurrent() Behavior >> and Happens-Before Guarantees >> >> Hi, Viktor. >> >> I recently suggested mapConcurrent() for a concurrent web crawling use >> case. But I was presented with a test case that showed surprising results. >> Basically, the current behavior may look like mapConcurrent() doesn't fail >> fast, and doesn't cancel in-flight tasks when a task has already failed. >> >> What actually happens in the following example is that the first two >> tasks are sleeping, while the 3rd task has already failed. But >> mapConcurrent() doesn't yet know that the 3rd task has failed until the >> first two tasks have successfully finished sleeping. >> >> Here's the test case: >> >> int work(int input) { >> >> if (input <= 2) { >> >> try { >> >> IO.println(input + " sleeping "); >> >> Thread.sleep(2000); >> >> IO.println("Returning " + (input * 2)); >> >> return input * 2; >> >> } catch (InterruptedException e) { >> >> println("Interrupted!"); >> >> throw new RuntimeException(e); >> >> } >> >> } else { >> >> IO.println(input + " Throwing"); >> >> throw new RuntimeException(); >> >> } >> >> } >> >> >> @Test public void mainTest() { >> >> var start = System.currentTimeMillis(); >> >> try { >> >> List results = Stream.of(1, 2, 3).gather(mapConcurrent(3, this >> ::work)).toList(); >> >> println("Results = " + results); >> >> } finally { >> >> println("Took " + (System.currentTimeMillis() - start) + " ms"); >> >> } >> >> } >> >> >> >> >> On Mon, Jul 14, 2025 at 12:25?AM Viktor Klang >> wrote: >> >> Hi Jige, >> >> The current behavior is what's currently achievable within the >> constraints of the Gatherer-model, if that changes in the future it would >> also mean that there could be stronger "guarantees" made. >> >> In the mean time, the good news is that if you're not satisfied with the >> behavior offered by mapConcurrent()?you can create your own which does what >> you want it to do! >> >> Cheers, >> ? >> >> >> *Viktor Klang* >> Software Architect, Java Platform Group >> Oracle >> ------------------------------ >> *From:* Jige Yu >> *Sent:* Sunday, 13 July 2025 05:54 >> *To:* Viktor Klang >> *Cc:* core-libs-dev at openjdk.org >> *Subject:* Re: [External] : Re: Question about mapConcurrent() Behavior >> and Happens-Before Guarantees >> >> Thanks for pressing on that, Viktor! >> >> I think I was fooled by my quick-and-dirty test. As I tried to harden it, >> I failed to deduce consistent behavior about what parallel stream does when >> unchecked exceptions happen. And in fact, it seems like it does *not* >> interrupt pending threads (?). >> >> With this in mind, do you consider this behavior of mapConcurrent() >> cancelling and joining the virtual threads on a best-effort basis >> acceptable trade-off? >> >> I wonder then if it's even worth it for mapConcurrent() to try to join >> the threads at all? If it can sometimes join and sometimes not, why not >> just always fail fast? At least then you get consistent fail-fast behavior: >> if a thread fails to respond to interruption and hangs, the main thread >> would still be able to respond to the exception. >> >> Cheers, >> >> >> >> On Tue, Jul 8, 2025 at 2:34?AM Viktor Klang >> wrote: >> >> >I understand that explicit API contracts are what matters. My concern, >> however, is that even if the API contract explicitly states *no* happens-before >> guarantee upon an unchecked exception, this behavior would still be a >> significant deviation from established visibility standards in other JDK >> APIs. >> >> Would you mind clariying *exactly* what you mean here?*what* happens-before >> completion/exception? >> >> Cheers, >> ? >> >> >> *Viktor Klang* >> Software Architect, Java Platform Group >> Oracle >> >> ------------------------------ >> *From:* Jige Yu >> *Sent:* Tuesday, 8 July 2025 04:26 >> *To:* Viktor Klang >> *Cc:* core-libs-dev at openjdk.org >> *Subject:* [External] : Re: Question about mapConcurrent() Behavior and >> Happens-Before Guarantees >> >> Thanks for the quick reply, Viktor! >> >> On Mon, Jul 7, 2025 at 2:35?AM Viktor Klang >> wrote: >> >> Hi Jige, >> >> >Initially, I thought this design choice might provide a strong >> happens-before guarantee. My assumption was that an application catching a >> RuntimeException would be able to *observe all side effects* from the >> virtual threads, even though this practice is generally discouraged. This >> seemed like a potentially significant advantage, outweighing the risk of a >> virtual thread failing to respond to interruption or responding slowly. >> >> Unless explicitly stated in the API contract, no such guarantees should >> be presumed to exist. >> >> >> I understand that explicit API contracts are what matters. My concern, >> however, is that even if the API contract explicitly states *no* happens-before >> guarantee upon an unchecked exception, this behavior would still be a >> significant deviation from established visibility standards in other JDK >> APIs. >> >> For instance, both *parallel streams* and Future.get() provide a >> happens-before guarantee upon completion (or exceptional completion in the >> case of Future.get()). So users will most likely take it for granted. If >> mapConcurrent() were to *not* offer this, it would potentially be the *first >> blocking JDK API that doesn't honor happens-before* in such a scenario. >> This inconsistency would likely be surprising and potentially confusing to >> users who have come to expect this behavior in concurrent programming >> constructs within the JDK. >> >> >> >> As for general resource-management in Stream, I have contemplated designs >> for Gatherer (and Collector) to be able to participate in the onClose >> actions, but there's a lot of ground to cover to ensure correct ordering >> and sufficiently-encompassing of cleanup action execution. >> >> >> Yeah. I agree that hooking into onClose() could provide a more reliable >> mechanism for cleanup. >> >> My primary concern though, is the change it imposes on the call-site >> contract. Requiring all users of mapConcurrent() to adopt a >> try-with-resources syntax, while ideal for correctness, introduces a >> burden and is more subject to users forgetting to do so, potentially >> leading to resource leaks. >> >> My previously proposed collectingAndThen(toList(), list -> >> list.stream().gather(mapConcurrent())) idea, on the other hand, avoids >> this call-site contract change. Being a collector, it needs to first >> consume the input, similar to how most Collectors operate. So it might >> be a less intrusive path to ensure proper resource handling without >> altering usage patterns. >> >> >> Cheers, >> ? >> >> >> *Viktor Klang* >> Software Architect, Java Platform Group >> Oracle >> ------------------------------ >> *From:* core-libs-dev on behalf of Jige >> Yu >> *Sent:* Thursday, 3 July 2025 16:36 >> *To:* core-libs-dev at openjdk.org >> *Subject:* Question about mapConcurrent() Behavior and Happens-Before >> Guarantees >> >> >> Hi JDK Core Devs, >> >> I'm writing to you today with a question about the behavior of >> mapConcurrent() and its interaction with unchecked exceptions. I've been >> experimenting with the API and observed that mapConcurrent() blocks and >> joins all virtual threads upon an unchecked exception before propagating it. >> >> Initially, I thought this design choice might provide a strong >> happens-before guarantee. My assumption was that an application catching a >> RuntimeException would be able to *observe all side effects* from the >> virtual threads, even though this practice is generally discouraged. This >> seemed like a potentially significant advantage, outweighing the risk of a >> virtual thread failing to respond to interruption or responding slowly. >> >> However, I've since realized that mapConcurrent() cannot fully guarantee >> a strong happens-before relationship when an unchecked exception occurs >> *somewhere* in the stream pipeline. While it can block and wait for >> exceptions thrown by the mapper function or downstream operations, it >> appears unable to intercept unchecked exceptions *thrown by an upstream* >> source. >> >> Consider a scenario with two input elements: if the first element starts >> a virtual thread, and then the second element causes an unchecked exception >> from the upstream *before* reaching the gather() call, the virtual >> thread initiated by the first element would not be interrupted. This makes >> the "happens-before" guarantee quite nuanced in practice. >> >> This brings me to my core questions: >> >> 1. >> >> Is providing a happens-before guarantee upon an unchecked exception a >> design goal for mapConcurrent()? >> 2. >> >> If not, would it be more desirable to *not* join on virtual threads >> when unchecked exceptions occur? This would allow the application code to >> catch the exception sooner and avoid the risk of being blocked indefinitely. >> >> Thank you for your time and insights. >> >> Best regards, >> >> Ben Yu >> >> > > -- > Archie L. Cobbs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xgong at openjdk.org Tue Oct 7 01:35:48 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 7 Oct 2025 01:35:48 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: <-Ei1bFBHQvpeD3n7j8WuhV572oNW1b9X8FI488DMigI=.d1f9c421-b0f5-49e0-9ac5-97732ca82c4f@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> <-Ei1bFBHQvpeD3n7j8WuhV572oNW1b9X8FI488DMigI=.d1f9c421-b0f5-49e0-9ac5-97732ca82c4f@github.com> Message-ID: On Thu, 2 Oct 2025 09:23:20 GMT, Bhavana Kilambi wrote: >> src/hotspot/cpu/aarch64/aarch64_vector.ad line 272: >> >>> 270: if (length_in_bytes > 16 || !is_feat_fp16_supported()) { >>> 271: return false; >>> 272: } >> >> Reductions with `length_in_bytes < 8` should also be skipped. Because such operations are not supported now, while the IRs with 32-bit vector size might exist, right? > > Hi @XiaohongGong, yes `length_in_bytes < 8` is also not supported and currently we support only for vector lengths of 8B and 16B. > IRs with 32-bit vector size might exist but we do not have an optimized implementation for 32B vector lengths and thus I have disabled it. Instead of that, it generates the 16B scalarized Neon instruction sequence for a 32B vector length. Is this what you were asking? I mean do we need to check the length_in_bytes < 8, such as: Suggestion: if (length_in_bytes < 8 || length_in_bytes > 16 || !is_feat_fp16_supported()) { return false; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2409091499 From egahlin at openjdk.org Tue Oct 7 01:44:53 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 7 Oct 2025 01:44:53 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v7] In-Reply-To: References: Message-ID: On Sat, 4 Oct 2025 05:09:27 GMT, Alan Bateman wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. >> >> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). >> >> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. >> >> Testing: tier1-6 > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - Merge branch 'master' into JDK-8353835 > - Add test for -Xlog:jni=debug > - Merge branch 'master' into JDK-8353835 > - Merge branch 'master' into JDK-8353835 > - Improve CommandLineTest.testWarn > - More test cleanup > - Merge branch 'master' into JDK-8353835 > - Expand jni/JNIAttachMutatorTest to final fields in named modules > - Merge branch 'master' into JDK-8353835 > - Test updates based on reviewer feedback > - ... and 24 more: https://git.openjdk.org/jdk/compare/72319167...eed7ec4a Thanks for adding the RemoveFields and StackFilter annotations to the event. I believe the filter can be simplified to this @StackFilter({"java.lang.reflect.Field", "java.lang.reflect.ReflectAccess", "java.lang.invoke.MethodHandles$Lookup"}) and then set the offset to 4 or 5 in PlatformEventType::determineStackTraceOffset() to skip the offer method. This is cheaper and probably more robust. It will also make the place where the mutation happens the top frame, similar to other events, which works well for tooling. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3374858793 From xgong at openjdk.org Tue Oct 7 02:50:45 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 7 Oct 2025 02:50:45 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: <4VXHOCR1YSoMVbDbB8j-j18Z-_VbO0y5fJfyp3IjQ9c=.19485011-9cb3-4016-a642-61cee81adcd1@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> <4VXHOCR1YSoMVbDbB8j-j18Z-_VbO0y5fJfyp3IjQ9c=.19485011-9cb3-4016-a642-61cee81adcd1@github.com> Message-ID: On Thu, 2 Oct 2025 10:21:06 GMT, Bhavana Kilambi wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1900: >> >>> 1898: fmulh(dst, dst, vtmp); >>> 1899: ins(vtmp, H, vsrc, 0, 7); >>> 1900: fmulh(dst, dst, vtmp); >> >> Do you know why the performance is not improved significantly for multiply reduction? Seems instructions between different `ins` instructions will have a data-dependence, which is not expected? Could you please use other instructions instead or clear the register `vtmp` before `ins` and check the performance changes? >> >> Note that a clear of `mov` such as `MOVI Vd.2D, #0` has zero cost from V2's guide. > > Are you referring to the N1 numbers? The add reduction operation has gains around ~40% while the mul reduction is around ~20% on N1. On V1 and V2 they look comparable (not considering the cases where we generate `fadda` instructions for add reduction). > >> Seems instructions between different ins instructions will have a data-dependence, which is not expected > > Why do you think it's not expected? We have the exact same sequence for Neon add reduction as well. There's back to back dependency there as well and yet it shows better performance. The N1 optimization guide shows 2 cyc latency for `fadd` and 3 cyc latency for `fmul`. Could this be the reason? WDYT? I mean we do not expect there is data-dependence between two `ins` operations, but it has now. We do not recommend use the instructions that just write part of a register. This might involve un-expected dependence between. I suggest to use `ext` instead, and I can observe about 20% performance improvement compared with current version on V2. I did not check the correctness, but it looks right to me. Could you please help check on other machines? Thanks! The change might look like: Suggestion: fmulh(dst, fsrc, vsrc); ext(vtmp, T8B, vsrc, vsrc, 2); fmulh(dst, dst, vtmp); ext(vtmp, T8B, vsrc, vsrc, 4); fmulh(dst, dst, vtmp); ext(vtmp, T8B, vsrc, vsrc, 6); fmulh(dst, dst, vtmp); if (isQ) { ext(vtmp, T16B, vsrc, vsrc, 8); fmulh(dst, dst, vtmp); ext(vtmp, T16B, vsrc, vsrc, 10); fmulh(dst, dst, vtmp); ext(vtmp, T16B, vsrc, vsrc, 12); fmulh(dst, dst, vtmp); ext(vtmp, T16B, vsrc, vsrc, 14); fmulh(dst, dst, vtmp); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2409190652 From duke at openjdk.org Tue Oct 7 03:21:55 2025 From: duke at openjdk.org (duke) Date: Tue, 7 Oct 2025 03:21:55 GMT Subject: RFR: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 04:22:24 GMT, Johny Jose wrote: >> Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6 > > Johny Jose has updated the pull request incrementally with one additional commit since the last revision: > > Review changes @johnyjose30 Your change (at version e7a20b5071d5debed3e8747401dc8851fe45ee43) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26815#issuecomment-3375014775 From dholmes at openjdk.org Tue Oct 7 04:13:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 04:13:49 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v4] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 15:25:41 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 997: >> >>> 995: // prevents this load from floating up previous store. >>> 996: // Note that we can have false positives where timed-park is not necessary. >>> 997: bool do_timed_parked = has_unmounted_vthreads(); >> >> Don't we still only need the timed-park if the current thread is a pinned vthread? > > Yes, except if the monitor is also used in the context of a carrier thread. Currently there are only very few such cases and we disable preemption for them (e.g. `interruptLock`), so it?s likely not needed. With the upcoming changes to preempt on klass initialization, we could also have this situation if a class can be initialized both in the context of a carrier and a vthread. Since code executed in the context of the carriers is limited to library code there will also be very few cases of this, but I?ve seen at least one such case with `LockSupport`. So you are saying the current code is insufficient and could still deadlock? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2409280439 From dholmes at openjdk.org Tue Oct 7 04:13:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 04:13:52 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v4] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 22:34:29 GMT, Patricio Chilano Mateo wrote: >> Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. >> This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. >> >> These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Move test to RetryMonitorEnterWhenPinned.java and add timed-variants src/hotspot/share/runtime/objectMonitor.inline.hpp line 147: > 145: > 146: inline void ObjectMonitor::inc_unmounted_vthreads() { > 147: assert(_unmounted_vthreads >= 0, ""); Suggestion: assert(_unmounted_vthreads >= 0, "invariant"); Here and below - thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2409285515 From alanb at openjdk.org Tue Oct 7 05:31:47 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Oct 2025 05:31:47 GMT Subject: RFR: 8365400: enhance JFR to emit file and module metadata for class loading In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 22:40:22 GMT, Larry Cable wrote: >> while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint. >> >> therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined. >> >> this association can be used for various "applications" such as basic auditing etc > > sounds good, will do so! > > thx > > > On 10/6/25 3:33 PM, Erik Gahlin wrote: >> *egahlin* left a comment (openjdk/jdk#27656) >> >> >> I have not reviewed SecureClassLoader, as this is better done by >> people who are more knowledgeable in the area. That said, >> toExternalForm() appears to be a somewhat expensive function, so you >> may want to add a guard. Also check for null. >> >> |ClassFileDefineEvent evt = new ClassFileDefineEvent(); if >> (event.shouldCommit()) { event.definedClass = cls; if (cs != null) { >> URL location = cs.getLocation(); if (location != null) { event = >> location.toExternalForm(); } } event.commit(); } | >> >> Could you also add the event to profile.jfc? Please remove "Name" from >> the label "Defined Class Name," as the whole class is serialized, and >> add a test to test/jdk/jdk/jfr/event/runtime. >> >> ? >> Reply to this email directly, view it on GitHub >> , >> or unsubscribe >> . >> You are receiving this because you were mentioned.Message ID: >> ***@***.***> >> > > --------------H8Nh870r73JozTO7kRSnjvm6 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > > > > > sounds good, will do so!
>
> thx
>
>
>
On 10/6/25 3:33 PM, Erik Gahlin wrote:
>
>
> >
egahlin left a comment References: Message-ID: <_6err-oI7jnkN1zwTDpqBR4Gurfez_OdLJtveJYvORc=.53394d2b-2214-47e1-a87a-1590a356aaab@github.com> On Wed, 20 Aug 2025 10:11:47 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Update callGenerator.hpp copyright year @jatin-bhateja I have no further comments, great work. After this PR is merged, I will complete the backend optimization of the aarch64 part based on it. Thanks! src/hotspot/cpu/x86/x86.ad line 10770: > 10768: %} > 10769: > 10770: instruct vector_slice_const_origin_LT16B_reg(vec dst, vec src1, vec src2, immI origin) Suggestion: instruct vector_slice_const_origin_EQ16B_reg(vec dst, vec src1, vec src2, immI origin) Or Suggestion: instruct vector_slice_const_origin_16B_reg(vec dst, vec src1, vec src2, immI origin) ------------- PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-3308445233 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2409418070 From duke at openjdk.org Tue Oct 7 05:49:50 2025 From: duke at openjdk.org (erifan) Date: Tue, 7 Oct 2025 05:49:50 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: <30EG_sC2od4Xwsibk4Uv1XW_XROt9OtbYSaEDwFmycY=.c2c59c3b-dbfe-4d52-a353-08b7f41bab1d@github.com> On Thu, 25 Sep 2025 08:52:09 GMT, erifan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Update callGenerator.hpp copyright year > > test/hotspot/jtreg/compiler/vectorapi/TestSliceOptValueTransforms.java line 45: > >> 43: public static final VectorSpecies SSP = ShortVector.SPECIES_PREFERRED; >> 44: public static final VectorSpecies ISP = IntVector.SPECIES_PREFERRED; >> 45: public static final VectorSpecies LSP = LongVector.SPECIES_PREFERRED; > > The implementation supports floating point types, but why doesn't the test include fp types? It might be better to consider **partial cases**. I looked at the aarch64 situation and found that different implementations are needed for partial and non-partial cases. The test indices in `test/jdk/jdk/incubator/vector/` are randomly generated, so it might be better to test different vector species here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2409431981 From bkilambi at openjdk.org Tue Oct 7 07:39:46 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 7 Oct 2025 07:39:46 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> <-Ei1bFBHQvpeD3n7j8WuhV572oNW1b9X8FI488DMigI=.d1f9c421-b0f5-49e0-9ac5-97732ca82c4f@github.com> Message-ID: On Tue, 7 Oct 2025 01:33:05 GMT, Xiaohong Gong wrote: >> Hi @XiaohongGong, yes `length_in_bytes < 8` is also not supported and currently we support only for vector lengths of 8B and 16B. >> IRs with 32-bit vector size might exist but we do not have an optimized implementation for 32B vector lengths and thus I have disabled it. Instead of that, it generates the 16B scalarized Neon instruction sequence for a 32B vector length. Is this what you were asking? > > I mean do we need to check the length_in_bytes < 8, such as: > Suggestion: > > if (length_in_bytes < 8 || length_in_bytes > 16 || !is_feat_fp16_supported()) { > return false; > } Yes, I understood that part (and I already made that change in my patch interally) but not this - > the IRs with 32-bit vector size might exist ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2409685656 From alanb at openjdk.org Tue Oct 7 08:01:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Oct 2025 08:01:54 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v7] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 01:42:15 GMT, Erik Gahlin wrote: > I believe the filter can be simplified to this > > ``` > @StackFilter({"java.lang.reflect.Field", "java.lang.reflect.ReflectAccess", "java.lang.invoke.MethodHandles$Lookup"}) > ``` > > and then set the offset to 4 or 5 in PlatformEventType::determineStackTraceOffset() to skip the offer method. This is cheaper and probably more robust. It will also make the place where the mutation happens the top frame, similar to other events, which works well for tooling. The APIs are in Field and Lookup so having the API method as the top frame is useful. It would be possible to reduce the filter to `{ "java.lang.reflect.ReflectAccess", "java.lang.invoke.MethodHandles$Lookup::unreflectField" }` with determineStackTraceOffset returning 6 but it's too fiddly and requires knowing about two "faraway places" when doing any refactoring. Mutating final fields is the slow path so performance is not a concern. So I think the trade-off to keep it as maintainable as possible is okay. The test checks the top frame and also scans the StackFilter to ensure the class is visible and that any filter value with a method name at least names a method that is declared in the class. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3375647041 From duke at openjdk.org Tue Oct 7 08:49:58 2025 From: duke at openjdk.org (Larry Cable) Date: Tue, 7 Oct 2025 08:49:58 GMT Subject: Withdrawn: 8365400: enhance JFR to emit file and module metadata for class loading In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 18:15:51 GMT, Larry Cable wrote: > while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint. > > therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined. > > this association can be used for various "applications" such as basic auditing etc This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27656 From jpai at openjdk.org Tue Oct 7 09:23:01 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 7 Oct 2025 09:23:01 GMT Subject: RFR: 8367157: Remove jrunscript tool [v2] In-Reply-To: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com> References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com> Message-ID: > Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157. > > `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests. > > tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note. Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - merge latest from master branch - remove tests for jrunscript - remove jrunscript implementation - remove references from tests - remove man page for jrunscript ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27163/files - new: https://git.openjdk.org/jdk/pull/27163/files/5458698f..8279d9b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27163&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27163&range=00-01 Stats: 184646 lines in 2418 files changed: 144820 ins; 24642 del; 15184 mod Patch: https://git.openjdk.org/jdk/pull/27163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27163/head:pull/27163 PR: https://git.openjdk.org/jdk/pull/27163 From alanb at openjdk.org Tue Oct 7 09:53:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Oct 2025 09:53:52 GMT Subject: RFR: 8367157: Remove jrunscript tool [v2] In-Reply-To: References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com> Message-ID: On Tue, 7 Oct 2025 09:23:01 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157. >> >> `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests. >> >> tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - merge latest from master branch > - remove tests for jrunscript > - remove jrunscript implementation > - remove references from tests > - remove man page for jrunscript Looks okay, and easy to adjust course in the event that something important comes out of the wood work that depends on this tool. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27163#pullrequestreview-3309324886 From alanb at openjdk.org Tue Oct 7 10:02:47 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Oct 2025 10:02:47 GMT Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work as expected [v2] In-Reply-To: <9gqy4YltBipAT7BuMq-_bhUKHmoQpOjKQIKZHeAv9pI=.f6daabd3-e323-48b2-8a4b-038e1f48b641@github.com> References: <9gqy4YltBipAT7BuMq-_bhUKHmoQpOjKQIKZHeAv9pI=.f6daabd3-e323-48b2-8a4b-038e1f48b641@github.com> Message-ID: On Tue, 30 Sep 2025 21:02:03 GMT, Xueming Shen wrote: >> ### Background >> >> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers. >> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource(). >> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them. >> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified. >> >> ### Problem >> >> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._** >> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance. >> >> ### Solution >> >> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader. >> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact. >> >> This approach ensures the integrity of class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders. >> >> ### Benchmark >> >> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant. >> >> **Before:** >> >> >> Benchmark Mode Cnt Score Error Units >> ClassLoaderDefineClass.testDefineClassByteBufferDirect avgt 15 8387.247 ? 1405.681 ns/op >> ClassLoaderDefineClass.testDefineClassByteBufferHeap avgt 15 8971.739 ? 1020.288 ns/op >> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass' >> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass >> >> >> **After:** >> >> >> Benchmark Mode Cnt Score Error Units >> ClassLoaderDefineClass.testDefineClassByteBufferDirect avgt 15 8521.881 ? 2002.011 ns/op >> ClassLoaderDefineClass.testDefineClassByt... > > Xueming Shen 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: > > 8365588: defineClass that accepts a ByteBuffer does not work as expected I think the changes to ClassLoader.defineClass are good. I created [JDK-8352583](https://bugs.openjdk.org/browse/JDK-8352583) some time ago to document whether it advances the buffer position (this is technical debt that goes back to when the method was added in JDK 5). Right now, the only case where the positive is advanced is when called with a read-only buffer backed by an array. The proposed change preserves this, so there is no change in behavior. test/jdk/java/lang/ClassLoader/defineClass/DefineClassDirectByteBuffer.java line 32: > 30: * @build DefineClassDirectByteBuffer > 31: * @run junit/othervm --add-opens java.base/java.lang=ALL-UNNAMED -Dmode=Direct DefineClassDirectByteBuffer > 32: * @run junit/othervm --add-opens java.base/java.lang=ALL-UNNAMED -Dmode=Heap DefineClassDirectByteBuffer I think it would be better to use a ParameterizedTest and a method source that give you a good selection of buffers (direct, view of a memory segment, heap, read-only, ...). No need to open java.lang as the class loader in the test that use super.defineClass to invoke the protected method in the super class. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27569#issuecomment-3376054427 PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2410084132 From duke at openjdk.org Tue Oct 7 12:34:25 2025 From: duke at openjdk.org (Johny Jose) Date: Tue, 7 Oct 2025 12:34:25 GMT Subject: RFR: 8368500: ContextClassLoader cannot be reset on threads in ForkJoinPool.commonPool() [v2] In-Reply-To: References: Message-ID: > The permanent disabling of the Security Manager in JDK 24 allow setCCL to set the CCL to a custom class loader. However, it doesn't allow it to be set to a custom class loader and then "reset" back to the system class loader before executing further code in the task. The changes are made to relax the restriction in setCCL to reset back to system class loader Johny Jose has updated the pull request incrementally with one additional commit since the last revision: Review changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27648/files - new: https://git.openjdk.org/jdk/pull/27648/files/c13b9a71..c9d2b7c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27648&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27648&range=00-01 Stats: 23 lines in 1 file changed: 1 ins; 15 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27648.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27648/head:pull/27648 PR: https://git.openjdk.org/jdk/pull/27648 From duke at openjdk.org Tue Oct 7 12:34:28 2025 From: duke at openjdk.org (Johny Jose) Date: Tue, 7 Oct 2025 12:34:28 GMT Subject: RFR: 8368500: ContextClassLoader cannot be reset on threads in ForkJoinPool.commonPool() [v2] In-Reply-To: <-RX79hkWEvsdGczO0FYrSzkv3nxNDbL2po8F44599sg=.e28eec6d-39b1-40c8-a950-77eee23805e1@github.com> References: <-RX79hkWEvsdGczO0FYrSzkv3nxNDbL2po8F44599sg=.e28eec6d-39b1-40c8-a950-77eee23805e1@github.com> Message-ID: On Mon, 6 Oct 2025 17:43:04 GMT, Alan Bateman wrote: >> Johny Jose has updated the pull request incrementally with one additional commit since the last revision: >> >> Review changes > > test/jdk/java/util/concurrent/forkjoin/ContextClassLoaderTest.java line 46: > >> 44: @Test >> 45: void testContextClassLoaderIsSetAndRestored() throws InterruptedException { >> 46: CountDownLatch latch = new CountDownLatch(1); > > It looks like latch.await() is missing from the test. Updated the test case > test/jdk/java/util/concurrent/forkjoin/ContextClassLoaderTest.java line 70: > >> 68: ((URLClassLoader) customCCL).close(); >> 69: } >> 70: } catch (Exception ignored) {} > > You can remove the customCCL.close, there are no JAR/other resources to close. Removed the close ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27648#discussion_r2410461348 PR Review Comment: https://git.openjdk.org/jdk/pull/27648#discussion_r2410462670 From duke at openjdk.org Tue Oct 7 12:40:43 2025 From: duke at openjdk.org (Johny Jose) Date: Tue, 7 Oct 2025 12:40:43 GMT Subject: RFR: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 04:22:24 GMT, Johny Jose wrote: >> Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6 > > Johny Jose has updated the pull request incrementally with one additional commit since the last revision: > > Review changes @stuart-marks I do not have access to integrate the changes. Can you please sponsor the changes if we are good to integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26815#issuecomment-3376705130 From alanb at openjdk.org Tue Oct 7 12:57:01 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Oct 2025 12:57:01 GMT Subject: RFR: 8368500: ContextClassLoader cannot be reset on threads in ForkJoinPool.commonPool() [v2] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 12:34:25 GMT, Johny Jose wrote: >> The permanent disabling of the Security Manager in JDK 24 allow setCCL to set the CCL to a custom class loader. However, it doesn't allow it to be set to a custom class loader and then "reset" back to the system class loader before executing further code in the task. The changes are made to relax the restriction in setCCL to reset back to system class loader > > Johny Jose has updated the pull request incrementally with one additional commit since the last revision: > > Review changes test/jdk/java/util/concurrent/forkjoin/ContextClassLoaderTest.java line 40: > 38: import java.util.concurrent.ForkJoinPool; > 39: import java.util.concurrent.TimeUnit; > 40: import static org.junit.jupiter.api.Assertions.*; The updated test looks okay. Can you tidy up the imports as you've ended up with (harmless) duplicates which I assume you didn't intend. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27648#discussion_r2410535247 From duke at openjdk.org Tue Oct 7 13:16:48 2025 From: duke at openjdk.org (Johny Jose) Date: Tue, 7 Oct 2025 13:16:48 GMT Subject: Integrated: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 08:01:58 GMT, Johny Jose wrote: > Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6 This pull request has now been integrated. Changeset: 4b4d0cd3 Author: Johny Jose Committer: Mark Sheppard URL: https://git.openjdk.org/jdk/commit/4b4d0cd35a32448e4b056109c502af2765766432 Stats: 21 lines in 2 files changed: 14 ins; 2 del; 5 mod 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently Reviewed-by: msheppar, smarks, jpai ------------- PR: https://git.openjdk.org/jdk/pull/26815 From mullan at openjdk.org Tue Oct 7 13:22:37 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 7 Oct 2025 13:22:37 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v12] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 15:31:27 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > one more null check; one less empty check Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3310089768 From swen at openjdk.org Tue Oct 7 13:32:43 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 7 Oct 2025 13:32:43 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v7] In-Reply-To: References: Message-ID: On Sat, 4 Oct 2025 05:09:27 GMT, Alan Bateman wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. >> >> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). >> >> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. >> >> Testing: tier1-6 > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - Merge branch 'master' into JDK-8353835 > - Add test for -Xlog:jni=debug > - Merge branch 'master' into JDK-8353835 > - Merge branch 'master' into JDK-8353835 > - Improve CommandLineTest.testWarn > - More test cleanup > - Merge branch 'master' into JDK-8353835 > - Expand jni/JNIAttachMutatorTest to final fields in named modules > - Merge branch 'master' into JDK-8353835 > - Test updates based on reviewer feedback > - ... and 24 more: https://git.openjdk.org/jdk/compare/72319167...eed7ec4a Field.set can be further simplified to reduce duplicate code, such as this https://github.com/wenshao/jdk/commit/188df2c43b313737552aa9f0b32d067de56a0d4d ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3376907134 From alanb at openjdk.org Tue Oct 7 13:43:35 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Oct 2025 13:43:35 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v7] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 13:29:40 GMT, Shaojin Wen wrote: > Field.set can be further simplified to reduce duplicate code. This PR is focused on the changes for JEP 500. There may be merit in doing refactoring some time in the future but not here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3376952169 From swen at openjdk.org Tue Oct 7 14:04:38 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 7 Oct 2025 14:04:38 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v7] In-Reply-To: References: Message-ID: On Sat, 4 Oct 2025 05:09:27 GMT, Alan Bateman wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. >> >> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). >> >> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. >> >> Testing: tier1-6 > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - Merge branch 'master' into JDK-8353835 > - Add test for -Xlog:jni=debug > - Merge branch 'master' into JDK-8353835 > - Merge branch 'master' into JDK-8353835 > - Improve CommandLineTest.testWarn > - More test cleanup > - Merge branch 'master' into JDK-8353835 > - Expand jni/JNIAttachMutatorTest to final fields in named modules > - Merge branch 'master' into JDK-8353835 > - Test updates based on reviewer feedback > - ... and 24 more: https://git.openjdk.org/jdk/compare/72319167...eed7ec4a src/java.base/share/classes/java/lang/reflect/Field.java line 982: > 980: } else { > 981: setFinal(Reflection.getCallerClass(), obj, () -> fa.setByte(obj, b)); > 982: } Suggestion: if (!Modifier.isFinal(modifiers)) { fa.setByte(obj, b); } else { setFinal(Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor().setByte(obj, b)); } src/java.base/share/classes/java/lang/reflect/Field.java line 1027: > 1025: } else { > 1026: setFinal(Reflection.getCallerClass(), obj, () -> fa.setChar(obj, c)); > 1027: } Suggestion: if (!Modifier.isFinal(modifiers)) { fa.setChar(obj, c); } else { setFinal(Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor().setChar(obj, c)); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2410745955 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2410751688 From liach at openjdk.org Tue Oct 7 15:07:40 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 7 Oct 2025 15:07:40 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v7] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 13:59:43 GMT, Shaojin Wen wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: >> >> - Merge branch 'master' into JDK-8353835 >> - Add test for -Xlog:jni=debug >> - Merge branch 'master' into JDK-8353835 >> - Merge branch 'master' into JDK-8353835 >> - Improve CommandLineTest.testWarn >> - More test cleanup >> - Merge branch 'master' into JDK-8353835 >> - Expand jni/JNIAttachMutatorTest to final fields in named modules >> - Merge branch 'master' into JDK-8353835 >> - Test updates based on reviewer feedback >> - ... and 24 more: https://git.openjdk.org/jdk/compare/72319167...eed7ec4a > > src/java.base/share/classes/java/lang/reflect/Field.java line 982: > >> 980: } else { >> 981: setFinal(Reflection.getCallerClass(), obj, () -> fa.setByte(obj, b)); >> 982: } > > Suggestion: > > if (!Modifier.isFinal(modifiers)) { > fa.setByte(obj, b); > } else { > setFinal(Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor().setByte(obj, b)); > } We still need to capture `b` here so this doesn't really improve anything. Same for others. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2410965404 From benjamin at engflow.com Tue Oct 7 15:15:41 2025 From: benjamin at engflow.com (Benjamin Peterson) Date: Tue, 7 Oct 2025 10:15:41 -0500 Subject: requesting review on JDK-8348828: Windows dll loading now resolves symlinks Message-ID: I've had a PR for the native library loading code up for a months that I'd appreciate any review on: https://github.com/openjdk/jdk/pull/24694 To summarize the issue and proposed fix: Before OpenJDK 24, System.loadLibrary on Windows passed symbolic links unresolved to the underlying LoadLibrary function. JDK-8003887 caused symbolic links to be resolved by Java before the system LoadLibrary function. Unfortunately, LoadLibrary is clever and may mangle the filename passed to it, which means passing a symlink may not have the same behavior as presenting the fully resolved path. I propose to fix this problem in the PR by disabling LoadLibrary's clever mangling behavior. Thank you for your time, Benjamin From alanb at openjdk.org Tue Oct 7 15:17:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Oct 2025 15:17:52 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v7] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 15:04:47 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/reflect/Field.java line 982: >> >>> 980: } else { >>> 981: setFinal(Reflection.getCallerClass(), obj, () -> fa.setByte(obj, b)); >>> 982: } >> >> Suggestion: >> >> if (!Modifier.isFinal(modifiers)) { >> fa.setByte(obj, b); >> } else { >> setFinal(Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor().setByte(obj, b)); >> } > > We still need to capture `b` here so this doesn't really improve anything. Same for others. Right, and capturing fa/obj/b vs. this/obj/b is also not a concern because this is the slow case for final fields. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2410998983 From vklang at openjdk.org Tue Oct 7 15:44:35 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 7 Oct 2025 15:44:35 GMT Subject: RFR: 8368500: ContextClassLoader cannot be reset on threads in ForkJoinPool.commonPool() [v2] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 12:34:25 GMT, Johny Jose wrote: >> The permanent disabling of the Security Manager in JDK 24 allow setCCL to set the CCL to a custom class loader. However, it doesn't allow it to be set to a custom class loader and then "reset" back to the system class loader before executing further code in the task. The changes are made to relax the restriction in setCCL to reset back to system class loader > > Johny Jose has updated the pull request incrementally with one additional commit since the last revision: > > Review changes Thanks for running with this, @johnyjose30! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27648#issuecomment-3377491907 From rgiulietti at openjdk.org Tue Oct 7 15:48:06 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 7 Oct 2025 15:48:06 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v2] In-Reply-To: <9tf2cj5SXOK1UJxnqjC3hpuGJPt1ueQ_LuElE7qQaa8=.089f9981-8c02-4c39-9850-d7a8ae9d489d@github.com> References: <4k8Zz0BSEO6C25i0EVTjFv8LAqmfNJsi9q--Z0blU4Y=.a3bd3711-789c-4740-97e6-1df03d27c1ef@github.com> <9tf2cj5SXOK1UJxnqjC3hpuGJPt1ueQ_LuElE7qQaa8=.089f9981-8c02-4c39-9850-d7a8ae9d489d@github.com> Message-ID: On Mon, 6 Oct 2025 20:26:54 GMT, Joe Darcy wrote: >>> For the use of regex, is it an aesthetics question or a JDK bootstrapping question? >> >> Thanks for your consideration. This particular regex seems fine aesthetically. >> >> Having been bitten by performance suprises in the past, it raises my eyebrows when regex-dependent String functions are used in platform, library or otherwise low-level code. This looks like an edge-case, and as you note it is pre-existing. So yes, probably fine. > >> > For the use of regex, is it an aesthetics question or a JDK bootstrapping question? >> >> Thanks for your consideration. This particular regex seems fine aesthetically. >> >> Having been bitten by performance suprises in the past, it raises my eyebrows when regex-dependent String functions are used in platform, library or otherwise low-level code. This looks like an edge-case, and as you note it is pre-existing. So yes, probably fine. > > Use of regex does merit some scrutiny, easy to write a regex that can run in exponential time. @jddarcy To address @eirbjo concerns about using a regex, what about `s.replace("-1022", "-14")` instead? There should be no ambiguity in this specific case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27625#issuecomment-3377503605 From liach at openjdk.org Tue Oct 7 15:55:28 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 7 Oct 2025 15:55:28 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v4] In-Reply-To: <-mnTMxvetLwkde03sxvgoVHtnNrrBEUWHwoXuf6wRqA=.94d9759b-a2d9-4eff-afb0-562892b14c15@github.com> References: <-mnTMxvetLwkde03sxvgoVHtnNrrBEUWHwoXuf6wRqA=.94d9759b-a2d9-4eff-afb0-562892b14c15@github.com> Message-ID: On Fri, 9 May 2025 17:42:14 GMT, Benjamin Peterson wrote: >> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. >> >> Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior. > > Benjamin Peterson 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: > > - switch platform helper to be mapToNativeLibraryName > - Merge remote-tracking branch 'upstream/master' into nativelibraries-fix > - fix spelling > - new approach: append . to file name on Windows > - 8348828: Windows dll loading now resolves symlinks Thanks for prompting for attention on the mailing list. I just wonder if it would be better for us to handle this in `os::dll_load` in `os_windows.cpp` - this seems a better way to handle generic platform-specific peculiarities. This approach also means JNI and all other users would be updated too, but I don't see why JNI would handle this differently from class loader APIs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3377528055 From alan.bateman at oracle.com Tue Oct 7 16:08:52 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Tue, 7 Oct 2025 17:08:52 +0100 Subject: requesting review on JDK-8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On 07/10/2025 16:15, Benjamin Peterson wrote: > I've had a PR for the native library loading code up for a months that > I'd appreciate any review on: > https://github.com/openjdk/jdk/pull/24694 > > To summarize the issue and proposed fix: Before OpenJDK 24, > System.loadLibrary on Windows passed symbolic links unresolved to the > underlying LoadLibrary function. JDK-8003887 caused symbolic links to > be resolved by Java before the system LoadLibrary function. > Unfortunately, LoadLibrary is clever and may mangle the filename > passed to it, which means passing a symlink may not have the same > behavior as presenting the fully resolved path. I propose to fix this > problem in the PR by disabling LoadLibrary's clever mangling behavior. > The reason this didn't come to a conclusion is because this isn't really a JDK bug, instead it's a about a strange environment where some "mystery product" has moved the DLLs out the JDK run-time image directory and put them somewhere without the .dll suffix. The JDK expects the DLLs to be in the bin directory and named ".dll".? So it's really a question as to whether the JDK should accept a change to allow this strange setup. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.org Tue Oct 7 16:11:57 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 7 Oct 2025 16:11:57 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v2] In-Reply-To: <9tf2cj5SXOK1UJxnqjC3hpuGJPt1ueQ_LuElE7qQaa8=.089f9981-8c02-4c39-9850-d7a8ae9d489d@github.com> References: <4k8Zz0BSEO6C25i0EVTjFv8LAqmfNJsi9q--Z0blU4Y=.a3bd3711-789c-4740-97e6-1df03d27c1ef@github.com> <9tf2cj5SXOK1UJxnqjC3hpuGJPt1ueQ_LuElE7qQaa8=.089f9981-8c02-4c39-9850-d7a8ae9d489d@github.com> Message-ID: On Mon, 6 Oct 2025 20:26:54 GMT, Joe Darcy wrote: >>> For the use of regex, is it an aesthetics question or a JDK bootstrapping question? >> >> Thanks for your consideration. This particular regex seems fine aesthetically. >> >> Having been bitten by performance suprises in the past, it raises my eyebrows when regex-dependent String functions are used in platform, library or otherwise low-level code. This looks like an edge-case, and as you note it is pre-existing. So yes, probably fine. > >> > For the use of regex, is it an aesthetics question or a JDK bootstrapping question? >> >> Thanks for your consideration. This particular regex seems fine aesthetically. >> >> Having been bitten by performance suprises in the past, it raises my eyebrows when regex-dependent String functions are used in platform, library or otherwise low-level code. This looks like an edge-case, and as you note it is pre-existing. So yes, probably fine. > > Use of regex does merit some scrutiny, easy to write a regex that can run in exponential time. > @jddarcy To address @eirbjo concerns about using a regex, what about `s.replace("-1022", "-14")` instead? There should be no ambiguity in this specific case. I'd prefer to do that in follow-up work that updated Float and Float16 at the same time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27625#issuecomment-3377587460 From rgiulietti at openjdk.org Tue Oct 7 16:24:11 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 7 Oct 2025 16:24:11 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v4] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 19:39:21 GMT, Joe Darcy wrote: >> Upon further inspection, found a few more opportunities to refine the use of constants in the Float16 implementation. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27625#pullrequestreview-3310895870 From rgiulietti at openjdk.org Tue Oct 7 16:24:12 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 7 Oct 2025 16:24:12 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v2] In-Reply-To: References: <4k8Zz0BSEO6C25i0EVTjFv8LAqmfNJsi9q--Z0blU4Y=.a3bd3711-789c-4740-97e6-1df03d27c1ef@github.com> <9tf2cj5SXOK1UJxnqjC3hpuGJPt1ueQ_LuElE7qQaa8=.089f9981-8c02-4c39-9850-d7a8ae9d489d@github.com> Message-ID: On Tue, 7 Oct 2025 16:09:44 GMT, Joe Darcy wrote: >>> > For the use of regex, is it an aesthetics question or a JDK bootstrapping question? >>> >>> Thanks for your consideration. This particular regex seems fine aesthetically. >>> >>> Having been bitten by performance suprises in the past, it raises my eyebrows when regex-dependent String functions are used in platform, library or otherwise low-level code. This looks like an edge-case, and as you note it is pre-existing. So yes, probably fine. >> >> Use of regex does merit some scrutiny, easy to write a regex that can run in exponential time. > >> @jddarcy To address @eirbjo concerns about using a regex, what about `s.replace("-1022", "-14")` instead? There should be no ambiguity in this specific case. > > I'd prefer to do that in follow-up work that updated Float and Float16 at the same time. @jddarcy Ah OK, I didn't note that the same "trick" is used in `Float` as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27625#issuecomment-3377633036 From darcy at openjdk.org Tue Oct 7 16:39:49 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 7 Oct 2025 16:39:49 GMT Subject: RFR: 8369123: Still more small Float16 refactorings [v2] In-Reply-To: References: <4k8Zz0BSEO6C25i0EVTjFv8LAqmfNJsi9q--Z0blU4Y=.a3bd3711-789c-4740-97e6-1df03d27c1ef@github.com> <9tf2cj5SXOK1UJxnqjC3hpuGJPt1ueQ_LuElE7qQaa8=.089f9981-8c02-4c39-9850-d7a8ae9d489d@github.com> Message-ID: On Tue, 7 Oct 2025 16:09:44 GMT, Joe Darcy wrote: >>> > For the use of regex, is it an aesthetics question or a JDK bootstrapping question? >>> >>> Thanks for your consideration. This particular regex seems fine aesthetically. >>> >>> Having been bitten by performance suprises in the past, it raises my eyebrows when regex-dependent String functions are used in platform, library or otherwise low-level code. This looks like an edge-case, and as you note it is pre-existing. So yes, probably fine. >> >> Use of regex does merit some scrutiny, easy to write a regex that can run in exponential time. > >> @jddarcy To address @eirbjo concerns about using a regex, what about `s.replace("-1022", "-14")` instead? There should be no ambiguity in this specific case. > > I'd prefer to do that in follow-up work that updated Float and Float16 at the same time. > @jddarcy Ah OK, I didn't note that the same "trick" is used in `Float` as well. Filed [JDK-8369312](https://bugs.openjdk.org/browse/JDK-8369312). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27625#issuecomment-3377691016 From darcy at openjdk.org Tue Oct 7 16:44:35 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 7 Oct 2025 16:44:35 GMT Subject: Integrated: 8369123: Still more small Float16 refactorings In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 16:32:38 GMT, Joe Darcy wrote: > Upon further inspection, found a few more opportunities to refine the use of constants in the Float16 implementation. This pull request has now been integrated. Changeset: 4ca3ab62 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/4ca3ab62759b366fd3e0b2267925f1fa70f057b7 Stats: 35 lines in 1 file changed: 15 ins; 3 del; 17 mod 8369123: Still more small Float16 refactorings Reviewed-by: rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/27625 From benjamin at engflow.com Tue Oct 7 17:08:40 2025 From: benjamin at engflow.com (Benjamin Peterson) Date: Tue, 7 Oct 2025 12:08:40 -0500 Subject: requesting review on JDK-8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On Tue, Oct 7, 2025 at 11:09?AM Alan Bateman wrote: > > > > On 07/10/2025 16:15, Benjamin Peterson wrote: > > I've had a PR for the native library loading code up for a months that > I'd appreciate any review on: > https://github.com/openjdk/jdk/pull/24694 > > To summarize the issue and proposed fix: Before OpenJDK 24, > System.loadLibrary on Windows passed symbolic links unresolved to the > underlying LoadLibrary function. JDK-8003887 caused symbolic links to > be resolved by Java before the system LoadLibrary function. > Unfortunately, LoadLibrary is clever and may mangle the filename > passed to it, which means passing a symlink may not have the same > behavior as presenting the fully resolved path. I propose to fix this > problem in the PR by disabling LoadLibrary's clever mangling behavior. > > The reason this didn't come to a conclusion is because this isn't really a JDK bug, instead it's a about a strange environment where some "mystery product" has moved the DLLs out the JDK run-time image directory and put them somewhere without the .dll suffix. The JDK expects the DLLs to be in the bin directory and named ".dll". So it's really a question as to whether the JDK should accept a change to allow this strange setup. The reproducer I submitted in the initial bug report is definitely weird looking because I attempted point out the breaking change in as simple and as self-contained a manner as possible. But, I did run into this in a very real and useful application. I've tried to add more context about the application in comments such as https://bugs.openjdk.org/browse/JDK-8348828?focusedId=14744766&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14744766. I can certainly answer more questions about the usecase if the would be helpful. The heart of the matter is: Is it legal to call System.loadLibrary() with a symlink on Windows? The JDK before 24's answer was yes. From alan.bateman at oracle.com Tue Oct 7 17:52:07 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Tue, 7 Oct 2025 18:52:07 +0100 Subject: requesting review on JDK-8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: <14172c0d-fa14-47aa-a088-9ba4a9d7cc0f@oracle.com> On 07/10/2025 18:08, Benjamin Peterson wrote: > The reproducer I submitted in the initial bug report is definitely > weird looking because I attempted point out the breaking change in as > simple and as self-contained a manner as possible. But, I did run into > this in a very real and useful application. I've tried to add more > context about the application in comments such as > https://bugs.openjdk.org/browse/JDK-8348828?focusedId=14744766&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14744766 . > I can certainly answer more questions about the usecase if the would > be helpful. > > The heart of the matter is: Is it legal to call System.loadLibrary() > with a symlink on Windows? The JDK before 24's answer was yes. I have sympathy for the more general case. I think it would be useful to create a small table of what works and doesn't work, e.g. foo.dll? ->? dir\bar.dll foo.dll? ->? dir\bar foo?????? ->? dir\bar.dll where "->" is a sym link so it's clear which cases that System.loadLibrary works or doesn't work. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Oct 7 17:54:22 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Tue, 7 Oct 2025 17:54:22 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v5] In-Reply-To: References: Message-ID: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - fix compilation - fix grammar - add dot in os::dll_load rather than NativeLibraries.java - Merge remote-tracking branch 'origin/master' into nativelibraries-fix - switch platform helper to be mapToNativeLibraryName - Merge remote-tracking branch 'upstream/master' into nativelibraries-fix - fix spelling - new approach: append . to file name on Windows - 8348828: Windows dll loading now resolves symlinks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24694/files - new: https://git.openjdk.org/jdk/pull/24694/files/58d644a5..0e4f3ffb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=03-04 Stats: 516304 lines in 7697 files changed: 345477 ins; 116288 del; 54539 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From duke at openjdk.org Tue Oct 7 17:54:22 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Tue, 7 Oct 2025 17:54:22 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v4] In-Reply-To: References: <-mnTMxvetLwkde03sxvgoVHtnNrrBEUWHwoXuf6wRqA=.94d9759b-a2d9-4eff-afb0-562892b14c15@github.com> Message-ID: On Tue, 7 Oct 2025 15:52:12 GMT, Chen Liang wrote: > Thanks for prompting for attention on the mailing list. Thanks for looking. > > I just wonder if it would be better for us to handle this in `os::dll_load` in `os_windows.cpp` - this seems a better way to handle generic platform-specific peculiarities. This approach also means JNI and all other users would be updated too, but I don't see why JNI would handle this differently from class loader APIs. This is a good suggestion. I've now updated do append the dot in `os_windows.cpp`'s `dll_load`. I suppose this turns it in a hotspot review rather than a core-libs change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3377943193 From pchilanomate at openjdk.org Tue Oct 7 18:36:30 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 7 Oct 2025 18:36:30 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v5] In-Reply-To: References: Message-ID: <8CQ5NYDakZIO2Y8agWBUgd12ReC2dJfgd-3rCZbemRo=.11fc27cb-6566-4bee-af83-591f10ae0295@github.com> > Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. > This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. > > These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Add string in asserts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27597/files - new: https://git.openjdk.org/jdk/pull/27597/files/bf3613e1..9e435e09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27597&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27597.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27597/head:pull/27597 PR: https://git.openjdk.org/jdk/pull/27597 From pchilanomate at openjdk.org Tue Oct 7 18:36:31 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 7 Oct 2025 18:36:31 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v5] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 04:03:40 GMT, David Holmes wrote: >> Yes, except if the monitor is also used in the context of a carrier thread. Currently there are only very few such cases and we disable preemption for them (e.g. `interruptLock`), so it?s likely not needed. With the upcoming changes to preempt on klass initialization, we could also have this situation if a class can be initialized both in the context of a carrier and a vthread. Since code executed in the context of the carriers is limited to library code there will also be very few cases of this, but I?ve seen at least one such case with `LockSupport`. > > So you are saying the current code is insufficient and could still deadlock? If there?s a monitor that is used both in the context of a virtual thread and the carriers then potentially yes. But this should almost never happen, and for the very few special cases we identified we currently disable preemption. So this is mostly to cover for the upcoming changes in case there is a class that can be initialized in the context of both a virtual thread and the carriers. Again this should also be a rare case but I?ve seen at least one case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2411545770 From pchilanomate at openjdk.org Tue Oct 7 18:36:33 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 7 Oct 2025 18:36:33 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v4] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 04:08:50 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Move test to RetryMonitorEnterWhenPinned.java and add timed-variants > > src/hotspot/share/runtime/objectMonitor.inline.hpp line 147: > >> 145: >> 146: inline void ObjectMonitor::inc_unmounted_vthreads() { >> 147: assert(_unmounted_vthreads >= 0, ""); > > Suggestion: > > assert(_unmounted_vthreads >= 0, "invariant"); > > Here and below - thanks. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2411544003 From naoto at openjdk.org Tue Oct 7 18:41:09 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 7 Oct 2025 18:41:09 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: <3joVVX55ZEto_x9dhTVpYgMGzPtL8tdNNvZxiBmsuHE=.42d5f21c-64b4-4547-99e1-f2a3af104272@github.com> On Fri, 3 Oct 2025 19:56:22 GMT, Xueming Shen wrote: > ### 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 thi... While working on Unicode 17 upgrade, I noticed that they changed the example from "MASSE"/"Ma?e" to "FUSS"/"Fu?" (https://www.unicode.org/L2/L2025/25085.htm#183-A59), so you might want to switch them as well ------------- PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3378153999 From jlu at openjdk.org Tue Oct 7 19:00:47 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 7 Oct 2025 19:00:47 GMT Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values [v2] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 21:49:31 GMT, Naoto Sato wrote: >> Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo LGTM src/java.base/share/classes/java/util/SimpleTimeZone.java line 871: > 869: public int hashCode() > 870: { > 871: int hash = 31 * getID().hashCode() + rawOffset; int hash = Objects.hash(getID(), rawOffset, useDaylight); return !useDaylight ? hash : 31 * hash + Objects.hash( startMonth, startDay, startDayOfWeek, startTime, endMonth, endDay, endDayOfWeek, endTime); Seems reasonable to use `Objects.hash` here. Could save some lines if wanted? test/jdk/java/util/TimeZone/SimpleTimeZoneHashCodeTest.java line 1: > 1: /* Include _equals_ in the test name as well? Perhaps _HashCodeEqualsTest_ or something along those lines. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/27660#pullrequestreview-3311435895 PR Review Comment: https://git.openjdk.org/jdk/pull/27660#discussion_r2411594933 PR Review Comment: https://git.openjdk.org/jdk/pull/27660#discussion_r2411564566 From sherman at openjdk.org Tue Oct 7 19:39:20 2025 From: sherman at openjdk.org (Xueming Shen) Date: Tue, 7 Oct 2025 19:39:20 GMT Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work as expected [v2] In-Reply-To: References: <9gqy4YltBipAT7BuMq-_bhUKHmoQpOjKQIKZHeAv9pI=.f6daabd3-e323-48b2-8a4b-038e1f48b641@github.com> Message-ID: On Tue, 7 Oct 2025 09:59:51 GMT, Alan Bateman wrote: >> Xueming Shen 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: >> >> 8365588: defineClass that accepts a ByteBuffer does not work as expected > > test/jdk/java/lang/ClassLoader/defineClass/DefineClassDirectByteBuffer.java line 32: > >> 30: * @build DefineClassDirectByteBuffer >> 31: * @run junit/othervm --add-opens java.base/java.lang=ALL-UNNAMED -Dmode=Direct DefineClassDirectByteBuffer >> 32: * @run junit/othervm --add-opens java.base/java.lang=ALL-UNNAMED -Dmode=Heap DefineClassDirectByteBuffer > > I think it would be better to use a ParameterizedTest and a method source that give you a good selection of buffers (direct, view of a memory segment, heap, read-only, ...). No need to open java.lang as the class loader in the test can use super.defineClass to invoke the protected method in the super class. --add-opens java.base/java.lang=ALL-UNNAMED is for the reflective access to "defineClass" of the platform classloader. any better alternative to test the platform classloader's defineClass behavior other than the reflect api? Method m = ClassLoader.class.getDeclaredMethod( "defineClass", String.class, ByteBuffer.class, ProtectionDomain.class ); m.setAccessible(true); Class clazz = (Class) m.invoke(builtin, null, bb, null); The dup @run lines are the workaround to test the platform classloader's defineClass on the same target test class class twice, one for the direct bb, one for the heap bb (with 2 separate vm runs). Otherwise the test fails with "java.lang.LinkageError: loader 'platform' attempted duplicate class definition for Greeting." Does ParameterizedTest support vm/platform classloader isolation for each parameterized test run against the same test with different parameters? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2411698488 From openjdk at icemanx.nl Tue Oct 7 19:43:20 2025 From: openjdk at icemanx.nl (Rob Spoor) Date: Tue, 7 Oct 2025 21:43:20 +0200 Subject: RFE: make AutoCloseable generic in its exception type Message-ID: <5afa96a1-1d59-4dca-8312-1136c19b762e@icemanx.nl> Hi all, AutoCloseable, as added in Java 7 and unchanged ever since, declares to throw Exception from its close() method. That means that anytime someone needs to have an AutoCloseable that throws a different exception, they must create an interface that extends AutoCloseable and override close() only to throw a different (or no) exception. That can become quite annoying if you have to do it often. But without such interfaces, we cannot use lambdas or method references in try-with-resources without having to deal with Exception: try (AutoCloseable _ = this::cleanup) { } // need to catch or re-throw Exception I think that making AutoCloseable generic in its exception type is a change that's quite simple, yet makes life easier for developers. The interface would become this: public interface AutoCloseable { /** * { // keep close for its documentation } That doesn't add much value yet, but we can now use it in try-with-resources without having to deal with Exception: try (AutoCloseable c = this::cleanup) { } // no need to catch or re-throw RuntimeException There is one other possible change that can make it even easier, and that is adding a factory method like Gatherer.Integrator.of: public interface AutoCloseable { // documentation omitted void close() throws X; // documentation omitted static AutoCloseable of(AutoCloseable closeable) { return closeable; } } The try-with-resources can now become even simpler: try (var _ = AutoCloseable.of(this::cleanup)) { } There is one possible issue with this "of" method, and that is possible incompatibilities with existing implementing classes or extending interfaces that already have an "of(AutoCloseable)" method with a different return type, or that are not static. I think the chances of that are not great, but it still is something to consider. Any thoughts? From openjdk at icemanx.nl Tue Oct 7 19:44:57 2025 From: openjdk at icemanx.nl (Rob Spoor) Date: Tue, 7 Oct 2025 21:44:57 +0200 Subject: Could ByteOrder be turned into an enum? In-Reply-To: References: <2493cf38-5324-408e-9912-202277c64b59@icemanx.nl> Message-ID: Is it OK if I create a PR for this? Or is there a reason not to implement this? On 02/07/2025 04:49, Chen Liang wrote: > Indeed, given that ByteOrder is more widely used and appears in many other > APIs like FFM, it would be quite helpful to modernize it. There are other > eligible candidates like CodingErrorAction, but their usages are more > restricted to Buffer itself. > > On Tue, Jul 1, 2025 at 11:15?AM Rob Spoor wrote: > >> Hi all, >> >> I've been using ByteOrder quite a bit, but something that's always >> annoyed me is that it's not an enum (because it predates them), and >> therefore cannot be easily used in switch expressions or statements. For >> instance, the closest I get is this, which still requires a default >> statement: >> >> var i = switch (ByteOrder.nativeOrder()) { >> case ByteOrder b when b.equals(ByteOrder.LITTLE_ENDIAN) -> 1; >> case ByteOrder b when b.equals(ByteOrder.BIG_ENDIAN) -> 2; >> default -> throw new IllegalStateException("not supported"); >> }; >> >> I know that it's also possible to use a ternary expression, but that >> depends on there never being a third value: >> >> var i = ByteOrder.nativeOrder().equals(ByteOrder.LITTLE_ENDIAN) >> ? 1 : 2 >> >> >> As a little proof-of-concept I created the enum below and checked the >> signatures with javap. Apart from a different super class (Object -> >> Enum) and the extra values() and valueOf(String) methods, the two have >> the same fields, constructors and methods with the same signatures. And >> it would allow us to use this shorter switch expression: >> >> var i = switch (ByteOrder.nativeOrder()) { >> case LITTLE_ENDIAN -> 1; >> case BIG_ENDIAN -> 2; >> }; >> >> So my question is: are there technical limitations that would prevent >> this change? >> >> >> The enum I created: >> >> public enum ByteOrder { >> >> BIG_ENDIAN("BIG_ENDIAN"), >> LITTLE_ENDIAN("LITTLE_ENDIAN"), >> ; >> >> private final String name; >> >> ByteOrder(String name) { >> this.name = name; >> } >> >> private static final ByteOrder NATIVE_ORDER >> = Unsafe.getUnsafe().isBigEndian() >> ? ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN; >> >> public static ByteOrder nativeOrder() { >> return NATIVE_ORDER; >> } >> >> public String toString() { >> return name; >> } >> } >> >> > From brian.burkhalter at oracle.com Tue Oct 7 19:47:15 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 7 Oct 2025 19:47:15 +0000 Subject: Could ByteOrder be turned into an enum? In-Reply-To: References: <2493cf38-5324-408e-9912-202277c64b59@icemanx.nl> Message-ID: <4FC6C5D6-8ED5-4B33-B266-F3CB43F211F0@oracle.com> There is one in progress: https://github.com/openjdk/jdk/pull/27657 On Oct 7, 2025, at 12:44?PM, Rob Spoor wrote: Is it OK if I create a PR for this? Or is there a reason not to implement this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openjdk at icemanx.nl Tue Oct 7 19:53:49 2025 From: openjdk at icemanx.nl (Rob Spoor) Date: Tue, 7 Oct 2025 21:53:49 +0200 Subject: Could ByteOrder be turned into an enum? In-Reply-To: <4FC6C5D6-8ED5-4B33-B266-F3CB43F211F0@oracle.com> References: <2493cf38-5324-408e-9912-202277c64b59@icemanx.nl> <4FC6C5D6-8ED5-4B33-B266-F3CB43F211F0@oracle.com> Message-ID: <7c2e5280-ed65-4604-ad88-e50bfa451c2b@icemanx.nl> Well, that's a very good reason indeed ;) Thanks for the info! On 07/10/2025 21:47, Brian Burkhalter wrote: > There is one in progress: https://github.com/openjdk/jdk/pull/27657 > > On Oct 7, 2025, at 12:44?PM, Rob Spoor wrote: > > Is it OK if I create a PR for this? Or is there a reason not to implement this? > From acobbs at openjdk.org Tue Oct 7 20:03:25 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 7 Oct 2025 20:03:25 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v3] In-Reply-To: References: Message-ID: > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 132 commits: - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflicts. - Add clarifying comment. - Merge branch 'master' into JDK-8344159 - Change inner class name to avoid shadowing superclass name. - Add a couple of code clarification comments. - Refactor test to avoid requiring changes to TestRunner. - Remove unnecessary -Xlint:-suppression flags. - Minor cleanups. - Add OPTIONS, PATH, and SUPPRESSION to the regression test. - ... and 122 more: https://git.openjdk.org/jdk/compare/910bb68e...3542625c ------------- Changes: https://git.openjdk.org/jdk/pull/25167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=02 Stats: 1659 lines in 34 files changed: 1486 ins; 49 del; 124 mod Patch: https://git.openjdk.org/jdk/pull/25167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167 PR: https://git.openjdk.org/jdk/pull/25167 From duke at openjdk.org Tue Oct 7 20:06:13 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Tue, 7 Oct 2025 20:06:13 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v6] In-Reply-To: References: Message-ID: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge branch 'master' into nativelibraries-fix - fix compilation - fix grammar - add dot in os::dll_load rather than NativeLibraries.java - Merge remote-tracking branch 'origin/master' into nativelibraries-fix - switch platform helper to be mapToNativeLibraryName - Merge remote-tracking branch 'upstream/master' into nativelibraries-fix - fix spelling - new approach: append . to file name on Windows - 8348828: Windows dll loading now resolves symlinks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24694/files - new: https://git.openjdk.org/jdk/pull/24694/files/0e4f3ffb..532891a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=04-05 Stats: 301 lines in 22 files changed: 213 ins; 40 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From scolebourne at openjdk.org Tue Oct 7 20:40:34 2025 From: scolebourne at openjdk.org (Stephen Colebourne) Date: Tue, 7 Oct 2025 20:40:34 GMT Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to Instant [v7] In-Reply-To: References: Message-ID: <2jsm8nKU3yUzHB4hjOy_79Ak91Jz0fDmloaEx9RoCBg=.d4a2073d-a39d-4de5-b074-f7629fdbcdc8@github.com> On Wed, 1 Oct 2025 20:17:00 GMT, Pavel Rappo wrote: >> We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR. >> >> I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`. >> >> My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`. >> >> Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`. >> >> [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Fix copy-paste typos Have any users been asking for these methods, or is it just a case of we think they might be useful? It is definitely a bit weird that the saturating methods take a `Duration`, while the non-saturating ones take `TemporalAmount`, but I don't think there is a lot that can be done about that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27549#issuecomment-3378557830 From duke at openjdk.org Tue Oct 7 20:43:06 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Tue, 7 Oct 2025 20:43:06 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v7] In-Reply-To: References: Message-ID: <7vzxlAlWx_gaQZSvMCYeuYlza-W9Z0DcjLJdWkjVZ5Q=.f616c102-decd-482c-b86e-fb204c8ca8e4@github.com> > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision: use os::malloc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24694/files - new: https://git.openjdk.org/jdk/pull/24694/files/532891a4..9f621161 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From naoto at openjdk.org Tue Oct 7 20:43:23 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 7 Oct 2025 20:43:23 GMT Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values [v2] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 18:54:34 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo > > src/java.base/share/classes/java/util/SimpleTimeZone.java line 871: > >> 869: public int hashCode() >> 870: { >> 871: int hash = 31 * getID().hashCode() + rawOffset; > > int hash = Objects.hash(getID(), rawOffset, useDaylight); > return !useDaylight ? hash : 31 * hash + Objects.hash( > startMonth, startDay, startDayOfWeek, startTime, endMonth, endDay, endDayOfWeek, endTime); > > > Seems reasonable to use `Objects.hash` here. Could save some lines if wanted? Initially, I thought so, but decided to avoid extra array allocation/copy. But on second thought, the instances of this class would seldom be used as hash keys so not that performance critical. Either way is fine with me > test/jdk/java/util/TimeZone/SimpleTimeZoneEqualsHashCodeTest.java line 1: > >> (failed to retrieve contents of file, check the PR for context) > Include _equals_ in the test name as well? Perhaps _HashCodeEqualsTest_ or something along those lines. Renamed. I left `SimpleTimeZone` as the test is specific for this class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27660#discussion_r2411787045 PR Review Comment: https://git.openjdk.org/jdk/pull/27660#discussion_r2411778576 From naoto at openjdk.org Tue Oct 7 20:43:20 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 7 Oct 2025 20:43:20 GMT Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values [v3] In-Reply-To: References: Message-ID: > Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27660/files - new: https://git.openjdk.org/jdk/pull/27660/files/a2c988d8..aafdf18b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27660&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27660&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27660.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27660/head:pull/27660 PR: https://git.openjdk.org/jdk/pull/27660 From prappo at openjdk.org Tue Oct 7 20:46:37 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 7 Oct 2025 20:46:37 GMT Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to Instant [v7] In-Reply-To: <2jsm8nKU3yUzHB4hjOy_79Ak91Jz0fDmloaEx9RoCBg=.d4a2073d-a39d-4de5-b074-f7629fdbcdc8@github.com> References: <2jsm8nKU3yUzHB4hjOy_79Ak91Jz0fDmloaEx9RoCBg=.d4a2073d-a39d-4de5-b074-f7629fdbcdc8@github.com> Message-ID: On Tue, 7 Oct 2025 20:14:07 GMT, Stephen Colebourne wrote: > Have any users been asking for these methods, or is it just a case of we think they might be useful? > I cannot recall if people specifically asked for those. But from the prior discussion on the mailing list, it seemed that it's what the users do themselves when they handle extreme durations. These methods are error-prone. And although I think there's value in providing them, if you think it's overkill, we can always settle for capturing them as _examples_ in documentation comments instead. > It is definitely a bit weird that the saturating methods take a `Duration`, while the non-saturating ones take `TemporalAmount`, but I don't think there is a lot that can be done about that. Should they be required in the future, more generic methods that take `TemporalAmount` can be added to `Temporal`. In the case of `Instant`, they will be harmless overloads. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27549#issuecomment-3378645437 From duke at openjdk.org Tue Oct 7 20:54:08 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Tue, 7 Oct 2025 20:54:08 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision: add cast ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24694/files - new: https://git.openjdk.org/jdk/pull/24694/files/9f621161..d571e826 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From pavel.rappo at gmail.com Tue Oct 7 21:18:09 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Tue, 7 Oct 2025 23:18:09 +0200 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: ?amonn, Kurt, Is there any saturating arithmetic for instant + duration in your code base? On Fri, Sep 5, 2025 at 8:58?PM ?amonn McManus wrote: > > As promised, Kurt and I have examined some of the uses of our Durations.MAX constant. This is a summary of what we see in a random sample of 30 out of about 700 usages in Google's (giant) codebase. > > First, about half of the usages specifically concern deadlines. Many of them involve a method that sets an RPC deadline and where it is explicitly documented that you should use Durations.MAX to mean no deadline (or equivalently, infinite deadline). > > Several other usages concern deadline-adjacent concepts such as time-to-live or cache expiration delay. > > A number of usages specifically compare a Duration against Durations.MAX to recognize the "infinite duration" value. > > One usage uses our internal Sleeper interface to do sleeper.sleep(Durations.MAX), for an indefinite sleep (until interrupted). > > In a couple of places, there is a maximum allowed Duration for some operation, and a user-supplied Duration value is capped by this maximum. When no maximum is needed, the cap is Durations.MAX. This is similar to the "sentinel" use case I mentioned earlier. > > One case is using Durations.MAX in a test, to ensure that a function works correctly for all Duration values including the largest one. It is testing a Kotlin extension function that allows you to write e.g. 5.minutes: > > val n = Durations.MAX.toMinutes() > > assertThat(n.minutes).isEqualTo(Duration.ofMinutes(n)) > > assertFailsWith { (n + 1).minutes } > > > In summary, I think the most interesting use cases fall into these categories: > > to express an effectively-infinite Duration, possibly accompanied by special-case logic to optimize the exact value Durations.MAX; > > to express the absence of an optional cap on a user-supplied Duration value; > > to test that code works correctly even with extreme Duration values. > > > Of these, the first is potentially fragile because of the overflow problems we discussed. The other two seem unproblematic, though. > > > > On Thu, 4 Sept 2025 at 15:02, ?amonn McManus wrote: >> >> Two typical use cases: >> >> // 1. Sentinel >> Duration min = Duration.MAX; >> for (var foo : something()) { >> if (foo.duration().compareTo(min) < 0) { >> min = foo.duration(); >> } >> } >> >> // 2. "Forever" >> void frob(Optional optionalTimeout) { >> Duration timeout = optionalTimeout.orElse(Duration.MAX); >> Instant start = Instant.now(); >> boolean done = false; >> while (!done && startTime.until(Instant.now()).compareTo(timeout) < 0) {...} >> } >> >> The second case illustrates why this is potentially a bit delicate. You better not write this: >> >> void frob(Optional optionalTimeout) { >> Duration timeout = optionalTimeout.orElse(Duration.MAX); >> Instant deadline = Instant.now().plus(timeout); // oops >> boolean done = false; >> while (!done && Instant.now().isBefore(deadline)) {...} >> } >> >> Like Kevin, I am skeptical about Duration.MIN. If it means the most negative Duration, that is just Duration.MAX.negated(); and if it means the smallest positive Duration, that is just Duration.ofNanos(1). >> >> On Wed, 3 Sept 2025 at 18:32, Roger Riggs wrote: >>> >>> Hi, >>> >>> I'd be interested in the range of use cases for Duration.MAX or MIN. >>> >>> But for deadlines, I think the code should compute the deadline from a Duration of its choice based on the use. >>> Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that ignores information about the particular use that is relevant. Its just sloppy code that doesn't bother to express how long is long enough to meet operational parameters. >>> >>> YMMV, Roger >>> >>> On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote: >>> >>> Duration.MIN is a whole 'nother bag of worms, because Durations are signed (they can be positive or negative...or zero). Internally we also have Durations.MIN, but it's not public ... and along with it, I left myself a helpful note about naming: >>> >>> /** The minimum supported {@code Duration}, approximately -292 billion years. */ >>> // Note: before making this constant public, consider that "MIN" might not be a great name (not >>> // everyone knows that Durations can be negative!). >>> static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE); >>> >>> This reminds me of Double.MIN_VALUE (which is the smallest _positive_ double value) --- we've seen Double.MIN_VALUE misused so much that we introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias. A large percent of Double.MIN_VALUE users actually want the smallest possible negative value, aka -Double.MAX_VALUE. >>> >>> If we introduce Duration.MIN, I hope it would not be Duration.ofNanos(1), but rather Duration.ofSeconds(Long.MIN_VALUE). >>> >>> On Wed, Sep 3, 2025 at 7:59?PM ecki wrote: >>>> >>>> If you ask me, I don?t find it very useful, It won?t work for arithmetrics, even the APIs would have a hard time using it (how do you express the deadline) and APIs with a timeout parameter do have a good reason for it, better pick ?possible? values for better self healing and unstuck of systems. In fact I would err on the smaller side in combination with expecting spurious wakeups. >>>> >>>> BTW, when you introduce MIN as well, maybe also think about min precision, min delta or such. Will it always be 1 nano? >>>> >>>> Gru?, >>>> Bernd >>>> -- >>>> https://bernd.eckenfels.net >>>> ________________________________ >>>> Von: core-libs-dev im Auftrag von Pavel Rappo >>>> Gesendet: Donnerstag, September 4, 2025 12:41 AM >>>> An: Kurt Alfred Kluever >>>> Cc: Stephen Colebourne ; core-libs-dev >>>> Betreff: Re: Duration.MAX_VALUE >>>> >>>> This is useful; thanks. It would be good to see more of your data. >>>> >>>> My use case is also duration which practically means **forever**. I >>>> pass it to methods that accept timeouts, and expect these methods to >>>> correctly interpret it. >>>> >>>> One example of a practical interpretation is >>>> java.util.concurrent.TimeUnit.convert(Duration). This method never >>>> overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is >>>> roughly 292 years. >>>> >>>> Would I be okay, if the proposed duration didn't reflect **forever** >>>> but instead reflected **long enough**? I think so. But it still >>>> somehow feels wrong to make it less than maximum representable value. >>>> >>>> Personally, I'm not interested in calendar arithmetic, that is, in >>>> adding or subtracting durations. Others might be, and that's okay and >>>> needs to be factored in. For better or worse, java.time made a choice >>>> to be unforgiving in regard to overflow and is very upfront about it. >>>> It's not only proposed Duration.MAX. The same thing happens if you try >>>> this >>>> >>>> Instant.MAX.toEpochMilli() >>>> >>>> I guess my point is that doing calendar arithmetic on an unknown value >>>> is probably wrong. Doing it on a known huge/edge-case value is surely >>>> wrong. So back to your data. I would be interested to see what >>>> triggers overflows for your Durations.MAX. >>>> >>>> On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever wrote: >>>> > >>>> > Hi all, >>>> > >>>> > Internally at Google, we've had a Durations.MAX constant exposed for the past 7 years. It now has about 700 usages across our depot, which I can try to categorize (at a future date). >>>> > >>>> > While I haven't performed that analysis yet, I think exposing this constant was a bit of a mistake. People seem to want to use MAX to mean "forever" (often in regards to an RPC deadline). This works fine as long as every single layer that touches the deadline is very careful about overflow. The only reasonable thing you can do with MAX is compareTo() and equals(). Attempting to do any simple math operation (e.g., now+deadline) is going to explode. Additionally, decomposing Duration.MAX explodes for any sub-second precision (e.g., toMillis()). >>>> > >>>> > As we dug into this, another proposal came up which was something like Durations.VERY_LONG. This duration would be longer than any reasonable finite duration but not long enough to cause an overflow when added to any reasonable time. E.g., a million years would probably satisfy both criteria. This would mean math operations and decompositions won't explode (well, microseconds and nanoseconds still would), and it could safely be used as a relative timeout. >>>> > >>>> > As I mentioned above, I'd be happy to try to categorize a sample of our 700 existing usages if folks think that would be useful for this proposal. >>>> > >>>> > Thanks, >>>> > >>>> > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem team) >>>> > >>>> > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo wrote: >>>> >> >>>> >> If I understood you correctly, you think we should also add >>>> >> Duration.MIN. If so, what use case do you envision for it? Or we add >>>> >> if purely for symmetry with Instant? >>>> >> >>>> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo wrote: >>>> >> > >>>> >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne wrote: >>>> >> > > >>>> >> > > Hmm, yes. Not sure why that didn't get added in Java 8! >>>> >> > > The constants would be MAX/MIN as per classes like Instant. >>>> >> > > Stephen >>>> >> > >>>> >> > I thought that naming could be tricky :) The public constant >>>> >> > Duration.ZERO and the public method isZero() are already there. >>>> >> > However, it does not preclude us from naming a new constant MAX. >>>> > >>>> > >>>> > >>>> > -- >>>> > kak >>>> >>> >>> >>> -- >>> kak >>> >>> From chen.l.liang at oracle.com Tue Oct 7 21:57:11 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Tue, 7 Oct 2025 21:57:11 +0000 Subject: RFE: make AutoCloseable generic in its exception type In-Reply-To: <5afa96a1-1d59-4dca-8312-1136c19b762e@icemanx.nl> References: <5afa96a1-1d59-4dca-8312-1136c19b762e@icemanx.nl> Message-ID: Hi Rob, Can you share an actual piece of code that would benefit from such a lambda migration? I have checked the library code of java.base module; the try-with-resources and finally are mostly used for I/O and security cleanups, none of which would significantly benefit from this improvement. In particular, I noted this form would only be more useful than finally with these preconditions: 1. The cleanup action must be throwing some exception 2. The cleanup action doesn't make use of local variables Which IMO makes this usage much more niche. Finally, for your proposed solution, I think we can accomplish that with a subinterface of AutoCloseable that has this type parameter - this does not require existing implementors to update, yet offers the same benefits. Regards, Chen Liang Confidential ? Oracle Internal ________________________________ From: core-libs-dev on behalf of Rob Spoor Sent: Tuesday, October 7, 2025 2:43 PM To: core-libs-dev at openjdk.java.net Subject: RFE: make AutoCloseable generic in its exception type Hi all, AutoCloseable, as added in Java 7 and unchanged ever since, declares to throw Exception from its close() method. That means that anytime someone needs to have an AutoCloseable that throws a different exception, they must create an interface that extends AutoCloseable and override close() only to throw a different (or no) exception. That can become quite annoying if you have to do it often. But without such interfaces, we cannot use lambdas or method references in try-with-resources without having to deal with Exception: try (AutoCloseable _ = this::cleanup) { } // need to catch or re-throw Exception I think that making AutoCloseable generic in its exception type is a change that's quite simple, yet makes life easier for developers. The interface would become this: public interface AutoCloseable { /** * { // keep close for its documentation } That doesn't add much value yet, but we can now use it in try-with-resources without having to deal with Exception: try (AutoCloseable c = this::cleanup) { } // no need to catch or re-throw RuntimeException There is one other possible change that can make it even easier, and that is adding a factory method like Gatherer.Integrator.of: public interface AutoCloseable { // documentation omitted void close() throws X; // documentation omitted static AutoCloseable of(AutoCloseable closeable) { return closeable; } } The try-with-resources can now become even simpler: try (var _ = AutoCloseable.of(this::cleanup)) { } There is one possible issue with this "of" method, and that is possible incompatibilities with existing implementing classes or extending interfaces that already have an "of(AutoCloseable)" method with a different return type, or that are not static. I think the chances of that are not great, but it still is something to consider. Any thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Tue Oct 7 22:25:08 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 7 Oct 2025 22:25:08 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Fri, 3 Oct 2025 19:56:22 GMT, Xueming Shen wrote: > ### 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 thi... The API looks good. Is the performance comparable to equalsIgnoreCase? src/java.base/share/classes/java/lang/StringLatin1.java line 194: > 192: char[] folded2 = null; > 193: int k1 = 0, k2 = 0, fk1 = 0, fk2 = 0; > 194: while ((k1 < len1 || folded1 != null && fk1 < folded1.length) && Many suggestions come to mind here on the algorithm, to optimize performance. For example, many strings will have identical prefixes. Using Arrays.mismatch could quickly skip over the identical prefix. Consider using code points (or a long, packing 4 chars) for the folded replacements, to avoid having to step through chars in char arrays. CaseFolding.foldIfDefined could return the full expansion as a long. It may be profitable to use Arrays.mismatch again after expanded characters are determined to be equal. Take another look at the data structure storing and doing the lookup of foldIfDefined both to increase the lookup performance. src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 230: > 228: private static class CaseFoldingEntry { > 229: final int cp; > 230: final char[] folding; Consider storing the folding as a int or long directly to avoid the overhead of small char arrays. Arrange to be able to compare the whole replacement with another codePoint, etc. src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 280: > 278: } > 279: > 280: private void add(CaseFoldingEntry entry) { CDS can map whole objects/data structures into the heap; consider how to make this data structure so it can be mapped and not re-computed each startup. ------------- PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3312084027 PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2412043131 PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2412060747 PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2412062604 From almatvee at openjdk.org Tue Oct 7 23:50:55 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 7 Oct 2025 23:50:55 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: Message-ID: > - Removed pre- and post- installation PKG scripts. > - This code is not needed and PKG should create destination folder and set correct permissions. > - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. > - Users will have ability to provide pre- and post- installation PKG scripts if needed. > - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. > - I think code in these scripts are some legacy leftovers. > - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v6] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25510/files - new: https://git.openjdk.org/jdk/pull/25510/files/bcd26fed..99380799 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=06-07 Stats: 125 lines in 1 file changed: 41 ins; 31 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/25510.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25510/head:pull/25510 PR: https://git.openjdk.org/jdk/pull/25510 From jlu at openjdk.org Tue Oct 7 23:52:37 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 7 Oct 2025 23:52:37 GMT Subject: RFR: 8369050: DecimalFormat Rounding Errors for Ties Torwards 1 in LSD or 0 Message-ID: Please review this PR which corrects a rounding error for DecimalFormat on tie cases when the maximum fraction digits allowed is one less than the position of the first significant digit in the double rounded. For example, rounding a value such as 0.0005 to a maximum of 3 fractional digits. In order to get the correct `count` value, we must strip the trailing zeros prior to the check to ensure we have the correct value of `count` = 1 so that we can go down the _Rounding position is the last index_ case which properly checks if the String double was already rounded or is exact from its true decimal form. ------------- Commit messages: - small test changes - init Changes: https://git.openjdk.org/jdk/pull/27681/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27681&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369050 Stats: 95 lines in 3 files changed: 88 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27681/head:pull/27681 PR: https://git.openjdk.org/jdk/pull/27681 From jlu at openjdk.org Tue Oct 7 23:52:39 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 7 Oct 2025 23:52:39 GMT Subject: RFR: 8369050: DecimalFormat Rounding Errors for Ties Torwards 1 in LSD or 0 In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 23:19:28 GMT, Justin Lu wrote: > Please review this PR which corrects a rounding error for DecimalFormat on tie cases when the maximum fraction digits allowed is one less than the position of the first significant digit in the double rounded. For example, rounding a value such as 0.0005 to a maximum of 3 fractional digits. In order to get the correct `count` value, we must strip the trailing zeros prior to the check to ensure we have the correct value of `count` = 1 so that we can go down the _Rounding position is the last index_ case which properly checks if the String double was already rounded or is exact from its true decimal form. For some history, this bug is long-standing, but has taken different forms after recent changes to DigitList. DigitList, when handling the specific case as mentioned in the summary statement returns a faulty value due to an incorrect value of `count`. DigitList used to parse its own `count` value, but was recently changed in [JDK-8367324](https://bugs.openjdk.org/browse/JDK-8367324) to retrieve `count`from `FloatingDecimal`. Consider the double `0.00005` rounded to 4 fractional digits, `count` prior to JDK-8367324 would be calculated as 2 while it is now calculated as 17 due to the implementation differences. Thus, when handling the following case, } else if (-decimalAt == maximumDigits) { // If we round 0.0009 to 3 fractional digits, then we have to // create a new one digit in the least significant location. if (shouldRoundUp(0, roundedUp, valueExactAsDecimal)) { count = 1; ++decimalAt; digits[0] = '1'; } else { For both `count` values, `if (maximumDigits == (count - 1))` is erroneously evaluated in `shouldRoundUp` under the HALF_* cases and instead falls under the _Rounding position is not the last index_ case. Notice that before JDK-8367324, `count` was still being read **incorrectly** as 2 (for fractional doubles in exponential form). However, the behavioral differences had not been observed, since the HALF_UP/DOWN cases prior to https://bugs.openjdk.org/browse/JDK-8314169 could return the right values by chance when going down the wrong path. test/jdk/java/text/Format/DecimalFormat/RoundingToLSDTieTest.java line 1: > 1: /* I considered adding the tests in this file under _TieRoundingTest_, but did not do so to make review easier since JUnit could be used for the test in this PR. (_TieRoundingTest_ is old and does not use JUnit.) Will consider updating _TieRoundingTest_ to use JUnit and merging the tests in this PR under it in a separate issue. test/jdk/java/text/Format/NumberFormat/NumberRegression.java line 1779: > 1777: "0%", "0%", "1%", "1%", "1%", > 1778: "0", "2", "0.2", "0.6", "0.04", > 1779: "0.04", "0.001", "0.002", This test is checking that `.0005` rounded to 3 digits is "0.000" under HALF_EVEN. This is wrong. See, `new BigDecimal(0.0005) ==> 0.0005000000000000000104083408558608425664715468883514404296875`. Resolving the bug in this PR requires fixing this incorrect test case. From the JDK-4241880 issue, it seems this case may have been put in to "document the incorrect but actual behavior". ------------- PR Comment: https://git.openjdk.org/jdk/pull/27681#issuecomment-3379027299 PR Review Comment: https://git.openjdk.org/jdk/pull/27681#discussion_r2412168905 PR Review Comment: https://git.openjdk.org/jdk/pull/27681#discussion_r2412167812 From emcmanus at google.com Wed Oct 8 00:13:24 2025 From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=) Date: Tue, 7 Oct 2025 17:13:24 -0700 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: Yes, we have utility classes Instants and Durations, and Instants includes methods Instants.saturatedAdd(Instant, Duration) and Instants.saturatedSubtract(Instant, Duration). Each has a modest number of uses in the codebase, about three orders of magnitude less than the number of classes that reference Instant or Duration. On Tue, 7 Oct 2025 at 14:18, Pavel Rappo wrote: > ?amonn, Kurt, > > Is there any saturating arithmetic for instant + duration in your code > base? > > > > On Fri, Sep 5, 2025 at 8:58?PM ?amonn McManus wrote: > > > > As promised, Kurt and I have examined some of the uses of our > Durations.MAX constant. This is a summary of what we see in a random sample > of 30 out of about 700 usages in Google's (giant) codebase. > > > > First, about half of the usages specifically concern deadlines. Many of > them involve a method that sets an RPC deadline and where it is explicitly > documented that you should use Durations.MAX to mean no deadline (or > equivalently, infinite deadline). > > > > Several other usages concern deadline-adjacent concepts such as > time-to-live or cache expiration delay. > > > > A number of usages specifically compare a Duration against Durations.MAX > to recognize the "infinite duration" value. > > > > One usage uses our internal Sleeper interface to do > sleeper.sleep(Durations.MAX), for an indefinite sleep (until interrupted). > > > > In a couple of places, there is a maximum allowed Duration for some > operation, and a user-supplied Duration value is capped by this maximum. > When no maximum is needed, the cap is Durations.MAX. This is similar to the > "sentinel" use case I mentioned earlier. > > > > One case is using Durations.MAX in a test, to ensure that a function > works correctly for all Duration values including the largest one. It is > testing a Kotlin extension function that allows you to write e.g. 5.minutes: > > > > val n = Durations.MAX.toMinutes() > > > > assertThat(n.minutes).isEqualTo(Duration.ofMinutes(n)) > > > > assertFailsWith { (n + 1).minutes } > > > > > > In summary, I think the most interesting use cases fall into these > categories: > > > > to express an effectively-infinite Duration, possibly accompanied by > special-case logic to optimize the exact value Durations.MAX; > > > > to express the absence of an optional cap on a user-supplied Duration > value; > > > > to test that code works correctly even with extreme Duration values. > > > > > > Of these, the first is potentially fragile because of the overflow > problems we discussed. The other two seem unproblematic, though. > > > > > > > > On Thu, 4 Sept 2025 at 15:02, ?amonn McManus > wrote: > >> > >> Two typical use cases: > >> > >> // 1. Sentinel > >> Duration min = Duration.MAX; > >> for (var foo : something()) { > >> if (foo.duration().compareTo(min) < 0) { > >> min = foo.duration(); > >> } > >> } > >> > >> // 2. "Forever" > >> void frob(Optional optionalTimeout) { > >> Duration timeout = optionalTimeout.orElse(Duration.MAX); > >> Instant start = Instant.now(); > >> boolean done = false; > >> while (!done && startTime.until(Instant.now()).compareTo(timeout) < > 0) {...} > >> } > >> > >> The second case illustrates why this is potentially a bit delicate. You > better not write this: > >> > >> void frob(Optional optionalTimeout) { > >> Duration timeout = optionalTimeout.orElse(Duration.MAX); > >> Instant deadline = Instant.now().plus(timeout); // oops > >> boolean done = false; > >> while (!done && Instant.now().isBefore(deadline)) {...} > >> } > >> > >> Like Kevin, I am skeptical about Duration.MIN. If it means the most > negative Duration, that is just Duration.MAX.negated(); and if it means the > smallest positive Duration, that is just Duration.ofNanos(1). > >> > >> On Wed, 3 Sept 2025 at 18:32, Roger Riggs > wrote: > >>> > >>> Hi, > >>> > >>> I'd be interested in the range of use cases for Duration.MAX or MIN. > >>> > >>> But for deadlines, I think the code should compute the deadline from a > Duration of its choice based on the use. > >>> Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that > ignores information about the particular use that is relevant. Its just > sloppy code that doesn't bother to express how long is long enough to meet > operational parameters. > >>> > >>> YMMV, Roger > >>> > >>> On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote: > >>> > >>> Duration.MIN is a whole 'nother bag of worms, because Durations are > signed (they can be positive or negative...or zero). Internally we also > have Durations.MIN, but it's not public ... and along with it, I left > myself a helpful note about naming: > >>> > >>> /** The minimum supported {@code Duration}, approximately -292 > billion years. */ > >>> // Note: before making this constant public, consider that "MIN" > might not be a great name (not > >>> // everyone knows that Durations can be negative!). > >>> static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE); > >>> > >>> This reminds me of Double.MIN_VALUE (which is the smallest _positive_ > double value) --- we've seen Double.MIN_VALUE misused so much that we > introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias. A large > percent of Double.MIN_VALUE users actually want the smallest possible > negative value, aka -Double.MAX_VALUE. > >>> > >>> If we introduce Duration.MIN, I hope it would not be > Duration.ofNanos(1), but rather Duration.ofSeconds(Long.MIN_VALUE). > >>> > >>> On Wed, Sep 3, 2025 at 7:59?PM ecki wrote: > >>>> > >>>> If you ask me, I don?t find it very useful, It won?t work for > arithmetrics, even the APIs would have a hard time using it (how do you > express the deadline) and APIs with a timeout parameter do have a good > reason for it, better pick ?possible? values for better self healing and > unstuck of systems. In fact I would err on the smaller side in combination > with expecting spurious wakeups. > >>>> > >>>> BTW, when you introduce MIN as well, maybe also think about min > precision, min delta or such. Will it always be 1 nano? > >>>> > >>>> Gru?, > >>>> Bernd > >>>> -- > >>>> https://bernd.eckenfels.net > >>>> ________________________________ > >>>> Von: core-libs-dev im Auftrag von > Pavel Rappo > >>>> Gesendet: Donnerstag, September 4, 2025 12:41 AM > >>>> An: Kurt Alfred Kluever > >>>> Cc: Stephen Colebourne ; core-libs-dev < > core-libs-dev at openjdk.org> > >>>> Betreff: Re: Duration.MAX_VALUE > >>>> > >>>> This is useful; thanks. It would be good to see more of your data. > >>>> > >>>> My use case is also duration which practically means **forever**. I > >>>> pass it to methods that accept timeouts, and expect these methods to > >>>> correctly interpret it. > >>>> > >>>> One example of a practical interpretation is > >>>> java.util.concurrent.TimeUnit.convert(Duration). This method never > >>>> overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is > >>>> roughly 292 years. > >>>> > >>>> Would I be okay, if the proposed duration didn't reflect **forever** > >>>> but instead reflected **long enough**? I think so. But it still > >>>> somehow feels wrong to make it less than maximum representable value. > >>>> > >>>> Personally, I'm not interested in calendar arithmetic, that is, in > >>>> adding or subtracting durations. Others might be, and that's okay and > >>>> needs to be factored in. For better or worse, java.time made a choice > >>>> to be unforgiving in regard to overflow and is very upfront about it. > >>>> It's not only proposed Duration.MAX. The same thing happens if you try > >>>> this > >>>> > >>>> Instant.MAX.toEpochMilli() > >>>> > >>>> I guess my point is that doing calendar arithmetic on an unknown value > >>>> is probably wrong. Doing it on a known huge/edge-case value is surely > >>>> wrong. So back to your data. I would be interested to see what > >>>> triggers overflows for your Durations.MAX. > >>>> > >>>> On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever > wrote: > >>>> > > >>>> > Hi all, > >>>> > > >>>> > Internally at Google, we've had a Durations.MAX constant exposed > for the past 7 years. It now has about 700 usages across our depot, which I > can try to categorize (at a future date). > >>>> > > >>>> > While I haven't performed that analysis yet, I think exposing this > constant was a bit of a mistake. People seem to want to use MAX to mean > "forever" (often in regards to an RPC deadline). This works fine as long as > every single layer that touches the deadline is very careful about > overflow. The only reasonable thing you can do with MAX is compareTo() and > equals(). Attempting to do any simple math operation (e.g., now+deadline) > is going to explode. Additionally, decomposing Duration.MAX explodes for > any sub-second precision (e.g., toMillis()). > >>>> > > >>>> > As we dug into this, another proposal came up which was something > like Durations.VERY_LONG. This duration would be longer than any reasonable > finite duration but not long enough to cause an overflow when added to any > reasonable time. E.g., a million years would probably satisfy both > criteria. This would mean math operations and decompositions won't explode > (well, microseconds and nanoseconds still would), and it could safely be > used as a relative timeout. > >>>> > > >>>> > As I mentioned above, I'd be happy to try to categorize a sample of > our 700 existing usages if folks think that would be useful for this > proposal. > >>>> > > >>>> > Thanks, > >>>> > > >>>> > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin > Ecosystem team) > >>>> > > >>>> > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo > wrote: > >>>> >> > >>>> >> If I understood you correctly, you think we should also add > >>>> >> Duration.MIN. If so, what use case do you envision for it? Or we > add > >>>> >> if purely for symmetry with Instant? > >>>> >> > >>>> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo > wrote: > >>>> >> > > >>>> >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne < > scolebourne at joda.org> wrote: > >>>> >> > > > >>>> >> > > Hmm, yes. Not sure why that didn't get added in Java 8! > >>>> >> > > The constants would be MAX/MIN as per classes like Instant. > >>>> >> > > Stephen > >>>> >> > > >>>> >> > I thought that naming could be tricky :) The public constant > >>>> >> > Duration.ZERO and the public method isZero() are already there. > >>>> >> > However, it does not preclude us from naming a new constant MAX. > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > kak > >>>> > >>> > >>> > >>> -- > >>> kak > >>> > >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5281 bytes Desc: S/MIME Cryptographic Signature URL: From almatvee at openjdk.org Wed Oct 8 00:14:39 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 Oct 2025 00:14:39 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 23:50:55 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v6] 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v6] - Test updated as discussed above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-3379112296 From sherman at openjdk.org Wed Oct 8 00:33:20 2025 From: sherman at openjdk.org (Xueming Shen) Date: Wed, 8 Oct 2025 00:33:20 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2] In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> 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 > > See CSR https://bugs.openjd... Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: minor api doc updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27628/files - new: https://git.openjdk.org/jdk/pull/27628/files/1abb0228..9d9997dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=00-01 Stats: 18 lines in 1 file changed: 5 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27628.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27628/head:pull/27628 PR: https://git.openjdk.org/jdk/pull/27628 From asemenyuk at openjdk.org Wed Oct 8 00:38:06 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Oct 2025 00:38:06 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 23:50:55 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v6] src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgInstallerScripts.java line 59: > 57: > 58: // Should never be reached > 59: return null; It is equivalent to: private String getPublicName() { return name(); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412238017 From almatvee at openjdk.org Wed Oct 8 01:02:39 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 Oct 2025 01:02:39 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v9] In-Reply-To: References: Message-ID: > - Removed pre- and post- installation PKG scripts. > - This code is not needed and PKG should create destination folder and set correct permissions. > - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. > - Users will have ability to provide pre- and post- installation PKG scripts if needed. > - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. > - I think code in these scripts are some legacy leftovers. > - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v7] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25510/files - new: https://git.openjdk.org/jdk/pull/25510/files/99380799..eb775533 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=07-08 Stats: 12 lines in 1 file changed: 0 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25510.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25510/head:pull/25510 PR: https://git.openjdk.org/jdk/pull/25510 From almatvee at openjdk.org Wed Oct 8 01:02:40 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 Oct 2025 01:02:40 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 23:50:55 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v6] 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v7] - Removed `getPublicName()`. `name()` will be used instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-3379214295 From asemenyuk at openjdk.org Wed Oct 8 01:15:08 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Oct 2025 01:15:08 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: Message-ID: <2YLXDbbJRCNsOkalJCH5E7u_3_1jBYo8bdxUK_WmfxI=.ef673c29-061a-4b1c-b850-973743c83dc4@github.com> On Tue, 7 Oct 2025 23:50:55 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v6] src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgPackager.java line 291: > 289: } catch (IOException ex) { > 290: throw new UncheckedIOException(ex); > 291: } This test is wrong. It contradicts the semantics of the `scriptsRoot()` function. If `scriptsRoot()` returns a non-empty Optional, something should be in the script directory. It would be better to alter `scriptsRoot()` to return an empty Optional instance if there are no scripts for the main pkg package. Something like: Optional scriptsRoot() { if (pkg.app().appStore() || pkg.isRuntimeInstaller() || MacPkgInstallerScripts.createAppScripts().setResourceDir(env).isEmpty()) { return Optional.empty(); } else { return Optional.of(env.configDir().resolve("scripts")); } } where `setResourceDir(BuildEnv)` and `isEmpty()` are two new functions in PackageScripts class: PackageScripts setResourceDir(BuildEnv env) { env.resourceDir().ifPresent(this::setResourceDir); return this; } boolean isEmpty() { return scripts.values().stream().map(ShellScriptResource::getResource).allMatch(overridableResource -> { try { return overridableResource.saveToStream(null) == null; } catch (IOException ex) { throw new UncheckedIOException(ex); } }); } As a supplementary change in MacPkgPackager, it would be good to replace `.setResourceDir(env.resourceDir().orElse(null))` with the new `.setResourceDir(env)`. src/jdk.jpackage/share/classes/jdk/jpackage/internal/OverridableResource.java line 237: > 235: Log.verbose(I18N.format("message.no-default-resource", > 236: publicName, getPrintableCategory(), publicName)); > 237: I still believe this log message is misleading. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412275171 PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412276864 From asemenyuk at openjdk.org Wed Oct 8 01:19:09 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Oct 2025 01:19:09 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 23:50:55 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v6] src/jdk.jpackage/unix/classes/jdk/jpackage/internal/PackageScripts.java line 97: > 95: resource = new OverridableResource(defaultName.get(), > 96: ResourceLocator.class).setCategory(category); > 97: } var resource = defaultName.map(v -> { return new OverridableResource(v, ResourceLocator.class); }).orElseGet(OverridableResource::new).setCategory(category); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412280790 From asemenyuk at openjdk.org Wed Oct 8 01:24:07 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Oct 2025 01:24:07 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: Message-ID: <6qwxQwqWPZSKsOFbm3828SZ4T00LGiWj-esKcfR3XDs=.731b2abb-9a6f-483f-ad04-af171dd050d0@github.com> On Tue, 7 Oct 2025 23:50:55 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v6] src/jdk.jpackage/unix/classes/jdk/jpackage/internal/PackageScripts.java line 110: > 108: } > 109: } > 110: return Optional.ofNullable(null); private Optional getDefaultPublicName() { return defaultName.flatMap(v -> { final String wellKnownSuffix = ".template"; if (v.endsWith(wellKnownSuffix)) { return Optional.of(v.substring(0, v.length() - wellKnownSuffix.length())); } return Optional.empty(); }); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412284993 From almatvee at openjdk.org Wed Oct 8 01:39:06 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 Oct 2025 01:39:06 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: <2YLXDbbJRCNsOkalJCH5E7u_3_1jBYo8bdxUK_WmfxI=.ef673c29-061a-4b1c-b850-973743c83dc4@github.com> References: <2YLXDbbJRCNsOkalJCH5E7u_3_1jBYo8bdxUK_WmfxI=.ef673c29-061a-4b1c-b850-973743c83dc4@github.com> Message-ID: On Wed, 8 Oct 2025 01:11:53 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v6] > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/OverridableResource.java line 237: > >> 235: Log.verbose(I18N.format("message.no-default-resource", >> 236: publicName, getPrintableCategory(), publicName)); >> 237: > > I still believe this log message is misleading. `[18:34:04.625] No default package resource postinstall [PKG postinstall script] (add postinstall to the resource-dir to customize).` `[18:34:04.625] No default package resource preinstall [PKG preinstall script] (add preinstall to the resource-dir to customize). ` This is example of log message. Do you have any suggestions on how to improve it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412298119 From dholmes at openjdk.org Wed Oct 8 02:01:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 02:01:05 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 20:54:08 GMT, Benjamin Peterson wrote: >> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. >> >> Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. > > Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision: > > add cast I don't see that this is a hotspot issue and you can't just unconditionally add a dot to all passed in names - that will surely break any code that expected the .DLL to be appended! As @AlanBateman has noted there are semantic question to address here. Library loading is tied to classloaders and the use of symlinks allows the same library to be loaded by different names in different classloaders - which could potentially wreak havoc I think if we execute the onLoad hooks multiple times. I would like to see core-libs folk decide exactly what should happen for these different cases, and then figure out where is the best place to make that happen. But initial view is that you should not be renaming the DLLs to not have a .dll extension - that just seems to be a self-inflicted wound. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24694#pullrequestreview-3312513111 From rriggs at openjdk.org Wed Oct 8 02:11:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 8 Oct 2025 02:11:53 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v15] In-Reply-To: References: Message-ID: > The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. > > The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. > > The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. Roger Riggs 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 22 additional commits since the last revision: - The ProcessCloseTest is modified to be able to test the logic around close() waiting for the process to exit and the specified behavior of interrupting the waitFor. - Close is modified to wait for the process to terminate before returning. Please review the revised javadoc. As suggested in review comments, waiting for the process to terminate allows a more orderly cleanup by the application. The streams are closed and close uses `waitFor()` with an unlimited timeout for the process to terminate. While waiting the thread can be `interrupted` to exit the `waitFor`. If/when `waitFor` is interrupted, the process is destroyedForcibly on all platforms. When close() returns, the thread interrupt will pending and can be handled by the caller. If a watchdog timeout is desired on close(), a separate thread can schedule an interrupt at a suitable time after close is called. - Review comment improvements to make expected behavior clearer. - Merge branch 'master' into 8364361-process-autocloseable - Clarify the use of waitFor after close() or T-W-R exit. - Additional review feedback. Updated to emphasize reading the data from the streams and calling waitFor to allow for normal termination. - Merge branch 'master' into 8364361-process-autocloseable - Address review comments for code and javadoc in Process, the test and the example. Reinforced that calling waitFor should occur before calling close to wait for termination and get the exitStatus. Corrected the error message check for invalid handles on Windows. Update test to allow normal completion when exceptions may be expected. Correct the expected message on Windows for an invalid handle exception. - Update close() to use "terminate" consistently. - Remove volatile from "closed" field; updates are guarded by synchronized. - ... and 12 more: https://git.openjdk.org/jdk/compare/73753a41...6f8f7327 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26649/files - new: https://git.openjdk.org/jdk/pull/26649/files/18637975..6f8f7327 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=13-14 Stats: 10946 lines in 514 files changed: 5350 ins; 2684 del; 2912 mod Patch: https://git.openjdk.org/jdk/pull/26649.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26649/head:pull/26649 PR: https://git.openjdk.org/jdk/pull/26649 From almatvee at openjdk.org Wed Oct 8 02:14:48 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 Oct 2025 02:14:48 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v10] In-Reply-To: References: Message-ID: > - Removed pre- and post- installation PKG scripts. > - This code is not needed and PKG should create destination folder and set correct permissions. > - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. > - Users will have ability to provide pre- and post- installation PKG scripts if needed. > - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. > - I think code in these scripts are some legacy leftovers. > - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25510/files - new: https://git.openjdk.org/jdk/pull/25510/files/eb775533..f3a0672d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=08-09 Stats: 44 lines in 2 files changed: 18 ins; 10 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25510.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25510/head:pull/25510 PR: https://git.openjdk.org/jdk/pull/25510 From almatvee at openjdk.org Wed Oct 8 02:14:48 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 Oct 2025 02:14:48 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v9] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 01:02:39 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v7] 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] - Fixed comments above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-3379316423 From benjamin at engflow.com Wed Oct 8 02:15:00 2025 From: benjamin at engflow.com (Benjamin Peterson) Date: Tue, 7 Oct 2025 21:15:00 -0500 Subject: requesting review on JDK-8348828: Windows dll loading now resolves symlinks In-Reply-To: <14172c0d-fa14-47aa-a088-9ba4a9d7cc0f@oracle.com> References: <14172c0d-fa14-47aa-a088-9ba4a9d7cc0f@oracle.com> Message-ID: On Tue, Oct 7, 2025 at 12:52?PM Alan Bateman wrote: > > On 07/10/2025 18:08, Benjamin Peterson wrote: > > The reproducer I submitted in the initial bug report is definitely > weird looking because I attempted point out the breaking change in as > simple and as self-contained a manner as possible. But, I did run into > this in a very real and useful application. I've tried to add more > context about the application in comments such as > https://bugs.openjdk.org/browse/JDK-8348828?focusedId=14744766&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14744766 . > I can certainly answer more questions about the usecase if the would > be helpful. > > The heart of the matter is: Is it legal to call System.loadLibrary() > with a symlink on Windows? The JDK before 24's answer was yes. > > I have sympathy for the more general case. I think it would be useful to create a small table of what works and doesn't work, e.g. > > foo.dll -> dir\bar.dll This works all on Java versions. > foo.dll -> dir\bar This doesn't work after Java 24. > foo -> dir\bar.dll This didn't work before Java 24 but works now I believe. From asemenyuk at openjdk.org Wed Oct 8 02:20:07 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Oct 2025 02:20:07 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: <2YLXDbbJRCNsOkalJCH5E7u_3_1jBYo8bdxUK_WmfxI=.ef673c29-061a-4b1c-b850-973743c83dc4@github.com> Message-ID: On Wed, 8 Oct 2025 01:36:03 GMT, Alexander Matveev wrote: >> src/jdk.jpackage/share/classes/jdk/jpackage/internal/OverridableResource.java line 237: >> >>> 235: Log.verbose(I18N.format("message.no-default-resource", >>> 236: publicName, getPrintableCategory(), publicName)); >>> 237: >> >> I still believe this log message is misleading. > > `[18:34:04.625] No default package resource postinstall [PKG postinstall script] (add postinstall to the resource-dir to customize).` > `[18:34:04.625] No default package resource preinstall [PKG preinstall script] (add preinstall to the resource-dir to customize). > ` > This is example of log message. Do you have any suggestions on how to improve it? This change adds the following log message: [22:09:41.559] No default package resource null [script to run after application image is populated] (add null to the resource-dir to customize). I can see it in PkgScriptsTest and in SimplePackageTest. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412335312 From asemenyuk at openjdk.org Wed Oct 8 02:20:08 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Oct 2025 02:20:08 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: <2YLXDbbJRCNsOkalJCH5E7u_3_1jBYo8bdxUK_WmfxI=.ef673c29-061a-4b1c-b850-973743c83dc4@github.com> Message-ID: On Wed, 8 Oct 2025 02:13:54 GMT, Alexey Semenyuk wrote: >> `[18:34:04.625] No default package resource postinstall [PKG postinstall script] (add postinstall to the resource-dir to customize).` >> `[18:34:04.625] No default package resource preinstall [PKG preinstall script] (add preinstall to the resource-dir to customize). >> ` >> This is example of log message. Do you have any suggestions on how to improve it? > > This change adds the following log message: > > [22:09:41.559] No default package resource null [script to run after application image is populated] (add null to the resource-dir to customize). > > I can see it in PkgScriptsTest and in SimplePackageTest. > Do you have any suggestions on how to improve it? No, I don't know off the top of my head. This is a broader issue: jpackage should write all customizable resources in the log. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412337596 From almatvee at openjdk.org Wed Oct 8 02:20:09 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 Oct 2025 02:20:09 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: <2YLXDbbJRCNsOkalJCH5E7u_3_1jBYo8bdxUK_WmfxI=.ef673c29-061a-4b1c-b850-973743c83dc4@github.com> Message-ID: On Wed, 8 Oct 2025 02:16:25 GMT, Alexey Semenyuk wrote: >> This change adds the following log message: >> >> [22:09:41.559] No default package resource null [script to run after application image is populated] (add null to the resource-dir to customize). >> >> I can see it in PkgScriptsTest and in SimplePackageTest. > >> Do you have any suggestions on how to improve it? > > No, I don't know off the top of my head. This is a broader issue: jpackage should write all customizable resources in the log. I can see it as well. I think we have a bug for some resources which does not exist and we do not provide public name for it. I will investigate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412338668 From duke at openjdk.org Wed Oct 8 02:25:04 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 8 Oct 2025 02:25:04 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 01:57:59 GMT, David Holmes wrote: > I don't see that this is a hotspot issue and you can't just unconditionally add a dot to all passed in names - that will surely break any code that expected the .DLL to be appended! I'm not sure such code previously would have worked. As far as I can tell, `System.loadLibrary` would fail before reaching `os::dll_load` if the string passed into `System.loadLibrary` could not be resolved to an extant file by `NativeLibraries`. (Okay, I suppose that if `mylib` and `mylib.dll` both exist, `System.loadLibrary("mylib")` would actually load `mylib.dll`. But that actually seems bad?) > > As @AlanBateman has noted there are semantic question to address here. Library loading is tied to classloaders and the use of symlinks allows the same library to be loaded by different names in different classloaders - which could potentially wreak havoc I think if we execute the onLoad hooks multiple times. This change doesn't affect the resolution of symlinks now, though. > > I would like to see core-libs folk decide exactly what should happen for these different cases, and then figure out where is the best place to make that happen. liach's observation in https://github.com/openjdk/jdk/pull/24694#issuecomment-3377528055 that the JNI and `System.loadLibrary` should behave similarly likely means some hotspot change is needed. > > But initial view is that you should not be renaming the DLLs to not have a .dll extension - that just seems to be a self-inflicted wound. I agree that the reproducer in the bug is not something you should do for itself; it is a small self-contained way to demonstrate the regression. I tried to expand on what the broken application actually does a few more places if that helps such as here: https://bugs.openjdk.org/browse/JDK-8348828?focusedId=14744766&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14744766. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3379336289 From dholmes at openjdk.org Wed Oct 8 02:39:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 02:39:05 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 02:22:15 GMT, Benjamin Peterson wrote: > I'm not sure such code previously would have worked. As far as I can tell, System.loadLibrary would fail before reaching os::dll_load if the string passed into System.loadLibrary could not be resolved to an extant file by NativeLibraries. `os::dll_load` is not used only to implement `System.loadLibrary`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3379356228 From almatvee at openjdk.org Wed Oct 8 02:39:51 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 Oct 2025 02:39:51 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v11] In-Reply-To: References: Message-ID: > - Removed pre- and post- installation PKG scripts. > - This code is not needed and PKG should create destination folder and set correct permissions. > - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. > - Users will have ability to provide pre- and post- installation PKG scripts if needed. > - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. > - I think code in these scripts are some legacy leftovers. > - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v9] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25510/files - new: https://git.openjdk.org/jdk/pull/25510/files/f3a0672d..47271a16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=09-10 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25510.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25510/head:pull/25510 PR: https://git.openjdk.org/jdk/pull/25510 From almatvee at openjdk.org Wed Oct 8 02:39:52 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 Oct 2025 02:39:52 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v10] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 02:14:48 GMT, Alexander Matveev wrote: >> - Removed pre- and post- installation PKG scripts. >> - This code is not needed and PKG should create destination folder and set correct permissions. >> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle. >> - Users will have ability to provide pre- and post- installation PKG scripts if needed. >> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`. >> - I think code in these scripts are some legacy leftovers. >> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v9] - Fixed `null` in log message. With this change all `createResource(null)` should call `setPublicName()`. I only found one location in `ScriptRunner`. Example of log message after fix: `[19:27:52.205] No default package resource Test-post-image.sh [script to run after application image is populated] (add Test-post-image.sh to the resource-dir to customize).` ------------- PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-3379352678 From asemenyuk at openjdk.org Wed Oct 8 02:39:53 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Oct 2025 02:39:53 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: <2YLXDbbJRCNsOkalJCH5E7u_3_1jBYo8bdxUK_WmfxI=.ef673c29-061a-4b1c-b850-973743c83dc4@github.com> Message-ID: On Wed, 8 Oct 2025 02:17:45 GMT, Alexander Matveev wrote: >>> Do you have any suggestions on how to improve it? >> >> No, I don't know off the top of my head. This is a broader issue: jpackage should write all customizable resources in the log. > > I can see it as well. I think we have a bug for some resources which does not exist and we do not provide public name for it. I will investigate. Let's address customizable resource logging in a separate patch. I filed [JDK-8369334](https://bugs.openjdk.org/browse/JDK-8369334) for this effort. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412354924 From almatvee at openjdk.org Wed Oct 8 02:39:54 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 Oct 2025 02:39:54 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: <2YLXDbbJRCNsOkalJCH5E7u_3_1jBYo8bdxUK_WmfxI=.ef673c29-061a-4b1c-b850-973743c83dc4@github.com> Message-ID: <4RzO_0PNdZf5C4wnxWJwfXcI-YcAzV11AxW7lSPy3ls=.8f7f8421-1fd6-457a-b701-6a40ebc5f8b1@github.com> On Wed, 8 Oct 2025 02:34:15 GMT, Alexey Semenyuk wrote: >> I can see it as well. I think we have a bug for some resources which does not exist and we do not provide public name for it. I will investigate. > > Let's address customizable resource logging in a separate patch. I filed [JDK-8369334](https://bugs.openjdk.org/browse/JDK-8369334) for this effort. I just fix it. Let me know what you think. I can revert my last commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412356707 From duke at openjdk.org Wed Oct 8 02:44:06 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 8 Oct 2025 02:44:06 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 02:36:42 GMT, David Holmes wrote: > > I'm not sure such code previously would have worked. As far as I can tell, System.loadLibrary would fail before reaching os::dll_load if the string passed into System.loadLibrary could not be resolved to an extant file by NativeLibraries. > > `os::dll_load` is not used only to implement `System.loadLibrary`. So, this dot logic should be lifted to `JVM_LoadLibrary`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3379362093 From dholmes at openjdk.org Wed Oct 8 02:47:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 02:47:03 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 02:40:58 GMT, Benjamin Peterson wrote: > So, this dot logic should be lifted to JVM_LoadLibrary? Possibly, but I still want to understand this change as it is now proposed. The whole thing has been about symlinks till now, so now what exactly is the problem and solution? You just want a way to load an arbitrarily-named file as if it were a dll? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3379366811 From asemenyuk at openjdk.org Wed Oct 8 03:01:08 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Oct 2025 03:01:08 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: <4RzO_0PNdZf5C4wnxWJwfXcI-YcAzV11AxW7lSPy3ls=.8f7f8421-1fd6-457a-b701-6a40ebc5f8b1@github.com> References: <2YLXDbbJRCNsOkalJCH5E7u_3_1jBYo8bdxUK_WmfxI=.ef673c29-061a-4b1c-b850-973743c83dc4@github.com> <4RzO_0PNdZf5C4wnxWJwfXcI-YcAzV11AxW7lSPy3ls=.8f7f8421-1fd6-457a-b701-6a40ebc5f8b1@github.com> Message-ID: On Wed, 8 Oct 2025 02:36:13 GMT, Alexander Matveev wrote: >> Let's address customizable resource logging in a separate patch. I filed [JDK-8369334](https://bugs.openjdk.org/browse/JDK-8369334) for this effort. > > I just fix it. Let me know what you think. I can revert my last commit. It fixes one specific issue that just popped up. There may be more, but jpackage tests don't trap "null"-s in log messages emitted by OverridableResource. The change to OverridableResource is wrong for a few reasons: - It unconditionally writes a log message; log messages in OverridableResource are created only when the destination file or output stream is not `null`. This change contradicts logging in OverridableResource. - It assumes that the set of resource sources is fixed. This assumption is wrong. It is possible to configure the order and the set of resource sources, see `OverridableResource.setSourceOrder()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412381007 From duke at openjdk.org Wed Oct 8 03:05:06 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 8 Oct 2025 03:05:06 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v8] In-Reply-To: References: Message-ID: <_n6Pb0NpMwo5q4DWQ9O2jaFsfB6KLXIELkGmk01vlQg=.3e9a0802-fb23-4824-b6ec-30dfc53f1796@github.com> On Wed, 8 Oct 2025 02:44:42 GMT, David Holmes wrote: > > So, this dot logic should be lifted to JVM_LoadLibrary? > > Possibly, but I still want to understand this change as it is now proposed. The whole thing has been about symlinks till now, so now what exactly is the problem and solution? It's been a windy path. As the PR description says, the problem appeared after JDK-8003887, which was a symlink-related change. JDK-8003887 looks be correct, though, and the regression was due to it exposing underlying problems in the native library loading code. Specifically, `JVM_LoadLibrary` on Windows does not work as expected when given a file without a `.dll` extension. We can make `JVM_LoadLibrary` work with the dot appending trick (current version of the PR), or apply the dot-appending trick in `NativeLibraries` (previous version of the PR). > You just want a way to load an arbitrarily-named file as if it were a dll? That sounds generally desirable. My use case is narrower. The file presented to `System.loadLibrary` does end with `.dll`. But after the path canonicalization done by `NativeLibraries`, the final path does not end with `.dll`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3379394592 From asemenyuk at openjdk.org Wed Oct 8 03:11:08 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Oct 2025 03:11:08 GMT Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v8] In-Reply-To: References: <2YLXDbbJRCNsOkalJCH5E7u_3_1jBYo8bdxUK_WmfxI=.ef673c29-061a-4b1c-b850-973743c83dc4@github.com> <4RzO_0PNdZf5C4wnxWJwfXcI-YcAzV11AxW7lSPy3ls=.8f7f8421-1fd6-457a-b701-6a40ebc5f8b1@github.com> Message-ID: On Wed, 8 Oct 2025 02:58:37 GMT, Alexey Semenyuk wrote: >> I just fix it. Let me know what you think. I can revert my last commit. > > It fixes one specific issue that just popped up. There may be more, but jpackage tests don't trap "null"-s in log messages emitted by OverridableResource. > > The change to OverridableResource is wrong for a few reasons: > - It unconditionally writes a log message; log messages in OverridableResource are created only when the destination file or output stream is not `null`. This change contradicts logging in OverridableResource. > - It assumes that the set of resource sources is fixed. This assumption is wrong. It is possible to configure the order and the set of resource sources, see `OverridableResource.setSourceOrder()`. The log: [23:04:58.315] Building PKG package for SimplePackageTest. [23:04:58.364] No default package resource postinstall [PKG postinstall script] (add postinstall to the resource-dir to customize). [23:04:58.364] No default package resource preinstall [PKG preinstall script] (add preinstall to the resource-dir to customize). [23:04:58.400] Using default package resource background_pkg.png [pkg background image] (add SimplePackageTest-background.png to the resource-dir to customize). [23:04:58.401] Using default package resource background_pkg.png [pkg background image] (add SimplePackageTest-background-darkAqua.png to the resource-dir to customize). [23:04:58.403] Using default package resource ApplicationRuntime-Info.plist.template [Embedded Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize). [23:04:58.407] Using default package resource JavaApp.icns [icon] (add SimplePackageTest.icns to the resource-dir to customize). [23:04:58.413] Preparing Info.plist: /var/folders/sp/mfz276114fq67h52dbd7vhb80000gn/T/jdk.jpackage2112168794503985414/image/SimplePackageTest.app/Contents/Info.plist. [23:04:58.417] Using default package resource Info-lite.plist.template [Application Info.plist] (add Info.plist to the resource-dir to customize). ... [23:04:58.620] Preparing distribution.dist: /var/folders/sp/mfz276114fq67h52dbd7vhb80000gn/T/jdk.jpackage2112168794503985414/config/distribution.dist. [23:04:58.630] No default package resource postinstall [PKG postinstall script] (add postinstall to the resource-dir to customize). [23:04:58.630] No default package resource preinstall [PKG preinstall script] (add preinstall to the resource-dir to customize). [23:04:58.633] No default package resource postinstall [PKG postinstall script] (add postinstall to the resource-dir to customize). [23:04:58.634] No default package resource preinstall [PKG preinstall script] (add preinstall to the resource-dir to customize). ... [23:04:58.836] No default package resource SimplePackageTest-post-image.sh [script to run after application image is populated] (add SimplePackageTest-post-image.sh to the resource-dir to customize). [23:04:58.837] No default package resource postinstall [PKG postinstall script] (add postinstall to the resource-dir to customize). [23:04:58.837] No default package resource preinstall [PKG preinstall script] (add preinstall to the resource-dir to customize). ... [23:04:58.912] No default package resource postinstall [PKG postinstall script] (add postinstall to the resource-dir to customize). [23:04:58.912] No default package resource preinstall [PKG preinstall script] (add preinstall to the resource-dir to customize). Zillion or duplicated log messages. Can you see them? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2412390541 From dholmes at openjdk.org Wed Oct 8 05:11:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 05:11:03 GMT Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support [v5] In-Reply-To: <8CQ5NYDakZIO2Y8agWBUgd12ReC2dJfgd-3rCZbemRo=.11fc27cb-6566-4bee-af83-591f10ae0295@github.com> References: <8CQ5NYDakZIO2Y8agWBUgd12ReC2dJfgd-3rCZbemRo=.11fc27cb-6566-4bee-af83-591f10ae0295@github.com> Message-ID: On Tue, 7 Oct 2025 18:36:30 GMT, Patricio Chilano Mateo wrote: >> Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized. >> This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization. >> >> These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Add string in asserts Okay - thanks for clarifying. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27597#pullrequestreview-3312844664 From alanb at openjdk.org Wed Oct 8 05:14:01 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Oct 2025 05:14:01 GMT Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work as expected [v2] In-Reply-To: References: <9gqy4YltBipAT7BuMq-_bhUKHmoQpOjKQIKZHeAv9pI=.f6daabd3-e323-48b2-8a4b-038e1f48b641@github.com> Message-ID: On Tue, 7 Oct 2025 19:36:31 GMT, Xueming Shen wrote: > Does ParameterizedTest support vm/platform classloader isolation for each parameterized test run against the same test with different parameters? I should have been clearer in my comment. The suggestion to use a ParameterizedTest is to exercise a custom class loader using super.defineClass with different buffers (direct, heap, position != 0, ...) so that it exercises the "non-trusted" cases. You are right that testing the platform class loader (as a trusted class loader) will require opening java.lang. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2412517612 From alanb at openjdk.org Wed Oct 8 05:29:09 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Oct 2025 05:29:09 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v15] In-Reply-To: References: Message-ID: <8XswExrj9izeP9hR_qXXu2UKSuecQfLskrrJ4D7fcLg=.e6dfe129-f413-484d-a2aa-993c223b4a9c@github.com> On Wed, 8 Oct 2025 02:11:53 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. >> >> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. >> >> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. > > Roger Riggs 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 22 additional commits since the last revision: > > - The ProcessCloseTest is modified to be able to test the logic > around close() waiting for the process to exit and the specified > behavior of interrupting the waitFor. > - Close is modified to wait for the process to terminate before returning. > Please review the revised javadoc. > As suggested in review comments, waiting for the process to terminate > allows a more orderly cleanup by the application. > The streams are closed and close uses `waitFor()` with an unlimited timeout > for the process to terminate. > While waiting the thread can be `interrupted` to exit the `waitFor`. > If/when `waitFor` is interrupted, the process is destroyedForcibly on > all platforms. When close() returns, the thread interrupt will pending > and can be handled by the caller. > If a watchdog timeout is desired on close(), a separate thread > can schedule an interrupt at a suitable time after close is called. > - Review comment improvements to make expected behavior clearer. > - Merge branch 'master' into 8364361-process-autocloseable > - Clarify the use of waitFor after close() or T-W-R exit. > - Additional review feedback. > Updated to emphasize reading the data from the streams and calling waitFor > to allow for normal termination. > - Merge branch 'master' into 8364361-process-autocloseable > - Address review comments for code and javadoc in Process, the test and the example. > Reinforced that calling waitFor should occur before calling close to wait for termination and get the exitStatus. > Corrected the error message check for invalid handles on Windows. > Update test to allow normal completion when exceptions may be expected. > Correct the expected message on Windows for an invalid handle exception. > - Update close() to use "terminate" consistently. > - Remove volatile from "closed" field; updates are guarded by synchronized. > - ... and 12 more: https://git.openjdk.org/jdk/compare/17e05424...6f8f7327 src/java.base/share/classes/java/lang/Process.java line 235: > 233: destroyForcibly(); > 234: // Re-assert the interrupt > 235: Thread.currentThread().interrupt(); I think this is still problematic as code after the t-w-r can't be guaranteed that the child has terminated. So I think it needs a loop that ends when waitFor completes without an exception (destroyForcibly would only be called on the first interrupt of course). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2412541369 From jlahoda at openjdk.org Wed Oct 8 05:38:12 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 8 Oct 2025 05:38:12 GMT Subject: Integrated: 8363917: SwitchBootstraps.enumSwitch() args not checked as documented In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 11:00:37 GMT, Jan Lahoda wrote: > The bug points out the implementation and the documentation for `SwitchBootstraps.enumSwitch` don't completely agree, and that some points in the documentation could be more clear. This PR adjusts the documentation for `SwitchBootstraps`. No behavioral changes. Tests added to verify the behavior. > > The adjustments are: > - `invocationName` can be `null` > - being explicit the `labels` array for `enumSwitch` may constain references to enum constants that don't exist > - disallowing empty strings in the `labels` array > - rephrasing of the handling of the situation when no element in the `labels` array matches This pull request has now been integrated. Changeset: 86211956 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/862119565db311fe0e02e383fd3493601ed23ea8 Stats: 68 lines in 2 files changed: 50 ins; 0 del; 18 mod 8363917: SwitchBootstraps.enumSwitch() args not checked as documented Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/27422 From duke at openjdk.org Wed Oct 8 06:58:40 2025 From: duke at openjdk.org (Johny Jose) Date: Wed, 8 Oct 2025 06:58:40 GMT Subject: RFR: 8368500: ContextClassLoader cannot be reset on threads in ForkJoinPool.commonPool() [v3] In-Reply-To: References: Message-ID: <7lt8sFGw-MtUJZ-tGzAEi7lj4rk4jHurFerr5Iu9vOw=.36236606-3713-4f18-bea6-48bcf6a28cf1@github.com> > The permanent disabling of the Security Manager in JDK 24 allow setCCL to set the CCL to a custom class loader. However, it doesn't allow it to be set to a custom class loader and then "reset" back to the system class loader before executing further code in the task. The changes are made to relax the restriction in setCCL to reset back to system class loader Johny Jose has updated the pull request incrementally with one additional commit since the last revision: cleanup changes for test case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27648/files - new: https://git.openjdk.org/jdk/pull/27648/files/c9d2b7c0..69cd37de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27648&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27648&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27648.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27648/head:pull/27648 PR: https://git.openjdk.org/jdk/pull/27648 From alanb at openjdk.org Wed Oct 8 07:30:05 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Oct 2025 07:30:05 GMT Subject: RFR: 8368500: ContextClassLoader cannot be reset on threads in ForkJoinPool.commonPool() [v3] In-Reply-To: <7lt8sFGw-MtUJZ-tGzAEi7lj4rk4jHurFerr5Iu9vOw=.36236606-3713-4f18-bea6-48bcf6a28cf1@github.com> References: <7lt8sFGw-MtUJZ-tGzAEi7lj4rk4jHurFerr5Iu9vOw=.36236606-3713-4f18-bea6-48bcf6a28cf1@github.com> Message-ID: On Wed, 8 Oct 2025 06:58:40 GMT, Johny Jose wrote: >> The permanent disabling of the Security Manager in JDK 24 allow setCCL to set the CCL to a custom class loader. However, it doesn't allow it to be set to a custom class loader and then "reset" back to the system class loader before executing further code in the task. The changes are made to relax the restriction in setCCL to reset back to system class loader > > Johny Jose has updated the pull request incrementally with one additional commit since the last revision: > > cleanup changes for test case Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27648#pullrequestreview-3313377113 From alanb at openjdk.org Wed Oct 8 08:08:05 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Oct 2025 08:08:05 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: <1Ed3XduxQZKSVBUng2-sUeD1ib9ZZqRQBN18n0SrAwY=.496748d7-01f9-4b9f-a184-d364f3d7d0f2@github.com> Message-ID: On Tue, 7 Oct 2025 00:44:05 GMT, David Holmes wrote: > > I think what you are suggesting is that the JEP could instead have -Xcheck:jni emit a warning when JNI setter functions mutate final fields, and maybe change it to be a fatal error in the future, maybe as part of the future JEP that proposes to move "deny" the default. > > @AlanBateman yes that is exactly what I am suggesting. Thanks I discussed this with Ron. Mutating final fields from native code isn't core to this JEP. A fatal error would be better but we are okay with it initially being a warning instead. So we'll update that section of the JEP, and today the addition to jniCheck to use ReportJNIWarning instead of ReportJNIFatalError. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3380229466 From alanb at openjdk.org Wed Oct 8 08:15:08 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Oct 2025 08:15:08 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v8] In-Reply-To: References: Message-ID: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits: - Suppress warnings from some tests - Change -Xcheck:jni to be warning rather than fatal error - Merge branch 'master' into JDK-8353835 - Simplify filter - Merge branch 'master' into JDK-8353835 - Update Xcheck:jni description - Add testUnreflectExpectingWarning - Merge branch 'master' into JDK-8353835 - Add test for -Xlog:jni=debug - Merge branch 'master' into JDK-8353835 - ... and 31 more: https://git.openjdk.org/jdk/compare/2ac24bf1...635556aa ------------- Changes: https://git.openjdk.org/jdk/pull/25115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=07 Stats: 4852 lines in 70 files changed: 4667 ins; 54 del; 131 mod Patch: https://git.openjdk.org/jdk/pull/25115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115 PR: https://git.openjdk.org/jdk/pull/25115 From ssarathi at openjdk.org Wed Oct 8 10:38:05 2025 From: ssarathi at openjdk.org (Sorna Sarathi N) Date: Wed, 8 Oct 2025 10:38:05 GMT Subject: RFR: 8369349: Add missing CPE headers Message-ID: Adds missing classpath exception copyright headers. ------------- Commit messages: - Adds missing CPE headers Changes: https://git.openjdk.org/jdk/pull/27687/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27687&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369349 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27687/head:pull/27687 PR: https://git.openjdk.org/jdk/pull/27687 From alanb at openjdk.org Wed Oct 8 12:39:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Oct 2025 12:39:10 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: <2X1KarQP2qTQoWGxVrAYpgUY4golsCfR8KoJqbCWnWw=.85896efa-5d1c-4df3-88df-e397892e7ff4@github.com> On Thu, 8 May 2025 13:58:54 GMT, Alan Bateman wrote: >> Would it be possible to paste in here, or in the JBS issue, some examples of the path provided to LoadLibrary with some commentary on the sym links created on the file system. > >> You might be correct. We'll see what @AlanBateman and others have to say about it. > > I'm still puzzled as to why the DLLs have been moved from the JDK bin directory to some other location, and renamed so they don't have the ".dll" suffix. There most be some other product in the picture that we can't see. The quoted text from the Windows LoadLibrary documentation, where it appends the ".dll" suffix when not provided, is very useful as it helps us understand why it fails. > > As regards dropping the canonicalization then it would require thinking about the lock map used for mapping the library names to locks. It would need checking if it would break concurrent loading when using different names / file paths to the same DLL. There may be a route that involves adding a method to ClassLoaderHelper to post-process the path and the Windows version could add the "." when it doesn't have the ".dll" suffix. > As @AlanBateman has noted there are semantic question to address here. Library loading is tied to classloaders and the use of symlinks allows the same library to be loaded by different names in different classloaders - which could potentially wreak havoc I think if we execute the onLoad hooks multiple times. > > I would like to see core-libs folk decide exactly what should happen for these different cases, and then figure out where is the best place to make that happen. > > But initial view is that you should not be renaming the DLLs to not have a .dll extension - that just seems to be a self-inflicted wound. The bug report is an unusual environment where the DLLs in the JDK bin directory are moved and renamed to some other location and without the .dll suffix, and sym links created in their place. That's a bit of distraction. A better starting point for discussion would be a test that exercises System.loadLibrary with the a library name that locates a DLL through a sym link to a final target that doesn't have the .dll suffix. There's a matrix of configurations to test there. Same thing with System.load to see what works and doesn't work. The discussion/proposal was originally to use the platform specific jdk.internal.load.ClassLoaderHelper as that gets used by the implementation of ClassLoader/NativeLibraries code to setup the path to the native library. I think we should stay away from JVM_LoadLibrary and os::dll_load for now, at least until we get come to some consensus on whether is this something that should be allowed (it may require input from security folks). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3381313263 From rriggs at openjdk.org Wed Oct 8 13:24:48 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 8 Oct 2025 13:24:48 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Tue, 7 Oct 2025 22:18:58 GMT, Roger Riggs wrote: >> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: >> >> minor api doc updates > > src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 230: > >> 228: private static class CaseFoldingEntry { >> 229: final int cp; >> 230: final char[] folding; > > Consider storing the folding as a int or long directly to avoid the overhead of small char arrays. > Arrange to be able to compare the whole replacement with another codePoint, etc. I misunderstood the algorithm when comparing folded characters against non-folded sequences. I still think a fast path for single character replacements will lower memory costs and improve performance. The case of single-codepoint to single-codepoint dominates the case folding mappings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2413846987 From duke at openjdk.org Wed Oct 8 14:02:47 2025 From: duke at openjdk.org (Jason Mehrens) Date: Wed, 8 Oct 2025 14:02:47 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v15] In-Reply-To: <8XswExrj9izeP9hR_qXXu2UKSuecQfLskrrJ4D7fcLg=.e6dfe129-f413-484d-a2aa-993c223b4a9c@github.com> References: <8XswExrj9izeP9hR_qXXu2UKSuecQfLskrrJ4D7fcLg=.e6dfe129-f413-484d-a2aa-993c223b4a9c@github.com> Message-ID: On Wed, 8 Oct 2025 05:26:37 GMT, Alan Bateman wrote: >> Roger Riggs 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 22 additional commits since the last revision: >> >> - The ProcessCloseTest is modified to be able to test the logic >> around close() waiting for the process to exit and the specified >> behavior of interrupting the waitFor. >> - Close is modified to wait for the process to terminate before returning. >> Please review the revised javadoc. >> As suggested in review comments, waiting for the process to terminate >> allows a more orderly cleanup by the application. >> The streams are closed and close uses `waitFor()` with an unlimited timeout >> for the process to terminate. >> While waiting the thread can be `interrupted` to exit the `waitFor`. >> If/when `waitFor` is interrupted, the process is destroyedForcibly on >> all platforms. When close() returns, the thread interrupt will pending >> and can be handled by the caller. >> If a watchdog timeout is desired on close(), a separate thread >> can schedule an interrupt at a suitable time after close is called. >> - Review comment improvements to make expected behavior clearer. >> - Merge branch 'master' into 8364361-process-autocloseable >> - Clarify the use of waitFor after close() or T-W-R exit. >> - Additional review feedback. >> Updated to emphasize reading the data from the streams and calling waitFor >> to allow for normal termination. >> - Merge branch 'master' into 8364361-process-autocloseable >> - Address review comments for code and javadoc in Process, the test and the example. >> Reinforced that calling waitFor should occur before calling close to wait for termination and get the exitStatus. >> Corrected the error message check for invalid handles on Windows. >> Update test to allow normal completion when exceptions may be expected. >> Correct the expected message on Windows for an invalid handle exception. >> - Update close() to use "terminate" consistently. >> - Remove volatile from "closed" field; updates are guarded by synchronized. >> - ... and 12 more: https://git.openjdk.org/jdk/compare/91574b3b...6f8f7327 > > src/java.base/share/classes/java/lang/Process.java line 235: > >> 233: destroyForcibly(); >> 234: // Re-assert the interrupt >> 235: Thread.currentThread().interrupt(); > > I think this is still problematic as code after the t-w-r can't be guaranteed that the child has terminated. So I think it needs a loop that ends when waitFor completes without an exception (destroyForcibly would only be called on the first interrupt of course). I also wonder if close of streams should happen after first wait on destroy or on interruption. I'm thinking the difference is that streams would still be usable to fetch buffered data. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2413964593 From rriggs at openjdk.org Wed Oct 8 14:06:44 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 8 Oct 2025 14:06:44 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v15] In-Reply-To: References: <8XswExrj9izeP9hR_qXXu2UKSuecQfLskrrJ4D7fcLg=.e6dfe129-f413-484d-a2aa-993c223b4a9c@github.com> Message-ID: On Wed, 8 Oct 2025 13:59:39 GMT, Jason Mehrens wrote: >> src/java.base/share/classes/java/lang/Process.java line 235: >> >>> 233: destroyForcibly(); >>> 234: // Re-assert the interrupt >>> 235: Thread.currentThread().interrupt(); >> >> I think this is still problematic as code after the t-w-r can't be guaranteed that the child has terminated. So I think it needs a loop that ends when waitFor completes without an exception (destroyForcibly would only be called on the first interrupt of course). > > I also wonder if close of streams should happen after first wait on destroy or on interruption. I'm thinking the difference is that streams would still be usable to fetch buffered data. Looping could still lead to an infinite hang if the process never dies. For example, some Unix processes can stay around as zombie's even after kill -9 if they don't get reap'ed. On Windows, some files can't be closed and the processes hang around indefinitely. Tracking down those dependencies and resolving them is outside of the Java scope. I don't think the contract for T-W-R/close has guarantee the process has gone away, only that it has been destroyed (forcibly). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2413979073 From liach at openjdk.org Wed Oct 8 14:14:26 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Oct 2025 14:14:26 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Wed, 8 Oct 2025 00:33:20 GMT, Xueming Shen wrote: >> ### 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 pass... > > Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: > > minor api doc updates Given this patch obviously has so many performance optimization opportunities, I recommend handling those in subsequent RFEs so that we can review this purely from a specification point of view. make/modules/java.base/gensrc/GensrcCharacterData.gmk line 76: > 74: > 75: > 76: GENSRC_STRINGCASEFOLDING := $(SUPPORT_OUTPUTDIR)/gensrc/java.base/jdk/internal/java/lang/CaseFolding.java Can we target the package `jdk.internal.lang` instead of `jdk.internal.java.lang`? I think the previous one is the convention set forth by stable values. ------------- PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3314954963 PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2413957017 From rriggs at openjdk.org Wed Oct 8 14:38:26 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 8 Oct 2025 14:38:26 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Wed, 8 Oct 2025 14:11:28 GMT, Chen Liang wrote: > Given this patch obviously has so many performance optimization opportunities, I recommend handling those in subsequent RFEs so that we can review this purely from a specification point of view. There is adequate time before RPD1 (Dec 4, 25) to improve performance, but the feature should not be included in JDK 26 unless the performance is comparable to the existing `compareToIgnoreCase` and `equalsIgnoreCase`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3381857251 From alanb at openjdk.org Wed Oct 8 14:44:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Oct 2025 14:44:42 GMT Subject: RFR: 8347007: --strip-debug removes parameter names included with -parameters [v3] In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 05:40:49 GMT, Henry Jen wrote: >> Since parameters is an opt-in choice, it's more reasonable to consider that's desired information and make strip parameter names an opt-in choice as well. >> >> This PR changes the default behavior of --strip-debug to keep parameter names when it's available. Add opt-in mechanism, >> via the strip-java-debug-attributes plugin by using argument `--strip-java-debug-attributes=+parameter-names`. >> >> The --strip-debug option is a little bit odd, as it's a main option as well as a plugin option to enable the DefaultStripDebugPlugin, which strip native debug information on platform support the feature, and strip java debug information. In this PR, we chose to support only one mechanism to enable strip parameter names, so we would disable the embed StripJavaDebugAttributesPlugin when StripJavaDebugAttributesPlugin is enabled. >> >> The StripParameterNamesTest illustrate and verify parameter names use cases, mainly focus on argument processing and the parameter names. We didn't verify the regular debug info as that's covered by existing test. >> >> -- Update >> >> The latest change removed the support of strip parameter names, as the MethodParameters attribute is considered necessary attribute to fulfill Java Language Spec even though this attribute is considered optional by JVM spec. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > MethodParameters attribute should not be removed It is surprising that the MethodParameters attribute is being stripped. I see ASM's SKIP_DEBUG is documented to skip this attribute, which explains why the re-implementation with the classfile API explicits drops it. So from a quick look, I think I think the change is doing the right thing. I will review closely soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27566#issuecomment-3381887651 From duke at openjdk.org Wed Oct 8 14:45:59 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 14:45:59 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v4] In-Reply-To: References: Message-ID: <10DEK65F7O7il0Fevpke19vEOJM4hlTzOuJeqLsj6OY=.ec69af10-cc17-4b62-bd44-efcc838e194e@github.com> > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update module-info.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/9d1d35b4..434d2a99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From duke at openjdk.org Wed Oct 8 14:54:30 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 14:54:30 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v5] In-Reply-To: References: Message-ID: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update module-info.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/434d2a99..7711d93c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From dfuchs at openjdk.org Wed Oct 8 14:54:33 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 14:54:33 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v4] In-Reply-To: <10DEK65F7O7il0Fevpke19vEOJM4hlTzOuJeqLsj6OY=.ec69af10-cc17-4b62-bd44-efcc838e194e@github.com> References: <10DEK65F7O7il0Fevpke19vEOJM4hlTzOuJeqLsj6OY=.ec69af10-cc17-4b62-bd44-efcc838e194e@github.com> Message-ID: On Wed, 8 Oct 2025 14:45:59 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update module-info.java src/jdk.httpserver/share/classes/module-info.java line 104: > 102: * > 103: * > 104: * Additional system/networking properties may be defined in net.properties I'd suggest the following to match other places were net.properties is mentioned in the API doc. Suggestion: * Additional system/networking properties may be defined in the {@code conf/net.properties} configuration file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2414119090 From duke at openjdk.org Wed Oct 8 14:55:02 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 14:55:02 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v4] In-Reply-To: <10DEK65F7O7il0Fevpke19vEOJM4hlTzOuJeqLsj6OY=.ec69af10-cc17-4b62-bd44-efcc838e194e@github.com> References: <10DEK65F7O7il0Fevpke19vEOJM4hlTzOuJeqLsj6OY=.ec69af10-cc17-4b62-bd44-efcc838e194e@github.com> Message-ID: On Wed, 8 Oct 2025 14:45:59 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update module-info.java > @SentryMan please create a [CSR](https://wiki.openjdk.org/display/csr/Main) request for issue [JDK-7105350](https://bugs.openjdk.org/browse/JDK-7105350) with the correct fix version. How should I go about creating a CSR? The FAQ on this page says that I need JIRA access (I don't have that) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3381946202 From lancea at openjdk.org Wed Oct 8 14:55:34 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 8 Oct 2025 14:55:34 GMT Subject: RFR: 8369432: Add Support for JDBC 4.5 MR Message-ID: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com> This PR adds support for the upcoming JDBC 4.5 MR which provides the following updates to the JDBC specification: - Deprecate SQLPermission for removal - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface - It is the exact same verbiage & default methods used when these methods were added to the Statement interface - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash Tiers 1-3 have been run ------------- Commit messages: - JDBC 4.5 MR initial push Changes: https://git.openjdk.org/jdk/pull/27693/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27693&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369432 Stats: 604 lines in 15 files changed: 487 ins; 52 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/27693.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27693/head:pull/27693 PR: https://git.openjdk.org/jdk/pull/27693 From dfuchs at openjdk.org Wed Oct 8 14:58:08 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 14:58:08 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v4] In-Reply-To: References: <10DEK65F7O7il0Fevpke19vEOJM4hlTzOuJeqLsj6OY=.ec69af10-cc17-4b62-bd44-efcc838e194e@github.com> Message-ID: On Wed, 8 Oct 2025 14:52:59 GMT, Josiah Noel wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> Update module-info.java > >> @SentryMan please create a [CSR](https://wiki.openjdk.org/display/csr/Main) request for issue [JDK-7105350](https://bugs.openjdk.org/browse/JDK-7105350) with the correct fix version. > > How should I go about creating a CSR? The FAQ on this page says that I need JIRA access (I don't have that) @SentryMan note: WRT to creating a CSR your sponsor will handle that if you do not have a JBS account. Let's wait until this PR has been approved and everyone is happy with the API doc / behaviours changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3381959526 From alanb at openjdk.org Wed Oct 8 15:04:17 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Oct 2025 15:04:17 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v5] In-Reply-To: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> References: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> Message-ID: On Wed, 8 Oct 2025 14:54:30 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update module-info.java src/java.base/share/classes/module-info.java line 282: > 280: java.net.http, > 281: jdk.naming.dns, > 282: jdk.httpserver; It would be good if we could avoid giving the jdk.httpserver module access to the sun.net.* package. @dfuch @Michael-Mc-Mahon Are you sure that net.properties is the right place for this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2414176619 From fandreuzzi at openjdk.org Wed Oct 8 15:04:17 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 8 Oct 2025 15:04:17 GMT Subject: RFR: 8369432: Add Support for JDBC 4.5 MR In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com> References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com> Message-ID: On Wed, 8 Oct 2025 14:49:07 GMT, Lance Andersen wrote: > This PR adds support for the upcoming JDBC 4.5 MR which provides the following updates to the JDBC specification: > > - Deprecate SQLPermission for removal > - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable > - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java > - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface > - It is the exact same verbiage & default methods used when these methods were added to the Statement interface > - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash > > Tiers 1-3 have been run src/java.sql/share/classes/java/sql/Array.java line 76: > 74: */ > 75: > 76: public interface Array extends AutoCloseable { Suggestion: public interface Array extends AutoCloseable { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2414175002 From dfuchs at openjdk.org Wed Oct 8 15:15:39 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 15:15:39 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v5] In-Reply-To: References: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> Message-ID: On Wed, 8 Oct 2025 15:02:02 GMT, Alan Bateman wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> Update module-info.java > > src/java.base/share/classes/module-info.java line 282: > >> 280: java.net.http, >> 281: jdk.naming.dns, >> 282: jdk.httpserver; > > It would be good if we could avoid giving the jdk.httpserver module access to the sun.net.* package. > > @dfuch @Michael-Mc-Mahon Are you sure that net.properties is the right place for this? @AlanBateman I hadn't realised that the HttpServer didn't already have access to `sun.net.*` - and I agree that it would be better if we did not add such an access. That said - the new property is a compatibility property - and documenting in module-info seemed a bit too much - so out of the way in `net.properties` seemed like an appealing place to add it. Another possibility could be to document it only in the release notes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2414209436 From rriggs at openjdk.org Wed Oct 8 15:25:08 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 8 Oct 2025 15:25:08 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v15] In-Reply-To: References: <8XswExrj9izeP9hR_qXXu2UKSuecQfLskrrJ4D7fcLg=.e6dfe129-f413-484d-a2aa-993c223b4a9c@github.com> Message-ID: On Wed, 8 Oct 2025 14:04:16 GMT, Roger Riggs wrote: >> I also wonder if close of streams should happen after first wait on destroy or on interruption. I'm thinking the difference is that streams would still be usable to fetch buffered data. > > Looping could still lead to an infinite hang if the process never dies. > For example, some Unix processes can stay around as zombie's even after kill -9 if they don't get reap'ed. > On Windows, some files can't be closed and the processes hang around indefinitely. > Tracking down those dependencies and resolving them is outside of the Java scope. > I don't think the contract for T-W-R/close has guarantee the process has gone away, only that it has been destroyed (forcibly). > I also wonder if close of streams should happen after first wait on destroy or on interruption. I'm thinking the difference is that streams would still be usable to fetch buffered data. When close() is called, the application can no longer expect the streams to have any data; any buffered data is lost. (I'm assuming a single threaded application). Asynchronous close() can result in races, but there's no good way (for the APIs/implementation) to get deterministic behavior. Shutting down the streams is the clearest and definitive way to bring things to an end. If the application wants fine grained control of the timing of the closes, it is free to close them explicitly. I would expect an application that is piping data to a process would close its output to the process and keep reading until EOF before exiting T-W-R or calling close. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2414243255 From rriggs at openjdk.org Wed Oct 8 16:28:09 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 8 Oct 2025 16:28:09 GMT Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values [v3] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 20:43:20 GMT, Naoto Sato wrote: >> Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27660#pullrequestreview-3315634206 From openjdk at icemanx.nl Wed Oct 8 16:33:03 2025 From: openjdk at icemanx.nl (Rob Spoor) Date: Wed, 8 Oct 2025 18:33:03 +0200 Subject: RFE: make AutoCloseable generic in its exception type In-Reply-To: References: <5afa96a1-1d59-4dca-8312-1136c19b762e@icemanx.nl> Message-ID: <55ac7361-eb45-407a-90db-0d8bea92cfec@icemanx.nl> I have two scenarios where I'd like to have this. The first scenario is existing APIs where classes haven't been changed to implement AutoCloseable yet. Think of JMS several years ago, or even ExecutorService before Java 19. These cannot be used in try-with-resources without creating an interface with a different exception (JMSException, RuntimeException) or requiring to deal with Exception. try (AutoCloseable _ = executor::shutdown) { } // have to deal with Exception The second scenario comes from one of my projects. I have a class where the close() method cannot be made public. To be able to use it in try-with-resources I had to create a custom wrapper class. Transaction transaction = Transaction.create(timeout, description); // custom class instead of AutoCloseable _ = transaction::close try (var _ = new TransactionCloseable(transaction)) { } Regarding the comparison with try-finally, I've encountered the first pre-condition often enough, like JMS. I don't think the second pre-condition is required, because we can use lambdas instead of method references. Regardoing a subinterface, that could definitely work. It would also get rid of the possible clash with the "of" method. I can of course create it myself, but then I'll have to create a library for just this single interface, or duplicate it in all projects where it would be needed (I've already identified a handful or so), so it would be very nice if it could be added to the JDK. Kind regards, Rob On 07/10/2025 23:57, Chen Liang wrote: > Hi Rob, > Can you share an actual piece of code that would benefit from such a lambda migration? > I have checked the library code of java.base module; the try-with-resources and finally are mostly used for I/O and security cleanups, none of which would significantly benefit from this improvement. > In particular, I noted this form would only be more useful than finally with these preconditions: > > 1. > The cleanup action must be throwing some exception > 2. > The cleanup action doesn't make use of local variables > > Which IMO makes this usage much more niche. > Finally, for your proposed solution, I think we can accomplish that with a subinterface of AutoCloseable that has this type parameter - this does not require existing implementors to update, yet offers the same benefits. > > Regards, > Chen Liang > > Confidential ? Oracle Internal > ________________________________ > From: core-libs-dev on behalf of Rob Spoor > Sent: Tuesday, October 7, 2025 2:43 PM > To: core-libs-dev at openjdk.java.net > Subject: RFE: make AutoCloseable generic in its exception type > > Hi all, > > AutoCloseable, as added in Java 7 and unchanged ever since, declares to > throw Exception from its close() method. That means that anytime someone > needs to have an AutoCloseable that throws a different exception, they > must create an interface that extends AutoCloseable and override close() > only to throw a different (or no) exception. That can become quite > annoying if you have to do it often. But without such interfaces, we > cannot use lambdas or method references in try-with-resources without > having to deal with Exception: > > try (AutoCloseable _ = this::cleanup) { > } // need to catch or re-throw Exception > > > I think that making AutoCloseable generic in its exception type is a > change that's quite simple, yet makes life easier for developers. The > interface would become this: > > public interface AutoCloseable { > /** > * * > * @throws X if this resource cannot be closed > */ > void close() throws X; > } > > In its raw form, the interface is exactly what we already have: close() > throws Exception. Therefore, any use of AutoCloseable that doesn't fill > in the generic type (including extending interfaces) will work as they > do now. They can still override close() and change the thrown exception > type. Interfaces that extend AutoCloseable can fill in the generic type, > and if the close() method doesn't add additional documentation it can be > removed completely. Interfaces like Closeable will only have to change > the extends clause: > > public interface Closeable extends AutoCloseable { > // keep close for its documentation > } > > That doesn't add much value yet, but we can now use it in > try-with-resources without having to deal with Exception: > > try (AutoCloseable c = this::cleanup) { > } // no need to catch or re-throw RuntimeException > > > There is one other possible change that can make it even easier, and > that is adding a factory method like Gatherer.Integrator.of: > > public interface AutoCloseable { > // documentation omitted > void close() throws X; > > // documentation omitted > static AutoCloseable > of(AutoCloseable closeable) { > return closeable; > } > } > > The try-with-resources can now become even simpler: > > try (var _ = AutoCloseable.of(this::cleanup)) { > } > > > There is one possible issue with this "of" method, and that is possible > incompatibilities with existing implementing classes or extending > interfaces that already have an "of(AutoCloseable)" method with a > different return type, or that are not static. I think the chances of > that are not great, but it still is something to consider. > > > Any thoughts? > > From iris at openjdk.org Wed Oct 8 16:34:07 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 8 Oct 2025 16:34:07 GMT Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values [v3] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 20:43:20 GMT, Naoto Sato wrote: >> Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27660#pullrequestreview-3315652499 From duke at openjdk.org Wed Oct 8 16:35:05 2025 From: duke at openjdk.org (Bernd) Date: Wed, 8 Oct 2025 16:35:05 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: <9c13AiS1RTrKhWGiVifePZ4CZa7Iws-AirXB-YMR4NQ=.cc24d342-334f-4be1-b886-7efd2c0a8898@github.com> On Wed, 8 Oct 2025 00:33:20 GMT, Xueming Shen wrote: >> ### 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 pass... > > Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: > > minor api doc updates Great progress thanks. Did you also consider a startsWith/containsCaseFold, I missed the case ignoring variants of those already. Or maybe provide an API to implement them on the cases folded intermediate buffers? If the API footprint gets too big on String as CaseFoldString.contains() helper maybe? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3382351349 From duke at openjdk.org Wed Oct 8 16:55:31 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 16:55:31 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v5] In-Reply-To: References: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> Message-ID: <_7C7kivl1GlzjlnfVGIjzBJLzIiUrQlgfA88zkHvPqY=.2672c6c7-27c0-47d5-b03b-8f0001e22e26@github.com> On Wed, 8 Oct 2025 15:12:45 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/module-info.java line 282: >> >>> 280: java.net.http, >>> 281: jdk.naming.dns, >>> 282: jdk.httpserver; >> >> It would be good if we could avoid giving the jdk.httpserver module access to the sun.net.* package. >> >> @dfuch @Michael-Mc-Mahon Are you sure that net.properties is the right place for this? > > @AlanBateman I hadn't realised that the HttpServer didn't already have access to `sun.net.*` - and I agree that it would be better if we did not add such an access. That said - the new property is a compatibility property - and documenting in module-info seemed a bit too much - so out of the way in `net.properties` seemed like an appealing place to add it. > > Another possibility could be to document it only in the release notes. Shall I revert the change and leave as a system property? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2414479292 From jlu at openjdk.org Wed Oct 8 17:08:16 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 8 Oct 2025 17:08:16 GMT Subject: RFR: 8369432: Add Support for JDBC 4.5 MR In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com> References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com> Message-ID: On Wed, 8 Oct 2025 14:49:07 GMT, Lance Andersen wrote: > This PR adds support for the upcoming JDBC 4.5 MR which provides the following updates to the JDBC specification: > > - Deprecate SQLPermission for removal > - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable > - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java > - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface > - It is the exact same verbiage & default methods used when these methods were added to the Statement interface > - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash > > Tiers 1-3 have been run src/java.sql/share/classes/java/sql/Connection.java line 1897: > 1895: * underlying datasource. > 1896: * @param identifier a SQL identifier > 1897: * @return true if a simple SQL identifier, false otherwise Suggestion: * @return true if a simple SQL identifier, false otherwise src/java.sql/share/classes/java/sql/DriverPropertyInfo.java line 33: > 31: *

Driver properties for making a connection. The > 32: * {@code DriverPropertyInfo} class is of interest only to advanced programmers. > 33: * The method {@linkplain Driver#getPropertyInfo(String, Properties)} may be used Suggestion: * The method {@link Driver#getPropertyInfo(String, Properties)} may be used src/java.sql/share/classes/java/sql/SQLPermission.java line 32: > 30: > 31: /** > 32: *This class was only useful in conjunction with the {@link java.lang.SecurityManager}, Suggestion: * This class was only useful in conjunction with the {@link java.lang.SecurityManager}, src/java.sql/share/classes/java/sql/SQLXML.java line 180: > 178: * writing APIs are called: setBinaryStream(), setCharacterStream(), setResult(), and setString(). > 179: * Implementations may also change the state to not readable when this occurs. > 180: *

Suggestion: *

------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2414490949 PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2414477211 PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2414458104 PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2414460512 From jlu at openjdk.org Wed Oct 8 17:27:15 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 8 Oct 2025 17:27:15 GMT Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values [v3] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 20:43:20 GMT, Naoto Sato wrote: >> Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/java.base/share/classes/java/util/SimpleTimeZone.java line 112: > 110: *

> 111: * The following are examples of parameters for constructing time zone objects. > 112: * 



We can consider replacing `
` with `@snippet` so that the code example can be copied by readers. Although I understand if leaving it for another time as to not invalidate the existing approvals.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27660#discussion_r2414548133

From prappo at openjdk.org  Wed Oct  8 17:36:50 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Oct 2025 17:36:50 GMT
Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal
 Instances with Different hashCode Values [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 8 Oct 2025 17:24:19 GMT, Justin Lu  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/java/util/SimpleTimeZone.java line 112:
> 
>> 110:  * 

>> 111:  * The following are examples of parameters for constructing time zone objects.
>> 112:  * 

> 
> We can consider replacing `
` with `@snippet` so that the code example can be copied by readers. Although I understand if leaving it for another time as to not invalidate the existing approvals.

I think, that's out of scope for this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27660#discussion_r2414569959

From naoto at openjdk.org  Wed Oct  8 17:42:44 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 Oct 2025 17:42:44 GMT
Subject: RFR: 8369050: DecimalFormat Rounding Errors for Ties Torwards 1 in
 LSD or 0
In-Reply-To: 
References: 
Message-ID: 

On Tue, 7 Oct 2025 23:19:28 GMT, Justin Lu  wrote:

> Please review this PR which corrects a rounding error for DecimalFormat on tie cases when the maximum fraction digits allowed is one less than the position of the first significant digit in the double rounded. For example, rounding a value such as 0.0005 to a maximum of 3 fractional digits. In order to get the correct `count` value, we must strip the trailing zeros prior to the check to ensure we have the correct value of `count` = 1 so that we can go down the _Rounding position is the last index_ case which properly checks if the String double was already rounded or is exact from its true decimal form.

LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/27681#pullrequestreview-3315869483

From naoto at openjdk.org  Wed Oct  8 17:42:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 Oct 2025 17:42:47 GMT
Subject: RFR: 8369050: DecimalFormat Rounding Errors for Ties Torwards 1 in
 LSD or 0
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 7 Oct 2025 23:34:49 GMT, Justin Lu  wrote:

>> Please review this PR which corrects a rounding error for DecimalFormat on tie cases when the maximum fraction digits allowed is one less than the position of the first significant digit in the double rounded. For example, rounding a value such as 0.0005 to a maximum of 3 fractional digits. In order to get the correct `count` value, we must strip the trailing zeros prior to the check to ensure we have the correct value of `count` = 1 so that we can go down the _Rounding position is the last index_ case which properly checks if the String double was already rounded or is exact from its true decimal form.
>
> test/jdk/java/text/Format/DecimalFormat/RoundingToLSDTieTest.java line 1:
> 
>> 1: /*
> 
> I considered adding the tests in this file under _TieRoundingTest_, but did not do so to make review easier since JUnit could be used for the test in this PR. (_TieRoundingTest_ is old and does not use JUnit.) Will consider updating  _TieRoundingTest_ to use JUnit and merging the tests in this PR under it in a separate issue.

I think "LSD" is a bit cryptic. I'd spell-out or replace with other words if possible (and the PR/JBS titles too)

> test/jdk/java/text/Format/NumberFormat/NumberRegression.java line 1779:
> 
>> 1777:                 "0%", "0%", "1%", "1%", "1%",
>> 1778:                 "0", "2", "0.2", "0.6", "0.04",
>> 1779:                 "0.04", "0.001", "0.002",
> 
> This test is checking that `.0005` rounded to 3 digits is "0.000" under HALF_EVEN.
> 
> This is wrong. See,
> `new BigDecimal(0.0005) ==> 0.0005000000000000000104083408558608425664715468883514404296875`. 
> 
> Resolving the bug in this PR requires fixing this incorrect test case. From the JDK-4241880 issue, it seems this case may have been put in to "document the incorrect but actual behavior".

I guess this is the exact case this fix is trying to address, but the expected result wrongly assumes the behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27681#discussion_r2414578536
PR Review Comment: https://git.openjdk.org/jdk/pull/27681#discussion_r2414581725

From prappo at openjdk.org  Wed Oct  8 17:50:36 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Oct 2025 17:50:36 GMT
Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal
 Instances with Different hashCode Values [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 7 Oct 2025 20:43:20 GMT, Naoto Sato  wrote:

>> Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

test/jdk/java/util/TimeZone/SimpleTimeZoneEqualsHashCodeTest.java line 59:

> 57:         assertNotEquals(STZ_WITH_DST, stz);
> 58:         // from the contract point, hash codes may be the same
> 59:         assertNotEquals(STZ_WITH_DST.hashCode(), stz.hashCode());

Like you said, from `!a.equals(b)` it does not follow that `a.hashCode() != b.hashCode()`. Unless you want hash code to specifically have this additional property, I'd remove this assertion.

test/jdk/java/util/TimeZone/SimpleTimeZoneEqualsHashCodeTest.java line 63:

> 61: 
> 62:     @Test
> 63:     void withOutDSTTest() {

Nit, really:

Suggestion:

    void withoutDSTTest() {

test/jdk/java/util/TimeZone/SimpleTimeZoneEqualsHashCodeTest.java line 76:

> 74:         assertTrue(stz.useDaylightTime());
> 75:         assertNotEquals(STZ_WITHOUT_DST, stz);
> 76:         assertNotEquals(STZ_WITHOUT_DST.hashCode(), stz.hashCode());

Ditto on equals-hashCode contract.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27660#discussion_r2414592801
PR Review Comment: https://git.openjdk.org/jdk/pull/27660#discussion_r2414583906
PR Review Comment: https://git.openjdk.org/jdk/pull/27660#discussion_r2414599801

From mullan at openjdk.org  Wed Oct  8 17:52:35 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 8 Oct 2025 17:52:35 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 3 Sep 2025 19:35:27 GMT, Matthew Donovan  wrote:

>> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.
>
> Matthew Donovan 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:
> 
>  - I removed signature algorithms output because the information is created during TLS handshake
>  - Merge branch 'master' into secsettings
>  - removed unused import, updated tools/launcher/Settings.java test
>  - Merge branch 'master' into secsettings
>  - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

src/java.base/share/classes/sun/launcher/SecuritySettings.java line 140:

> 138:             }
> 139: 
> 140:             ostream.println("\n" + TWOINDENT + "Enabled Groups:");

Change this to "Enabled Named Groups:". This would be more consistent with the API (`get/setNamedGroups`) and the Named Groups section of the Standard Algorithm Names spec.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24424#discussion_r2414604767

From jlu at openjdk.org  Wed Oct  8 18:06:05 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 8 Oct 2025 18:06:05 GMT
Subject: RFR: 8369050: DecimalFormat Rounding Errors for Ties Torwards 1 in
 LSD or 0
In-Reply-To: 
References: 
 
 
Message-ID: <-I2YDnaUqYuCyjvA0SZizCDga9zYdd4NVwvQjVjzn7I=.e82f011e-4801-436f-8b43-a8bf210b9efa@github.com>

On Wed, 8 Oct 2025 17:39:39 GMT, Naoto Sato  wrote:

>> test/jdk/java/text/Format/NumberFormat/NumberRegression.java line 1779:
>> 
>>> 1777:                 "0%", "0%", "1%", "1%", "1%",
>>> 1778:                 "0", "2", "0.2", "0.6", "0.04",
>>> 1779:                 "0.04", "0.001", "0.002",
>> 
>> This test is checking that `.0005` rounded to 3 digits is "0.000" under HALF_EVEN.
>> 
>> This is wrong. See,
>> `new BigDecimal(0.0005) ==> 0.0005000000000000000104083408558608425664715468883514404296875`. 
>> 
>> Resolving the bug in this PR requires fixing this incorrect test case. From the JDK-4241880 issue, it seems this case may have been put in to "document the incorrect but actual behavior".
>
> I guess this is the exact case this fix is trying to address, but the expected result wrongly assumes the behavior.

Right. This code used to return "0.000" because `count` would erroneously not be `1` for this specific case, hence going down the "there are additional digits" path. For HALF_EVEN, this returns true if there are additional non-zero digits past the last index. As there are none because the String double is given as ".0005", it rounded down.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27681#discussion_r2414634438

From naoto at openjdk.org  Wed Oct  8 18:08:38 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 Oct 2025 18:08:38 GMT
Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal
 Instances with Different hashCode Values [v4]
In-Reply-To: 
References: 
Message-ID: <9bOsoI7nGhYmcdwG8zRjBS74Oca_N5Cfh11iRaAP0oM=.68e1add0-b309-409b-ba95-b583ce99d44f@github.com>

> Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule.

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

  Apply suggestion from @pavelrappo
  
  Co-authored-by: Pavel Rappo <32523691+pavelrappo at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27660/files
  - new: https://git.openjdk.org/jdk/pull/27660/files/aafdf18b..e764e2a6

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

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

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

From jlu at openjdk.org  Wed Oct  8 18:10:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 8 Oct 2025 18:10:31 GMT
Subject: RFR: 8369050: DecimalFormat Rounding Errors for Fractional Ties
 Near Zero [v2]
In-Reply-To: 
References: 
Message-ID: <27RVFebqGufV83sFeY124966lHN1oi2x2Baa_p0P04Q=.319bfbc4-7fe0-4f3b-a66f-f4e52a8db928@github.com>

> Please review this PR which corrects a rounding error for DecimalFormat on tie cases when the maximum fraction digits allowed is one less than the position of the first significant digit in the double rounded. For example, rounding a value such as 0.0005 to a maximum of 3 fractional digits. In order to get the correct `count` value, we must strip the trailing zeros prior to the check to ensure we have the correct value of `count` = 1 so that we can go down the _Rounding position is the last index_ case which properly checks if the String double was already rounded or is exact from its true decimal form.

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

  Naoto's review -> test file rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27681/files
  - new: https://git.openjdk.org/jdk/pull/27681/files/6d22124e..1ebf7b0e

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

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

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

From naoto at openjdk.org  Wed Oct  8 18:15:39 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 Oct 2025 18:15:39 GMT
Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal
 Instances with Different hashCode Values [v5]
In-Reply-To: 
References: 
Message-ID: 

> Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule.

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

  Reflects review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27660/files
  - new: https://git.openjdk.org/jdk/pull/27660/files/e764e2a6..75ec7e71

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

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

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

From prappo at openjdk.org  Wed Oct  8 18:15:40 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Oct 2025 18:15:40 GMT
Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal
 Instances with Different hashCode Values [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 8 Oct 2025 18:12:45 GMT, Naoto Sato  wrote:

>> Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by prappo (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27660#pullrequestreview-3315973763

From naoto at openjdk.org  Wed Oct  8 18:15:42 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 Oct 2025 18:15:42 GMT
Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal
 Instances with Different hashCode Values [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 8 Oct 2025 17:44:43 GMT, Pavel Rappo  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> test/jdk/java/util/TimeZone/SimpleTimeZoneEqualsHashCodeTest.java line 59:
> 
>> 57:         assertNotEquals(STZ_WITH_DST, stz);
>> 58:         // from the contract point, hash codes may be the same
>> 59:         assertNotEquals(STZ_WITH_DST.hashCode(), stz.hashCode());
> 
> Like you said, from `!a.equals(b)` it does not follow that `a.hashCode() != b.hashCode()`. Unless you want hash code to specifically have this additional property, I'd remove this assertion.

I wanted to test the implementation which takes DST related fields into consideration for hash code calculation. Added some comments for clarity

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27660#discussion_r2414647340

From rriggs at openjdk.org  Wed Oct  8 18:21:41 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Oct 2025 18:21:41 GMT
Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to
 Instant [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 1 Oct 2025 20:17:00 GMT, Pavel Rappo  wrote:

>> We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR.
>> 
>> I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`.
>> 
>> My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`.
>> 
>> Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`.
>> 
>> [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copy-paste typos

src/java.base/share/classes/java/time/Instant.java line 814:

> 812:                     ? this.plus(duration) : Instant.MAX;
> 813:         }
> 814:     }

Can this be generalized to work across Temporals? To allow expansion later.
Addi a default method to the Temporal interface for `plusSaturating(TemporalAmount amount)`.
The default method can throw Unsupported Exception.
The override in Instant can be implemented as above and throw UnsupportedTemporalType for all other temporalAmounts.
The javadoc can use Duration for the example.
This would allow more types to consistently support saturating arithmetic.

src/java.base/share/classes/java/time/Instant.java line 1011:

> 1009:         }
> 1010:     }
> 1011: 

Omit minusSaturating, I think subtraction is much less common and even more so to exceed the negative range.
The caller can negate their argument and use plus if that's needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2414667478
PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2414671503

From liach at openjdk.org  Wed Oct  8 18:23:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 8 Oct 2025 18:23:26 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: <9c13AiS1RTrKhWGiVifePZ4CZa7Iws-AirXB-YMR4NQ=.cc24d342-334f-4be1-b886-7efd2c0a8898@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
 <9c13AiS1RTrKhWGiVifePZ4CZa7Iws-AirXB-YMR4NQ=.cc24d342-334f-4be1-b886-7efd2c0a8898@github.com>
Message-ID: 

On Wed, 8 Oct 2025 16:31:53 GMT, Bernd  wrote:

> Did you also consider a startsWith/containsCaseFold, I missed the case ignoring variants of those already.

I think for this purpose, we should rather introduce an API to case fold a string - we can use these operations on the case-fold-normalized strings.

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

PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3382715644

From naoto at openjdk.org  Wed Oct  8 18:26:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 Oct 2025 18:26:25 GMT
Subject: RFR: 8369050: DecimalFormat Rounding Errors for Fractional Ties
 Near Zero [v2]
In-Reply-To: <27RVFebqGufV83sFeY124966lHN1oi2x2Baa_p0P04Q=.319bfbc4-7fe0-4f3b-a66f-f4e52a8db928@github.com>
References: 
 <27RVFebqGufV83sFeY124966lHN1oi2x2Baa_p0P04Q=.319bfbc4-7fe0-4f3b-a66f-f4e52a8db928@github.com>
Message-ID: 

On Wed, 8 Oct 2025 18:10:31 GMT, Justin Lu  wrote:

>> Please review this PR which corrects a rounding error for DecimalFormat on tie cases when the maximum fraction digits allowed is one less than the position of the first significant digit in the double rounded. For example, rounding a value such as 0.0005 to a maximum of 3 fractional digits. In order to get the correct `count` value, we must strip the trailing zeros prior to the check to ensure we have the correct value of `count` = 1 so that we can go down the _Rounding position is the last index_ case which properly checks if the String double was already rounded or is exact from its true decimal form.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's review -> test file rename

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27681#pullrequestreview-3316021946

From rriggs at openjdk.org  Wed Oct  8 18:40:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Oct 2025 18:40:58 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 00:33:20 GMT, Xueming Shen  wrote:

>> ### 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 pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor api doc updates

The new APIs mentioned would be more effective, leveraging the underlying implementation without needing to create new Strings.  Earlier discussions of the support for folding, raised a concern about tempting developers to a more ambiguous situation in which folded and unfolded strings exist and can be confused.

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

PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3382766309

From liach at openjdk.org  Wed Oct  8 18:58:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 8 Oct 2025 18:58:30 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 00:33:20 GMT, Xueming Shen  wrote:

>> ### 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 pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor api doc updates

I don't think it's a good idea to have an explosion of case-folding variants of string operations if we are adding a case-folding overload for every operation. In that case, the confusion of case folding applicability would be less of a problem compared to the API bloat.

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

PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3382818647

From prappo at openjdk.org  Wed Oct  8 19:03:19 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Oct 2025 19:03:19 GMT
Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to
 Instant [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 8 Oct 2025 18:18:50 GMT, Roger Riggs  wrote:

> Omit minusSaturating, I think subtraction is much less common and even more so to exceed the negative range.
> The caller can negate their argument and use plus if that's needed.

On the one hand, I also don't think we need `minusSaturating` as far as the typical use case is concerned. On the other hand, negating durations is a tricky business. Although, it's not a real use case, negating the minimum duration will cause `ArithmeticException`:


jshell> Duration.ofSeconds(Long.MIN_VALUE, 0).negated()
|  Exception java.lang.ArithmeticException: Exceeds capacity of Duration: 9223372036854775808000000000
|        at Duration.create (Duration.java:1056)
|        at Duration.multipliedBy (Duration.java:995)
|        at Duration.negated (Duration.java:1074)
|        at (#2:1)


So one cannot implement `i.minusSaturaring(Duration.ofSeconds(Long.MIN_VALUE, 0))` as `i.plusSaturating(Duration.ofSeconds(Long.MIN_VALUE, 0).negated())`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2414764263

From rriggs at openjdk.org  Wed Oct  8 19:08:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Oct 2025 19:08:57 GMT
Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to
 Instant [v7]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 8 Oct 2025 19:00:44 GMT, Pavel Rappo  wrote:

>> src/java.base/share/classes/java/time/Instant.java line 1011:
>> 
>>> 1009:         }
>>> 1010:     }
>>> 1011: 
>> 
>> Omit minusSaturating, I think subtraction is much less common and even more so to exceed the negative range.
>> The caller can negate their argument and use plus if that's needed.
>
>> Omit minusSaturating, I think subtraction is much less common and even more so to exceed the negative range.
>> The caller can negate their argument and use plus if that's needed.
> 
> On the one hand, I also don't think we need `minusSaturating` as far as the typical use case is concerned. On the other hand, negating durations is a tricky business. Although, it's not a real use case, negating the minimum duration will cause `ArithmeticException`:
> 
> 
> jshell> Duration.ofSeconds(Long.MIN_VALUE, 0).negated()
> |  Exception java.lang.ArithmeticException: Exceeds capacity of Duration: 9223372036854775808000000000
> |        at Duration.create (Duration.java:1056)
> |        at Duration.multipliedBy (Duration.java:995)
> |        at Duration.negated (Duration.java:1074)
> |        at (#2:1)
> 
> 
> So one cannot implement `i.minusSaturaring(Duration.ofSeconds(Long.MIN_VALUE, 0))` as `i.plusSaturating(Duration.ofSeconds(Long.MIN_VALUE, 0).negated())`.

We're defining the values of MIN and MAX and they *could* be defined to be the negation of the other.
The defined use case is a sentinels and the exact value is less significant.
It just a different kind of oddity compared to twos-complement numbers that have their own asymmetry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2414774950

From prappo at openjdk.org  Wed Oct  8 20:05:50 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Oct 2025 20:05:50 GMT
Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to
 Instant [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 8 Oct 2025 18:17:39 GMT, Roger Riggs  wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copy-paste typos
>
> src/java.base/share/classes/java/time/Instant.java line 814:
> 
>> 812:                     ? this.plus(duration) : Instant.MAX;
>> 813:         }
>> 814:     }
> 
> Can this be generalized to work across Temporals? To allow expansion later.
> Addi a default method to the Temporal interface for `plusSaturating(TemporalAmount amount)`.
> The default method can throw Unsupported Exception.
> The override in Instant can be implemented as above and throw UnsupportedTemporalType for all other temporalAmounts.
> The javadoc can use Duration for the example.
> This would allow more types to consistently support saturating arithmetic.

It sure can be generalised like you said. The question is how useful that would be as far as the main use case is concerned.

Also, `java.time` is a kind of API that makes it hard to tell if a particular call would work unless you know the exact types of the receiver and the arguments. Having a method that throws an exception for everything but one particular type of the receiver and the argument -- even if temporarily -- can be confusing. (I've done my fair share of attempts to add a `Period` to an `Instant`.) But we can try, experiment, and see what happens.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2414893617

From rriggs at openjdk.org  Wed Oct  8 20:05:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Oct 2025 20:05:51 GMT
Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to
 Instant [v7]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 8 Oct 2025 19:59:17 GMT, Pavel Rappo  wrote:

>> src/java.base/share/classes/java/time/Instant.java line 814:
>> 
>>> 812:                     ? this.plus(duration) : Instant.MAX;
>>> 813:         }
>>> 814:     }
>> 
>> Can this be generalized to work across Temporals? To allow expansion later.
>> Addi a default method to the Temporal interface for `plusSaturating(TemporalAmount amount)`.
>> The default method can throw Unsupported Exception.
>> The override in Instant can be implemented as above and throw UnsupportedTemporalType for all other temporalAmounts.
>> The javadoc can use Duration for the example.
>> This would allow more types to consistently support saturating arithmetic.
>
> It sure can be generalised like you said. The question is how useful that would be as far as the main use case is concerned.
> 
> Also, `java.time` is a kind of API that makes it hard to tell if a particular call would work unless you know the exact types of the receiver and the arguments. Having a method that throws an exception for everything but one particular type of the receiver and the argument -- even if temporarily -- can be confusing. (I've done my fair share of attempts to add a `Period` to an `Instant`.) But we can try, experiment, and see what happens.

A Period with only day units *can* be added to an Instant.  (Because the day can be converted to seconds).

jshell> import java.time.*
jshell> var i = Instant.now()
i ==> 2025-10-08T20:02:15.231622Z
jshell> var p = Period.of(0,0,1)
p ==> P1D
jshell> i.plus(p)
$4 ==> 2025-10-09T20:02:15.231622Z

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2414902346

From prappo at openjdk.org  Wed Oct  8 20:05:52 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Oct 2025 20:05:52 GMT
Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to
 Instant [v7]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 8 Oct 2025 19:05:50 GMT, Roger Riggs  wrote:

>>> Omit minusSaturating, I think subtraction is much less common and even more so to exceed the negative range.
>>> The caller can negate their argument and use plus if that's needed.
>> 
>> On the one hand, I also don't think we need `minusSaturating` as far as the typical use case is concerned. On the other hand, negating durations is a tricky business. Although, it's not a real use case, negating the minimum duration will cause `ArithmeticException`:
>> 
>> 
>> jshell> Duration.ofSeconds(Long.MIN_VALUE, 0).negated()
>> |  Exception java.lang.ArithmeticException: Exceeds capacity of Duration: 9223372036854775808000000000
>> |        at Duration.create (Duration.java:1056)
>> |        at Duration.multipliedBy (Duration.java:995)
>> |        at Duration.negated (Duration.java:1074)
>> |        at (#2:1)
>> 
>> 
>> So one cannot implement `i.minusSaturaring(Duration.ofSeconds(Long.MIN_VALUE, 0))` as `i.plusSaturating(Duration.ofSeconds(Long.MIN_VALUE, 0).negated())`.
>
> We're defining the values of MIN and MAX and they *could* be defined to be the negation of the other.
> The defined use case is a sentinels and the exact value is less significant.
> It just a different kind of oddity compared to twos-complement numbers that have their own asymmetry.

Hm... I imagine it would be confusing if we did that. Should we ask about it on that recent core-libs-dev discussion thread?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2414897705

From rriggs at openjdk.org  Wed Oct  8 20:16:25 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Oct 2025 20:16:25 GMT
Subject: RFR: 8366829: Add java.time.Duration constants MIN and MAX [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 3 Oct 2025 09:50:23 GMT, Pavel Rappo  wrote:

>> We have [recently discussed][] a possibility of adding the `Duration.MIN` and `Duration.MAX` constants. Can we now start implementation? If and when we are in agreement on this PR, I will file a CSR.
>> 
>> I drafted a minimal specification and added some tests. I tried to phrase the spec for `Duration.MIN` in a way that makes it clear that `Duration.MIN` is the most negative value and not the least positive.
>> 
>> [recently discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to feedback
>   
>   Apply Stephen's suggestion on wording, although modified.

As proposed. Duration.MAX() is not the negated value of Duration.MIN.
Is there any value for them to have that mathematical property?
Duration.MIN can not be negated, it throws "Exceeds capacity of Duration".

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

PR Comment: https://git.openjdk.org/jdk/pull/27534#issuecomment-3383068470

From pavel.rappo at gmail.com  Wed Oct  8 20:28:35 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Wed, 8 Oct 2025 22:28:35 +0200
Subject: Duration.MAX_VALUE
In-Reply-To: 
References: 
Message-ID: 

In another thread, there's a question on whether we can define
Duration.MIN such that it's not the exact minimum, but rather the
minimum "negatable minimum"? Put differently, can we define
Duration.MIN as Duration.MAX.negated(), where Duration.MAX is
Duration.ofSeconds(Long.MAX_VALUE, 999_999_999)? What are the concerns
with this, if any?

-Pavel

On Wed, Sep 3, 2025 at 1:49?PM Pavel Rappo  wrote:
>
> Couldn't recall or quickly find if this was asked before.
>
> I come across this quite often: there doesn?t seem to be a readily
> available maximum value for java.time.Duration -- a value that
> represents the longest possible duration.
>
> I assume there are plenty of homegrown constants out in the wild
> addressing this. Don?t get me wrong: it?s not hard to create one. The
> issue, in my experience, is that it takes time and sometimes
> experimentation.
>
> Unless one reads the Javadoc carefully, it?s not obvious that the
> maximum duration can be constructed as follows:
>
>     Duration.of(Long.MAX_VALUE, 999_999_999);
>
> Naturally, one might first try using IDE autocomplete. For example,
> creating a Duration from Long.MAX_VALUE of a large unit -- millennia,
> centuries, decades, etc. -- only to run into ArithmeticException. Only
> when reaching seconds does it finally work:
>
>     Duration.ofSeconds(Long.MAX_VALUE);
>
> or
>
>     Duration.of(Long.MAX_VALUE, ChronoUnit.SECONDS);
>
> Of course, there?s no practical difference between
> Duration.of(Long.MAX_VALUE, 999_999_999) and
> Duration.ofSeconds(Long.MAX_VALUE). We?re talking about durations on
> the order of 292 billion years, after all. The exact value isn?t the
> problem. The problem is that the values are inconsistent, and arriving
> to them is error-prone. Adding a constant to java.time.Duration would
> simplify things.
>
> -Pavel

From asemenyuk at openjdk.org  Wed Oct  8 21:34:48 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 8 Oct 2025 21:34:48 GMT
Subject: RFR: 8363979: Add JDK bundle/image validation for --runtime-image
 option
Message-ID: <4fwrSDJyOkBE9tWN_LQJcGK3EcAxomHrs0Qcc8veDpE=.9ba36680-ddc6-4189-ba99-30529abd269c@github.com>

- Validate "libjli.dylib" file in the "lib" directory referenced with the `--runtime-image` option.
 - Split "ERR_MissingJLinkOptMacAppStore" error key into "error.invalid-runtime-image-bin-dir" and "error.invalid-runtime-image-bin-dir.advice"; moved new keys to mac-specific string property file.
 - Fix a couple of typos in RuntimeBuilderBuilder and WixSourceConverter classes.

Error messages:

Runtime image "ErrorTest/test.85b994e1/empty-runtime-image" is missing "lib/**/libjli.dylib" file

Runtime image "ErrorTest/test.05a7421a/invalid-runtime-bundle" is missing "Contents/Home/lib/**/libjli.dylib" file

Runtime image "/Users/alexeysemenyuk/jpackage-dev-runtime" should not contain "bin" folder
Advice to fix: Use --strip-native-commands jlink option when generating runtime image used with --mac-app-store option

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

Commit messages:
 - MacFromParams: trim trailing whitespace
 - ErrorTest: renames
 - 8363979: Add JDK bundle/image validation for --runtime-image option
 - RuntimeBuilderBuilder: fix a typo
 - WixSourceConverter: fix a typo

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

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

From asemenyuk at openjdk.org  Wed Oct  8 21:34:49 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 8 Oct 2025 21:34:49 GMT
Subject: RFR: 8363979: Add JDK bundle/image validation for --runtime-image
 option
In-Reply-To: <4fwrSDJyOkBE9tWN_LQJcGK3EcAxomHrs0Qcc8veDpE=.9ba36680-ddc6-4189-ba99-30529abd269c@github.com>
References: <4fwrSDJyOkBE9tWN_LQJcGK3EcAxomHrs0Qcc8veDpE=.9ba36680-ddc6-4189-ba99-30529abd269c@github.com>
Message-ID: <12wEAkWfY0wX9KKACeh-zqMBB7u6VQE52_2hTv_seUY=.d0cc09de-aaca-4594-b704-8f7c7db459da@github.com>

On Wed, 8 Oct 2025 17:51:59 GMT, Alexey Semenyuk  wrote:

> - Validate "libjli.dylib" file in the "lib" directory referenced with the `--runtime-image` option.
>  - Split "ERR_MissingJLinkOptMacAppStore" error key into "error.invalid-runtime-image-bin-dir" and "error.invalid-runtime-image-bin-dir.advice"; moved new keys to mac-specific string property file.
>  - Fix a couple of typos in RuntimeBuilderBuilder and WixSourceConverter classes.
> 
> Error messages:
> 
> Runtime image "ErrorTest/test.85b994e1/empty-runtime-image" is missing "lib/**/libjli.dylib" file
> 
> Runtime image "ErrorTest/test.05a7421a/invalid-runtime-bundle" is missing "Contents/Home/lib/**/libjli.dylib" file
> 
> Runtime image "/Users/alexeysemenyuk/jpackage-dev-runtime" should not contain "bin" folder
> Advice to fix: Use --strip-native-commands jlink option when generating runtime image used with --mac-app-store option

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/27701#issuecomment-3383298212

From rriggs at openjdk.org  Wed Oct  8 21:36:08 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Oct 2025 21:36:08 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v18]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 1 Oct 2025 17:22:39 GMT, Kieran Farrell  wrote:

>> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
>> 
>> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>> 
>> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
>> 
>> 
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>> 
>> 
>> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
>> 
>> - random-byte-only   143.487 ? 10.932  ns/op
>> - higher-precision      149.651 ?  8.438 ns/op
>> - counter-based         245.036 ?  2.943  ns/op
>> 
>> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove old test case reference

The suggestions for comparing UUIDs and method to extract the epoch time value can be consider as separate RFE's.
I think there is consensus on the current (single) new method to create UUIDS for v7
and get a fresh start (or not) on additional methods.
If you agree, please do a final review of the PR and CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3383314452

From rriggs at openjdk.org  Wed Oct  8 21:36:10 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Oct 2025 21:36:10 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v18]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 2 Oct 2025 10:56:34 GMT, Kieran Farrell  wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove old test case reference
>
> As Bokken highlighted, I think it might be worth adding a method (similar to the below) to extract the timestamp from v7 UUIDs?
> 
> 
> public long epochMilliTimestamp() {
>     if (version() != 7) {
>         throw new UnsupportedOperationException("Not a version 7 UUID");
>     }
>     return (mostSigBits >>> 16) & 0xFFFFFFFFFFFFL;
> }
> 
> 
> Regarding, the issues around comparison, as mentioned I think would it would be worth updating the current `compareTo` doc to identify that the implmentation uses signed long comparison and may not provide lexographical sorting in align with the rfc which can be problmetaic for time based UUIDs and also to add a seperate instance method but with lexographical sorting using unsigned comparrsion.

@kieran-farrell Please update the CSR with the current single API addition.

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

PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3383316919

From prappo at openjdk.org  Wed Oct  8 21:54:06 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Oct 2025 21:54:06 GMT
Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to
 Instant [v7]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 8 Oct 2025 20:03:37 GMT, Roger Riggs  wrote:

>> It sure can be generalised like you said. The question is how useful that would be as far as the main use case is concerned.
>> 
>> Also, `java.time` is a kind of API that makes it hard to tell if a particular call would work unless you know the exact types of the receiver and the arguments. Having a method that throws an exception for everything but one particular type of the receiver and the argument -- even if temporarily -- can be confusing. (I've done my fair share of attempts to add a `Period` to an `Instant`.) But we can try, experiment, and see what happens.
>
> A Period with only day units *can* be added to an Instant.  (Because the day can be converted to seconds).
> 
> jshell> import java.time.*
> jshell> var i = Instant.now()
> i ==> 2025-10-08T20:02:15.231622Z
> jshell> var p = Period.of(0,0,1)
> p ==> P1D
> jshell> i.plus(p)
> $4 ==> 2025-10-09T20:02:15.231622Z

You are right: if a `Period` is carefully picked, it can be added to `Instant`. However, one cannot _always_ convert days to seconds. For example,


jshell> Duration.from(Period.ofDays(1))
|  Exception java.time.temporal.UnsupportedTemporalTypeException: Unit must not have an estimated duration
|        at Duration.plus (Duration.java:733)
|        at Duration.from (Duration.java:340)
|        at (#23:1)


If you ask me, that feels surprising.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2415109640

From almatvee at openjdk.org  Wed Oct  8 22:05:03 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 8 Oct 2025 22:05:03 GMT
Subject: RFR: 8363979: Add JDK bundle/image validation for --runtime-image
 option
In-Reply-To: <4fwrSDJyOkBE9tWN_LQJcGK3EcAxomHrs0Qcc8veDpE=.9ba36680-ddc6-4189-ba99-30529abd269c@github.com>
References: <4fwrSDJyOkBE9tWN_LQJcGK3EcAxomHrs0Qcc8veDpE=.9ba36680-ddc6-4189-ba99-30529abd269c@github.com>
Message-ID: 

On Wed, 8 Oct 2025 17:51:59 GMT, Alexey Semenyuk  wrote:

> - Validate "libjli.dylib" file in the "lib" directory referenced with the `--runtime-image` option.
>  - Split "ERR_MissingJLinkOptMacAppStore" error key into "error.invalid-runtime-image-bin-dir" and "error.invalid-runtime-image-bin-dir.advice"; moved new keys to mac-specific string property file.
>  - Fix a couple of typos in RuntimeBuilderBuilder and WixSourceConverter classes.
> 
> Error messages:
> 
> Runtime image "ErrorTest/test.85b994e1/empty-runtime-image" is missing "lib/**/libjli.dylib" file
> 
> Runtime image "ErrorTest/test.05a7421a/invalid-runtime-bundle" is missing "Contents/Home/lib/**/libjli.dylib" file
> 
> Runtime image "/Users/alexeysemenyuk/jpackage-dev-runtime" should not contain "bin" folder
> Advice to fix: Use --strip-native-commands jlink option when generating runtime image used with --mac-app-store option

test/jdk/tools/jpackage/share/ErrorTest.java line 102:

> 100:             return root.toString();
> 101:         })),
> 102:         EMPTY_DIR(toFunction(cmd -> {

It is good idea to test `EMPTY_DIR`, but I think we should test one with `lib` subdirectory and at least one file in it to cover all code paths.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27701#discussion_r2415126716

From asemenyuk at openjdk.org  Wed Oct  8 22:58:03 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 8 Oct 2025 22:58:03 GMT
Subject: RFR: 8363979: Add JDK bundle/image validation for --runtime-image
 option
In-Reply-To: 
References: <4fwrSDJyOkBE9tWN_LQJcGK3EcAxomHrs0Qcc8veDpE=.9ba36680-ddc6-4189-ba99-30529abd269c@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 22:02:31 GMT, Alexander Matveev  wrote:

>> - Validate "libjli.dylib" file in the "lib" directory referenced with the `--runtime-image` option.
>>  - Split "ERR_MissingJLinkOptMacAppStore" error key into "error.invalid-runtime-image-bin-dir" and "error.invalid-runtime-image-bin-dir.advice"; moved new keys to mac-specific string property file.
>>  - Fix a couple of typos in RuntimeBuilderBuilder and WixSourceConverter classes.
>> 
>> Error messages:
>> 
>> Runtime image "ErrorTest/test.85b994e1/empty-runtime-image" is missing "lib/**/libjli.dylib" file
>> 
>> Runtime image "ErrorTest/test.05a7421a/invalid-runtime-bundle" is missing "Contents/Home/lib/**/libjli.dylib" file
>> 
>> Runtime image "/Users/alexeysemenyuk/jpackage-dev-runtime" should not contain "bin" folder
>> Advice to fix: Use --strip-native-commands jlink option when generating runtime image used with --mac-app-store option
>
> test/jdk/tools/jpackage/share/ErrorTest.java line 102:
> 
>> 100:             return root.toString();
>> 101:         })),
>> 102:         EMPTY_DIR(toFunction(cmd -> {
> 
> It is good idea to test `EMPTY_DIR`, but I think we should test one with `lib` subdirectory and at least one file in it to cover all code paths.

Agreed. I'll do that

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27701#discussion_r2415194987

From bpb at openjdk.org  Wed Oct  8 23:29:02 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 8 Oct 2025 23:29:02 GMT
Subject: RFR: 8368846: java/io/File/createTempFile/TargetDirectory fails
 when run by root user
In-Reply-To: 
References: 
Message-ID: <1J8-L6ZXcFwa8r3miMPKsvMk-6i9JXysqafYvvD463Y=.68becf72-0d8b-4d2c-8243-34f9cde7459f@github.com>

On Mon, 29 Sep 2025 08:28:38 GMT, Francesco Andreuzzi  wrote:

> The test checks whether writing to a read-only directory throws a `IOException`. This test is not applicable when the user running the test is root. Thus, I propose to skip it.
> 
> I converted the class to several JUnit tests, so we can use `@DisabledIf`.

test/jdk/java/io/File/createTempFile/TargetDirectory.java line 29:

> 27:  * @summary Verify directory parameter behavior in File.createTempFile(String,String,File)
> 28:  * @library /test/lib
> 29:  * @run junit/othervm TargetDirectory

Is `othervm` needed here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27542#discussion_r2415228400

From bpb at openjdk.org  Wed Oct  8 23:34:05 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 8 Oct 2025 23:34:05 GMT
Subject: RFR: 8368846: java/io/File/createTempFile/TargetDirectory fails
 when run by root user
In-Reply-To: 
References: 
Message-ID: 

On Mon, 29 Sep 2025 08:28:38 GMT, Francesco Andreuzzi  wrote:

> The test checks whether writing to a read-only directory throws a `IOException`. This test is not applicable when the user running the test is root. Thus, I propose to skip it.
> 
> I converted the class to several JUnit tests, so we can use `@DisabledIf`.

test/jdk/java/io/File/createTempFile/TargetDirectory.java line 54:

> 52: class TargetDirectory {
> 53: 
> 54:     @TempDir

In my testing I saw this output for each of the four sub-tests:

INFO: Skipping cleanup of temp dir [...] for field TargetDirectory.tempDir due to CleanupMode.NEVER.

Should this have `CleanupMode.ALWAYS`? In the old version of the test there were explcit calls to `File.delete`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27542#discussion_r2415232784

From almatvee at openjdk.org  Wed Oct  8 23:39:48 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 8 Oct 2025 23:39:48 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts [v12]
In-Reply-To: 
References: 
Message-ID: 

> - Removed pre- and post- installation PKG scripts.
> - This code is not needed and PKG should create destination folder and set correct permissions.
> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
> - Users will have ability to provide pre- and post- installation PKG scripts if needed.
> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`.
> - I think code in these scripts are some legacy leftovers.
> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`.

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

  8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v10]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25510/files
  - new: https://git.openjdk.org/jdk/pull/25510/files/47271a16..07260799

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

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

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

From almatvee at openjdk.org  Wed Oct  8 23:39:49 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 8 Oct 2025 23:39:49 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 8 Oct 2025 02:39:51 GMT, Alexander Matveev  wrote:

>> - Removed pre- and post- installation PKG scripts.
>> - This code is not needed and PKG should create destination folder and set correct permissions.
>> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
>> - Users will have ability to provide pre- and post- installation PKG scripts if needed.
>> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`.
>> - I think code in these scripts are some legacy leftovers.
>> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v9]

8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v10]
- Fixed log messages.
`[15:55:47.893] Using custom package resource [PKG postinstall script] (loaded from postinstall).`
`[15:55:47.894] No default package resource preinstall [PKG preinstall script] (add preinstall to the resource-dir to customize).`

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

PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-3383563033

From bpb at openjdk.org  Wed Oct  8 23:48:02 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 8 Oct 2025 23:48:02 GMT
Subject: RFR: 8368846: java/io/File/createTempFile/TargetDirectory fails
 when run by root user
In-Reply-To: 
References: 
Message-ID: 

On Mon, 29 Sep 2025 08:28:38 GMT, Francesco Andreuzzi  wrote:

> The test checks whether writing to a read-only directory throws a `IOException`. This test is not applicable when the user running the test is root. Thus, I propose to skip it.
> 
> I converted the class to several JUnit tests, so we can use `@DisabledIf`.

test/jdk/java/io/File/createTempFile/TargetDirectory.java line 50:

> 48: import jdk.test.lib.Platform;
> 49: 
> 50: import static org.junit.jupiter.api.Assertions.*;

I think you can dispense with the wild card at line 50 by doing:

import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.junit.jupiter.api.Assertions.assertTrue;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27542#discussion_r2415245878

From bpb at openjdk.org  Thu Oct  9 00:11:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 9 Oct 2025 00:11:03 GMT
Subject: RFR: 8191963: Path.equals() and File.equals() return true for two
 different files on Windows [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: <7pZEX57ViVz3tmRREC7vu7EstyZNGIumnCyxp4mINtM=.93aaa98c-4945-44c6-8d38-28e7e5c1d9ae@github.com>

On Mon, 6 Oct 2025 16:12:49 GMT, Naoto Sato  wrote:

> Would it be safer to make the new behavior as opt-in, as well as making the system property to be windows specific `windowsCompatibleEquals` or something? Making it as the default might be a bit risky to me.

Opt-in might mean that no one will ever do it, but it would make the compatibility risk zero. The suggested property name is good, or it could be `jdk.io.File.windowsNIOCompatibleEquals`.

> Also, IIUC the test is comparing cases between 'I', '\u0130' and '\u0131'. Probably we need to cross test with 'i' too.

Acknowledged.

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

PR Comment: https://git.openjdk.org/jdk/pull/25788#issuecomment-3383609797

From almatvee at openjdk.org  Thu Oct  9 00:59:50 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 9 Oct 2025 00:59:50 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts [v13]
In-Reply-To: 
References: 
Message-ID: 

> - Removed pre- and post- installation PKG scripts.
> - This code is not needed and PKG should create destination folder and set correct permissions.
> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
> - Users will have ability to provide pre- and post- installation PKG scripts if needed.
> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`.
> - I think code in these scripts are some legacy leftovers.
> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`.

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

  8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v11]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25510/files
  - new: https://git.openjdk.org/jdk/pull/25510/files/07260799..26530a27

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

  Stats: 45 lines in 4 files changed: 18 ins; 25 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25510/head:pull/25510

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

From almatvee at openjdk.org  Thu Oct  9 00:59:51 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 9 Oct 2025 00:59:51 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 8 Oct 2025 23:39:48 GMT, Alexander Matveev  wrote:

>> - Removed pre- and post- installation PKG scripts.
>> - This code is not needed and PKG should create destination folder and set correct permissions.
>> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
>> - Users will have ability to provide pre- and post- installation PKG scripts if needed.
>> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`.
>> - I think code in these scripts are some legacy leftovers.
>> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v10]

8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v11]
- Moved log message for no resource to `ShellScriptResource`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-3383682422

From almatvee at openjdk.org  Thu Oct  9 01:54:42 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 9 Oct 2025 01:54:42 GMT
Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v6]
In-Reply-To: 
References: 
Message-ID: 

> - Added test for custom info plist to cover app image including embedded runtime and runtime installer.
> - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string.

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

  8362598: [macos] Add tests for custom info plist files [v6]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27509/files
  - new: https://git.openjdk.org/jdk/pull/27509/files/01e41f1f..a8fff653

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

  Stats: 799 lines in 9 files changed: 554 ins; 135 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/27509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27509/head:pull/27509

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

From almatvee at openjdk.org  Thu Oct  9 01:54:43 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 9 Oct 2025 01:54:43 GMT
Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 4 Oct 2025 01:01:37 GMT, Alexander Matveev  wrote:

>> - Added test for custom info plist to cover app image including embedded runtime and runtime installer.
>> - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362598: [macos] Add tests for custom info plist files [v5]

8362598: [macos] Add tests for custom info plist files [v6]
- Merged with https://github.com/openjdk/jdk/pull/27658

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

PR Comment: https://git.openjdk.org/jdk/pull/27509#issuecomment-3383767332

From dholmes at openjdk.org  Thu Oct  9 02:08:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Oct 2025 02:08:07 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v4]
In-Reply-To: 
References: 
 
 
 
 <1Ed3XduxQZKSVBUng2-sUeD1ib9ZZqRQBN18n0SrAwY=.496748d7-01f9-4b9f-a184-d364f3d7d0f2@github.com>
 
 
Message-ID: 

On Wed, 8 Oct 2025 08:05:22 GMT, Alan Bateman  wrote:

> > > I think what you are suggesting is that the JEP could instead have -Xcheck:jni emit a warning when JNI setter functions mutate final fields, and maybe change it to be a fatal error in the future, maybe as part of the future JEP that proposes to move "deny" the default.
> > 
> > 
> > @AlanBateman yes that is exactly what I am suggesting. Thanks
> 
> I discussed this with Ron. Mutating final fields from native code isn't core to this JEP. A fatal error would be better but we are okay with it initially being a warning instead. So we'll update that section of the JEP, and change the addition to jniCheck to use ReportJNIWarning instead of ReportJNIFatalError.

Thank you @AlanBateman and @pron !

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3383789373

From almatvee at openjdk.org  Thu Oct  9 03:01:01 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 9 Oct 2025 03:01:01 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts [v14]
In-Reply-To: 
References: 
Message-ID: 

> - Removed pre- and post- installation PKG scripts.
> - This code is not needed and PKG should create destination folder and set correct permissions.
> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
> - Users will have ability to provide pre- and post- installation PKG scripts if needed.
> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`.
> - I think code in these scripts are some legacy leftovers.
> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`.

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

  8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v12]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25510/files
  - new: https://git.openjdk.org/jdk/pull/25510/files/26530a27..074feedd

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

  Stats: 123 lines in 5 files changed: 61 ins; 41 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/25510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25510/head:pull/25510

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

From almatvee at openjdk.org  Thu Oct  9 03:01:03 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 9 Oct 2025 03:01:03 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Oct 2025 00:59:50 GMT, Alexander Matveev  wrote:

>> - Removed pre- and post- installation PKG scripts.
>> - This code is not needed and PKG should create destination folder and set correct permissions.
>> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
>> - Users will have ability to provide pre- and post- installation PKG scripts if needed.
>> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`.
>> - I think code in these scripts are some legacy leftovers.
>> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v11]

8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v12]
- Moved no resources log message to `OverridableResource`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-3383867294

From kfarrell at openjdk.org  Thu Oct  9 10:17:10 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 9 Oct 2025 10:17:10 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v18]
In-Reply-To: 
References: 
 
 
 
Message-ID: <4F5N-wAqaRhxwlbeNOu23K7QYOsVyTCJyogcQeqfrjU=.cba22bca-3bd1-4f93-88b4-3114e6c27d18@github.com>

On Wed, 8 Oct 2025 21:33:19 GMT, Roger Riggs  wrote:

>> As Bokken highlighted, I think it might be worth adding a method (similar to the below) to extract the timestamp from v7 UUIDs?
>> 
>> 
>> public long epochMilliTimestamp() {
>>     if (version() != 7) {
>>         throw new UnsupportedOperationException("Not a version 7 UUID");
>>     }
>>     return (mostSigBits >>> 16) & 0xFFFFFFFFFFFFL;
>> }
>> 
>> 
>> Regarding, the issues around comparison, as mentioned I think would it would be worth updating the current `compareTo` doc to identify that the implmentation uses signed long comparison and may not provide lexographical sorting in align with the rfc which can be problmetaic for time based UUIDs and also to add a seperate instance method but with lexographical sorting using unsigned comparrsion.
>
> @kieran-farrell Please update the CSR with the current single API addition.

@RogerRiggs good with me, CSR has been updated now

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

PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3385157330

From prappo at openjdk.org  Thu Oct  9 10:34:06 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 Oct 2025 10:34:06 GMT
Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to
 Instant [v7]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <2eZ6K77GYi4fOxPVPEI4xFKtqPPtFp8TtuJr8zbCsJ4=.fe167639-7864-41cd-8e8b-c2bdb264acfe@github.com>

On Wed, 8 Oct 2025 20:01:15 GMT, Pavel Rappo  wrote:

>> We're defining the values of MIN and MAX and they *could* be defined to be the negation of the other.
>> The defined use case is a sentinels and the exact value is less significant.
>> It just a different kind of oddity compared to twos-complement numbers that have their own asymmetry.
>
> Hm... I imagine it would be confusing if we did that. Should we ask about it on that recent core-libs-dev discussion thread?

Thinking about it more. Roger, I don't think we should define `Duration.MIN` as `Duration.MAX.negated()` now. We missed that opportunity long ago. `Duration` could've **initially** had the minimum addressable value as that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2416324715

From mdonovan at openjdk.org  Thu Oct  9 11:45:35 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 9 Oct 2025 11:45:35 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups [v4]
In-Reply-To: 
References: 
Message-ID: 

> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.

Matthew Donovan 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:

 - changed title to 'Enabled Named Groups'
 - Merge branch 'master' into secsettings
 - I removed signature algorithms output because the information is created during TLS handshake
 - Merge branch 'master' into secsettings
 - removed unused import, updated tools/launcher/Settings.java test
 - Merge branch 'master' into secsettings
 - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24424/files
  - new: https://git.openjdk.org/jdk/pull/24424/files/1e21e080..a2182b9f

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

  Stats: 204412 lines in 2784 files changed: 154746 ins; 31954 del; 17712 mod
  Patch: https://git.openjdk.org/jdk/pull/24424.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24424/head:pull/24424

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

From mullan at openjdk.org  Thu Oct  9 13:08:31 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 9 Oct 2025 13:08:31 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Oct 2025 11:45:35 GMT, Matthew Donovan  wrote:

>> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.
>
> Matthew Donovan 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:
> 
>  - changed title to 'Enabled Named Groups'
>  - Merge branch 'master' into secsettings
>  - I removed signature algorithms output because the information is created during TLS handshake
>  - Merge branch 'master' into secsettings
>  - removed unused import, updated tools/launcher/Settings.java test
>  - Merge branch 'master' into secsettings
>  - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24424#pullrequestreview-3318883788

From alanb at openjdk.org  Thu Oct  9 13:11:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Oct 2025 13:11:54 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v18]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 1 Oct 2025 17:22:39 GMT, Kieran Farrell  wrote:

>> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
>> 
>> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>> 
>> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
>> 
>> 
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>> 
>> 
>> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
>> 
>> - random-byte-only   143.487 ? 10.932  ns/op
>> - higher-precision      149.651 ?  8.438 ns/op
>> - counter-based         245.036 ?  2.943  ns/op
>> 
>> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove old test case reference

src/java.base/share/classes/java/util/UUID.java line 207:

> 205:      * @return a {@code UUID} constructed using the given {@code timestamp}
> 206:      *
> 207:      * @throws IllegalArgumentException if the timestamp is negative or greater than {@code 281474976710655L}

What would you think about using (1L << 48) - 1 instead?

src/java.base/share/classes/java/util/UUID.java line 210:

> 208:      *
> 209:      * @spec https://www.rfc-editor.org/rfc/rfc9562.html
> 210:      *       RFC 9562 Universally Unique IDentifiers (UUIDs)

The updated class description means the class now has a prominent link to RFC, so not sure about having another link here. If we are linking then can we link to ##name-uuid-version-7.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2416732407
PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2416721464

From mdonovan at openjdk.org  Thu Oct  9 13:23:22 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 9 Oct 2025 13:23:22 GMT
Subject: Integrated: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups
In-Reply-To: 
References: 
Message-ID: 

On Thu, 3 Apr 2025 18:47:43 GMT, Matthew Donovan  wrote:

> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.

This pull request has now been integrated.

Changeset: 5bb9fed9
Author:    Matthew Donovan 
URL:       https://git.openjdk.org/jdk/commit/5bb9fed9de3297639d5c0cd1d8046656d98863dd
Stats:     16 lines in 2 files changed: 14 ins; 0 del; 2 mod

8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups

Reviewed-by: mullan, coffeys

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

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

From jpai at openjdk.org  Thu Oct  9 13:28:35 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 9 Oct 2025 13:28:35 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v18]
In-Reply-To: 
References: 
 
 
Message-ID: <2497kbngotmageSFb34cWKiSNJsD4qBQuInU2_qyY24=.ef25e565-6f32-418a-92ef-67d6584dc7c6@github.com>

On Thu, 9 Oct 2025 13:04:51 GMT, Alan Bateman  wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove old test case reference
>
> src/java.base/share/classes/java/util/UUID.java line 207:
> 
>> 205:      * @return a {@code UUID} constructed using the given {@code timestamp}
>> 206:      *
>> 207:      * @throws IllegalArgumentException if the timestamp is negative or greater than {@code 281474976710655L}
> 
> What would you think about using (1L << 48) - 1 instead?

I think the use of `281474976710655L` value in the javadoc was borrowed from my proposal to use this value. My personal preference was to use this explicit value because I then don't have to do the actual computation of what "(1L << 48) - 1" equals to when reading that javadoc.

But if "(1L << 48) - 1" is preferable, then that's OK with me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2416793794

From alanb at openjdk.org  Thu Oct  9 13:34:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Oct 2025 13:34:00 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v18]
In-Reply-To: <2497kbngotmageSFb34cWKiSNJsD4qBQuInU2_qyY24=.ef25e565-6f32-418a-92ef-67d6584dc7c6@github.com>
References: 
 
 
 <2497kbngotmageSFb34cWKiSNJsD4qBQuInU2_qyY24=.ef25e565-6f32-418a-92ef-67d6584dc7c6@github.com>
Message-ID: 

On Thu, 9 Oct 2025 13:25:40 GMT, Jaikiran Pai  wrote:

>> src/java.base/share/classes/java/util/UUID.java line 207:
>> 
>>> 205:      * @return a {@code UUID} constructed using the given {@code timestamp}
>>> 206:      *
>>> 207:      * @throws IllegalArgumentException if the timestamp is negative or greater than {@code 281474976710655L}
>> 
>> What would you think about using (1L << 48) - 1 instead?
>
> I think the use of `281474976710655L` value in the javadoc was borrowed from my proposal to use this value. My personal preference was to use this explicit value because I then don't have to do the actual computation of what "(1L << 48) - 1" equals to when reading that javadoc.
> 
> But if "(1L << 48) - 1" is preferable, then that's OK with me.

It's not important, it's just that the apiNote uses "48 bits" at least twice, it may not be immediately obvious when it then jumps to 281474976710655L in the IAE description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2416812247

From alanb at openjdk.org  Thu Oct  9 13:38:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Oct 2025 13:38:12 GMT
Subject: RFR: 8347007: --strip-debug removes parameter names included with
 -parameters [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 2 Oct 2025 05:40:49 GMT, Henry Jen  wrote:

>> Since parameters is an opt-in choice, it's more reasonable to consider that's desired information and make strip parameter names an opt-in choice as well.
>> 
>> This PR changes the default behavior of --strip-debug to keep parameter names when it's available. Add opt-in mechanism,
>> via the strip-java-debug-attributes plugin by using argument `--strip-java-debug-attributes=+parameter-names`.
>> 
>> The --strip-debug option is a little bit odd, as it's a main option as well as a plugin option to enable the DefaultStripDebugPlugin, which strip native debug information on platform support the feature, and strip java debug information. In this PR, we chose to support only one mechanism to enable strip parameter names, so we would disable the embed StripJavaDebugAttributesPlugin when StripJavaDebugAttributesPlugin is enabled.
>> 
>> The StripParameterNamesTest illustrate and verify parameter names use cases, mainly focus on argument processing and the parameter names. We didn't verify the regular debug info as that's covered by existing test.
>> 
>> -- Update
>> 
>> The latest change removed the support of strip parameter names, as the MethodParameters attribute is considered necessary attribute to fulfill Java Language Spec even though this attribute is considered optional by JVM spec.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MethodParameters attribute should not be removed

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java line 465:

> 463:             // disable StripJavaDebugAttributesPlugin within DefaultStripDebug plugin if both enabled
> 464:             if (seenPlugins.contains(StripJavaDebugAttributesPlugin.NAME) && defaultStripDebugPlugin != null) {
> 465:                 defaultStripDebugPlugin.enableJavaStripPlugin(false);

This is unfortunate, but as you explained in the PR description, we are kinda stuck with this because there is both a jlink options and a plugin option.

test/jdk/tools/jlink/plugins/DefaultStripDebugPluginTest.java line 76:

> 74:     }
> 75: 
> 76:     public void testOnlyNativePlugin() {

Would it be possible to add a one or two sentence description to these test methods as it's not immediately obvious what these tests do. The name gives some hint of course but it would be helpful to have something so it's clear which combination be being tested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416825686
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416773503

From alanb at openjdk.org  Thu Oct  9 13:46:26 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Oct 2025 13:46:26 GMT
Subject: RFR: 8347007: --strip-debug removes parameter names included with
 -parameters [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 2 Oct 2025 05:40:49 GMT, Henry Jen  wrote:

>> Since parameters is an opt-in choice, it's more reasonable to consider that's desired information and make strip parameter names an opt-in choice as well.
>> 
>> This PR changes the default behavior of --strip-debug to keep parameter names when it's available. Add opt-in mechanism,
>> via the strip-java-debug-attributes plugin by using argument `--strip-java-debug-attributes=+parameter-names`.
>> 
>> The --strip-debug option is a little bit odd, as it's a main option as well as a plugin option to enable the DefaultStripDebugPlugin, which strip native debug information on platform support the feature, and strip java debug information. In this PR, we chose to support only one mechanism to enable strip parameter names, so we would disable the embed StripJavaDebugAttributesPlugin when StripJavaDebugAttributesPlugin is enabled.
>> 
>> The StripParameterNamesTest illustrate and verify parameter names use cases, mainly focus on argument processing and the parameter names. We didn't verify the regular debug info as that's covered by existing test.
>> 
>> -- Update
>> 
>> The latest change removed the support of strip parameter names, as the MethodParameters attribute is considered necessary attribute to fulfill Java Language Spec even though this attribute is considered optional by JVM spec.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MethodParameters attribute should not be removed

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 133:

> 131:                     .forEach(File::delete);
> 132:         }
> 133:     }

jdk.test.lib.util.FilesUtils has method for this.

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 189:

> 187:         Process process = processBuilder.start();
> 188:         int exitCode = process.waitFor();
> 189:         var output = process.inputReader().readLine();

Have you looked into using  jdk.test.lib.process.ProcessTools?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416845430
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416846080

From alanb at openjdk.org  Thu Oct  9 13:52:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Oct 2025 13:52:59 GMT
Subject: RFR: 8347007: --strip-debug removes parameter names included with
 -parameters [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 2 Oct 2025 05:40:49 GMT, Henry Jen  wrote:

>> Since parameters is an opt-in choice, it's more reasonable to consider that's desired information and make strip parameter names an opt-in choice as well.
>> 
>> This PR changes the default behavior of --strip-debug to keep parameter names when it's available. Add opt-in mechanism,
>> via the strip-java-debug-attributes plugin by using argument `--strip-java-debug-attributes=+parameter-names`.
>> 
>> The --strip-debug option is a little bit odd, as it's a main option as well as a plugin option to enable the DefaultStripDebugPlugin, which strip native debug information on platform support the feature, and strip java debug information. In this PR, we chose to support only one mechanism to enable strip parameter names, so we would disable the embed StripJavaDebugAttributesPlugin when StripJavaDebugAttributesPlugin is enabled.
>> 
>> The StripParameterNamesTest illustrate and verify parameter names use cases, mainly focus on argument processing and the parameter names. We didn't verify the regular debug info as that's covered by existing test.
>> 
>> -- Update
>> 
>> The latest change removed the support of strip parameter names, as the MethodParameters attribute is considered necessary attribute to fulfill Java Language Spec even though this attribute is considered optional by JVM spec.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MethodParameters attribute should not be removed

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 67:

> 65:     private static List testJmods = new ArrayList<>();
> 66: 
> 67:     record Jmod(Path moduleDir, boolean withDebugInfo, boolean withParameterNames) {}

Is the withDebugInfo component used?

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 67:

> 65:     private static List testJmods = new ArrayList<>();
> 66: 
> 67:     record Jmod(Path moduleDir, boolean withDebugInfo, boolean withParameterNames) {}

Is the withDebugInfo component used?

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 67:

> 65:     private static List testJmods = new ArrayList<>();
> 66: 
> 67:     record Jmod(Path moduleDir, boolean withDebugInfo, boolean withParameterNames) {}

Is the withDebugInfo component used?

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 67:

> 65:     private static List testJmods = new ArrayList<>();
> 66: 
> 67:     record Jmod(Path moduleDir, boolean withDebugInfo, boolean withParameterNames) {}

Is the withDebugInfo component used?

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 67:

> 65:     private static List testJmods = new ArrayList<>();
> 66: 
> 67:     record Jmod(Path moduleDir, boolean withDebugInfo, boolean withParameterNames) {}

Is the withDebugInfo component used?

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 67:

> 65:     private static List testJmods = new ArrayList<>();
> 66: 
> 67:     record Jmod(Path moduleDir, boolean withDebugInfo, boolean withParameterNames) {}

Is the withDebugInfo component used?

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 67:

> 65:     private static List testJmods = new ArrayList<>();
> 66: 
> 67:     record Jmod(Path moduleDir, boolean withDebugInfo, boolean withParameterNames) {}

Is the withDebugInfo component used?

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 221:

> 219:     @Test
> 220:     public void testWithoutStripParameterName() throws Exception {
> 221:         var imageDir = Paths.get("img");

(You can replace all uses of Paths.get with Path.of if you want)

Are we missing a 4th test to test --strip-java-debug-attributes on its own?

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 221:

> 219:     @Test
> 220:     public void testWithoutStripParameterName() throws Exception {
> 221:         var imageDir = Paths.get("img");

(You can replace all uses of Paths.get with Path.of if you want)

Are we missing a 4th test to test --strip-java-debug-attributes on its own?

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 221:

> 219:     @Test
> 220:     public void testWithoutStripParameterName() throws Exception {
> 221:         var imageDir = Paths.get("img");

(You can replace all uses of Paths.get with Path.of if you want)

Are we missing a 4th test to test --strip-java-debug-attributes on its own?

test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 221:

> 219:     @Test
> 220:     public void testWithoutStripParameterName() throws Exception {
> 221:         var imageDir = Paths.get("img");

(You can replace all uses of Paths.get with Path.of if you want)

Are we missing a 4th test to test --strip-java-debug-attributes on its own?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416862433
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416862740
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416866887
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416869328
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416869655
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416870113
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416870371
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416866546
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416867294
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416868671
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2416868957

From rriggs at openjdk.org  Thu Oct  9 14:18:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 9 Oct 2025 14:18:05 GMT
Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to
 Instant [v7]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 8 Oct 2025 21:50:55 GMT, Pavel Rappo  wrote:

>> A Period with only day units *can* be added to an Instant.  (Because the day can be converted to seconds).
>> 
>> jshell> import java.time.*
>> jshell> var i = Instant.now()
>> i ==> 2025-10-08T20:02:15.231622Z
>> jshell> var p = Period.of(0,0,1)
>> p ==> P1D
>> jshell> i.plus(p)
>> $4 ==> 2025-10-09T20:02:15.231622Z
>
> You are right: if a `Period` is carefully picked, it can be added to `Instant`. However, one cannot _always_ convert days to seconds. For example,
> 
> 
> jshell> Duration.from(Period.ofDays(1))
> |  Exception java.time.temporal.UnsupportedTemporalTypeException: Unit must not have an estimated duration
> |        at Duration.plus (Duration.java:733)
> |        at Duration.from (Duration.java:340)
> |        at (#23:1)
> 
> 
> If you ask me, that feels surprising.

As specified and implemented, `Duration.plus(long amount, TemporalUnit)` does not make an exception for amount == 0.  For any other value of month or years, the value is an estimate and the exception is thrown.
It might be useful to consider a change (as a separate enhancement)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2416958704

From cstein at openjdk.org  Thu Oct  9 14:22:44 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 9 Oct 2025 14:22:44 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
Message-ID: 

Please review the change to update to using jtreg `8.1`.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

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

Commit messages:
 - 8369488: Update to use jtreg 8.1

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

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

From pavel.rappo at gmail.com  Thu Oct  9 14:25:01 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Thu, 9 Oct 2025 16:25:01 +0200
Subject: Duration.MAX_VALUE
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
 
 
 
Message-ID: 

Out of curiosity, how is Instants.saturatedSubtract(Instant, Duration) used?

On Wed, Oct 8, 2025 at 2:13?AM ?amonn McManus  wrote:
>
> Yes, we have utility classes Instants and Durations, and Instants includes methods Instants.saturatedAdd(Instant, Duration) and Instants.saturatedSubtract(Instant, Duration). Each has a modest number of uses in the codebase, about three orders of magnitude less than the number of classes that reference Instant or Duration.
>
> On Tue, 7 Oct 2025 at 14:18, Pavel Rappo  wrote:
>>
>> ?amonn, Kurt,
>>
>> Is there any saturating arithmetic for instant + duration in your code base?
>>
>>
>>
>> On Fri, Sep 5, 2025 at 8:58?PM ?amonn McManus  wrote:
>> >
>> > As promised, Kurt and I have examined some of the uses of our Durations.MAX constant. This is a summary of what we see in a random sample of 30 out of about 700 usages in Google's (giant) codebase.
>> >
>> > First, about half of the usages specifically concern deadlines. Many of them involve a method that sets an RPC deadline and where it is explicitly documented that you should use Durations.MAX to mean no deadline (or equivalently, infinite deadline).
>> >
>> > Several other usages concern deadline-adjacent concepts such as time-to-live or cache expiration delay.
>> >
>> > A number of usages specifically compare a Duration against Durations.MAX to recognize the "infinite duration" value.
>> >
>> > One usage uses our internal Sleeper interface to do sleeper.sleep(Durations.MAX), for an indefinite sleep (until interrupted).
>> >
>> > In a couple of places, there is a maximum allowed Duration for some operation, and a user-supplied Duration value is capped by this maximum. When no maximum is needed, the cap is Durations.MAX. This is similar to the "sentinel" use case I mentioned earlier.
>> >
>> > One case is using Durations.MAX in a test, to ensure that a function works correctly for all Duration values including the largest one. It is testing a Kotlin extension function that allows you to write e.g. 5.minutes:
>> >
>> >     val n = Durations.MAX.toMinutes()
>> >
>> >     assertThat(n.minutes).isEqualTo(Duration.ofMinutes(n))
>> >
>> >     assertFailsWith { (n + 1).minutes }
>> >
>> >
>> > In summary, I think the most interesting use cases fall into these categories:
>> >
>> > to express an effectively-infinite Duration, possibly accompanied by special-case logic to optimize the exact value Durations.MAX;
>> >
>> > to express the absence of an optional cap on a user-supplied Duration value;
>> >
>> > to test that code works correctly even with extreme Duration values.
>> >
>> >
>> > Of these, the first is potentially fragile because of the overflow problems we discussed. The other two seem unproblematic, though.
>> >
>> >
>> >
>> > On Thu, 4 Sept 2025 at 15:02, ?amonn McManus  wrote:
>> >>
>> >> Two typical use cases:
>> >>
>> >> // 1. Sentinel
>> >> Duration min = Duration.MAX;
>> >> for (var foo : something()) {
>> >>   if (foo.duration().compareTo(min) < 0) {
>> >>     min = foo.duration();
>> >>   }
>> >> }
>> >>
>> >> // 2. "Forever"
>> >> void frob(Optional optionalTimeout) {
>> >>   Duration timeout = optionalTimeout.orElse(Duration.MAX);
>> >>   Instant start = Instant.now();
>> >>   boolean done = false;
>> >>   while (!done && startTime.until(Instant.now()).compareTo(timeout) < 0) {...}
>> >> }
>> >>
>> >> The second case illustrates why this is potentially a bit delicate. You better not write this:
>> >>
>> >> void frob(Optional optionalTimeout) {
>> >>   Duration timeout = optionalTimeout.orElse(Duration.MAX);
>> >>   Instant deadline = Instant.now().plus(timeout); // oops
>> >>   boolean done = false;
>> >>   while (!done && Instant.now().isBefore(deadline)) {...}
>> >> }
>> >>
>> >> Like Kevin, I am skeptical about Duration.MIN. If it means the most negative Duration, that is just Duration.MAX.negated(); and if it means the smallest positive Duration, that is just Duration.ofNanos(1).
>> >>
>> >> On Wed, 3 Sept 2025 at 18:32, Roger Riggs  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I'd be interested in the range of use cases for Duration.MAX or MIN.
>> >>>
>> >>> But for deadlines, I think the code should compute the deadline from a Duration of its choice based on the use.
>> >>> Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that ignores information about the particular use that is relevant. Its just sloppy code that doesn't bother to express how long is long enough to meet operational parameters.
>> >>>
>> >>> YMMV, Roger
>> >>>
>> >>> On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote:
>> >>>
>> >>> Duration.MIN is a whole 'nother bag of worms, because Durations are signed (they can be positive or negative...or zero). Internally we also have Durations.MIN, but it's not public ... and along with it, I left myself a helpful note about naming:
>> >>>
>> >>>   /** The minimum supported {@code Duration}, approximately -292 billion years. */
>> >>>   // Note: before making this constant public, consider that "MIN" might not be a great name (not
>> >>>   //       everyone knows that Durations can be negative!).
>> >>>   static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE);
>> >>>
>> >>> This reminds me of Double.MIN_VALUE (which is the smallest _positive_ double value) --- we've seen Double.MIN_VALUE misused so much that we introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias. A large percent of Double.MIN_VALUE users actually want the smallest possible negative value, aka -Double.MAX_VALUE.
>> >>>
>> >>> If we introduce Duration.MIN, I hope it would not be Duration.ofNanos(1), but rather Duration.ofSeconds(Long.MIN_VALUE).
>> >>>
>> >>> On Wed, Sep 3, 2025 at 7:59?PM ecki  wrote:
>> >>>>
>> >>>> If you ask me, I don?t find it very useful, It won?t work for arithmetrics, even the APIs would have a hard time using it (how do you express the deadline) and APIs with a timeout parameter do have a good reason for it, better pick ?possible? values for better self healing and unstuck of systems. In fact I would err on the smaller side in combination with expecting spurious wakeups.
>> >>>>
>> >>>> BTW, when you introduce MIN as well, maybe also think about min precision, min delta or such. Will it always be 1 nano?
>> >>>>
>> >>>> Gru?,
>> >>>> Bernd
>> >>>> --
>> >>>> https://bernd.eckenfels.net
>> >>>> ________________________________
>> >>>> Von: core-libs-dev  im Auftrag von Pavel Rappo 
>> >>>> Gesendet: Donnerstag, September 4, 2025 12:41 AM
>> >>>> An: Kurt Alfred Kluever 
>> >>>> Cc: Stephen Colebourne ; core-libs-dev 
>> >>>> Betreff: Re: Duration.MAX_VALUE
>> >>>>
>> >>>> This is useful; thanks. It would be good to see more of your data.
>> >>>>
>> >>>> My use case is also duration which practically means **forever**. I
>> >>>> pass it to methods that accept timeouts, and expect these methods to
>> >>>> correctly interpret it.
>> >>>>
>> >>>> One example of a practical interpretation is
>> >>>> java.util.concurrent.TimeUnit.convert(Duration). This method never
>> >>>> overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is
>> >>>> roughly 292 years.
>> >>>>
>> >>>> Would I be okay, if the proposed duration didn't reflect **forever**
>> >>>> but instead reflected **long enough**? I think so. But it still
>> >>>> somehow feels wrong to make it less than maximum representable value.
>> >>>>
>> >>>> Personally, I'm not interested in calendar arithmetic, that is, in
>> >>>> adding or subtracting durations. Others might be, and that's okay and
>> >>>> needs to be factored in. For better or worse, java.time made a choice
>> >>>> to be unforgiving in regard to overflow and is very upfront about it.
>> >>>> It's not only proposed Duration.MAX. The same thing happens if you try
>> >>>> this
>> >>>>
>> >>>> Instant.MAX.toEpochMilli()
>> >>>>
>> >>>> I guess my point is that doing calendar arithmetic on an unknown value
>> >>>> is probably wrong. Doing it on a known huge/edge-case value is surely
>> >>>> wrong. So back to your data. I would be interested to see what
>> >>>> triggers overflows for your Durations.MAX.
>> >>>>
>> >>>> On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever  wrote:
>> >>>> >
>> >>>> > Hi all,
>> >>>> >
>> >>>> > Internally at Google, we've had a Durations.MAX constant exposed for the past 7 years. It now has about 700 usages across our depot, which I can try to categorize (at a future date).
>> >>>> >
>> >>>> > While I haven't performed that analysis yet, I think exposing this constant was a bit of a mistake. People seem to want to use MAX to mean "forever" (often in regards to an RPC deadline). This works fine as long as every single layer that touches the deadline is very careful about overflow. The only reasonable thing you can do with MAX is compareTo() and equals(). Attempting to do any simple math operation (e.g., now+deadline) is going to explode. Additionally, decomposing Duration.MAX explodes for any sub-second precision (e.g., toMillis()).
>> >>>> >
>> >>>> > As we dug into this, another proposal came up which was something like Durations.VERY_LONG. This duration would be longer than any reasonable finite duration but not long enough to cause an overflow when added to any reasonable time. E.g., a million years would probably satisfy both criteria. This would mean math operations and decompositions won't explode (well, microseconds and nanoseconds still would), and it could safely be used as a relative timeout.
>> >>>> >
>> >>>> > As I mentioned above, I'd be happy to try to categorize a sample of our 700 existing usages if folks think that would be useful for this proposal.
>> >>>> >
>> >>>> > Thanks,
>> >>>> >
>> >>>> > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem team)
>> >>>> >
>> >>>> > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo  wrote:
>> >>>> >>
>> >>>> >> If I understood you correctly, you think we should also add
>> >>>> >> Duration.MIN. If so, what use case do you envision for it? Or we add
>> >>>> >> if purely for symmetry with Instant?
>> >>>> >>
>> >>>> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo  wrote:
>> >>>> >> >
>> >>>> >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne  wrote:
>> >>>> >> > >
>> >>>> >> > > Hmm, yes. Not sure why that didn't get added in Java 8!
>> >>>> >> > > The constants would be MAX/MIN as per classes like Instant.
>> >>>> >> > > Stephen
>> >>>> >> >
>> >>>> >> > I thought that naming could be tricky :) The public constant
>> >>>> >> > Duration.ZERO and the public method isZero() are already there.
>> >>>> >> > However, it does not preclude us from naming a new constant MAX.
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> > kak
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> kak
>> >>>
>> >>>

From rriggs at openjdk.org  Thu Oct  9 14:31:34 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 9 Oct 2025 14:31:34 GMT
Subject: RFR: 8368846: java/io/File/createTempFile/TargetDirectory fails
 when run by root user
In-Reply-To: 
References: 
Message-ID: <9wXjOCZsA2bMp3nHylHpKbm3mAIdydnzTqpv_AKjt_o=.998ba2ad-72c2-49b8-8087-3e6f8fb237b0@github.com>

On Mon, 29 Sep 2025 08:28:38 GMT, Francesco Andreuzzi  wrote:

> The test checks whether writing to a read-only directory throws a `IOException`. This test is not applicable when the user running the test is root. Thus, I propose to skip it.
> 
> I converted the class to several JUnit tests, so we can use `@DisabledIf`.

test/jdk/java/io/File/createTempFile/TargetDirectory.java line 66:

> 64: 
> 65:     @Test
> 66:     @DisabledIf("jdk.test.lib.Platform#isRoot")

This will silently skip the test.
Jtreg has a feature for keeping track of Skipped tests and reporting they were skipped.
Throwing SkippedException would enable that reporting.
Take a look at a similar test: `test/jdk/java/io/File/SetAccess.java`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27542#discussion_r2417007605

From kfarrell at openjdk.org  Thu Oct  9 15:26:45 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 9 Oct 2025 15:26:45 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v18]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 9 Oct 2025 13:00:59 GMT, Alan Bateman  wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove old test case reference
>
> src/java.base/share/classes/java/util/UUID.java line 210:
> 
>> 208:      *
>> 209:      * @spec https://www.rfc-editor.org/rfc/rfc9562.html
>> 210:      *       RFC 9562 Universally Unique IDentifiers (UUIDs)
> 
> The updated class description means the class now has a prominent link to RFC, so not sure about having another link here. If we are linking then can we link to ##name-uuid-version-7.

I'll remove the spec reference to align with the methods for other versions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2417121926

From bpb at openjdk.org  Thu Oct  9 15:35:24 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 9 Oct 2025 15:35:24 GMT
Subject: RFR: 8368846: java/io/File/createTempFile/TargetDirectory fails
 when run by root user
In-Reply-To: <9wXjOCZsA2bMp3nHylHpKbm3mAIdydnzTqpv_AKjt_o=.998ba2ad-72c2-49b8-8087-3e6f8fb237b0@github.com>
References: 
 <9wXjOCZsA2bMp3nHylHpKbm3mAIdydnzTqpv_AKjt_o=.998ba2ad-72c2-49b8-8087-3e6f8fb237b0@github.com>
Message-ID: 

On Thu, 9 Oct 2025 14:28:38 GMT, Roger Riggs  wrote:

> This will silently skip the test.

I ran the test as root and as my normal user. For the normal user one gets

STARTED    TargetDirectory::testReadOnlyDirectory 'testReadOnlyDirectory()'

whereas for root

SKIPPED    TargetDirectory::testReadOnlyDirectory 'testReadOnlyDirectory()' @DisabledIf("jdk.test.lib.Platform#isRoot") evaluated to true

which looked okay to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27542#discussion_r2417154078

From iris at openjdk.org  Thu Oct  9 15:54:33 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 9 Oct 2025 15:54:33 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein  wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27719#pullrequestreview-3319601046

From duke at openjdk.org  Thu Oct  9 16:11:02 2025
From: duke at openjdk.org (Bernd)
Date: Thu, 9 Oct 2025 16:11:02 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
Message-ID: <7FNQkL6cersUolPLQ1NViK0811Mx3AkaNzid3tQktbI=.2eaa33d4-8051-486a-b305-a5d4000948de@github.com>

On Wed, 8 Oct 2025 00:33:20 GMT, Xueming Shen  wrote:

>> ### 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 pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor api doc updates

src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 36:

> 34: 
> 35: /**
> 36:  * Utility class for {@code String.toCaseFold()} that handles Unicode case folding

Maybe make it clear this is a planned api (or not refer to it?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2417269101

From asemenyuk at openjdk.org  Thu Oct  9 16:12:48 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 9 Oct 2025 16:12:48 GMT
Subject: RFR: 8363979: Add JDK bundle/image validation for --runtime-image
 option [v2]
In-Reply-To: <4fwrSDJyOkBE9tWN_LQJcGK3EcAxomHrs0Qcc8veDpE=.9ba36680-ddc6-4189-ba99-30529abd269c@github.com>
References: <4fwrSDJyOkBE9tWN_LQJcGK3EcAxomHrs0Qcc8veDpE=.9ba36680-ddc6-4189-ba99-30529abd269c@github.com>
Message-ID: <6WkZUQzCVRt05oQdZalO4gNYsZ1Cd4NZU3Ox2KtnEuE=.a9bf0b85-325e-4706-aef4-fbf7d1240bf3@github.com>

> - Validate "libjli.dylib" file in the "lib" directory referenced with the `--runtime-image` option.
>  - Split "ERR_MissingJLinkOptMacAppStore" error key into "error.invalid-runtime-image-bin-dir" and "error.invalid-runtime-image-bin-dir.advice"; moved new keys to mac-specific string property file.
>  - Fix a couple of typos in RuntimeBuilderBuilder and WixSourceConverter classes.
> 
> Error messages:
> 
> Runtime image "ErrorTest/test.85b994e1/empty-runtime-image" is missing "lib/**/libjli.dylib" file
> 
> Runtime image "ErrorTest/test.05a7421a/invalid-runtime-bundle" is missing "Contents/Home/lib/**/libjli.dylib" file
> 
> Runtime image "/Users/alexeysemenyuk/jpackage-dev-runtime" should not contain "bin" folder
> Advice to fix: Use --strip-native-commands jlink option when generating runtime image used with --mac-app-store option

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

 - ErrorTest: better coverage
 - MacFromParams: Restore missing imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27701/files
  - new: https://git.openjdk.org/jdk/pull/27701/files/a48a3c18..a35bc119

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

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

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

From alanb at openjdk.org  Thu Oct  9 16:13:18 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Oct 2025 16:13:18 GMT
Subject: RFR: 8362123: ClassLoader Leak via
 Executors.newSingleThreadExecutor(...) [v2]
In-Reply-To: 
References: <_RSrJDqgl9UDaKCwPK31uetZp7TEzY4VzkC00P7TKaQ=.fca60c93-cae5-43db-879a-0b63cd2e5d77@github.com>
 
Message-ID: 

On Fri, 26 Sep 2025 16:42:49 GMT, Chris Dennis  wrote:

>> Executors shutdown via `shutdownNow()` should have their cleanables cleaned to prevent a classloader leak. This can happen if a classloader exists that both references the wrapped executor and is referenced by the delegate executor.
>> 
>> To quote @Martin-Buchholz:
>>> BTW: I find Cleaners much harder to use than old finalize, and it looks like I'm not the only one!
>
> Chris Dennis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8362123: ClassLoader Leak via Executors.newSingleThreadExecutor(...)
>   
>   Executors shutdown via `shutdownNow()` should have their cleanables cleaned to
>   prevent a classloader leak. This can happen if a classloader exists that both
>   references the wrapped executor and is referenced by the delegate executor.

Yes, you need to use "/integrate", and then one of us will sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/26296#issuecomment-3386513740

From asemenyuk at openjdk.org  Thu Oct  9 16:15:21 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 9 Oct 2025 16:15:21 GMT
Subject: RFR: 8363979: Add JDK bundle/image validation for --runtime-image
 option [v2]
In-Reply-To: 
References: <4fwrSDJyOkBE9tWN_LQJcGK3EcAxomHrs0Qcc8veDpE=.9ba36680-ddc6-4189-ba99-30529abd269c@github.com>
 
 
Message-ID: 

On Wed, 8 Oct 2025 22:55:46 GMT, Alexey Semenyuk  wrote:

>> test/jdk/tools/jpackage/share/ErrorTest.java line 102:
>> 
>>> 100:             return root.toString();
>>> 101:         })),
>>> 102:         EMPTY_DIR(toFunction(cmd -> {
>> 
>> It is good idea to test `EMPTY_DIR`, but I think we should test one with `lib` subdirectory and at least one file in it to cover all code paths.
>
> Agreed. I'll do that

New errors in ErrorTest:

Bundler Mac Application Image skipped because of a configuration problem: Runtime image "ErrorTest/test.f7b24e53/empty-dir" is missing "lib/**/libjli.dylib" file
Bundler Mac Application Image skipped because of a configuration problem: Runtime image "ErrorTest/test.05a7421a/mac-invalid-runtime-bundle" is missing "Contents/Home/lib/**/libjli.dylib" file
Bundler Mac Application Image skipped because of a configuration problem: Runtime image "ErrorTest/test.40e41dd5/mac-invalid-runtime-image" is missing "lib/**/libjli.dylib" file
Bundler Mac DMG Package skipped because of a configuration problem: Runtime image "ErrorTest/test.3902d173/empty-dir" is missing "lib/**/libjli.dylib" file
Bundler Mac DMG Package skipped because of a configuration problem: Runtime image "ErrorTest/test.c1f9053a/mac-invalid-runtime-bundle" is missing "Contents/Home/lib/**/libjli.dylib" file
Bundler Mac DMG Package skipped because of a configuration problem: Runtime image "ErrorTest/test.626020f5/mac-invalid-runtime-image" is missing "lib/**/libjli.dylib" file
Bundler Mac DMG Package skipped because of a configuration problem: Runtime image "ErrorTest/test.ad0f34dc/empty-dir" is missing "lib/**/libjli.dylib" file
Bundler Mac DMG Package skipped because of a configuration problem: Runtime image "ErrorTest/test.740392a3/mac-invalid-runtime-bundle" is missing "Contents/Home/lib/**/libjli.dylib" file
Bundler Mac DMG Package skipped because of a configuration problem: Runtime image "ErrorTest/test.b19ca05e/mac-invalid-runtime-image" is missing "lib/**/libjli.dylib" file

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27701#discussion_r2417284294

From duke at openjdk.org  Thu Oct  9 16:13:18 2025
From: duke at openjdk.org (Chris Dennis)
Date: Thu, 9 Oct 2025 16:13:18 GMT
Subject: RFR: 8362123: ClassLoader Leak via
 Executors.newSingleThreadExecutor(...) [v2]
In-Reply-To: 
References: <_RSrJDqgl9UDaKCwPK31uetZp7TEzY4VzkC00P7TKaQ=.fca60c93-cae5-43db-879a-0b63cd2e5d77@github.com>
 
Message-ID: 

On Fri, 26 Sep 2025 16:42:49 GMT, Chris Dennis  wrote:

>> Executors shutdown via `shutdownNow()` should have their cleanables cleaned to prevent a classloader leak. This can happen if a classloader exists that both references the wrapped executor and is referenced by the delegate executor.
>> 
>> To quote @Martin-Buchholz:
>>> BTW: I find Cleaners much harder to use than old finalize, and it looks like I'm not the only one!
>
> Chris Dennis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8362123: ClassLoader Leak via Executors.newSingleThreadExecutor(...)
>   
>   Executors shutdown via `shutdownNow()` should have their cleanables cleaned to
>   prevent a classloader leak. This can happen if a classloader exists that both
>   references the wrapped executor and is referenced by the delegate executor.

Apologies gentlemen, but do I need to do something to move this on? If I understand correctly it's just a `/integrate` command to the Skara machinery now, but I don't believe I have the permissions to trigger that?

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

PR Comment: https://git.openjdk.org/jdk/pull/26296#issuecomment-3382096547

From naoto at openjdk.org  Thu Oct  9 16:23:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 9 Oct 2025 16:23:51 GMT
Subject: Integrated: 8369184: SimpleTimeZone equals() Returns True for Unequal
 Instances with Different hashCode Values
In-Reply-To: 
References: 
Message-ID: 

On Mon, 6 Oct 2025 21:36:44 GMT, Naoto Sato  wrote:

> Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule.

This pull request has now been integrated.

Changeset: 37b725d9
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/37b725d9c12834358a562e6c03fb7f566d639ca5
Stats:     102 lines in 2 files changed: 94 ins; 0 del; 8 mod

8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values

Reviewed-by: prappo, jlu, rriggs, iris

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

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

From naoto at openjdk.org  Thu Oct  9 16:23:49 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 9 Oct 2025 16:23:49 GMT
Subject: RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal
 Instances with Different hashCode Values [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 8 Oct 2025 18:15:39 GMT, Naoto Sato  wrote:

>> Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27660#issuecomment-3386564567

From duke at openjdk.org  Thu Oct  9 16:25:39 2025
From: duke at openjdk.org (duke)
Date: Thu, 9 Oct 2025 16:25:39 GMT
Subject: RFR: 8362123: ClassLoader Leak via
 Executors.newSingleThreadExecutor(...) [v2]
In-Reply-To: 
References: <_RSrJDqgl9UDaKCwPK31uetZp7TEzY4VzkC00P7TKaQ=.fca60c93-cae5-43db-879a-0b63cd2e5d77@github.com>
 
Message-ID: 

On Fri, 26 Sep 2025 16:42:49 GMT, Chris Dennis  wrote:

>> Executors shutdown via `shutdownNow()` should have their cleanables cleaned to prevent a classloader leak. This can happen if a classloader exists that both references the wrapped executor and is referenced by the delegate executor.
>> 
>> To quote @Martin-Buchholz:
>>> BTW: I find Cleaners much harder to use than old finalize, and it looks like I'm not the only one!
>
> Chris Dennis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8362123: ClassLoader Leak via Executors.newSingleThreadExecutor(...)
>   
>   Executors shutdown via `shutdownNow()` should have their cleanables cleaned to
>   prevent a classloader leak. This can happen if a classloader exists that both
>   references the wrapped executor and is referenced by the delegate executor.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26296#issuecomment-3386579739

From kfarrell at openjdk.org  Thu Oct  9 17:13:23 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 9 Oct 2025 17:13:23 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v19]
In-Reply-To: 
References: 
Message-ID: 

> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
> 
> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
> 
> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
> 
> 
> - random-byte-only - 99.8%
> - higher-precision - 3.5%
> - counter-based - 0%
> 
> 
> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
> 
> - random-byte-only   143.487 ? 10.932  ns/op
> - higher-precision      149.651 ?  8.438 ns/op
> - counter-based         245.036 ?  2.943  ns/op
> 
> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.

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

  update spec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25303/files
  - new: https://git.openjdk.org/jdk/pull/25303/files/ae7e2f27..8bf7cf21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=17-18

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

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

From erikj at openjdk.org  Thu Oct  9 17:31:20 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Oct 2025 17:31:20 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein  wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27719#pullrequestreview-3319953574

From viktor.klang at oracle.com  Thu Oct  9 18:11:36 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 9 Oct 2025 18:11:36 +0000
Subject: [External] : Re: Question about mapConcurrent() Behavior and
 Happens-Before Guarantees
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
 
 
Message-ID: 

>Thanks again for patiently explaining the design rationale, Viktor!

You're most welcome, Jige!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

Confidential ? Oracle Internal
________________________________
From: Jige Yu 
Sent: Tuesday, 7 October 2025 03:25
To: Archie Cobbs 
Cc: Viktor Klang ; core-libs-dev at openjdk.org 
Subject: Re: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees

To put it into context, it came up from the discussion thread regarding the web crawler use case (still being discussed in "Problem report on the usage of Structured Concurrency").

The use case of crawled page spawning more urls to be further crawled would seem pretty trivial to implement using mapConcurrent():

int maxConcurrency = 10;
Set seen = new HashSet<>();
seen.add(root);
for (List toCrawl = List.of(root); toCrawl.size() > 0; ) {
  toCrawl = toCrawl.stream()
      .gather(mapConcurrent(maxConcurrency, url -> loadWebPage(url)))
      .flatMap(page -> page.getLinks().stream())
      .filter(seen::add)
      .toList();
}

It's a breadth-first traversal, where each round it crawls all remaining urls concurrently with a max concurrency.

The potential power of mapConcurrent() is very appealing to me. It can solve rather complicated concurrency problems elegantly.

And then someone brought it up that mapConcurrent() doesn't cancel when it should have. And it turned out not to be a cancellation issue, but about the missing fail-fast.

Just fwiw.

Thanks again for patiently explaining the design rationale, Viktor!


On Mon, Oct 6, 2025 at 8:41?AM Archie Cobbs > wrote:
Just a drive-by comment...

I agree with Victor about being careful about making any API/semantic changes. However, I also have a lot of sympathy for what is being asked for.

A common pattern is to want to say, "Try doing these N things in parallel; if any of them fails, just bail out - immediately cancel all of them and throw an exception".

In other words, in a particular scenario you are expecting perfection, and if anything less occurs, it's preferable to just completely give up. Trying to salvage it is not worth it.

So it would be nice if there were some parallel stream map() variant with those semantics (it could also preserve order, but that seems orthogonal).

-Archie

On Mon, Oct 6, 2025 at 9:59?AM Viktor Klang > wrote:
Hi Jige,

I'm not sure it's productive to discuss the in-order behavior of mapConcurrent() further, as it is specified to be in-order, so changing that would be an incompatible change regardless of whether the change itself would be beneficial or not.

For potential future Gatherer-implementations made available from the Gatherers class, there'd need to be new implementations made available which over time prove themselves to be candidates for inclusion (also taking into consideration everything which comes with contributing code to OpenJDK).

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

Confidential ? Oracle Internal
________________________________
From: Jige Yu >
Sent: Sunday, 5 October 2025 19:06
To: Viktor Klang >
Cc: core-libs-dev at openjdk.org >
Subject: Re: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees


Hi Viktor,

Thanks again for explaining the current in-order contract. While I understand the implementation is currently compliant with the Javadoc, I have a few additional concerns about the practical consequences of this delayed exception propagation.

Potential for Starvation

While in theory it's also a lack of fail fast, it may show up more like a starvation or system hangs in certain concurrent architectures.

Imagine a scenario where the virtual threads are consuming work items from a shared, blocking queue (like what's being discussed in the other thread, the virtual threads could themselves be producing data into the queue):

  1.  Task 3 successfully takes an item from the queue and then immediately fails with an exception, without producing any data into the queue.

  2.  Tasks 1 and 2 block on the queue to get their work items, indefinitely.

  3.  Because the exception from Task 3 is not propagated until Tasks 1 and 2 finish, the main thread or stream pipeline is blocked indefinitely if Tasks 1 or 2 hang.

  4.  The work item consumed by Task 3 is lost, and the system is effectively halted, as the failure isn't reported and cleanup/cancellation is delayed.

So, except performance hit; it creates stability and liveness issues.

________________________________

Ambiguity in Current Javadoc

Regarding the Javadoc, while I did read it, I found the lack of an explicit fail-fast guarantee and the precise timing of exception propagation to be subtle. The phrase, "If a result of the function is to be pushed downstream," seems to leave ample room for interpretation, and it was not immediately clear whether the lack of fail-fast was an intentional design choice versus a side effect of the in-order implementation. Clarifying this timing can probably improve the API's contract clarity.

________________________________

Re-evaluating the "In-Order" Contract

Apologies for circling back to the same "in-order" question that has already been discussed.

But from a usability perspective, I suggest we also bring the "in-order" contract itself up for discussion.

I believe that the issues we've identified?the potential for starvation/hanging and the earlier discussed concurrency throughput concerns?are significant, realistic downsides of requiring strict in-order processing. These drawbacks should be carefully weighed against the benefits of the "in-order" contract, especially for concurrent processing APIs intended for I/O-bound tasks where strict ordering often has minimal value compared to resilience and performance.

If it's a trade off between having in-order or fail-fast (but not both simultaneously), it may warrant some more consideration about which is more useful. Particularly, Java users have traditionally been educated that parallel streams don't necessarily retain encounter order.

Cheers,

On Sun, Oct 5, 2025 at 2:13?AM Viktor Klang > wrote:
Hi Jige,

Thanks for your question!

It is important to acknowledge that Gatherers.mapConcurrent() does not specify fail-fast behavior.

From https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)

"In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements."

This does not refer to failed tasks

"If a result of the function is to be pushed downstream but instead the function completed exceptionally then the corresponding exception will instead be rethrown by this method as an instance of RuntimeException, after which any remaining tasks are canceled."

Since mapConcurrent is in-order, "is to be pushed downstream" means that it is next in line.



Now, I'm not saying that fail-fast wouldn't be desirable behavior, but it would require research into how to implement it without breaking observable behavior.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

Confidential ? Oracle Internal
________________________________
From: Jige Yu >
Sent: Sunday, 5 October 2025 07:10
To: Viktor Klang >
Cc: core-libs-dev at openjdk.org >
Subject: Re: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees

Hi, Viktor.

I recently suggested mapConcurrent() for a concurrent web crawling use case. But I was presented with a test case that showed surprising results. Basically, the current behavior may look like mapConcurrent() doesn't fail fast, and doesn't cancel in-flight tasks when a task has already failed.

What actually happens in the following example is that the first two tasks are sleeping, while the 3rd task has already failed. But mapConcurrent() doesn't yet know that the 3rd task has failed until the first two tasks have successfully finished sleeping.

Here's the test case:


int work(int input) {

if (input <= 2) {

try {

IO.println(input + " sleeping ");

Thread.sleep(2000);

IO.println("Returning " + (input * 2));

return input * 2;

} catch (InterruptedException e) {

println("Interrupted!");

throw new RuntimeException(e);

}

} else {

IO.println(input + " Throwing");

throw new RuntimeException();

}

}


@Test public void mainTest() {

var start = System.currentTimeMillis();

try {

List results = Stream.of(1, 2, 3).gather(mapConcurrent(3, this::work)).toList();

println("Results = " + results);

} finally {

println("Took " + (System.currentTimeMillis() - start) + " ms");

}

}




On Mon, Jul 14, 2025 at 12:25?AM Viktor Klang > wrote:
Hi Jige,

The current behavior is what's currently achievable within the constraints of the Gatherer-model, if that changes in the future it would also mean that there could be stronger "guarantees" made.

In the mean time, the good news is that if you're not satisfied with the behavior offered by mapConcurrent()?you can create your own which does what you want it to do!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu >
Sent: Sunday, 13 July 2025 05:54
To: Viktor Klang >
Cc: core-libs-dev at openjdk.org >
Subject: Re: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees

Thanks for pressing on that, Viktor!

I think I was fooled by my quick-and-dirty test. As I tried to harden it, I failed to deduce consistent behavior about what parallel stream does when unchecked exceptions happen. And in fact, it seems like it does *not* interrupt pending threads (?).

With this in mind, do you consider this behavior of mapConcurrent() cancelling and joining the virtual threads on a best-effort basis acceptable trade-off?

I wonder then if it's even worth it for mapConcurrent() to try to join the threads at all? If it can sometimes join and sometimes not, why not just always fail fast? At least then you get consistent fail-fast behavior: if a thread fails to respond to interruption and hangs, the main thread would still be able to respond to the exception.

Cheers,



On Tue, Jul 8, 2025 at 2:34?AM Viktor Klang > wrote:
>I understand that explicit API contracts are what matters. My concern, however, is that even if the API contract explicitly states no happens-before guarantee upon an unchecked exception, this behavior would still be a significant deviation from established visibility standards in other JDK APIs.

Would you mind clariying exactly what you mean here?what happens-before completion/exception?

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Jige Yu >
Sent: Tuesday, 8 July 2025 04:26
To: Viktor Klang >
Cc: core-libs-dev at openjdk.org >
Subject: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees

Thanks for the quick reply, Viktor!

On Mon, Jul 7, 2025 at 2:35?AM Viktor Klang > wrote:
Hi Jige,

>Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a RuntimeException would be able to observe all side effects from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing to respond to interruption or responding slowly.

Unless explicitly stated in the API contract, no such guarantees should be presumed to exist.


I understand that explicit API contracts are what matters. My concern, however, is that even if the API contract explicitly states no happens-before guarantee upon an unchecked exception, this behavior would still be a significant deviation from established visibility standards in other JDK APIs.

For instance, both parallel streams and Future.get() provide a happens-before guarantee upon completion (or exceptional completion in the case of Future.get()). So users will most likely take it for granted. If mapConcurrent() were to not offer this, it would potentially be the first blocking JDK API that doesn't honor happens-before in such a scenario. This inconsistency would likely be surprising and potentially confusing to users who have come to expect this behavior in concurrent programming constructs within the JDK.


As for general resource-management in Stream, I have contemplated designs for Gatherer (and Collector) to be able to participate in the onClose actions, but there's a lot of ground to cover to ensure correct ordering and sufficiently-encompassing of cleanup action execution.


Yeah. I agree that hooking into onClose() could provide a more reliable mechanism for cleanup.

My primary concern though, is the change it imposes on the call-site contract. Requiring all users of mapConcurrent() to adopt a try-with-resources syntax, while ideal for correctness, introduces a burden and is more subject to users forgetting to do so, potentially leading to resource leaks.

My previously proposed collectingAndThen(toList(), list -> list.stream().gather(mapConcurrent())) idea, on the other hand, avoids this call-site contract change. Being a collector, it needs to first consume the input, similar to how most Collectors operate. So it might be a less intrusive path to ensure proper resource handling without altering usage patterns.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev > on behalf of Jige Yu >
Sent: Thursday, 3 July 2025 16:36
To: core-libs-dev at openjdk.org >
Subject: Question about mapConcurrent() Behavior and Happens-Before Guarantees


Hi JDK Core Devs,

I'm writing to you today with a question about the behavior of mapConcurrent() and its interaction with unchecked exceptions. I've been experimenting with the API and observed that mapConcurrent() blocks and joins all virtual threads upon an unchecked exception before propagating it.

Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a RuntimeException would be able to observe all side effects from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing to respond to interruption or responding slowly.

However, I've since realized that mapConcurrent() cannot fully guarantee a strong happens-before relationship when an unchecked exception occurs somewhere in the stream pipeline. While it can block and wait for exceptions thrown by the mapper function or downstream operations, it appears unable to intercept unchecked exceptions thrown by an upstream source.

Consider a scenario with two input elements: if the first element starts a virtual thread, and then the second element causes an unchecked exception from the upstream before reaching the gather() call, the virtual thread initiated by the first element would not be interrupted. This makes the "happens-before" guarantee quite nuanced in practice.

This brings me to my core questions:

  1.  Is providing a happens-before guarantee upon an unchecked exception a design goal for mapConcurrent()?

  2.  If not, would it be more desirable to not join on virtual threads when unchecked exceptions occur? This would allow the application code to catch the exception sooner and avoid the risk of being blocked indefinitely.

Thank you for your time and insights.

Best regards,

Ben Yu


--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jlu at openjdk.org  Thu Oct  9 18:19:13 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 9 Oct 2025 18:19:13 GMT
Subject: RFR: 8369452: Locale.Builder.setLanguageTag(String) does not clear on
 empty or null String
Message-ID: 

Please review this PR which corrects the behavior of `Locale.Builder.setLanguageTag(String)` on the null and empty String case.

> Null and the empty string cause the builder to be reset

Currently, NPE is thrown for a null tag, and ILE is thrown for an empty String. They are both corrected to not throw, and instead reset the state of the `Locale.Builder`.

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

Commit messages:
 - The fix and reg test

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

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

From henryjen at openjdk.org  Thu Oct  9 18:31:09 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 9 Oct 2025 18:31:09 GMT
Subject: RFR: 8347007: --strip-debug removes parameter names included with
 -parameters [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 9 Oct 2025 13:50:23 GMT, Alan Bateman  wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   MethodParameters attribute should not be removed
>
> test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 67:
> 
>> 65:     private static List testJmods = new ArrayList<>();
>> 66: 
>> 67:     record Jmod(Path moduleDir, boolean withDebugInfo, boolean withParameterNames) {}
> 
> Is the withDebugInfo component used?

Not at this point, as we don't try to verify debug info simply because we have that covered in StripJavaDebugAttributesPluginTest.java.
I can remove it if we like, it describes how the jmod was built.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2417625517

From prappo at openjdk.org  Thu Oct  9 19:37:21 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 Oct 2025 19:37:21 GMT
Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to
 Instant [v7]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Thu, 9 Oct 2025 14:15:23 GMT, Roger Riggs  wrote:

> As specified and implemented, `Duration.plus(long amount, TemporalUnit)` does not make an exception for amount == 0. For any other value of month or years, the value is an estimate and the exception is thrown. It might be useful to consider a change (as a separate enhancement)

I'm not sure that I completely understand what you are saying. Are you saying that a zero of any unit is still zero and, if added, could result in the initial instant rather than throw an exception if the unit is "incompatible" with `Instant`?

If so, then it reminds me of the following problem: should an unmodifiable set allow to delete an element which it does not contain? Different APIs decide differently. For example, this throws an exception:

    Set.of().remove(1)

Whereas this doesn't:

    Collections.emptySet().remove(1)

I don't know java.time deeply enough to lean one way or the other. But my gut feeling tells me that unconditional exception is easier to reason about and is more reliable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2417776606

From henryjen at openjdk.org  Thu Oct  9 21:00:04 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 9 Oct 2025 21:00:04 GMT
Subject: RFR: 8347007: --strip-debug removes parameter names included with
 -parameters [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <-5j7DN17I5Ub252kgIKAvZpQD4pJxUhtIWVy_NkKuwM=.6619ffd9-4359-4c6e-9d69-0d49afb0474a@github.com>

On Thu, 9 Oct 2025 13:42:38 GMT, Alan Bateman  wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   MethodParameters attribute should not be removed
>
> test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 189:
> 
>> 187:         Process process = processBuilder.start();
>> 188:         int exitCode = process.waitFor();
>> 189:         var output = process.inputReader().readLine();
> 
> Have you looked into using  jdk.test.lib.process.ProcessTools?

What do you recommend? Since I don't need complex processing of output, so I just did this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2417943352

From almatvee at openjdk.org  Thu Oct  9 21:24:26 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 9 Oct 2025 21:24:26 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts [v15]
In-Reply-To: 
References: 
Message-ID: <9iCNWkHyvQY7OCKpPoszK2J56uRnZThdgNEsTlDSoV4=.3623dc7f-3aa6-4a48-8da3-15a349ff8129@github.com>

> - Removed pre- and post- installation PKG scripts.
> - This code is not needed and PKG should create destination folder and set correct permissions.
> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
> - Users will have ability to provide pre- and post- installation PKG scripts if needed.
> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`.
> - I think code in these scripts are some legacy leftovers.
> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`.

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

  8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v13]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25510/files
  - new: https://git.openjdk.org/jdk/pull/25510/files/074feedd..13a95a5b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=13-14

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

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

From almatvee at openjdk.org  Thu Oct  9 21:24:28 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 9 Oct 2025 21:24:28 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts [v14]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Oct 2025 03:01:01 GMT, Alexander Matveev  wrote:

>> - Removed pre- and post- installation PKG scripts.
>> - This code is not needed and PKG should create destination folder and set correct permissions.
>> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
>> - Users will have ability to provide pre- and post- installation PKG scripts if needed.
>> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`.
>> - I think code in these scripts are some legacy leftovers.
>> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v12]

8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v13]
- Fixed issue when the response files were written in the resource directory instead of the response directory.

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

PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-3387526036

From asemenyuk at openjdk.org  Thu Oct  9 21:28:18 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 9 Oct 2025 21:28:18 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts [v15]
In-Reply-To: <9iCNWkHyvQY7OCKpPoszK2J56uRnZThdgNEsTlDSoV4=.3623dc7f-3aa6-4a48-8da3-15a349ff8129@github.com>
References: 
 <9iCNWkHyvQY7OCKpPoszK2J56uRnZThdgNEsTlDSoV4=.3623dc7f-3aa6-4a48-8da3-15a349ff8129@github.com>
Message-ID: <7JlYYq1o7yvW5QO_Gd241j79cDJgxe_P-XvKBYkQku8=.eea8f203-dc55-47f8-ae7b-34dcc41f0387@github.com>

On Thu, 9 Oct 2025 21:24:26 GMT, Alexander Matveev  wrote:

>> - Removed pre- and post- installation PKG scripts.
>> - This code is not needed and PKG should create destination folder and set correct permissions.
>> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
>> - Users will have ability to provide pre- and post- installation PKG scripts if needed.
>> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`.
>> - I think code in these scripts are some legacy leftovers.
>> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v13]

Marked as reviewed by asemenyuk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25510#pullrequestreview-3320693612

From asemenyuk at openjdk.org  Thu Oct  9 21:31:14 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 9 Oct 2025 21:31:14 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts [v15]
In-Reply-To: <9iCNWkHyvQY7OCKpPoszK2J56uRnZThdgNEsTlDSoV4=.3623dc7f-3aa6-4a48-8da3-15a349ff8129@github.com>
References: 
 <9iCNWkHyvQY7OCKpPoszK2J56uRnZThdgNEsTlDSoV4=.3623dc7f-3aa6-4a48-8da3-15a349ff8129@github.com>
Message-ID: <40HRct5sWtXP_EOStyMJp-Qi34eUdwwdV9yWoO0Su34=.d0f6b74d-5862-4584-8ed0-d6003e8ca7fc@github.com>

On Thu, 9 Oct 2025 21:24:26 GMT, Alexander Matveev  wrote:

>> - Removed pre- and post- installation PKG scripts.
>> - This code is not needed and PKG should create destination folder and set correct permissions.
>> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
>> - Users will have ability to provide pre- and post- installation PKG scripts if needed.
>> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`.
>> - I think code in these scripts are some legacy leftovers.
>> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v13]

Looks good. Thank you for making an effort and getting it done right ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-3387545096

From sherman at openjdk.org  Thu Oct  9 21:32:44 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Thu, 9 Oct 2025 21:32:44 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v3]
In-Reply-To: 
References: 
Message-ID: <65RNNXEOnusNW3cpiBPFEe-rTEktFj10ZPUHN0HIFIo=.a6b3e784-93b1-482a-ab7d-b9403bd04211@github.com>

> ### Background
> 
> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
> 
> ### Problem
> 
> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
> 
> ### Solution
> 
> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
> 
> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
> 
> ### Benchmark
> 
> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
> 
> **Before:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
> 
> 
> **After:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  9002.842 ? 1099.635  ns/op
> Finished running test 'mi...

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

  update the test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27569/files
  - new: https://git.openjdk.org/jdk/pull/27569/files/c7cb474f..23ada406

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

  Stats: 84 lines in 1 file changed: 62 ins; 11 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27569/head:pull/27569

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

From prappo at openjdk.org  Thu Oct  9 21:36:01 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 Oct 2025 21:36:01 GMT
Subject: RFR: 8366829: Add java.time.Duration constants MIN and MAX [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 8 Oct 2025 20:13:50 GMT, Roger Riggs  wrote:

> As proposed. Duration.MAX() is not the negated value of Duration.MIN. Is there any value for them to have that mathematical property? Duration.MIN can not be negated, it throws "Exceeds capacity of Duration".

To future readers: initially this question was asked in [another PR][], and then I forwarded it to this [mailing list discussion][].

[another PR]: https://github.com/openjdk/jdk/pull/27549#discussion_r2414774950
[mailing list discussion]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-October/153062.html

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

PR Comment: https://git.openjdk.org/jdk/pull/27534#issuecomment-3387557653

From sherman at openjdk.org  Thu Oct  9 21:37:05 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Thu, 9 Oct 2025 21:37:05 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v2]
In-Reply-To: 
References: 
 <9gqy4YltBipAT7BuMq-_bhUKHmoQpOjKQIKZHeAv9pI=.f6daabd3-e323-48b2-8a4b-038e1f48b641@github.com>
 
 
 
Message-ID: 

On Wed, 8 Oct 2025 05:11:12 GMT, Alan Bateman  wrote:

>> --add-opens java.base/java.lang=ALL-UNNAMED is for the reflective access to "defineClass" of the platform classloader. any better alternative to test the platform classloader's defineClass behavior other than the reflect api? 
>> 
>> 
>>             Method m = ClassLoader.class.getDeclaredMethod(
>>                     "defineClass", String.class, ByteBuffer.class, ProtectionDomain.class
>>             );
>>             m.setAccessible(true);
>>             Class clazz = (Class) m.invoke(builtin, null, bb, null);
>> 
>> 
>> The dup  @run lines are the workaround to test the platform classloader's defineClass on the same target test class  class twice, one for the direct bb, one for the heap bb (with 2 separate vm runs). Otherwise the test fails with "java.lang.LinkageError: loader 'platform' attempted duplicate class definition for Greeting."
>> 
>> Does ParameterizedTest support vm/platform classloader isolation for each parameterized test run against the same test with different parameters?
>
>> Does ParameterizedTest support vm/platform classloader isolation for each parameterized test run against the same test with different parameters?
> 
> I should have been clearer in my comment. The suggestion to use a ParameterizedTest is to exercise a custom class loader using super.defineClass with different buffers (direct, heap, position != 0, ...) so that it exercises the "non-trusted" cases.
> 
> You are right that testing the platform class loader (as a trusted class loader) will require opening java.lang.

The test case has been updated to use @ParameterizedTest for the user-defined classloader, for the following variants.


    static Stream bufferTypes() {
        return Stream.of(
                arguments(ARRAY_BUFFER, 0, false),
                arguments(ARRAY_BUFFER_READONLY, 0, true),
                arguments(DIRECT_BUFFER, 0, false),
                arguments(DIRECT_BUFFER_READONLY, 0, false),
                arguments(ARRAY_BUFFER, 16, false),
                arguments(ARRAY_BUFFER_READONLY, 16, true),
                arguments(DIRECT_BUFFER, 16, false),
                arguments(DIRECT_BUFFER_READONLY, 16, false)
        );
    }


I keep the built-in classloader testing asis in the same test file for now. Let me know if you have a strong opinion to split it out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2418010283

From almatvee at openjdk.org  Thu Oct  9 21:49:19 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 9 Oct 2025 21:49:19 GMT
Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v7]
In-Reply-To: 
References: 
Message-ID: 

> - Added test for custom info plist to cover app image including embedded runtime and runtime installer.
> - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string.

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

  8362598: [macos] Add tests for custom info plist files [v7]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27509/files
  - new: https://git.openjdk.org/jdk/pull/27509/files/a8fff653..3e49eb72

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

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

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

From almatvee at openjdk.org  Thu Oct  9 21:49:20 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 9 Oct 2025 21:49:20 GMT
Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Oct 2025 01:54:42 GMT, Alexander Matveev  wrote:

>> - Added test for custom info plist to cover app image including embedded runtime and runtime installer.
>> - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362598: [macos] Add tests for custom info plist files [v6]

8362598: [macos] Add tests for custom info plist files [v7]
- Move PListWriter to the shared code.

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

PR Comment: https://git.openjdk.org/jdk/pull/27509#issuecomment-3387583326

From henryjen at openjdk.org  Thu Oct  9 22:10:23 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 9 Oct 2025 22:10:23 GMT
Subject: RFR: 8347007: --strip-debug removes parameter names included with
 -parameters [v4]
In-Reply-To: 
References: 
Message-ID: 

> Since parameters is an opt-in choice, it's more reasonable to consider that's desired information and make strip parameter names an opt-in choice as well.
> 
> This PR changes the default behavior of --strip-debug to keep parameter names when it's available. Add opt-in mechanism,
> via the strip-java-debug-attributes plugin by using argument `--strip-java-debug-attributes=+parameter-names`.
> 
> The --strip-debug option is a little bit odd, as it's a main option as well as a plugin option to enable the DefaultStripDebugPlugin, which strip native debug information on platform support the feature, and strip java debug information. In this PR, we chose to support only one mechanism to enable strip parameter names, so we would disable the embed StripJavaDebugAttributesPlugin when StripJavaDebugAttributesPlugin is enabled.
> 
> The StripParameterNamesTest illustrate and verify parameter names use cases, mainly focus on argument processing and the parameter names. We didn't verify the regular debug info as that's covered by existing test.
> 
> -- Update
> 
> The latest change removed the support of strip parameter names, as the MethodParameters attribute is considered necessary attribute to fulfill Java Language Spec even though this attribute is considered optional by JVM spec.

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

  Address review feedbacks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27566/files
  - new: https://git.openjdk.org/jdk/pull/27566/files/766dc01e..e18577cb

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

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

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

From asemenyuk at openjdk.org  Thu Oct  9 22:38:04 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 9 Oct 2025 22:38:04 GMT
Subject: RFR: 8362598: [macos] Add tests for custom info plist files [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Oct 2025 21:49:19 GMT, Alexander Matveev  wrote:

>> - Added test for custom info plist to cover app image including embedded runtime and runtime installer.
>> - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362598: [macos] Add tests for custom info plist files [v7]

Marked as reviewed by asemenyuk (Reviewer).

Looks good. Thank you!

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

PR Review: https://git.openjdk.org/jdk/pull/27509#pullrequestreview-3320832538
PR Comment: https://git.openjdk.org/jdk/pull/27509#issuecomment-3387690495

From duke at openjdk.org  Thu Oct  9 23:07:15 2025
From: duke at openjdk.org (duke)
Date: Thu, 9 Oct 2025 23:07:15 GMT
Subject: Withdrawn: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases
In-Reply-To: 
References: 
Message-ID: <07J09pr3IpSfp75CIF5fr6X-QWe7aFUjdA0TLV-M2Ss=.83b7b04c-2cca-471d-81ca-3160f0edda77@github.com>

On Tue, 10 Jun 2025 09:01:17 GMT, Per Minborg  wrote:

> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.

This pull request has been closed without being integrated.

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

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

From naoto at openjdk.org  Thu Oct  9 23:30:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 9 Oct 2025 23:30:01 GMT
Subject: RFR: 8369452: Locale.Builder.setLanguageTag(String) does not clear
 on empty or null String
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Oct 2025 18:12:58 GMT, Justin Lu  wrote:

> Please review this PR which corrects the behavior of `Locale.Builder.setLanguageTag(String)` on the null and empty String case.
> 
> This method is specified as follows,
> 
>> Null and the empty string cause the builder to be reset
> 
> Currently, NPE is thrown for a null tag, and ILE is thrown for an empty String. They are both corrected to not throw, and instead reset the state of the `Locale.Builder`.

LGTM

test/jdk/java/util/Locale/LocaleEnhanceTest.java line 779:

> 777:         bldr.setLanguageTag("en-US");
> 778:         assertDoesNotThrow(() -> bldr.setLanguageTag(tag));
> 779:         assertEquals(tag + " did not clear the builder", empty.build(), bldr.build());

Should not happen, but if empty string caused an assertion failure, the error message starts with " did not clear..."

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27734#pullrequestreview-3320916918
PR Review Comment: https://git.openjdk.org/jdk/pull/27734#discussion_r2418168857

From jlu at openjdk.org  Thu Oct  9 23:42:39 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 9 Oct 2025 23:42:39 GMT
Subject: RFR: 8369452: Locale.Builder.setLanguageTag(String) does not clear
 on empty or null String [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which corrects the behavior of `Locale.Builder.setLanguageTag(String)` on the null and empty String case.
> 
> This method is specified as follows,
> 
>> Null and the empty string cause the builder to be reset
> 
> Currently, NPE is thrown for a null tag, and ILE is thrown for an empty String. They are both corrected to not throw, and instead reset the state of the `Locale.Builder`.

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

  Naoto's comment - improve err msg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27734/files
  - new: https://git.openjdk.org/jdk/pull/27734/files/68bb29a1..fa385c8a

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

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

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

From jlu at openjdk.org  Thu Oct  9 23:42:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 9 Oct 2025 23:42:40 GMT
Subject: RFR: 8369452: Locale.Builder.setLanguageTag(String) does not clear
 on empty or null String [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Oct 2025 23:27:06 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naoto's comment - improve err msg
>
> test/jdk/java/util/Locale/LocaleEnhanceTest.java line 779:
> 
>> 777:         bldr.setLanguageTag("en-US");
>> 778:         assertDoesNotThrow(() -> bldr.setLanguageTag(tag));
>> 779:         assertEquals(tag + " did not clear the builder", empty.build(), bldr.build());
> 
> Should not happen, but if empty string caused an assertion failure, the error message starts with " did not clear..."

Good point, updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27734#discussion_r2418189274

From fandreuzzi at openjdk.org  Fri Oct 10 00:42:38 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 10 Oct 2025 00:42:38 GMT
Subject: RFR: 8368846: java/io/File/createTempFile/TargetDirectory fails
 when run by root user [v2]
In-Reply-To: 
References: 
Message-ID: 

> The test checks whether writing to a read-only directory throws a `IOException`. This test is not applicable when the user running the test is root. Thus, I propose to skip it.
> 
> I converted the class to several JUnit tests, so we can use `@DisabledIf`.

Francesco Andreuzzi 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:

 - review
 - Merge branch 'master' into JDK-8368846
 - nn
 - cc
 - convert to junit and skip

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27542/files
  - new: https://git.openjdk.org/jdk/pull/27542/files/1a0b5065..8b828646

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

  Stats: 16358 lines in 642 files changed: 9600 ins; 3265 del; 3493 mod
  Patch: https://git.openjdk.org/jdk/pull/27542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27542/head:pull/27542

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

From fandreuzzi at openjdk.org  Fri Oct 10 00:42:41 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 10 Oct 2025 00:42:41 GMT
Subject: RFR: 8368846: java/io/File/createTempFile/TargetDirectory fails
 when run by root user [v2]
In-Reply-To: <1J8-L6ZXcFwa8r3miMPKsvMk-6i9JXysqafYvvD463Y=.68becf72-0d8b-4d2c-8243-34f9cde7459f@github.com>
References: 
 <1J8-L6ZXcFwa8r3miMPKsvMk-6i9JXysqafYvvD463Y=.68becf72-0d8b-4d2c-8243-34f9cde7459f@github.com>
Message-ID: <1xEsfSo9QYHVtX3m-UMhHGa25NfpZB9ZZkZWoN5iBg4=.c4ea943f-c449-4158-a741-7814861b162b@github.com>

On Wed, 8 Oct 2025 23:26:41 GMT, Brian Burkhalter  wrote:

>> Francesco Andreuzzi 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:
>> 
>>  - review
>>  - Merge branch 'master' into JDK-8368846
>>  - nn
>>  - cc
>>  - convert to junit and skip
>
> test/jdk/java/io/File/createTempFile/TargetDirectory.java line 29:
> 
>> 27:  * @summary Verify directory parameter behavior in File.createTempFile(String,String,File)
>> 28:  * @library /test/lib
>> 29:  * @run junit/othervm TargetDirectory
> 
> Is `othervm` needed here?

Not really, fixed

> test/jdk/java/io/File/createTempFile/TargetDirectory.java line 50:
> 
>> 48: import jdk.test.lib.Platform;
>> 49: 
>> 50: import static org.junit.jupiter.api.Assertions.*;
> 
> I think you can dispense with the wild card at line 50 by doing:
> 
> import static org.junit.jupiter.api.Assertions.assertThrows;
> import static org.junit.jupiter.api.Assertions.assertTrue;

Fixed

> test/jdk/java/io/File/createTempFile/TargetDirectory.java line 54:
> 
>> 52: class TargetDirectory {
>> 53: 
>> 54:     @TempDir
> 
> In my testing I saw this output for each of the four sub-tests:
> 
> INFO: Skipping cleanup of temp dir [...] for field TargetDirectory.tempDir due to CleanupMode.NEVER.
> 
> Should this have `CleanupMode.ALWAYS`? In the old version of the test there were explcit calls to `File.delete`.

Fixed, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27542#discussion_r2418247261
PR Review Comment: https://git.openjdk.org/jdk/pull/27542#discussion_r2418248157
PR Review Comment: https://git.openjdk.org/jdk/pull/27542#discussion_r2418248031

From bpb at openjdk.org  Fri Oct 10 01:02:12 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Oct 2025 01:02:12 GMT
Subject: RFR: 8368846: java/io/File/createTempFile/TargetDirectory fails
 when run by root user [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 10 Oct 2025 00:42:38 GMT, Francesco Andreuzzi  wrote:

>> The test checks whether writing to a read-only directory throws a `IOException`. This test is not applicable when the user running the test is root. Thus, I propose to skip it.
>> 
>> I converted the class to several JUnit tests, so we can use `@DisabledIf`.
>
> Francesco Andreuzzi 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:
> 
>  - review
>  - Merge branch 'master' into JDK-8368846
>  - nn
>  - cc
>  - convert to junit and skip

Looks good now.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27542#pullrequestreview-3321037364

From almatvee at openjdk.org  Fri Oct 10 01:14:22 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 10 Oct 2025 01:14:22 GMT
Subject: Integrated: 8356047: [macos] jpackage produces confusing post- and
 pre- installation PKG scripts
In-Reply-To: 
References: 
Message-ID: 

On Wed, 28 May 2025 19:32:47 GMT, Alexander Matveev  wrote:

> - Removed pre- and post- installation PKG scripts.
> - This code is not needed and PKG should create destination folder and set correct permissions.
> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
> - Users will have ability to provide pre- and post- installation PKG scripts if needed.
> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$2` argument in scripts is same as `INSTALL_LOCATION`.
> - I think code in these scripts are some legacy leftovers.
> - Added test to test that pre- and post-scripts are no longer exist and can be added via `--resource-dir`.

This pull request has now been integrated.

Changeset: 1873b459
Author:    Alexander Matveev 
URL:       https://git.openjdk.org/jdk/commit/1873b4594883758a5c8b4094f49dfea36c7c0145
Stats:     309 lines in 9 files changed: 246 ins; 26 del; 37 mod

8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts

Reviewed-by: asemenyuk

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

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

From almatvee at openjdk.org  Fri Oct 10 01:14:17 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 10 Oct 2025 01:14:17 GMT
Subject: Integrated: 8362598: [macos] Add tests for custom info plist files
In-Reply-To: 
References: 
Message-ID: 

On Fri, 26 Sep 2025 02:54:32 GMT, Alexander Matveev  wrote:

> - Added test for custom info plist to cover app image including embedded runtime and runtime installer.
> - Fixed bug in `writePList`. It was missing `writeStartDocument()/writeEndDocument()` and `DOCTYPE` should be full xml string.

This pull request has now been integrated.

Changeset: 52b02eda
Author:    Alexander Matveev 
URL:       https://git.openjdk.org/jdk/commit/52b02edaba55920c44b9aba6a9db53d8c9ae9292
Stats:     803 lines in 8 files changed: 722 ins; 64 del; 17 mod

8362598: [macos] Add tests for custom info plist files

Reviewed-by: asemenyuk

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

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

From almatvee at openjdk.org  Fri Oct 10 01:11:08 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 10 Oct 2025 01:11:08 GMT
Subject: RFR: 8363979: Add JDK bundle/image validation for --runtime-image
 option [v2]
In-Reply-To: <6WkZUQzCVRt05oQdZalO4gNYsZ1Cd4NZU3Ox2KtnEuE=.a9bf0b85-325e-4706-aef4-fbf7d1240bf3@github.com>
References: <4fwrSDJyOkBE9tWN_LQJcGK3EcAxomHrs0Qcc8veDpE=.9ba36680-ddc6-4189-ba99-30529abd269c@github.com>
 <6WkZUQzCVRt05oQdZalO4gNYsZ1Cd4NZU3Ox2KtnEuE=.a9bf0b85-325e-4706-aef4-fbf7d1240bf3@github.com>
Message-ID: <3FwmYczYikZrfgT5LGI1P3er1Y1mD_nylo51bXxtuLM=.72eb3bf5-8d2c-4b87-97bb-8d6689023384@github.com>

On Thu, 9 Oct 2025 16:12:48 GMT, Alexey Semenyuk  wrote:

>> - Validate "libjli.dylib" file in the "lib" directory referenced with the `--runtime-image` option.
>>  - Split "ERR_MissingJLinkOptMacAppStore" error key into "error.invalid-runtime-image-bin-dir" and "error.invalid-runtime-image-bin-dir.advice"; moved new keys to mac-specific string property file.
>>  - Fix a couple of typos in RuntimeBuilderBuilder and WixSourceConverter classes.
>> 
>> Error messages:
>> 
>> Runtime image "ErrorTest/test.85b994e1/empty-runtime-image" is missing "lib/**/libjli.dylib" file
>> 
>> Runtime image "ErrorTest/test.05a7421a/invalid-runtime-bundle" is missing "Contents/Home/lib/**/libjli.dylib" file
>> 
>> Runtime image "/Users/alexeysemenyuk/jpackage-dev-runtime" should not contain "bin" folder
>> Advice to fix: Use --strip-native-commands jlink option when generating runtime image used with --mac-app-store option
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - ErrorTest: better coverage
>  - MacFromParams: Restore missing imports

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27701#pullrequestreview-3321053815

From asemenyuk at openjdk.org  Fri Oct 10 02:45:11 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 10 Oct 2025 02:45:11 GMT
Subject: Integrated: 8363979: Add JDK bundle/image validation for
 --runtime-image option
In-Reply-To: <4fwrSDJyOkBE9tWN_LQJcGK3EcAxomHrs0Qcc8veDpE=.9ba36680-ddc6-4189-ba99-30529abd269c@github.com>
References: <4fwrSDJyOkBE9tWN_LQJcGK3EcAxomHrs0Qcc8veDpE=.9ba36680-ddc6-4189-ba99-30529abd269c@github.com>
Message-ID: 

On Wed, 8 Oct 2025 17:51:59 GMT, Alexey Semenyuk  wrote:

> - Validate "libjli.dylib" file in the "lib" directory referenced with the `--runtime-image` option.
>  - Split "ERR_MissingJLinkOptMacAppStore" error key into "error.invalid-runtime-image-bin-dir" and "error.invalid-runtime-image-bin-dir.advice"; moved new keys to mac-specific string property file.
>  - Fix a couple of typos in RuntimeBuilderBuilder and WixSourceConverter classes.
> 
> Error messages:
> 
> Runtime image "ErrorTest/test.85b994e1/empty-runtime-image" is missing "lib/**/libjli.dylib" file
> 
> Runtime image "ErrorTest/test.05a7421a/invalid-runtime-bundle" is missing "Contents/Home/lib/**/libjli.dylib" file
> 
> Runtime image "/Users/alexeysemenyuk/jpackage-dev-runtime" should not contain "bin" folder
> Advice to fix: Use --strip-native-commands jlink option when generating runtime image used with --mac-app-store option

This pull request has now been integrated.

Changeset: 2311ec39
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/2311ec394df9a096d6f7cd52b65ae2660dfe20b4
Stats:     196 lines in 10 files changed: 155 ins; 29 del; 12 mod

8363979: Add JDK bundle/image validation for --runtime-image option

Reviewed-by: almatvee

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

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

From fandreuzzi at openjdk.org  Fri Oct 10 07:53:07 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 10 Oct 2025 07:53:07 GMT
Subject: RFR: 8368846: java/io/File/createTempFile/TargetDirectory fails
 when run by root user [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 10 Oct 2025 00:42:38 GMT, Francesco Andreuzzi  wrote:

>> The test checks whether writing to a read-only directory throws a `IOException`. This test is not applicable when the user running the test is root. Thus, I propose to skip it.
>> 
>> I converted the class to several JUnit tests, so we can use `@DisabledIf`.
>
> Francesco Andreuzzi 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:
> 
>  - review
>  - Merge branch 'master' into JDK-8368846
>  - nn
>  - cc
>  - convert to junit and skip

Thanks for the review @RogerRiggs and @bplb.

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

PR Comment: https://git.openjdk.org/jdk/pull/27542#issuecomment-3388703414

From duke at openjdk.org  Fri Oct 10 07:53:08 2025
From: duke at openjdk.org (duke)
Date: Fri, 10 Oct 2025 07:53:08 GMT
Subject: RFR: 8368846: java/io/File/createTempFile/TargetDirectory fails
 when run by root user [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 10 Oct 2025 00:42:38 GMT, Francesco Andreuzzi  wrote:

>> The test checks whether writing to a read-only directory throws a `IOException`. This test is not applicable when the user running the test is root. Thus, I propose to skip it.
>> 
>> I converted the class to several JUnit tests, so we can use `@DisabledIf`.
>
> Francesco Andreuzzi 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:
> 
>  - review
>  - Merge branch 'master' into JDK-8368846
>  - nn
>  - cc
>  - convert to junit and skip

@fandreuz 
Your change (at version 8b828646634f231d6941a665cf7762c63b2f117b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27542#issuecomment-3388707811

From duke at openjdk.org  Fri Oct 10 09:23:24 2025
From: duke at openjdk.org (Chris Dennis)
Date: Fri, 10 Oct 2025 09:23:24 GMT
Subject: Integrated: 8362123: ClassLoader Leak via
 Executors.newSingleThreadExecutor(...)
In-Reply-To: <_RSrJDqgl9UDaKCwPK31uetZp7TEzY4VzkC00P7TKaQ=.fca60c93-cae5-43db-879a-0b63cd2e5d77@github.com>
References: <_RSrJDqgl9UDaKCwPK31uetZp7TEzY4VzkC00P7TKaQ=.fca60c93-cae5-43db-879a-0b63cd2e5d77@github.com>
Message-ID: 

On Mon, 14 Jul 2025 15:49:04 GMT, Chris Dennis  wrote:

> Executors shutdown via `shutdownNow()` should have their cleanables cleaned to prevent a classloader leak. This can happen if a classloader exists that both references the wrapped executor and is referenced by the delegate executor.
> 
> To quote @Martin-Buchholz:
>> BTW: I find Cleaners much harder to use than old finalize, and it looks like I'm not the only one!

This pull request has now been integrated.

Changeset: d5a20799
Author:    Chris Dennis 
Committer: Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/d5a207994b9c374e6638e57826326f8f4593b96b
Stats:     65 lines in 2 files changed: 63 ins; 1 del; 1 mod

8362123: ClassLoader Leak via Executors.newSingleThreadExecutor(...)

Reviewed-by: vklang, alanb

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

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

From alanb at openjdk.org  Fri Oct 10 10:51:16 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Oct 2025 10:51:16 GMT
Subject: RFR: 8347007: --strip-debug removes parameter names included with
 -parameters [v4]
In-Reply-To: 
References: 
 
Message-ID: <8rIuyjTDyTub67Hc6P7Zfy3VJqaoI_yoO_6dqV5Thok=.68bb7210-3991-40fb-8969-0768138a753c@github.com>

On Thu, 9 Oct 2025 22:10:23 GMT, Henry Jen  wrote:

>> Since parameters is an opt-in choice, it's more reasonable to consider that's desired information and make strip parameter names an opt-in choice as well.
>> 
>> This PR changes the default behavior of --strip-debug to keep parameter names when it's available. Add opt-in mechanism,
>> via the strip-java-debug-attributes plugin by using argument `--strip-java-debug-attributes=+parameter-names`.
>> 
>> The --strip-debug option is a little bit odd, as it's a main option as well as a plugin option to enable the DefaultStripDebugPlugin, which strip native debug information on platform support the feature, and strip java debug information. In this PR, we chose to support only one mechanism to enable strip parameter names, so we would disable the embed StripJavaDebugAttributesPlugin when StripJavaDebugAttributesPlugin is enabled.
>> 
>> The StripParameterNamesTest illustrate and verify parameter names use cases, mainly focus on argument processing and the parameter names. We didn't verify the regular debug info as that's covered by existing test.
>> 
>> -- Update
>> 
>> The latest change removed the support of strip parameter names, as the MethodParameters attribute is considered necessary attribute to fulfill Java Language Spec even though this attribute is considered optional by JVM spec.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27566#pullrequestreview-3322579580

From alanb at openjdk.org  Fri Oct 10 10:51:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Oct 2025 10:51:19 GMT
Subject: RFR: 8347007: --strip-debug removes parameter names included with
 -parameters [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 9 Oct 2025 18:28:04 GMT, Henry Jen  wrote:

>> test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 67:
>> 
>>> 65:     private static List testJmods = new ArrayList<>();
>>> 66: 
>>> 67:     record Jmod(Path moduleDir, boolean withDebugInfo, boolean withParameterNames) {}
>> 
>> Is the withDebugInfo component used?
>
> Not at this point, as we don't try to verify debug info simply because we have that covered in StripJavaDebugAttributesPluginTest.java.
> I can remove it if we like, it describes how the jmod was built.

Okay, I was mostly looking to see if it is used and wasn't sure if missed something.

>> test/jdk/tools/jlink/plugins/StripParameterNamesTest.java line 189:
>> 
>>> 187:         Process process = processBuilder.start();
>>> 188:         int exitCode = process.waitFor();
>>> 189:         var output = process.inputReader().readLine();
>> 
>> Have you looked into using  jdk.test.lib.process.ProcessTools?
>
> What do you recommend? Since I don't need complex processing of output, so I just did this.

My preference would be to use ProcessTools because tests that launch other VMs are amongst the most troublesome. The jlink tests, link most areas, have grow organically, and there is a mix of Process/ProcessBuilder and ProcessTools. So I'm okay with what you have, maybe some day we can migrate the existing tests to use ProcessTools and make them more robust.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2419398438
PR Review Comment: https://git.openjdk.org/jdk/pull/27566#discussion_r2419394008

From alanb at openjdk.org  Fri Oct 10 11:27:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Oct 2025 11:27:03 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v2]
In-Reply-To: 
References: 
 <9gqy4YltBipAT7BuMq-_bhUKHmoQpOjKQIKZHeAv9pI=.f6daabd3-e323-48b2-8a4b-038e1f48b641@github.com>
 
 
 
 
Message-ID: 

On Thu, 9 Oct 2025 21:34:18 GMT, Xueming Shen  wrote:

>>> Does ParameterizedTest support vm/platform classloader isolation for each parameterized test run against the same test with different parameters?
>> 
>> I should have been clearer in my comment. The suggestion to use a ParameterizedTest is to exercise a custom class loader using super.defineClass with different buffers (direct, heap, position != 0, ...) so that it exercises the "non-trusted" cases.
>> 
>> You are right that testing the platform class loader (as a trusted class loader) will require opening java.lang.
>
> The test case has been updated to use @ParameterizedTest for the user-defined classloader, with the following variants.
> 
> 
>     static Stream bufferTypes() {
>         return Stream.of(
>                 arguments(ARRAY_BUFFER, 0, false),
>                 arguments(ARRAY_BUFFER_READONLY, 0, true),
>                 arguments(DIRECT_BUFFER, 0, false),
>                 arguments(DIRECT_BUFFER_READONLY, 0, false),
>                 arguments(ARRAY_BUFFER, 16, false),
>                 arguments(ARRAY_BUFFER_READONLY, 16, true),
>                 arguments(DIRECT_BUFFER, 16, false),
>                 arguments(DIRECT_BUFFER_READONLY, 16, false)
>         );
>     }
> 
> 
> I keep the built-in classloader testing asis in the same test file for now. Let me know if you have a strong opinion to split it out.

Good, but I think we think we need to buffers created with ByteBuffer.allocateDirect and ByteBuffer.allocate. Also there are 4 arena types so allocating from each would make for a more complete test.

One suggestion, up to you, is create all the buffers in the method source. That would allow additional buffers to be added without needing to change the test method to special case each one. (For the confined arena case it just means you can't close, but that's okay for this test).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2419560540

From syan at openjdk.org  Fri Oct 10 11:55:08 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 10 Oct 2025 11:55:08 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein  wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Hi, is there a way to get the jtreg8.1 binary, except build from source.

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

PR Comment: https://git.openjdk.org/jdk/pull/27719#issuecomment-3389686651

From syan at openjdk.org  Fri Oct 10 12:00:06 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 10 Oct 2025 12:00:06 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: 
References: 
Message-ID: <4WET954Oj6nVqTC0d9fTAAFyjWoUnu0EsGy7VM-V9do=.b4957a46-6b4e-4e74-bfde-33291622fde4@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein  wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Hi, is there a way to get the jtreg8.1 binary, except build from source.

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

PR Comment: https://git.openjdk.org/jdk/pull/27719#issuecomment-3389704303

From alanb at openjdk.org  Fri Oct 10 14:19:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Oct 2025 14:19:54 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR
In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
Message-ID: 

On Wed, 8 Oct 2025 14:49:07 GMT, Lance Andersen  wrote:

> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
> 
> - Deprecate SQLPermission for removal
> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
> 
> Tiers 1-3 have been run

src/java.sql/share/classes/java/sql/Connection.java line 1840:

> 1838:             throw new SQLException("Invalid name");
> 1839:         }
> 1840:     }

Have you considered creating a non-public class with the implementations so that we don't have the same implementation in Statement and Connection? This would also provide somewhere to cache the compiled Patterns (a candidate for LazyConstant in the future, not now as the java.sql does not participate in preview features at this time).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2420470418

From alanb at openjdk.org  Fri Oct 10 14:23:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Oct 2025 14:23:05 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR
In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
Message-ID: 

On Wed, 8 Oct 2025 14:49:07 GMT, Lance Andersen  wrote:

> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
> 
> - Deprecate SQLPermission for removal
> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
> 
> Tiers 1-3 have been run

src/java.sql/share/classes/java/sql/JDBCType.java line 213:

> 211:      * Identifies the generic SQL type {@code DECFLOAT}.
> 212:      */
> 213:     JSON(Types.JSON);

I thin both of these will need `@since 26`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2420488694

From alanb at openjdk.org  Fri Oct 10 14:25:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Oct 2025 14:25:00 GMT
Subject: RFR: 8368877: Generate Jextract bindings for Kqueue [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 6 Oct 2025 10:18:50 GMT, Darragh Clarke  wrote:

>> This PR is based on #25546 , though it was suggested to split that PR into 2 for easier reviewing and to give better visibility in the git history.
>> This PR contains all the JExtract generated code that will be needed for converting Java's KQueue implementation to use Panama features instead of JNI. The actual updates to KQueue to make use of these files will come in the second PR.
>> 
>> The basic structure here has the different native structures and methods split into 3 different packages all preceded by
>> `src/java.base/macosx/classes/jdk/internal/ffi/generated/`
>> Included in each package is a file `package-info.java` which contains the script that was used to generate these files so that others can reproduce them in future.
>> 
>> The only modifications that have been made to the files post-generation are:
>> - Adding copyright headers
>> - Adding warning suppression for using restricted methods
>> 
>> Some further modifications to these files to cut down on code duplication and adding support for errno handling on the native calls will come in the 2nd PR alongside the KQueue changes mentioned.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed comment and fixed newlines at end of files

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27590#pullrequestreview-3323889808

From cstein at openjdk.org  Fri Oct 10 15:13:56 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 10 Oct 2025 15:13:56 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein  wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Usually @shipilev is kind and quick to provide them here: https://builds.shipilev.net/jtreg/

Mind his warning and motto, though:
> WARNING: These artifacts are not well-tested, not virus-checked, may contain horrible bugs that could lead to data corruption, engulfing machines in flames, sharing your financial data, selling your pets on eBay, etc. etc. etc. everything that applies for binaries^W code^W anything downloaded from the Internet. Be cautious. If in doubt, build from the source yourself, and/or run on staging environment that is not painful to restore.
>

> Our motto: "[builds.shipilev.net](https://builds.shipilev.net/) ? still more secure than npm install"

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

PR Comment: https://git.openjdk.org/jdk/pull/27719#issuecomment-3390690779

From fandreuzzi at openjdk.org  Fri Oct 10 15:42:49 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 10 Oct 2025 15:42:49 GMT
Subject: Integrated: 8368846: java/io/File/createTempFile/TargetDirectory fails
 when run by root user
In-Reply-To: 
References: 
Message-ID: 

On Mon, 29 Sep 2025 08:28:38 GMT, Francesco Andreuzzi  wrote:

> The test checks whether writing to a read-only directory throws a `IOException`. This test is not applicable when the user running the test is root. Thus, I propose to skip it.
> 
> I converted the class to several JUnit tests, so we can use `@DisabledIf`.

This pull request has now been integrated.

Changeset: fc49a1b5
Author:    Francesco Andreuzzi 
Committer: Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/fc49a1b502530908618b19bcd749aa4db0b598d9
Stats:     52 lines in 1 file changed: 18 ins; 10 del; 24 mod

8368846: java/io/File/createTempFile/TargetDirectory fails when run by root user

Reviewed-by: bpb

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

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

From lancea at openjdk.org  Fri Oct 10 16:03:38 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 10 Oct 2025 16:03:38 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v2]
In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
Message-ID: 

> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
> 
> - Deprecate SQLPermission for removal
> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
> 
> Tiers 1-3 have been run

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

  Doc clean up based on feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27693/files
  - new: https://git.openjdk.org/jdk/pull/27693/files/9a2685a7..99495e80

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

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

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

From lancea at openjdk.org  Fri Oct 10 16:06:03 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 10 Oct 2025 16:06:03 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v2]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
Message-ID: 

On Fri, 10 Oct 2025 14:16:38 GMT, Alan Bateman  wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc clean up based on feedback
>
> src/java.sql/share/classes/java/sql/Connection.java line 1840:
> 
>> 1838:             throw new SQLException("Invalid name");
>> 1839:         }
>> 1840:     }
> 
> Have you considered creating a non-public class with the implementations so that we don't have the same implementation in Statement and Connection? This would also provide somewhere to cache the compiled Patterns (a candidate for LazyConstant in the future, not now as the java.sql does not participate in preview features at this time).

I hadn't but can look at this for follow on clean up before GA and after CSR is approved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2421026721

From naoto at openjdk.org  Fri Oct 10 16:13:05 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 10 Oct 2025 16:13:05 GMT
Subject: RFR: 8369452: Locale.Builder.setLanguageTag(String) does not clear
 on empty or null String [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Oct 2025 23:42:39 GMT, Justin Lu  wrote:

>> Please review this PR which corrects the behavior of `Locale.Builder.setLanguageTag(String)` on the null and empty String case.
>> 
>> This method is specified as follows,
>> 
>>> Null and the empty string cause the builder to be reset
>> 
>> Currently, NPE is thrown for a null tag, and ILE is thrown for an empty String. They are both corrected to not throw, and instead reset the state of the `Locale.Builder`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's comment - improve err msg

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27734#pullrequestreview-3324546666

From duke at openjdk.org  Fri Oct 10 16:19:51 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Fri, 10 Oct 2025 16:19:51 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v2]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
Message-ID: 

On Fri, 10 Oct 2025 16:03:38 GMT, Lance Andersen  wrote:

>> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
>> 
>> - Deprecate SQLPermission for removal
>> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
>> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
>> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
>> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
>> 
>> Tiers 1-3 have been run
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc clean up based on feedback

test/jdk/java/sql/testng/test/sql/ConnectionTests.java line 36:

> 34: import static org.testng.Assert.assertEquals;
> 35: 
> 36: public class ConnectionTests extends BaseTest {

Suggestion: `ConnectionTests` -> `ConnectionTest`, also use JUnit instead of TestNG.

test/jdk/java/sql/testng/test/sql/ConnectionTests.java line 39:

> 37: 
> 38:     protected StubConnection conn;
> 39:     protected static String maxIdentifier;

You could use `protected static final String MAX_IDENTIFIER = "a".repeat(128);`

test/jdk/java/sql/testng/test/sql/ConnectionTests.java line 59:

> 57:      * single quote to two single quotes
> 58:      */
> 59: 

Suggestion: Move empty line before the method comment.

test/jdk/java/sql/testng/test/sql/ConnectionTests.java line 72:

> 70:     public void test01() throws SQLException {
> 71:         conn.enquoteLiteral(null);
> 72: 

Suggestion: remove empty line (also in following methods).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2421052230
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2421043792
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2421084553
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2421055485

From chris.w.dennis at gmail.com  Fri Oct 10 16:19:47 2025
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Fri, 10 Oct 2025 12:19:47 -0400
Subject: Backporting of JDK-8362123
Message-ID: 

Now that JDK-8162123 has been fixed in 26/main (
https://github.com/openjdk/jdk/commit/d5a207994b9c374e6638e57826326f8f4593b96b),
and considering that the fix is a clean cherry-pick (including test
coverage) and is in a non-performance sensitive area. What's the process to
go about getting this backported to JDK 21 & 25?

Thanks,

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lancea at openjdk.org  Fri Oct 10 16:27:03 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 10 Oct 2025 16:27:03 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v2]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
 
Message-ID: 

On Fri, 10 Oct 2025 16:07:18 GMT, Johannes D?bler  wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc clean up based on feedback
>
> test/jdk/java/sql/testng/test/sql/ConnectionTests.java line 39:
> 
>> 37: 
>> 38:     protected StubConnection conn;
>> 39:     protected static String maxIdentifier;
> 
> You could use `protected static final String MAX_IDENTIFIER = "a".repeat(128);`

Will address as part of the future refactoring  of these tests back to Junit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2421119781

From jlu at openjdk.org  Fri Oct 10 16:31:00 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 10 Oct 2025 16:31:00 GMT
Subject: Integrated: 8369050: DecimalFormat Rounding Errors for Fractional Ties
 Near Zero
In-Reply-To: 
References: 
Message-ID: 

On Tue, 7 Oct 2025 23:19:28 GMT, Justin Lu  wrote:

> Please review this PR which corrects a rounding error for DecimalFormat on tie cases when the maximum fraction digits allowed is one less than the position of the first significant digit in the double rounded. For example, rounding a value such as 0.0005 to a maximum of 3 fractional digits. In order to get the correct `count` value, we must strip the trailing zeros prior to the check to ensure we have the correct value of `count` = 1 so that we can go down the _Rounding position is the last index_ case which properly checks if the String double was already rounded or is exact from its true decimal form.

This pull request has now been integrated.

Changeset: 376d77e8
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/376d77e8a71478f456af5baaf47f446eebd79e36
Stats:     95 lines in 3 files changed: 88 ins; 5 del; 2 mod

8369050: DecimalFormat Rounding Errors for Fractional Ties Near Zero

Reviewed-by: naoto

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

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

From jvernee at openjdk.org  Fri Oct 10 16:32:45 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 10 Oct 2025 16:32:45 GMT
Subject: RFR: 8366424: Missing type profiling in generated Record Object
 methods
In-Reply-To: 
References: 
Message-ID: 

On Fri, 26 Sep 2025 22:13:00 GMT, Chen Liang  wrote:

> Hotspot profiles by bytecode; as a result, some shared methods become polluted and suffer in type profiling, as described in depth in [this essay](https://cr.openjdk.org/~jrose/jvm/equals-profile.html) by John Rose. The record methods generated by `ObjectMethods::bootstrap` just proved itself another victim in this RFE.
> 
> To bypass this issue, I naively generated distinct bytecode to allow distinct profiles for now. If hotspot adds any kind of split profiles exposed via internal APIs, we can migrate to such split profile and throw away these extra copies of bytecode.
> 
> In particular, in a method handle tree, each leaf method handle seems not separately profiled - for example, all DMH to Object.hashCode share the same profile regardless of their position in a MH tree, making MH trees less useful than explicitly rolled bytecode, unfortunately.
> 
> The attached benchmark should be a good demonstration of the effect of type profiling.

Looks mostly good.

src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 178:

> 176:     private static boolean isMonomorphic(Class type) {
> 177:         // Includes primitives and final classes
> 178:         return Modifier.isFinal(type.getModifiers()) && !type.isArray();

Why are arrays excluded here? Could you add a comment?

src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 213:

> 211:             var type = getter.type().returnType();
> 212:             if (isMonomorphic(type)) {
> 213:                 equalators[i] = equalator(lookup, type);

Do we also have tests that test this code path now? `final` class seems like it might be rare in tests.

src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 250:

> 248:                                .aload(0) // arg0.equals(arg1) - bytecode subject to customized profiling
> 249:                                .aload(1)
> 250:                                .invoke(isInterface ? Opcode.INVOKEINTERFACE : Opcode.INVOKEVIRTUAL, typeDesc, "equals", MethodTypeDesc.of(CD_boolean, CD_Object), isInterface)

Could factor out the MethodTypeDesc here.

test/micro/org/openjdk/bench/java/lang/runtime/RecordMethodsBenchmark.java line 51:

> 49: @OutputTimeUnit(TimeUnit.MICROSECONDS)
> 50: @BenchmarkMode(Mode.Throughput)
> 51: public class RecordMethodsBenchmark {

I think it would be interesting to add another case here where the records fields are monomorphic, to see how that compares against the specialized case.

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

PR Review: https://git.openjdk.org/jdk/pull/27533#pullrequestreview-3324486245
PR Review Comment: https://git.openjdk.org/jdk/pull/27533#discussion_r2421088849
PR Review Comment: https://git.openjdk.org/jdk/pull/27533#discussion_r2421076291
PR Review Comment: https://git.openjdk.org/jdk/pull/27533#discussion_r2421006192
PR Review Comment: https://git.openjdk.org/jdk/pull/27533#discussion_r2421111513

From lancea at openjdk.org  Fri Oct 10 17:25:34 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 10 Oct 2025 17:25:34 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v3]
In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
Message-ID: 

> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
> 
> - Deprecate SQLPermission for removal
> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
> 
> Tiers 1-3 have been run

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

  Spacing clean up in ConnectionTests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27693/files
  - new: https://git.openjdk.org/jdk/pull/27693/files/99495e80..0f9876b2

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

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

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

From duke at openjdk.org  Fri Oct 10 19:52:04 2025
From: duke at openjdk.org (=?UTF-8?B?SmVhbi1Ob8OrbA==?= Rouvignac)
Date: Fri, 10 Oct 2025 19:52:04 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 00:33:20 GMT, Xueming Shen  wrote:

>> ### 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 pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor api doc updates

test/micro/org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java line 89:

> 87: 
> 88:     @Benchmark
> 89:     public int lowerrCF() {

Suggestion:

    public int lowerCF() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2421934368

From rriggs at openjdk.org  Fri Oct 10 20:51:14 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 10 Oct 2025 20:51:14 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v3]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
Message-ID: 

On Fri, 10 Oct 2025 17:25:34 GMT, Lance Andersen  wrote:

>> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
>> 
>> - Deprecate SQLPermission for removal
>> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
>> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
>> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
>> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
>> 
>> Tiers 1-3 have been run
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spacing clean up in ConnectionTests

src/java.sql/share/classes/java/sql/Array.java line 384:

> 382:   default void close() throws SQLException {
> 383:     free();
> 384:   };

The indention in this file is 4 spaces.
Also check new close() methods in Blob, Clob and SQLXML.

src/java.sql/share/classes/java/sql/Connection.java line 1680:

> 1678:         throw new SQLFeatureNotSupportedException("setShardingKey not implemented");
> 1679:     }
> 1680:     // JDBC 4.5

Would this be information to developers if added in and @apiNote as a function in supported by JDBC 4.5.

src/java.sql/share/classes/java/sql/Connection.java line 1747:

> 1745:      * 
  • The first character is an alphabetic character from a through z, or
> 1746:      * from A through Z
    • 
> 1747:      * 
  • The name only contains alphanumeric characters or the character "_"
    • 

Trailing  tags can be omitted to make the source more readable.  YMMV

src/java.sql/share/classes/java/sql/Connection.java line 1816:

> 1814:      * @param alwaysQuote indicates if a simple SQL identifier should be
> 1815:      * returned as a quoted identifier
> 1816:      * @return A simple SQL identifier or a delimited identifier

Is there a difference between a "quoted identifier" and a "delimited identifier"?
The terminology should be consistent (with the jdbc spec).

src/java.sql/share/classes/java/sql/Connection.java line 1827:

> 1825:         int len = identifier.length();
> 1826:         if (len < 1 || len > 128) {
> 1827:             throw new SQLException("Invalid name");

The exception would be easier to debug if the identifier were included in the exception.

src/java.sql/share/classes/java/sql/Connection.java line 1829:

> 1827:             throw new SQLException("Invalid name");
> 1828:         }
> 1829:         if (Pattern.compile("[\\p{Alpha}][\\p{Alnum}_]*").matcher(identifier).matches()) {

In the implementation, it would save a bit of performance to do the Pattern.compile once instead of on every invocation.   ?ConstantValue or Holder class, or static.

src/java.sql/share/classes/java/sql/Connection.java line 1832:

> 1830:             return alwaysQuote ?  "\"" + identifier + "\"" : identifier;
> 1831:         }
> 1832:         if (identifier.matches("^\".+\"$")) {

Ditto: precompile the regex.

src/java.sql/share/classes/java/sql/Connection.java line 1835:

> 1833:             identifier = identifier.substring(1, len - 1);
> 1834:         }
> 1835:         if (Pattern.compile("[^\u0000\"]+").matcher(identifier).matches()) {

Could `identifier.indexOf(0)` be a more efficient way to look for an embedded null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2421996228
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2422007116
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2422018714
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2422014939
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2422015965
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2422027684
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2422030143
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2422033151

From sherman at openjdk.org  Sat Oct 11 01:26:53 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Sat, 11 Oct 2025 01:26:53 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v4]
In-Reply-To: 
References: 
Message-ID: 

> ### Background
> 
> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
> 
> ### Problem
> 
> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
> 
> ### Solution
> 
> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
> 
> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
> 
> ### Benchmark
> 
> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
> 
> **Before:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
> 
> 
> **After:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  9002.842 ? 1099.635  ns/op
> Finished running test 'mi...

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

  test case update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27569/files
  - new: https://git.openjdk.org/jdk/pull/27569/files/23ada406..43b61040

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

  Stats: 127 lines in 1 file changed: 41 ins; 23 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/27569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27569/head:pull/27569

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

From sherman at openjdk.org  Sat Oct 11 01:47:44 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Sat, 11 Oct 2025 01:47:44 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v5]
In-Reply-To: 
References: 
Message-ID: 

> ### Background
> 
> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
> 
> ### Problem
> 
> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
> 
> ### Solution
> 
> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
> 
> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
> 
> ### Benchmark
> 
> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
> 
> **Before:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
> 
> 
> **After:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  9002.842 ? 1099.635  ns/op
> Finished running test 'mi...

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

  test case update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27569/files
  - new: https://git.openjdk.org/jdk/pull/27569/files/43b61040..c1cc95e6

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

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

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

From sherman at openjdk.org  Sat Oct 11 01:47:44 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Sat, 11 Oct 2025 01:47:44 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v2]
In-Reply-To: 
References: 
 <9gqy4YltBipAT7BuMq-_bhUKHmoQpOjKQIKZHeAv9pI=.f6daabd3-e323-48b2-8a4b-038e1f48b641@github.com>
 
 
 
 
 
Message-ID: 

On Fri, 10 Oct 2025 11:24:03 GMT, Alan Bateman  wrote:

>> The test case has been updated to use @ParameterizedTest for the user-defined classloader, with the following variants.
>> 
>> 
>>     static Stream bufferTypes() {
>>         return Stream.of(
>>                 arguments(ARRAY_BUFFER, 0, false),
>>                 arguments(ARRAY_BUFFER_READONLY, 0, true),
>>                 arguments(DIRECT_BUFFER, 0, false),
>>                 arguments(DIRECT_BUFFER_READONLY, 0, false),
>>                 arguments(ARRAY_BUFFER, 16, false),
>>                 arguments(ARRAY_BUFFER_READONLY, 16, true),
>>                 arguments(DIRECT_BUFFER, 16, false),
>>                 arguments(DIRECT_BUFFER_READONLY, 16, false)
>>         );
>>     }
>> 
>> 
>> I keep the built-in classloader testing asis in the same test file for now. Let me know if you have a strong opinion to split it out.
>
> Good, but I think we think we need to test buffers created with ByteBuffer.allocateDirect and ByteBuffer.allocate. Also there are 4 arena types so allocating from each would make for a more complete test.
> 
> One suggestion, up to you, is create all the buffers in the method source. That would allow additional buffers to be added without needing to change the test method to special case each one. (For the confined arena case it just means you can't close, but that's okay for this test).

Updated to test the following 8 types


    static final int ARRAY_BUFFER = 0;
    static final int WRAPPED_BUFFER = 1;
    static final int DIRECT_BUFFER = 2;
    static final int MAPPED_BUFFER = 3;
    static final int FOREIGN_AUTO_BUFFER = 4;
    static final int FOREIGN_CONFINED_BUFFER = 5;
    static final int FOREIGN_GLOBAL_BUFFER = 6;
    static final int FOREIGN_SHARED_BUFFER = 7;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2422365352

From ascarpino at openjdk.org  Sat Oct 11 01:54:52 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 11 Oct 2025 01:54:52 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v5]
In-Reply-To: 
References: 
Message-ID: 

> Hi
> 
> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
> 
> - Renamed the name of `PEMRecord` class to `PEM`.
> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
> 
> thanks
> 
> Tony

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

 - major doc update, change to encrypt()
 - update preview

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27147/files
  - new: https://git.openjdk.org/jdk/pull/27147/files/e13bff47..db913c3c

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

  Stats: 566 lines in 11 files changed: 177 ins; 154 del; 235 mod
  Patch: https://git.openjdk.org/jdk/pull/27147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27147/head:pull/27147

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

From tvaleev at openjdk.org  Sat Oct 11 09:21:03 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 11 Oct 2025 09:21:03 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v2]
In-Reply-To: <_luhOnsZ6IwgSempKXCGLFcRxT5pv6wo30kgCynESCQ=.cbb9982d-ec4c-402e-9716-b4e86be555b2@github.com>
References: 
 <_luhOnsZ6IwgSempKXCGLFcRxT5pv6wo30kgCynESCQ=.cbb9982d-ec4c-402e-9716-b4e86be555b2@github.com>
Message-ID: 

On Fri, 26 Sep 2025 22:39:29 GMT, Vladimir Yaroslavskiy  wrote:

>> The goal of the PR is to improve both, sequential and parallel, sorting of primitives.
>> 
>> **The main achievements**
>> 
>> - introduced Radix in parallel sorting which shows several times boost of performance and has linear complexity instead of n*ln(n)
>> - improved mixed insertion sort (makes whole sorting faster)
>> - improved merging sort for almost sorted data
>> - optimized parallel sorting
>> - improved step for pivot candidates and pivot partitioning
>> - suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError
>> - minor javadoc and comment changes
>> 
>> - extended existing tests
>> - added tests for radix sort, heap sort, insertion sort
>> - added benchmarking JMH tests
>> - improved test coverage
>> 
>> **The summary of benchmarking:**
>> 
>> **Sequential sorting (Arrays.sort)**
>> 
>> byte: up to 50% faster
>> char: 4-7 times faster
>> short: 2-6 times faster
>> int: 1.2-5 times faster
>> long: 1.2-5 times faster
>> float: 1.2-5 times faster
>> double: 1.2-4 times faster
>> 
>> **Parallel sorting (Arrays.parallelSort)**
>> 
>> int: 1.2-9 times faster
>> long: 1.2-9 times faster
>> float: 1.2-4 times faster
>> double: 1.2-4 times faster
>> 
>> **AVX512 support**
>> 
>> Vamsi Parasa suggested faster sort routines by taking advantage of AVX512 instructions, see https://github.com/openjdk/jdk/pull/14227, sources of sorting were modified. Therefore, I performed benchmarking of the final version (which includes optimizations by Vamsi Parasa and optimizations from my side) on a server with CPUs supported AVX512 instructions, no regression of performance was found, see detailed benchmarking results.
>> 
>> **High-level chart showing how the actual sorting algorithm is selected
>> based on parallel/sequential and input size**
>> 
>> **int/long/float/double**
>> 
>> if size < MAX_INSERTION_SORT_SIZE(=51) => [ mixed ] insertion sort
>> if array is almost sorted and size > MIN_MERGING_SORT_SIZE(=512) => merging sort
>> if recursion depth > MAX_RECURSION_DEPTH(=64) => heap sort
>> if random data => two pivots quicksort, else => one pivot quicksort
>> 
>> **byte**
>> 
>> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort
>> else => counting sort
>> 
>> **char/short**
>> 
>> if size > MIN_COUNTING_SORT_SIZE(640) => counting sort
>> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort
>> if recursion depth > MAX_RECURSION_DEPTH(=64) => counting sort
>> if random data => two pivots quicksort, else => one pivot quicksort
>> 
>> **parallel sorting (int/lo...
>
> Vladimir Yaroslavskiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements
>   
>   * Moved Radix sort out from sorting

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

> 64:      * Max size of array to use insertion sort.
> 65:      */
> 66:     private static final int MAX_INSERTION_SORT_SIZE = 51;

Was this change justified by benchmarking? Why was the best value different before? Due to hardware changes or due to HotSpot/JIT changes or due to algorithmic changes below?

src/java.base/share/classes/java/util/DualPivotQuicksort.java line 152:

> 150:     @ForceInline
> 151:     @IntrinsicCandidate
> 152:     private static  void sort(Class elemType, T a, long offset,

Why do we need this method? Offset and elemType are not used here. Probably it could be inlined?

src/java.base/share/classes/java/util/DualPivotQuicksort.java line 4472:

> 4470:     private static final class Sorter extends CountedCompleter {
> 4471: 
> 4472:         private static final long serialVersionUID = 123456789L;

I wonder why it should be serializable? I mean, this is useful for fork-join tasks in general, but is serialization ever used for these Sorter and Merger tasks?

Also, if `serialVersionUID` is really necessary, probably it makes sense to annotate it as `@Serial`. See
https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/io/Serial.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27411#discussion_r2422617471
PR Review Comment: https://git.openjdk.org/jdk/pull/27411#discussion_r2422640769
PR Review Comment: https://git.openjdk.org/jdk/pull/27411#discussion_r2422647632

From duke at openjdk.org  Sat Oct 11 09:45:02 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Sat, 11 Oct 2025 09:45:02 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v2]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
 
 
Message-ID: 

On Fri, 10 Oct 2025 16:24:53 GMT, Lance Andersen  wrote:

>> test/jdk/java/sql/testng/test/sql/ConnectionTests.java line 39:
>> 
>>> 37: 
>>> 38:     protected StubConnection conn;
>>> 39:     protected static String maxIdentifier;
>> 
>> You could use `protected static final String MAX_IDENTIFIER = "a".repeat(128);`
>
> Will address as part of the future refactoring  of these tests back to Junit

This seems to be a new test, so why not address comments right now, instead of shifting to a refactoring in the future? E.g. this simple change allows you to get rid of the setupClass method and it's a one-minute edit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2422689516

From duke at openjdk.org  Sat Oct 11 11:24:07 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Sat, 11 Oct 2025 11:24:07 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v3]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
 
Message-ID: 

On Fri, 10 Oct 2025 16:03:23 GMT, Lance Andersen  wrote:

>> src/java.sql/share/classes/java/sql/Connection.java line 1840:
>> 
>>> 1838:             throw new SQLException("Invalid name");
>>> 1839:         }
>>> 1840:     }
>> 
>> Have you considered creating a non-public class with the implementations so that we don't have the same implementation in Statement and Connection? This would also provide somewhere to cache the compiled Patterns (a candidate for LazyConstant in the future, not now as the java.sql does not participate in preview features at this time).
>
> I hadn't but can look at this for follow on clean up before GA and after CSR is approved.

Also from the perspective of a JDBC driver provider it would be beneficial to have the default implementations in Statement..enquoteLiteral() and Statement.enquoteIdentifier() call the new methods in Connection. Driver implementations would then only need to override the Connection methods if they want to adjust the default implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2422747200

From duke at openjdk.org  Sat Oct 11 11:24:10 2025
From: duke at openjdk.org (Thomas Zimmermann)
Date: Sat, 11 Oct 2025 11:24:10 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v3]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
Message-ID: 

On Fri, 10 Oct 2025 17:25:34 GMT, Lance Andersen  wrote:

>> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
>> 
>> - Deprecate SQLPermission for removal
>> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
>> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
>> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
>> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
>> 
>> Tiers 1-3 have been run
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spacing clean up in ConnectionTests

src/java.sql/share/classes/java/sql/JDBCType.java line 214:

> 212: 
> 213:     /**
> 214:      * Identifies the generic SQL type {@code DECFLOAT}.

Suggestion:

     * Identifies the generic SQL type {@code JSON}.

src/java.sql/share/classes/java/sql/SQLXML.java line 186:

> 184:  * {@code SQLXML} object has been closed, will result in a {@link SQLException}
> 185:  * being thrown.
> 186:  * 
    

Suggestion:

 * 
    

src/java.sql/share/classes/java/sql/Timestamp.java line 473:

> 471:      * }
> 472:      *
> 473:      * @return  a hash code value for this Timestamp.

Suggestion:

     * @return a hash code value for this Timestamp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2422745497
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2422746464
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2422747021

From alan.bateman at oracle.com  Sun Oct 12 07:14:35 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sun, 12 Oct 2025 08:14:35 +0100
Subject: Backporting of JDK-8362123
In-Reply-To: 
References: 
Message-ID: <69529b13-9f56-4523-ac17-790908178878@oracle.com>


On 10/10/2025 17:19, Chris Dennis wrote:
> Now that JDK-8162123 has been fixed in 26/main 
> (https://github.com/openjdk/jdk/commit/d5a207994b9c374e6638e57826326f8f4593b96b), 
> and considering that the fix is a clean cherry-pick (including test 
> coverage) and is in a non-performance sensitive area. What's the 
> process to go about?getting this?backported to JDK 21 & 25?

The JDK Update Releases page [1] has links to the process.

-Alan

[1] https://openjdk.org/projects/jdk-updates/

From alanb at openjdk.org  Sun Oct 12 07:15:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 Oct 2025 07:15:07 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 11 Oct 2025 01:47:44 GMT, Xueming Shen  wrote:

>> ### Background
>> 
>> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
>> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
>> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
>> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
>> 
>> ### Problem
>> 
>> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
>> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
>> 
>> ### Solution
>> 
>> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
>> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
>> 
>> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
>> 
>> ### Benchmark
>> 
>> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
>> 
>> **Before:**
>> 
>> 
>> Benchmark                                               Mode  Cnt     Score      Error  Units
>> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
>> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
>> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
>> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
>> 
>> 
>> **After:**
>> 
>> 
>> Benchmark                                               Mode  Cnt     Score      Error  Units
>> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
>> ClassLoaderDefineClass.testDefineClassByt...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test case update

test/jdk/java/lang/ClassLoader/defineClass/DefineClassDirectByteBuffer.java line 192:

> 190:     @MethodSource("bufferTypes")
> 191:     void testDefineClassWithCustomLoaderByteBuffer(int type, boolean readonly, int pos, boolean posAtLimit)
> 192:             throws Exception

Have you tried changing the method source to create a stream of the ByteBuffers to test? 

In the current version we need to add to bufferTypes(), getByteBufferWithTestClassBytes(), and maybe adding a new constant, in order to add a new buffer to test. I suspect it would be a lot simpler if method source created all the buffers (including the read-only buffers), and testDefineClassWithCustomLoaderByteBuffer just tests defineClass with that BB.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2423375236

From alanb at openjdk.org  Sun Oct 12 07:59:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 Oct 2025 07:59:10 GMT
Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for
 virtual thread support [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 6 Oct 2025 22:30:21 GMT, Patricio Chilano Mateo  wrote:

>> test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java line 645:
>> 
>>> 643:     /**
>>> 644:      * Test no deadlock happens when Object.wait is called from a mix of pinned and non-pinned
>>> 645:      * paths and notification is done using notifyAll.
>> 
>> At some point then maybe we should combine this with RetryMonitorEnterWhenPinned. I'm not suggesting we do this now but some of the expanded description might be useful to include here as a passing reader might not immediately know what this test is doing.
>
> I wasn?t sure where to put the extra test and missed `RetryMonitorEnterWhenPinned.java`. I agree it makes more sense to have it there. Moved now, let me know what you think.

Thanks for moving to RetryMonitorEnterWhenPinned as it is similar to the test we had for enter. The update, and conversion to JUnit look good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27597#discussion_r2423388839

From alanb at openjdk.org  Sun Oct 12 07:59:08 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 Oct 2025 07:59:08 GMT
Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for
 virtual thread support [v5]
In-Reply-To: <8CQ5NYDakZIO2Y8agWBUgd12ReC2dJfgd-3rCZbemRo=.11fc27cb-6566-4bee-af83-591f10ae0295@github.com>
References: 
 <8CQ5NYDakZIO2Y8agWBUgd12ReC2dJfgd-3rCZbemRo=.11fc27cb-6566-4bee-af83-591f10ae0295@github.com>
Message-ID: 

On Tue, 7 Oct 2025 18:36:30 GMT, Patricio Chilano Mateo  wrote:

>> Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized.
>> This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization.
>> 
>> These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add string in asserts

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27597#pullrequestreview-3327961626

From scolebourne at joda.org  Sun Oct 12 22:26:31 2025
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 12 Oct 2025 23:26:31 +0100
Subject: Duration.MAX_VALUE
In-Reply-To: 
References: 
 
Message-ID: 

Just noting that the conceptual definition of Duration.MAX and MIN
have been in use since Java 8, and I disagree with any change to the
current definition.

You cannot successfully negate Long.MIN_VALUE, so there is no
requirement that edge cases like this support negation.

Stephen


On Wed, 8 Oct 2025 at 21:29, Pavel Rappo  wrote:
>
> In another thread, there's a question on whether we can define
> Duration.MIN such that it's not the exact minimum, but rather the
> minimum "negatable minimum"? Put differently, can we define
> Duration.MIN as Duration.MAX.negated(), where Duration.MAX is
> Duration.ofSeconds(Long.MAX_VALUE, 999_999_999)? What are the concerns
> with this, if any?
>
> -Pavel
>
> On Wed, Sep 3, 2025 at 1:49?PM Pavel Rappo  wrote:
> >
> > Couldn't recall or quickly find if this was asked before.
> >
> > I come across this quite often: there doesn?t seem to be a readily
> > available maximum value for java.time.Duration -- a value that
> > represents the longest possible duration.
> >
> > I assume there are plenty of homegrown constants out in the wild
> > addressing this. Don?t get me wrong: it?s not hard to create one. The
> > issue, in my experience, is that it takes time and sometimes
> > experimentation.
> >
> > Unless one reads the Javadoc carefully, it?s not obvious that the
> > maximum duration can be constructed as follows:
> >
> >     Duration.of(Long.MAX_VALUE, 999_999_999);
> >
> > Naturally, one might first try using IDE autocomplete. For example,
> > creating a Duration from Long.MAX_VALUE of a large unit -- millennia,
> > centuries, decades, etc. -- only to run into ArithmeticException. Only
> > when reaching seconds does it finally work:
> >
> >     Duration.ofSeconds(Long.MAX_VALUE);
> >
> > or
> >
> >     Duration.of(Long.MAX_VALUE, ChronoUnit.SECONDS);
> >
> > Of course, there?s no practical difference between
> > Duration.of(Long.MAX_VALUE, 999_999_999) and
> > Duration.ofSeconds(Long.MAX_VALUE). We?re talking about durations on
> > the order of 292 billion years, after all. The exact value isn?t the
> > problem. The problem is that the values are inconsistent, and arriving
> > to them is error-prone. Adding a constant to java.time.Duration would
> > simplify things.
> >
> > -Pavel

From sherman at openjdk.org  Mon Oct 13 02:18:52 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 13 Oct 2025 02:18:52 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v6]
In-Reply-To: 
References: 
Message-ID: 

> ### Background
> 
> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
> 
> ### Problem
> 
> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
> 
> ### Solution
> 
> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
> 
> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
> 
> ### Benchmark
> 
> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
> 
> **Before:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
> 
> 
> **After:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  9002.842 ? 1099.635  ns/op
> Finished running test 'mi...

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

  test case update3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27569/files
  - new: https://git.openjdk.org/jdk/pull/27569/files/c1cc95e6..33389d5c

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

  Stats: 309 lines in 1 file changed: 179 ins; 108 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/27569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27569/head:pull/27569

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

From sherman at openjdk.org  Mon Oct 13 02:18:56 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 13 Oct 2025 02:18:56 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 12 Oct 2025 07:12:49 GMT, Alan Bateman  wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test case update
>
> test/jdk/java/lang/ClassLoader/defineClass/DefineClassDirectByteBuffer.java line 192:
> 
>> 190:     @MethodSource("bufferTypes")
>> 191:     void testDefineClassWithCustomLoaderByteBuffer(int type, boolean readonly, int pos, boolean posAtLimit)
>> 192:             throws Exception
> 
> Have you tried changing the method source to create a stream of the ByteBuffers to test? 
> 
> In the current version we need to add to bufferTypes(), getByteBufferWithTestClassBytes(), and maybe adding a new constant, in order to add a new buffer to test. I suspect it would be a lot simpler if method source created all the buffers (including the read-only buffers), and testDefineClassWithCustomLoaderByteBuffer just tests defineClass with that BB.

Just tried to make the test code less verbose / repetitive :-) Updated accordingly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2425109714

From sherman at openjdk.org  Mon Oct 13 02:24:44 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 13 Oct 2025 02:24:44 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v7]
In-Reply-To: 
References: 
Message-ID: 

> ### Background
> 
> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
> 
> ### Problem
> 
> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
> 
> ### Solution
> 
> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
> 
> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
> 
> ### Benchmark
> 
> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
> 
> **Before:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
> 
> 
> **After:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  9002.842 ? 1099.635  ns/op
> Finished running test 'mi...

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

  test case update.format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27569/files
  - new: https://git.openjdk.org/jdk/pull/27569/files/33389d5c..07049bd2

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

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

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

From alanb at openjdk.org  Mon Oct 13 06:58:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Oct 2025 06:58:04 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 02:15:09 GMT, Xueming Shen  wrote:

>> test/jdk/java/lang/ClassLoader/defineClass/DefineClassDirectByteBuffer.java line 192:
>> 
>>> 190:     @MethodSource("bufferTypes")
>>> 191:     void testDefineClassWithCustomLoaderByteBuffer(int type, boolean readonly, int pos, boolean posAtLimit)
>>> 192:             throws Exception
>> 
>> Have you tried changing the method source to create a stream of the ByteBuffers to test? 
>> 
>> In the current version we need to add to bufferTypes(), getByteBufferWithTestClassBytes(), and maybe adding a new constant, in order to add a new buffer to test. I suspect it would be a lot simpler if method source created all the buffers (including the read-only buffers), and testDefineClassWithCustomLoaderByteBuffer just tests defineClass with that BB.
>
> Just tried to make the test code less verbose / repetitive :-) Updated accordingly.

Thank you, this is much better. One other thing that will simplify it further is to drop the posAtLimit parameter. Instead, testDefineClassWithCustomLoaderByteBuffer can capture the bb position and limit, then test their values after the defineClass, e.g.

        if (bb.isDirect() || bb.hasArray()) {
            assertEquals(originalPos, bb.position());
        } else {
            assertEquals(originalLimit, bb.position());
        }
        assertEquals(originalLimit, bb.limit());

This will test long-standing (and undocumented) behavior. I created JDK-8352583 on the spec issue. It would be too risky to change behavior and advance the position. There may be some flexibility to not advance the position for the read-only buffer case, but we would need to work through the compatibility impacts of that. The fallback is to just document long standing behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2425360962

From alanb at openjdk.org  Mon Oct 13 07:05:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Oct 2025 07:05:09 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 13 Oct 2025 02:24:44 GMT, Xueming Shen  wrote:

>> ### Background
>> 
>> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
>> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
>> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
>> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
>> 
>> ### Problem
>> 
>> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
>> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
>> 
>> ### Solution
>> 
>> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
>> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
>> 
>> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
>> 
>> ### Benchmark
>> 
>> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
>> 
>> **Before:**
>> 
>> 
>> Benchmark                                               Mode  Cnt     Score      Error  Units
>> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
>> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
>> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
>> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
>> 
>> 
>> **After:**
>> 
>> 
>> Benchmark                                               Mode  Cnt     Score      Error  Units
>> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
>> ClassLoaderDefineClass.testDefineClassByt...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test case update.format

test/jdk/java/lang/ClassLoader/defineClass/DefineClassDirectByteBuffer.java line 283:

> 281:         m.setAccessible(true);
> 282:         Class clazz = (Class) m.invoke(builtin, null, bb, null);
> 283:         assertInvocating(clazz);

It would be good to test the buffer position after the defineClass in this test method too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2425373974

From sherman at openjdk.org  Mon Oct 13 07:44:25 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 13 Oct 2025 07:44:25 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v8]
In-Reply-To: 
References: 
Message-ID: 

> ### Background
> 
> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
> 
> ### Problem
> 
> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
> 
> ### Solution
> 
> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
> 
> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
> 
> ### Benchmark
> 
> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
> 
> **Before:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
> 
> 
> **After:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  9002.842 ? 1099.635  ns/op
> Finished running test 'mi...

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

  test case update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27569/files
  - new: https://git.openjdk.org/jdk/pull/27569/files/07049bd2..8cd28a8a

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

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

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

From sherman at openjdk.org  Mon Oct 13 07:49:08 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 13 Oct 2025 07:49:08 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v5]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 06:55:02 GMT, Alan Bateman  wrote:

>> Just tried to make the test code less verbose / repetitive :-) Updated accordingly.
>
> Thank you, this is much better. One other thing that will simplify it further is to drop the posAtLimit parameter. Instead, testDefineClassWithCustomLoaderByteBuffer can capture the bb position and limit, then test their values after the defineClass, e.g.
> 
>         if (bb.isDirect() || bb.hasArray()) {
>             assertEquals(originalPos, bb.position());
>         } else {
>             assertEquals(originalLimit, bb.position());
>         }
>         assertEquals(originalLimit, bb.limit());
> 
> This will test long-standing (and undocumented) behavior. I created JDK-8352583 on the spec issue. It would be too risky to change behavior and advance the position. There may be some flexibility to not advance the position for the read-only buffer case, but we would need to work through the compatibility impacts of that. The fallback is to just document long standing behavior.

updated as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2425464873

From sherman at openjdk.org  Mon Oct 13 07:54:31 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 13 Oct 2025 07:54:31 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v9]
In-Reply-To: 
References: 
Message-ID: 

> ### Background
> 
> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
> 
> ### Problem
> 
> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
> 
> ### Solution
> 
> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
> 
> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
> 
> ### Benchmark
> 
> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
> 
> **Before:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
> 
> 
> **After:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  9002.842 ? 1099.635  ns/op
> Finished running test 'mi...

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

  test case update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27569/files
  - new: https://git.openjdk.org/jdk/pull/27569/files/8cd28a8a..520671a5

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

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

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

From dclarke at openjdk.org  Mon Oct 13 08:27:06 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Mon, 13 Oct 2025 08:27:06 GMT
Subject: RFR: 8368877: Generate Jextract bindings for Kqueue [v2]
In-Reply-To: 
References: 
 
Message-ID: <9TncZwS8yKAvtNMXMI42DuAxgGJ2pgB2aoiAkr0JirA=.d011bf55-deb6-4c34-a715-85421ef1599e@github.com>

On Mon, 6 Oct 2025 10:18:50 GMT, Darragh Clarke  wrote:

>> This PR is based on #25546 , though it was suggested to split that PR into 2 for easier reviewing and to give better visibility in the git history.
>> This PR contains all the JExtract generated code that will be needed for converting Java's KQueue implementation to use Panama features instead of JNI. The actual updates to KQueue to make use of these files will come in the second PR.
>> 
>> The basic structure here has the different native structures and methods split into 3 different packages all preceded by
>> `src/java.base/macosx/classes/jdk/internal/ffi/generated/`
>> Included in each package is a file `package-info.java` which contains the script that was used to generate these files so that others can reproduce them in future.
>> 
>> The only modifications that have been made to the files post-generation are:
>> - Adding copyright headers
>> - Adding warning suppression for using restricted methods
>> 
>> Some further modifications to these files to cut down on code duplication and adding support for errno handling on the native calls will come in the 2nd PR alongside the KQueue changes mentioned.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed comment and fixed newlines at end of files

/Integrate

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

PR Comment: https://git.openjdk.org/jdk/pull/27590#issuecomment-3396388579

From vklang at openjdk.org  Mon Oct 13 09:50:11 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 13 Oct 2025 09:50:11 GMT
Subject: RFR: 8368500: ContextClassLoader cannot be reset on threads in
 ForkJoinPool.commonPool() [v3]
In-Reply-To: <7lt8sFGw-MtUJZ-tGzAEi7lj4rk4jHurFerr5Iu9vOw=.36236606-3713-4f18-bea6-48bcf6a28cf1@github.com>
References: 
 <7lt8sFGw-MtUJZ-tGzAEi7lj4rk4jHurFerr5Iu9vOw=.36236606-3713-4f18-bea6-48bcf6a28cf1@github.com>
Message-ID: 

On Wed, 8 Oct 2025 06:58:40 GMT, Johny Jose  wrote:

>> The permanent disabling of the Security Manager in JDK 24  allow setCCL to set the CCL to a custom class loader. However, it doesn't allow it to be set to a custom class loader and then "reset" back to the system class loader before executing further code in the task. The changes are made to relax the restriction in setCCL to reset back to system class loader
>
> Johny Jose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup changes for test case

Changes requested by vklang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27648#pullrequestreview-3310753662

From vklang at openjdk.org  Mon Oct 13 09:50:16 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 13 Oct 2025 09:50:16 GMT
Subject: RFR: 8368500: ContextClassLoader cannot be reset on threads in
 ForkJoinPool.commonPool() [v2]
In-Reply-To: 
References: 
 
Message-ID: <-LMBeGajdAs4SdSp09fMreZfJRcQSqonIkpbvDFGIPA=.a109785b-00a4-4ead-a7bd-cc79aa3e8ad3@github.com>

On Tue, 7 Oct 2025 12:34:25 GMT, Johny Jose  wrote:

>> The permanent disabling of the Security Manager in JDK 24  allow setCCL to set the CCL to a custom class loader. However, it doesn't allow it to be set to a custom class loader and then "reset" back to the system class loader before executing further code in the task. The changes are made to relax the restriction in setCCL to reset back to system class loader
>
> Johny Jose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review changes

test/jdk/java/util/concurrent/forkjoin/ContextClassLoaderTest.java line 32:

> 30: 
> 31: import java.util.concurrent.CountDownLatch;
> 32: import java.util.concurrent.ForkJoinPool;

Suggestion:

test/jdk/java/util/concurrent/forkjoin/ContextClassLoaderTest.java line 59:

> 57:             assertSame(originalCCL, thread.getContextClassLoader(), "Original context class loader not restored");
> 58:             latch.countDown();
> 59:         });

These assertion failures will not get re-thrown in the test runner thread, so failures will just mean that the test hangs until the harness times it out.

If you do a commonPool().submit(?) instead and then get the Future returned by that, then you can do .get() on the Future to have it throw an exception in case of failure.

If you want to keep using `execute(?)` you can do the equivalent but instead wrapping the test logic in a try-catch and then set an exception on a pre-constructed Future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27648#discussion_r2411082731
PR Review Comment: https://git.openjdk.org/jdk/pull/27648#discussion_r2411094836

From michaelm at openjdk.org  Mon Oct 13 10:13:21 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 13 Oct 2025 10:13:21 GMT
Subject: RFR: 7105350: HttpExchange's attributes are the same as
 HttpContext's attributes [v5]
In-Reply-To: <_7C7kivl1GlzjlnfVGIjzBJLzIiUrQlgfA88zkHvPqY=.2672c6c7-27c0-47d5-b03b-8f0001e22e26@github.com>
References: 
 <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com>
 
 
 <_7C7kivl1GlzjlnfVGIjzBJLzIiUrQlgfA88zkHvPqY=.2672c6c7-27c0-47d5-b03b-8f0001e22e26@github.com>
Message-ID: 

On Wed, 8 Oct 2025 16:53:13 GMT, Josiah Noel  wrote:

>> @AlanBateman I hadn't realised that the HttpServer didn't already have access to `sun.net.*` - and I agree that it would be better if we did not add such an access. That said - the new property is a compatibility property - and documenting in module-info seemed a bit too much - so out of the way in `net.properties` seemed like an appealing place to add it. 
>> 
>> Another possibility could be to document it only in the release notes.
>
> Shall I revert the change and leave as a system property?

Could we get access to net.properties without needing to use that class in sun.net?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2425807256

From alanb at openjdk.org  Mon Oct 13 10:22:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Oct 2025 10:22:47 GMT
Subject: RFR: 7105350: HttpExchange's attributes are the same as
 HttpContext's attributes [v5]
In-Reply-To: 
References: 
 <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com>
 
 
 <_7C7kivl1GlzjlnfVGIjzBJLzIiUrQlgfA88zkHvPqY=.2672c6c7-27c0-47d5-b03b-8f0001e22e26@github.com>
 
Message-ID: 

On Mon, 13 Oct 2025 10:10:59 GMT, Michael McMahon  wrote:

> Could we get access to net.properties without needing to use that class in sun.net?

net.properties is user editable configuration (in ${java.home}/conf), it's not an encapsulated resource.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2425836895

From michaelm at openjdk.org  Mon Oct 13 10:40:04 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 13 Oct 2025 10:40:04 GMT
Subject: RFR: 7105350: HttpExchange's attributes are the same as
 HttpContext's attributes [v5]
In-Reply-To: 
References: 
 <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com>
 
 
 <_7C7kivl1GlzjlnfVGIjzBJLzIiUrQlgfA88zkHvPqY=.2672c6c7-27c0-47d5-b03b-8f0001e22e26@github.com>
 
 
Message-ID: 

On Mon, 13 Oct 2025 10:20:31 GMT, Alan Bateman  wrote:

> > Could we get access to net.properties without needing to use that class in sun.net?
> 
> net.properties is user editable configuration (in ${java.home}/conf), it's not an encapsulated resource.

I guess it still means duplicating the NetProperties class in jdk.httpserver, which might not be too desirable. Or alternatively create a httpserver specific properties file. Not sure it's worth all that effort unless other properties might migrate there also. Otherwise, we can revert to a simple system property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2425891383

From dclarke at openjdk.org  Mon Oct 13 11:07:18 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Mon, 13 Oct 2025 11:07:18 GMT
Subject: Integrated: 8368877: Generate Jextract bindings for Kqueue
In-Reply-To: 
References: 
Message-ID: 

On Wed, 1 Oct 2025 11:22:34 GMT, Darragh Clarke  wrote:

> This PR is based on #25546 , though it was suggested to split that PR into 2 for easier reviewing and to give better visibility in the git history.
> This PR contains all the JExtract generated code that will be needed for converting Java's KQueue implementation to use Panama features instead of JNI. The actual updates to KQueue to make use of these files will come in the second PR.
> 
> The basic structure here has the different native structures and methods split into 3 different packages all preceded by
> `src/java.base/macosx/classes/jdk/internal/ffi/generated/`
> Included in each package is a file `package-info.java` which contains the script that was used to generate these files so that others can reproduce them in future.
> 
> The only modifications that have been made to the files post-generation are:
> - Adding copyright headers
> - Adding warning suppression for using restricted methods
> 
> Some further modifications to these files to cut down on code duplication and adding support for errno handling on the native calls will come in the 2nd PR alongside the KQueue changes mentioned.

This pull request has now been integrated.

Changeset: 0db47028
Author:    Darragh Clarke 
URL:       https://git.openjdk.org/jdk/commit/0db47028913b64b84116d912876c58b136a9f70c
Stats:     1343 lines in 11 files changed: 1343 ins; 0 del; 0 mod

8368877: Generate Jextract bindings for Kqueue

Reviewed-by: alanb, aefimov

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

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

From jpai at openjdk.org  Mon Oct 13 11:14:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 Oct 2025 11:14:08 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein  wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27719#pullrequestreview-3331114106

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


/*
 * 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 final ScopedValue scope() {
			return (ScopedValue) SCOPE;
		}

		private final void preventReentry() throws IllegalStateException {
			if (Thread.holdsLock(this)) {
				throw new IllegalStateException("Recursive initialization of a stable value is illegal");
			}
		}

		@Override
		public boolean trySet(final T contents) throws NullPointerException, IllegalStateException {
			requireNonNull(contents);
			if (this.contents.isInitialized()) return false;

			preventReentry();
			synchronized (this) {
				return this.setImpl(contents);
			}
		}

		@Override
		@SuppressWarnings("unchecked")
		public final @Nullable T orNull() {
			return unwrapUnset(((LazyConstant) this.contents).orElse(UNSET));
		}

		@Override
		public T orElse(T other) throws NullPointerException {
			return this.contents.orElse(other);
		}

		@Override
		public T orElseThrow() throws NoSuchElementException {
			{ final T contents; if ((contents = this.orNull()) != null) {
				return contents;
			} }
			throw new NoSuchElementException();
		}

		@Override
		public boolean isSet() {
			return this.contents.isInitialized();
		}

		@Override
		public T orElseSet(final Supplier supplier) throws NullPointerException, IllegalStateException {
			requireNonNull(supplier);
			{ final T contents; if ((contents = this.orNull()) != null) {
				return contents;
			} }
			return orElseSetSlowPath(supplier);
		}

		@Override
		public void setOrThrow(final T contents) throws NullPointerException, IllegalStateException {
			if (!trySet(contents)) {
				throw new IllegalStateException();
			}
		}

		private final T orElseSetSlowPath(
			final Supplier supplier
		) throws NullPointerException, IllegalStateException {
			preventReentry();
			synchronized (this) {
				{ final T contents; if ((contents = this.orNull()) != null) {
					return contents;
				} }

				final T newValue;
				this.setImpl(newValue = requireNonNull(supplier.get()));
				return newValue;
			}
		}

		private final boolean setImpl(final T contents) {
			assert Thread.holdsLock(this);
			if (this.contents.isInitialized()) {
				return false;
			}

			ScopedValue.where(this.scope(), contents).run(this.contents::get);
			return true;
		}

		@Override
		public final boolean equals(final Object obj) {
			return this == obj;
		}

		@Override
		public final int hashCode() {
			return identityHashCode(this);
		}

		@Override
		public String toString() {
			final Object contents;
			return renderValue(
				"StableValue",
				(contents = this.orNull()) != this
					? contents
					: "(this StableValue)"
			);
		}
	}

	@SuppressWarnings("unchecked")
	private static final  @Nullable T unwrapUnset(final @Nullable Object obj) {
		return (obj == UNSET) ? null : (T) obj;
	}

	private static final String renderValue(
		final String type,
		final @Nullable Object value
	) throws NullPointerException {
		return (value == null)
			? type.concat(UNSET_SUFFIX)
			: (type + '[' + value + ']');
	}
}


    

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

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: 
 
Message-ID: 

On Thu, 2 Oct 2025 15:21:37 GMT, Jefferson Quesado  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`.

Unfortunately, BooleanSupplier does not extend Supplier.

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

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

From dfuchs at openjdk.org  Mon Oct 13 12:59:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 Oct 2025 12:59:49 GMT
Subject: RFR: 7105350: HttpExchange's attributes are the same as
 HttpContext's attributes [v5]
In-Reply-To: 
References: 
 <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com>
 
 
 <_7C7kivl1GlzjlnfVGIjzBJLzIiUrQlgfA88zkHvPqY=.2672c6c7-27c0-47d5-b03b-8f0001e22e26@github.com>
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 10:37:47 GMT, Michael McMahon  wrote:

>>> Could we get access to net.properties without needing to use that class in sun.net?
>> 
>> net.properties is user editable configuration (in ${java.home}/conf), it's not an encapsulated resource.
>
>> > Could we get access to net.properties without needing to use that class in sun.net?
>> 
>> net.properties is user editable configuration (in ${java.home}/conf), it's not an encapsulated resource.
> 
> I guess it still means duplicating the NetProperties class in jdk.httpserver, which might not be too desirable. Or alternatively create a httpserver specific properties file. Not sure it's worth all that effort unless other properties might migrate there also. Otherwise, we can revert to a simple system property.

+1 for reverting to a simple system property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2426274101

From mcimadamore at openjdk.org  Mon Oct 13 13:08:03 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 13:08:03 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.

test/jdk/java/lang/LazyConstant/DemoImperativeTest.java line 25:

> 23: 
> 24: /* @test
> 25:  * @summary Demo of an imperative stable value based on a lazy constant

Should this summary be updated (and. some of the classes defined here)

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

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

From mcimadamore at openjdk.org  Mon Oct 13 13:20:38 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 13:20:38 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/LazyCollections.java line 255:

> 253:     }
> 254: 
> 255:     interface LenientList extends List {

Ok, this seems needed to give access to `getAcquire` from sublists created from other sublists...

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...

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

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

From mcimadamore at openjdk.org  Mon Oct 13 13:30:34 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 13:30:34 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 42:

> 40: 
> 41: /**
> 42:  * A lazy constant is a deferred, shallowly immutable constant to be computed at

It seems like the javadoc is a snapshot of an earlier version of the JEP where the word "content" was replaced with "constant". I think we should go back to "content" and say (as we did for stable values) that a "A lazy constant is a holder of contents that can be set at most once."

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

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

From mcimadamore at openjdk.org  Mon Oct 13 13:34:33 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 13:34:33 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: 
References: 
Message-ID: <56kNzRwD6WRl9bHJUKb-YU1TuN6Tha_crXrwvfb-EmU=.c601a0b2-a66f-4d7f-9952-d235ee935fb1@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 98:

> 96:  * constant is not initialized.
> 97:  * 
    
> 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 duke at openjdk.org  Mon Oct 13 13:56:21 2025
From: duke at openjdk.org (Josiah Noel)
Date: Mon, 13 Oct 2025 13:56:21 GMT
Subject: RFR: 7105350: HttpExchange's attributes are the same as
 HttpContext's attributes [v6]
In-Reply-To: 
References: 
Message-ID: 

> Now ExchangeImpl will default to having a separate attribute map for the request duration.

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

  System property once more

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27652/files
  - new: https://git.openjdk.org/jdk/pull/27652/files/7711d93c..9a971fe4

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

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

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

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 dfuchs at openjdk.org  Mon Oct 13 14:05:44 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 Oct 2025 14:05:44 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v4]
In-Reply-To: <18wOsB1ycd6JEaIieaDFcDhoJMedcBTokO6gowhWLGA=.2098adf5-96b3-41fa-a9c3-6cc7d1af7398@github.com>
References: 
 <18wOsB1ycd6JEaIieaDFcDhoJMedcBTokO6gowhWLGA=.2098adf5-96b3-41fa-a9c3-6cc7d1af7398@github.com>
Message-ID: 

On Thu, 2 Oct 2025 16:19:56 GMT, Weibing Xiao  wrote:

>> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
>> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
>> 
>> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
>> 
>> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
>> 
>> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the code

The proposed solution needs more explaining, and integrate properly with the connection lock.

src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java line 497:

> 495:         } catch (IOException ioEx) {
> 496:             //ignore the error;
> 497:         }

Given that this is called after `conn.cleanup` and that `conn.cleanup` closes the socket if not null and set it to null after, can you explain in which circumstance this method would find a non-null `conn.sock`?

Another issue is that this method attempts to modify the state of the connection without holding the connection lock. This is not good.

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

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26566#pullrequestreview-3331775448
PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2426446665

From kfarrell at openjdk.org  Mon Oct 13 14:07:33 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Mon, 13 Oct 2025 14:07:33 GMT
Subject: [jdk25] RFR: 8369184: SimpleTimeZone equals() Returns True for Unequal
 Instances with Different hashCode Values
Message-ID: 

Clean backport

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

Commit messages:
 - Backport 37b725d9c12834358a562e6c03fb7f566d639ca5

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

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

From syan at openjdk.org  Mon Oct 13 14:07:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 13 Oct 2025 14:07:56 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein  wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

I have run the tests with jtreg8.1, and there is no new failure.

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27719#pullrequestreview-3331786495

From pchilanomate at openjdk.org  Mon Oct 13 14:10:15 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 13 Oct 2025 14:10:15 GMT
Subject: RFR: 8369019: Improve timed-park mechanism in ObjectMonitor for
 virtual thread support [v5]
In-Reply-To: 
References: 
 <8CQ5NYDakZIO2Y8agWBUgd12ReC2dJfgd-3rCZbemRo=.11fc27cb-6566-4bee-af83-591f10ae0295@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 05:08:52 GMT, David Holmes  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add string in asserts
>
> Okay - thanks for clarifying.

Thanks for the reviews and comments @dholmes-ora, @AlanBateman and @coleenp!

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

PR Comment: https://git.openjdk.org/jdk/pull/27597#issuecomment-3397686924

From pchilanomate at openjdk.org  Mon Oct 13 14:10:16 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 13 Oct 2025 14:10:16 GMT
Subject: Integrated: 8369019: Improve timed-park mechanism in ObjectMonitor for
 virtual thread support
In-Reply-To: 
References: 
Message-ID: 

On Wed, 1 Oct 2025 22:13:58 GMT, Patricio Chilano Mateo  wrote:

> Please review the following fix. When blocking in `ObjectMonitor::enter_internal` we currently use timed-park for pinned virtual threads. This is done to alleviate some potential deadlocks cases where the successor is an unmounted virtual thread that cannot run. In particular this could happen during class loading/initialization if all other carriers are blocked waiting for the same class to be loaded/initialized.
> This mechanism should be extended to cover `ObjectMonitor::reenter_internal` used in `Object.wait` (notification case). Also, the criteria to decide whether to do a timed-park should be based on whether there are unmounted vthreads already in the `_entry_list`, and not just if this is a pinned virtual thread. This covers mixed usages of the same ObjectMonitor between virtual threads and platform threads. This will become more relevant once we bring the changes currently in the fibers branch to preempt virtual threads during klass initialization.
> 
> These changes have been running in the loom pipeline for a couple of months already. I also added a new test case to test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java which deadlocks without these changes.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 9feb8f21
Author:    Patricio Chilano Mateo 
URL:       https://git.openjdk.org/jdk/commit/9feb8f21b5d000f8901938f1dde89638c79ca805
Stats:     206 lines in 4 files changed: 180 ins; 3 del; 23 mod

8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support

Reviewed-by: dholmes, alanb

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

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

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 dfuchs at openjdk.org  Mon Oct 13 14:17:12 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 Oct 2025 14:17:12 GMT
Subject: RFR: 7105350: HttpExchange's attributes are the same as
 HttpContext's attributes [v6]
In-Reply-To: 
References: 
 <6vO3ve_6Iro8hf-8QMehOa-mULE7hUOqxEEOwPmi-08=.e9dd5688-95a1-4de0-bcfe-5bf778ade8cc@github.com>
 
 
 
Message-ID: 

On Wed, 8 Oct 2025 12:53:48 GMT, Daniel Fuchs  wrote:

>> Yeah, I think we should put the property in `net.properties` something like this:
>> 
>> 
>>   # Prior to JDK 26, the HttpExchange attribute map was shared with the enclosing HttpContext.
>>   # Since JDK 26, by default, exchange attributes are per-exchange and the context attributes must
>>   # be accessed by calling getHttpContext().getAttributes(). Uncomment this property to
>>   # restore the pre JDK 26 behavior.
>>   #
>>   # jdk.httpserver.attributes=context
>> 
>> Then I think we should add a sentence at the end of the jdk.httpserver module-info to say that additional
>> system/networking properties may be defined in `net.properties`
>
> That proposal sounds good to me. Documenting the compatibiity in net.properties makes sense.

When talking with Michael he suggested that we could document the new property at the bottom of the module-info, in a new section dedicated to compatibility.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2426483886

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 duke at openjdk.org  Mon Oct 13 14:23:39 2025
From: duke at openjdk.org (Josiah Noel)
Date: Mon, 13 Oct 2025 14:23:39 GMT
Subject: RFR: 7105350: HttpExchange's attributes are the same as
 HttpContext's attributes [v7]
In-Reply-To: 
References: 
Message-ID: 

> Now ExchangeImpl will default to having a separate attribute map for the request duration.

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

  doc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27652/files
  - new: https://git.openjdk.org/jdk/pull/27652/files/9a971fe4..099d7652

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

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

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

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 kfarrell at openjdk.org  Mon Oct 13 14:39:18 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Mon, 13 Oct 2025 14:39:18 GMT
Subject: [jdk25] RFR: 8336695: Update Commons BCEL to Version 6.10.0
Message-ID: 

Clean backport

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

Commit messages:
 - Backport 3790965df3e7cba3b9792b8719d1e2ead046da15

Changes: https://git.openjdk.org/jdk/pull/27773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27773&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336695
  Stats: 2579 lines in 122 files changed: 1451 ins; 118 del; 1010 mod
  Patch: https://git.openjdk.org/jdk/pull/27773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27773/head:pull/27773

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

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 dfuchs at openjdk.org  Mon Oct 13 14:48:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 Oct 2025 14:48:03 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v4]
In-Reply-To: <18wOsB1ycd6JEaIieaDFcDhoJMedcBTokO6gowhWLGA=.2098adf5-96b3-41fa-a9c3-6cc7d1af7398@github.com>
References: 
 <18wOsB1ycd6JEaIieaDFcDhoJMedcBTokO6gowhWLGA=.2098adf5-96b3-41fa-a9c3-6cc7d1af7398@github.com>
Message-ID: <4eeQ0CbilDZk7lV_uym2Ljc2ml2scqzdXngypsxJd2g=.aa15ac6e-a2f7-4b45-b508-bc3d522f851f@github.com>

On Thu, 2 Oct 2025 16:19:56 GMT, Weibing Xiao  wrote:

>> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
>> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
>> 
>> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
>> 
>> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
>> 
>> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the code

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 728:

> 726: 
> 727:     // flush and close output stream
> 728:     private void flushAndCloseOutputStream() {

If this method no longer closes the output stream it should no longer be called `flushAndCloseOutputStream()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2426518167

From dfuchs at openjdk.org  Mon Oct 13 14:48:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 Oct 2025 14:48:06 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v4]
In-Reply-To: 
References: 
 <18wOsB1ycd6JEaIieaDFcDhoJMedcBTokO6gowhWLGA=.2098adf5-96b3-41fa-a9c3-6cc7d1af7398@github.com>
 
Message-ID: <28HuiAgul6pkdGJSzNJSDFejHnJ7GoZ-k-WmNs1p2vw=.919a1733-ecd7-4624-9451-af39309f3778@github.com>

On Mon, 13 Oct 2025 14:00:19 GMT, Daniel Fuchs  wrote:

>> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update the code
>
> src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java line 497:
> 
>> 495:         } catch (IOException ioEx) {
>> 496:             //ignore the error;
>> 497:         }
> 
> [OK - I missed that the cleanup method had been modified to no longer close the socket]
> 
> But another issue is that this method attempts to modify the state of the connection without holding the connection lock. This is not good.

One possibility could be to move this code to the connection so that it can participate in the locking.

However - I'm concerned that this proposed fix will reintroduced https://bugs.openjdk.org/browse/JDK-8313657

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2426563973

From henryjen at openjdk.org  Mon Oct 13 15:08:56 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 13 Oct 2025 15:08:56 GMT
Subject: Integrated: 8347007: --strip-debug removes parameter names included
 with -parameters
In-Reply-To: 
References: 
Message-ID: 

On Mon, 29 Sep 2025 23:36:00 GMT, Henry Jen  wrote:

> Since parameters is an opt-in choice, it's more reasonable to consider that's desired information and make strip parameter names an opt-in choice as well.
> 
> This PR changes the default behavior of --strip-debug to keep parameter names when it's available. Add opt-in mechanism,
> via the strip-java-debug-attributes plugin by using argument `--strip-java-debug-attributes=+parameter-names`.
> 
> The --strip-debug option is a little bit odd, as it's a main option as well as a plugin option to enable the DefaultStripDebugPlugin, which strip native debug information on platform support the feature, and strip java debug information. In this PR, we chose to support only one mechanism to enable strip parameter names, so we would disable the embed StripJavaDebugAttributesPlugin when StripJavaDebugAttributesPlugin is enabled.
> 
> The StripParameterNamesTest illustrate and verify parameter names use cases, mainly focus on argument processing and the parameter names. We didn't verify the regular debug info as that's covered by existing test.
> 
> -- Update
> 
> The latest change removed the support of strip parameter names, as the MethodParameters attribute is considered necessary attribute to fulfill Java Language Spec even though this attribute is considered optional by JVM spec.

This pull request has now been integrated.

Changeset: b83e7939
Author:    Henry Jen 
URL:       https://git.openjdk.org/jdk/commit/b83e7939dd9401314f2351a9fefd1e212387c6e5
Stats:     296 lines in 5 files changed: 289 ins; 2 del; 5 mod

8347007: --strip-debug removes parameter names included with -parameters

Reviewed-by: alanb

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

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

From dfuchs at openjdk.org  Mon Oct 13 15:18:45 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 Oct 2025 15:18:45 GMT
Subject: RFR: 7105350: HttpExchange's attributes are the same as
 HttpContext's attributes [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 13 Oct 2025 14:23:39 GMT, Josiah Noel  wrote:

>> Now ExchangeImpl will default to having a separate attribute map for the request duration.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doc

src/jdk.httpserver/share/classes/module-info.java line 108:

> 106:  * be accessed by calling getHttpContext().getAttributes(). Set this property to "context"
> 107:  * to restore the pre JDK 26 behavior.
> 108:  * 

I would suggest to move that to an `@implNote` - something like:

Suggestion:

 * 
 * 
 * @implNote
 * Prior to JDK 26, in the JDK default implementation, the {@link HttpExchange} attribute map was
 * shared with the enclosing {@link HttpContext}.
 * Since JDK 26, by default, exchange attributes are per-exchange and the context attributes must
 * be accessed by calling {@link HttpExchange#getHttpContext() getHttpContext()}
 * {@link HttpContext#getAttributes() HttpContext.getAttributes()}. 
    
 * A new system property, {@systemProperty jdk.httpserver.attributes} (default value: {@code ""})
 * allows to revert this new behavior. Set this property to "context" to restore the pre JDK 26 behavior.
 * 


@Michael-Mc-Mahon what do you think?

(@SentryMan please double check whether some package should imported - or the `{@link }` modified to use full pacakage names for the links to work properly in the generated API doc)

src/jdk.httpserver/share/classes/module-info.java line 111:

> 109:  *
> 110:  * Additional system/networking properties may be defined in the {@code conf/net.properties} configuration file.
> 111:  *

@Michael-Mc-Mahon should we keep that paragraph? It looks like it could be removed now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2426635214
PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2426600519

From duke at openjdk.org  Mon Oct 13 16:05:16 2025
From: duke at openjdk.org (Josiah Noel)
Date: Mon, 13 Oct 2025 16:05:16 GMT
Subject: RFR: 7105350: HttpExchange's attributes are the same as
 HttpContext's attributes [v8]
In-Reply-To: 
References: 
Message-ID: 

> Now ExchangeImpl will default to having a separate attribute map for the request duration.

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

  implnote

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27652/files
  - new: https://git.openjdk.org/jdk/pull/27652/files/099d7652..2880dffc

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

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

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

From jlu at openjdk.org  Mon Oct 13 16:14:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 13 Oct 2025 16:14:31 GMT
Subject: Integrated: 8369452: Locale.Builder.setLanguageTag(String) does not
 clear on empty or null String
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Oct 2025 18:12:58 GMT, Justin Lu  wrote:

> Please review this PR which corrects the behavior of `Locale.Builder.setLanguageTag(String)` on the null and empty String case.
> 
> This method is specified as follows,
> 
>> Null and the empty string cause the builder to be reset
> 
> Currently, NPE is thrown for a null tag, and ILE is thrown for an empty String. They are both corrected to not throw, and instead reset the state of the `Locale.Builder`.

This pull request has now been integrated.

Changeset: 1d6cafdc
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/1d6cafdc5244960ddec2fd82b8454c6c3cafe022
Stats:     27 lines in 2 files changed: 22 ins; 0 del; 5 mod

8369452: Locale.Builder.setLanguageTag(String) does not clear on empty or null String

Reviewed-by: naoto

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

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

From dfuchs at openjdk.org  Mon Oct 13 16:27:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 Oct 2025 16:27:03 GMT
Subject: RFR: 7105350: HttpExchange's attributes are the same as
 HttpContext's attributes [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 13 Oct 2025 16:05:16 GMT, Josiah Noel  wrote:

>> Now ExchangeImpl will default to having a separate attribute map for the request duration.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implnote

src/jdk.httpserver/share/classes/module-info.java line 111:

> 109:  * Since JDK 26, by default, exchange attributes are per-exchange and the context attributes must
> 110:  * be accessed by calling {@link HttpExchange#getHttpContext() getHttpContext()}
> 111:  * {@link HttpContext#getAttributes() HttpContext.getAttributes()}. 
    

Suggestion:

 * be accessed by calling {@link HttpExchange#getHttpContext() getHttpContext()}{@link
 * HttpContext#getAttributes() .getAttributes()}. 
    


Sorry, there was a mistake in my previous suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2426798503

From duke at openjdk.org  Mon Oct 13 16:32:24 2025
From: duke at openjdk.org (Josiah Noel)
Date: Mon, 13 Oct 2025 16:32:24 GMT
Subject: RFR: 7105350: HttpExchange's attributes are the same as
 HttpContext's attributes [v9]
In-Reply-To: 
References: 
Message-ID: 

> Now ExchangeImpl will default to having a separate attribute map for the request duration.

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

  Update module-info.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27652/files
  - new: https://git.openjdk.org/jdk/pull/27652/files/2880dffc..1164702a

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

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

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

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 alanb at openjdk.org  Mon Oct 13 17:13:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Oct 2025 17:13:00 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 13 Oct 2025 07:54:31 GMT, Xueming Shen  wrote:

>> ### Background
>> 
>> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
>> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
>> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
>> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
>> 
>> ### Problem
>> 
>> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
>> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
>> 
>> ### Solution
>> 
>> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
>> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
>> 
>> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
>> 
>> ### Benchmark
>> 
>> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
>> 
>> **Before:**
>> 
>> 
>> Benchmark                                               Mode  Cnt     Score      Error  Units
>> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
>> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
>> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
>> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
>> 
>> 
>> **After:**
>> 
>> 
>> Benchmark                                               Mode  Cnt     Score      Error  Units
>> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
>> ClassLoaderDefineClass.testDefineClassByt...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test case update

Updated test looks good. Just one comment on testDefineClassWithBuiltinLoaderByteBuffer where I note it can check the buffer position after the defineClass.

test/jdk/java/lang/ClassLoader/defineClass/DefineClassDirectByteBuffer.java line 29:

> 27:  * @bug 8365588
> 28:  *
> 29:  * @library /lib/testlibrary/java/lang

What is this used for?

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27569#pullrequestreview-3332401739
PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2426886855

From emcmanus at google.com  Mon Oct 13 17:16:00 2025
From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=)
Date: Mon, 13 Oct 2025 10:16:00 -0700
Subject: Duration.MAX_VALUE
In-Reply-To: 
References: 
 
 
Message-ID: 

I agree that it would be weird for Duration.MIN not to be the true minimum
Duration value, and that weirdness outweighs the quirk whereby
Duration.MIN.negated() throws an exception.

[It's much too late to do anything about it now, of course, but I would
argue that it would have been better for Duration values to be completely
symmetrical about zero. I think the parallel with Long.MIN_VALUE (etc)
doesn't really work. There, the use of two's complement and the fact that
every bit pattern is a valid long value together force there to be one more
negative value than positive. That leads to all sorts of problems, like
Math.abs sometimes being negative. I don't think the same considerations
apply to Duration.]

Although I gave some use cases for Duration.MAX earlier, I'm not actually
aware of any for Duration.MIN. That's partly because Google's internal
Durations class defines a public MAX but not a MIN. (Partly out of concern
that MIN could be misconstrued to mean the smallest positive Duration, like
Double.MIN_VALUE.) So I think it would be an option to define just MAX.

On Sun, 12 Oct 2025 at 15:26, Stephen Colebourne 
wrote:

> Just noting that the conceptual definition of Duration.MAX and MIN
> have been in use since Java 8, and I disagree with any change to the
> current definition.
>
> You cannot successfully negate Long.MIN_VALUE, so there is no
> requirement that edge cases like this support negation.
>
> Stephen
>
>
> On Wed, 8 Oct 2025 at 21:29, Pavel Rappo  wrote:
> >
> > In another thread, there's a question on whether we can define
> > Duration.MIN such that it's not the exact minimum, but rather the
> > minimum "negatable minimum"? Put differently, can we define
> > Duration.MIN as Duration.MAX.negated(), where Duration.MAX is
> > Duration.ofSeconds(Long.MAX_VALUE, 999_999_999)? What are the concerns
> > with this, if any?
> >
> > -Pavel
> >
> > On Wed, Sep 3, 2025 at 1:49?PM Pavel Rappo 
> wrote:
> > >
> > > Couldn't recall or quickly find if this was asked before.
> > >
> > > I come across this quite often: there doesn?t seem to be a readily
> > > available maximum value for java.time.Duration -- a value that
> > > represents the longest possible duration.
> > >
> > > I assume there are plenty of homegrown constants out in the wild
> > > addressing this. Don?t get me wrong: it?s not hard to create one. The
> > > issue, in my experience, is that it takes time and sometimes
> > > experimentation.
> > >
> > > Unless one reads the Javadoc carefully, it?s not obvious that the
> > > maximum duration can be constructed as follows:
> > >
> > >     Duration.of(Long.MAX_VALUE, 999_999_999);
> > >
> > > Naturally, one might first try using IDE autocomplete. For example,
> > > creating a Duration from Long.MAX_VALUE of a large unit -- millennia,
> > > centuries, decades, etc. -- only to run into ArithmeticException. Only
> > > when reaching seconds does it finally work:
> > >
> > >     Duration.ofSeconds(Long.MAX_VALUE);
> > >
> > > or
> > >
> > >     Duration.of(Long.MAX_VALUE, ChronoUnit.SECONDS);
> > >
> > > Of course, there?s no practical difference between
> > > Duration.of(Long.MAX_VALUE, 999_999_999) and
> > > Duration.ofSeconds(Long.MAX_VALUE). We?re talking about durations on
> > > the order of 292 billion years, after all. The exact value isn?t the
> > > problem. The problem is that the values are inconsistent, and arriving
> > > to them is error-prone. Adding a constant to java.time.Duration would
> > > simplify things.
> > >
> > > -Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5281 bytes
Desc: S/MIME Cryptographic Signature
URL: 

From sherman at openjdk.org  Mon Oct 13 17:44:22 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 13 Oct 2025 17:44:22 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v10]
In-Reply-To: 
References: 
Message-ID: 

> ### Background
> 
> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
> 
> ### Problem
> 
> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
> 
> ### Solution
> 
> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
> 
> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
> 
> ### Benchmark
> 
> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
> 
> **Before:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
> 
> 
> **After:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  9002.842 ? 1099.635  ns/op
> Finished running test 'mi...

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

  test case update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27569/files
  - new: https://git.openjdk.org/jdk/pull/27569/files/520671a5..8fbf1117

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

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

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

From sherman at openjdk.org  Mon Oct 13 17:44:25 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 13 Oct 2025 17:44:25 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v9]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 13 Oct 2025 17:08:09 GMT, Alan Bateman  wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test case update
>
> test/jdk/java/lang/ClassLoader/defineClass/DefineClassDirectByteBuffer.java line 29:
> 
>> 27:  * @bug 8365588
>> 28:  *
>> 29:  * @library /lib/testlibrary/java/lang
> 
> What is this used for?

removed. leftover from my early draft

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2426958984

From alanb at openjdk.org  Mon Oct 13 17:49:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Oct 2025 17:49:33 GMT
Subject: RFR: 8365588: defineClass that accepts a ByteBuffer does not work
 as expected [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 13 Oct 2025 17:44:22 GMT, Xueming Shen  wrote:

>> ### Background
>> 
>> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
>> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
>> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
>> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
>> 
>> ### Problem
>> 
>> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
>> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
>> 
>> ### Solution
>> 
>> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
>> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
>> 
>> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
>> 
>> ### Benchmark
>> 
>> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
>> 
>> **Before:**
>> 
>> 
>> Benchmark                                               Mode  Cnt     Score      Error  Units
>> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
>> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
>> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
>> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
>> 
>> 
>> **After:**
>> 
>> 
>> Benchmark                                               Mode  Cnt     Score      Error  Units
>> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
>> ClassLoaderDefineClass.testDefineClassByt...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test case update

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27569#pullrequestreview-3332531203

From emcmanus at google.com  Mon Oct 13 17:56:16 2025
From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=)
Date: Mon, 13 Oct 2025 10:56:16 -0700
Subject: Duration.MAX_VALUE
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
 
 
 
 
Message-ID: 

On Thu, 9 Oct 2025 at 07:25, Pavel Rappo  wrote:

> Out of curiosity, how is Instants.saturatedSubtract(Instant, Duration)
> used?


That is an excellent question, and it prompted me to look into saturated
addition and subtraction in a bit more detail. As an experiment, I tried
running all of Google's internal tests against a modified Instants class
where saturatedAdd and saturatedSubtract behaved identically to regular
Instant.add/subtract(Duration). That led to hundreds of test failures,
although I think there might have been fewer than 10 distinct root causes.
Then I retried the failing tests with only saturatedSubtract being changed.
All but one of the previously-failing tests now passed. That shows that
saturatedAdd has a much wider applicability than saturatedSubtract.

I get the impression from looking at some samples that people are often
using saturatedSubtract out of an abundance of caution rather than having a
real reason to think the subtraction might overflow. Many of the examples I
saw were using fixed-length durations, which could only overflow if being
subtracted from Instant.MIN or thereabouts.

The one test that failed with saturatedSubtract was testing code that does
something like this:

Instant finalizationTime = ...;
boolean recentlyFinalized =
    finalizationTime.isAfter(
        Instants.saturatedSubtract(now, minAgeForDeletion));

The idea is that something can only be deleted if it was *not* "recently
finalized". If it was finalized less than minAgeForDeletion time ago then
it can't be deleted. In the failing test, minAgeForDeletion is
Durations.MAX, which signals that something can never be deleted (it will
always be recently finalized).
The code could just as easily do this:

boolean recentlyFinalized =
    now.isBefore(
        Instants.saturatedAdd(finalizationTime, minAgeForDeletion));

So I don't think this is a particularly convincing use case for
saturatedSubtract. The main reason for having it would be that it might be
surprising to have add but not subtract.

?amonn

On Thu, 9 Oct 2025 at 07:25, Pavel Rappo  wrote:

> Out of curiosity, how is Instants.saturatedSubtract(Instant, Duration)
> used?
>
> On Wed, Oct 8, 2025 at 2:13?AM ?amonn McManus  wrote:
> >
> > Yes, we have utility classes Instants and Durations, and Instants
> includes methods Instants.saturatedAdd(Instant, Duration) and
> Instants.saturatedSubtract(Instant, Duration). Each has a modest number of
> uses in the codebase, about three orders of magnitude less than the number
> of classes that reference Instant or Duration.
> >
> > On Tue, 7 Oct 2025 at 14:18, Pavel Rappo  wrote:
> >>
> >> ?amonn, Kurt,
> >>
> >> Is there any saturating arithmetic for instant + duration in your code
> base?
> >>
> >>
> >>
> >> On Fri, Sep 5, 2025 at 8:58?PM ?amonn McManus 
> wrote:
> >> >
> >> > As promised, Kurt and I have examined some of the uses of our
> Durations.MAX constant. This is a summary of what we see in a random sample
> of 30 out of about 700 usages in Google's (giant) codebase.
> >> >
> >> > First, about half of the usages specifically concern deadlines. Many
> of them involve a method that sets an RPC deadline and where it is
> explicitly documented that you should use Durations.MAX to mean no deadline
> (or equivalently, infinite deadline).
> >> >
> >> > Several other usages concern deadline-adjacent concepts such as
> time-to-live or cache expiration delay.
> >> >
> >> > A number of usages specifically compare a Duration against
> Durations.MAX to recognize the "infinite duration" value.
> >> >
> >> > One usage uses our internal Sleeper interface to do
> sleeper.sleep(Durations.MAX), for an indefinite sleep (until interrupted).
> >> >
> >> > In a couple of places, there is a maximum allowed Duration for some
> operation, and a user-supplied Duration value is capped by this maximum.
> When no maximum is needed, the cap is Durations.MAX. This is similar to the
> "sentinel" use case I mentioned earlier.
> >> >
> >> > One case is using Durations.MAX in a test, to ensure that a function
> works correctly for all Duration values including the largest one. It is
> testing a Kotlin extension function that allows you to write e.g. 5.minutes:
> >> >
> >> >     val n = Durations.MAX.toMinutes()
> >> >
> >> >     assertThat(n.minutes).isEqualTo(Duration.ofMinutes(n))
> >> >
> >> >     assertFailsWith { (n + 1).minutes }
> >> >
> >> >
> >> > In summary, I think the most interesting use cases fall into these
> categories:
> >> >
> >> > to express an effectively-infinite Duration, possibly accompanied by
> special-case logic to optimize the exact value Durations.MAX;
> >> >
> >> > to express the absence of an optional cap on a user-supplied Duration
> value;
> >> >
> >> > to test that code works correctly even with extreme Duration values.
> >> >
> >> >
> >> > Of these, the first is potentially fragile because of the overflow
> problems we discussed. The other two seem unproblematic, though.
> >> >
> >> >
> >> >
> >> > On Thu, 4 Sept 2025 at 15:02, ?amonn McManus 
> wrote:
> >> >>
> >> >> Two typical use cases:
> >> >>
> >> >> // 1. Sentinel
> >> >> Duration min = Duration.MAX;
> >> >> for (var foo : something()) {
> >> >>   if (foo.duration().compareTo(min) < 0) {
> >> >>     min = foo.duration();
> >> >>   }
> >> >> }
> >> >>
> >> >> // 2. "Forever"
> >> >> void frob(Optional optionalTimeout) {
> >> >>   Duration timeout = optionalTimeout.orElse(Duration.MAX);
> >> >>   Instant start = Instant.now();
> >> >>   boolean done = false;
> >> >>   while (!done && startTime.until(Instant.now()).compareTo(timeout)
> < 0) {...}
> >> >> }
> >> >>
> >> >> The second case illustrates why this is potentially a bit delicate.
> You better not write this:
> >> >>
> >> >> void frob(Optional optionalTimeout) {
> >> >>   Duration timeout = optionalTimeout.orElse(Duration.MAX);
> >> >>   Instant deadline = Instant.now().plus(timeout); // oops
> >> >>   boolean done = false;
> >> >>   while (!done && Instant.now().isBefore(deadline)) {...}
> >> >> }
> >> >>
> >> >> Like Kevin, I am skeptical about Duration.MIN. If it means the most
> negative Duration, that is just Duration.MAX.negated(); and if it means the
> smallest positive Duration, that is just Duration.ofNanos(1).
> >> >>
> >> >> On Wed, 3 Sept 2025 at 18:32, Roger Riggs 
> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> I'd be interested in the range of use cases for Duration.MAX or MIN.
> >> >>>
> >> >>> But for deadlines, I think the code should compute the deadline
> from a Duration of its choice based on the use.
> >> >>> Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that
> ignores information about the particular use that is relevant. Its just
> sloppy code that doesn't bother to express how long is long enough to meet
> operational parameters.
> >> >>>
> >> >>> YMMV, Roger
> >> >>>
> >> >>> On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote:
> >> >>>
> >> >>> Duration.MIN is a whole 'nother bag of worms, because Durations are
> signed (they can be positive or negative...or zero). Internally we also
> have Durations.MIN, but it's not public ... and along with it, I left
> myself a helpful note about naming:
> >> >>>
> >> >>>   /** The minimum supported {@code Duration}, approximately -292
> billion years. */
> >> >>>   // Note: before making this constant public, consider that "MIN"
> might not be a great name (not
> >> >>>   //       everyone knows that Durations can be negative!).
> >> >>>   static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE);
> >> >>>
> >> >>> This reminds me of Double.MIN_VALUE (which is the smallest
> _positive_ double value) --- we've seen Double.MIN_VALUE misused so much
> that we introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias.
> A large percent of Double.MIN_VALUE users actually want the smallest
> possible negative value, aka -Double.MAX_VALUE.
> >> >>>
> >> >>> If we introduce Duration.MIN, I hope it would not be
> Duration.ofNanos(1), but rather Duration.ofSeconds(Long.MIN_VALUE).
> >> >>>
> >> >>> On Wed, Sep 3, 2025 at 7:59?PM ecki  wrote:
> >> >>>>
> >> >>>> If you ask me, I don?t find it very useful, It won?t work for
> arithmetrics, even the APIs would have a hard time using it (how do you
> express the deadline) and APIs with a timeout parameter do have a good
> reason for it, better pick ?possible? values for better self healing and
> unstuck of systems. In fact I would err on the smaller side in combination
> with expecting spurious wakeups.
> >> >>>>
> >> >>>> BTW, when you introduce MIN as well, maybe also think about min
> precision, min delta or such. Will it always be 1 nano?
> >> >>>>
> >> >>>> Gru?,
> >> >>>> Bernd
> >> >>>> --
> >> >>>> https://bernd.eckenfels.net
> >> >>>> ________________________________
> >> >>>> Von: core-libs-dev  im Auftrag
> von Pavel Rappo 
> >> >>>> Gesendet: Donnerstag, September 4, 2025 12:41 AM
> >> >>>> An: Kurt Alfred Kluever 
> >> >>>> Cc: Stephen Colebourne ; core-libs-dev <
> core-libs-dev at openjdk.org>
> >> >>>> Betreff: Re: Duration.MAX_VALUE
> >> >>>>
> >> >>>> This is useful; thanks. It would be good to see more of your data.
> >> >>>>
> >> >>>> My use case is also duration which practically means **forever**. I
> >> >>>> pass it to methods that accept timeouts, and expect these methods
> to
> >> >>>> correctly interpret it.
> >> >>>>
> >> >>>> One example of a practical interpretation is
> >> >>>> java.util.concurrent.TimeUnit.convert(Duration). This method never
> >> >>>> overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is
> >> >>>> roughly 292 years.
> >> >>>>
> >> >>>> Would I be okay, if the proposed duration didn't reflect
> **forever**
> >> >>>> but instead reflected **long enough**? I think so. But it still
> >> >>>> somehow feels wrong to make it less than maximum representable
> value.
> >> >>>>
> >> >>>> Personally, I'm not interested in calendar arithmetic, that is, in
> >> >>>> adding or subtracting durations. Others might be, and that's okay
> and
> >> >>>> needs to be factored in. For better or worse, java.time made a
> choice
> >> >>>> to be unforgiving in regard to overflow and is very upfront about
> it.
> >> >>>> It's not only proposed Duration.MAX. The same thing happens if you
> try
> >> >>>> this
> >> >>>>
> >> >>>> Instant.MAX.toEpochMilli()
> >> >>>>
> >> >>>> I guess my point is that doing calendar arithmetic on an unknown
> value
> >> >>>> is probably wrong. Doing it on a known huge/edge-case value is
> surely
> >> >>>> wrong. So back to your data. I would be interested to see what
> >> >>>> triggers overflows for your Durations.MAX.
> >> >>>>
> >> >>>> On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever 
> wrote:
> >> >>>> >
> >> >>>> > Hi all,
> >> >>>> >
> >> >>>> > Internally at Google, we've had a Durations.MAX constant exposed
> for the past 7 years. It now has about 700 usages across our depot, which I
> can try to categorize (at a future date).
> >> >>>> >
> >> >>>> > While I haven't performed that analysis yet, I think exposing
> this constant was a bit of a mistake. People seem to want to use MAX to
> mean "forever" (often in regards to an RPC deadline). This works fine as
> long as every single layer that touches the deadline is very careful about
> overflow. The only reasonable thing you can do with MAX is compareTo() and
> equals(). Attempting to do any simple math operation (e.g., now+deadline)
> is going to explode. Additionally, decomposing Duration.MAX explodes for
> any sub-second precision (e.g., toMillis()).
> >> >>>> >
> >> >>>> > As we dug into this, another proposal came up which was
> something like Durations.VERY_LONG. This duration would be longer than any
> reasonable finite duration but not long enough to cause an overflow when
> added to any reasonable time. E.g., a million years would probably satisfy
> both criteria. This would mean math operations and decompositions won't
> explode (well, microseconds and nanoseconds still would), and it could
> safely be used as a relative timeout.
> >> >>>> >
> >> >>>> > As I mentioned above, I'd be happy to try to categorize a sample
> of our 700 existing usages if folks think that would be useful for this
> proposal.
> >> >>>> >
> >> >>>> > Thanks,
> >> >>>> >
> >> >>>> > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin
> Ecosystem team)
> >> >>>> >
> >> >>>> > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo <
> pavel.rappo at gmail.com> wrote:
> >> >>>> >>
> >> >>>> >> If I understood you correctly, you think we should also add
> >> >>>> >> Duration.MIN. If so, what use case do you envision for it? Or
> we add
> >> >>>> >> if purely for symmetry with Instant?
> >> >>>> >>
> >> >>>> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo <
> pavel.rappo at gmail.com> wrote:
> >> >>>> >> >
> >> >>>> >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne <
> scolebourne at joda.org> wrote:
> >> >>>> >> > >
> >> >>>> >> > > Hmm, yes. Not sure why that didn't get added in Java 8!
> >> >>>> >> > > The constants would be MAX/MIN as per classes like Instant.
> >> >>>> >> > > Stephen
> >> >>>> >> >
> >> >>>> >> > I thought that naming could be tricky :) The public constant
> >> >>>> >> > Duration.ZERO and the public method isZero() are already
> there.
> >> >>>> >> > However, it does not preclude us from naming a new constant
> MAX.
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > --
> >> >>>> > kak
> >> >>>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> kak
> >> >>>
> >> >>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5281 bytes
Desc: S/MIME Cryptographic Signature
URL: 

From lancea at openjdk.org  Mon Oct 13 18:26:40 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 13 Oct 2025 18:26:40 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v4]
In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
Message-ID: 

> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
> 
> - Deprecate SQLPermission for removal
> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
> 
> Tiers 1-3 have been run

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

  Round 3 of formating/typo updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27693/files
  - new: https://git.openjdk.org/jdk/pull/27693/files/0f9876b2..1c1c8047

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

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

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

From lancea at openjdk.org  Mon Oct 13 18:26:49 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 13 Oct 2025 18:26:49 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v3]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
 
Message-ID: 

On Fri, 10 Oct 2025 20:13:14 GMT, Roger Riggs  wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spacing clean up in ConnectionTests
>
> src/java.sql/share/classes/java/sql/Array.java line 384:
> 
>> 382:   default void close() throws SQLException {
>> 383:     free();
>> 384:   };
> 
> The indention in this file is 4 spaces.
> Also check new close() methods in Blob, Clob and SQLXML.

fixed(SQLXML looked ok)

the joys of using different IDEs over the years

> src/java.sql/share/classes/java/sql/Connection.java line 1680:
> 
>> 1678:         throw new SQLFeatureNotSupportedException("setShardingKey not implemented");
>> 1679:     }
>> 1680:     // JDBC 4.5
> 
> Would this be information to developers if added in and @apiNote as a function in supported by JDBC 4.5.

This is just informational separation from within the interface as to where the JDBC 4.5 additions were added as had been done in previous releases.  The package-info cross references the JDBC xxx -> JDK xxx

> src/java.sql/share/classes/java/sql/Connection.java line 1747:
> 
>> 1745:      * 
  • The first character is an alphabetic character from a through z, or
>> 1746:      * from A through Z
    • 
>> 1747:      * 
  • The name only contains alphanumeric characters or the character "_"
    • 
> 
> Trailing  tags can be omitted to make the source more readable.  YMMV

Some tools complain(or used to anyways) if the closing tag is not provided.    So I am going to leave it for now and if/when we decide to change it, I would go through all of java.sql and probably would want to do the same for other areas of the JDK which include them.

FWIW, [www.w3schools.com](https://www.w3schools.com/tags/tag_li.asp) shows including them in their tutorial still

> src/java.sql/share/classes/java/sql/Connection.java line 1816:
> 
>> 1814:      * @param alwaysQuote indicates if a simple SQL identifier should be
>> 1815:      * returned as a quoted identifier
>> 1816:      * @return A simple SQL identifier or a delimited identifier
> 
> Is there a difference between a "quoted identifier" and a "delimited identifier"?
> The terminology should be consistent (with the jdbc spec).

A quoted identifier is a form of a delimited identifier and are often interchangeable(depending on the database).  The intent here was to be specific as some databases did not support  quotes

> src/java.sql/share/classes/java/sql/Connection.java line 1827:
> 
>> 1825:         int len = identifier.length();
>> 1826:         if (len < 1 || len > 128) {
>> 1827:             throw new SQLException("Invalid name");
> 
> The exception would be easier to debug if the identifier were included in the exception.

We talked about this during original implementation added in  JDK 9 and the feedback at the time was not to provide the name

> src/java.sql/share/classes/java/sql/Connection.java line 1829:
> 
>> 1827:             throw new SQLException("Invalid name");
>> 1828:         }
>> 1829:         if (Pattern.compile("[\\p{Alpha}][\\p{Alnum}_]*").matcher(identifier).matches()) {
> 
> In the implementation, it would save a bit of performance to do the Pattern.compile once instead of on every invocation.   ?ConstantValue or Holder class, or static.

Will look at this a part of the follow on work where we an additional internal class to host these methods which are then called by Connection/Statement as suggested by Alan

> src/java.sql/share/classes/java/sql/Connection.java line 1832:
> 
>> 1830:             return alwaysQuote ?  "\"" + identifier + "\"" : identifier;
>> 1831:         }
>> 1832:         if (identifier.matches("^\".+\"$")) {
> 
> Ditto: precompile the regex.

See above

> src/java.sql/share/classes/java/sql/Connection.java line 1835:
> 
>> 1833:             identifier = identifier.substring(1, len - 1);
>> 1834:         }
>> 1835:         if (Pattern.compile("[^\u0000\"]+").matcher(identifier).matches()) {
> 
> Could `identifier.indexOf(0)` be a more efficient way to look for an embedded null.

see above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2426863941
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2426872970
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2426890121
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2426894289
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2426926467
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2426955825
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2426956264
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2426958129

From lancea at openjdk.org  Mon Oct 13 18:26:50 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 13 Oct 2025 18:26:50 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v4]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
 
 
Message-ID: 

On Sat, 11 Oct 2025 11:21:48 GMT, Johannes D?bler  wrote:

>> I hadn't but can look at this for follow on clean up before GA and after CSR is approved.
>
> Also from the perspective of a JDBC driver provider it would be beneficial to have the default implementations in Statement..enquoteLiteral() and Statement.enquoteIdentifier() call the new methods in Connection. Driver implementations would then only need to override the Connection methods if they want to adjust the default implementation.

JDBC driver vendors can certainly optimize these methods for their own driver implementations and should.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2426939982

From lancea at openjdk.org  Mon Oct 13 18:26:52 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 13 Oct 2025 18:26:52 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v3]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
 
Message-ID: <6v47QeHNaJiWnV1ITHG1KrqmInOPQeF2vVL6W3FVTY4=.a1d8bd8a-c8b9-4b50-b581-9c6d711569d8@github.com>

On Sat, 11 Oct 2025 11:17:32 GMT, Thomas Zimmermann  wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spacing clean up in ConnectionTests
>
> src/java.sql/share/classes/java/sql/JDBCType.java line 214:
> 
>> 212: 
>> 213:     /**
>> 214:      * Identifies the generic SQL type {@code DECFLOAT}.
> 
> Suggestion:
> 
>      * Identifies the generic SQL type {@code JSON}.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2426942750

From liach at openjdk.org  Mon Oct 13 18:49:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 Oct 2025 18:49:05 GMT
Subject: [jdk25] RFR: 8369184: SimpleTimeZone equals() Returns True for
 Unequal Instances with Different hashCode Values
In-Reply-To: 
References: 
Message-ID: 

On Mon, 13 Oct 2025 13:58:04 GMT, Kieran Farrell  wrote:

> Clean backport

Hi, I don't think this is the right branch to backport to - you should backport to the master branch of jdk25u repo.

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

PR Comment: https://git.openjdk.org/jdk/pull/27772#issuecomment-3398668419

From kfarrell at openjdk.org  Mon Oct 13 19:34:14 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Mon, 13 Oct 2025 19:34:14 GMT
Subject: [jdk25] Withdrawn: 8369184: SimpleTimeZone equals() Returns True for
 Unequal Instances with Different hashCode Values
In-Reply-To: 
References: 
Message-ID: 

On Mon, 13 Oct 2025 13:58:04 GMT, Kieran Farrell  wrote:

> Clean backport

This pull request has been closed without being integrated.

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

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

From kfarrell at openjdk.org  Mon Oct 13 19:35:13 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Mon, 13 Oct 2025 19:35:13 GMT
Subject: [jdk25] Withdrawn: 8336695: Update Commons BCEL to Version 6.10.0
In-Reply-To: 
References: 
Message-ID: 

On Mon, 13 Oct 2025 14:32:07 GMT, Kieran Farrell  wrote:

> Clean backport

This pull request has been closed without being integrated.

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

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

From sherman at openjdk.org  Mon Oct 13 20:32:15 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 13 Oct 2025 20:32:15 GMT
Subject: Integrated: 8365588: defineClass that accepts a ByteBuffer does not
 work as expected
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Sep 2025 07:54:20 GMT, Xueming Shen  wrote:

> ### Background
> 
> - ClassLoader.defineClass can receive class data in the form of arrays or ByteBuffers.
> - For array-backed data (defineClass1), a defensive copy is made before passing it to JVM_DefineClassWithSource().
> - For Direct-ByteBuffer variants (defineClass2), no defensive copy is made, which creates a risk that the underlying bytes could be modified while the JVM is processing them.
> - Although a caller could always modify a buffer before a defensive copy is made ? a race condition that cannot be completely prevented ? the **_main concern_** is ensuring that the JVM never processes class bytes that are being concurrently modified.
> 
> ### Problem
> 
> - Concurrent modification risk during processing: while we cannot prevent pre-copy modifications, we **_must prevent the JVM from using class bytes that are being modified concurrently._**
> - Performance concerns: defensive copies have a cost, especially for direct byte buffers. Making copies unnecessarily for trusted class loaders (like the built-in class loader) would hurt performance.
> 
> ### Solution
> 
> - Make a defensive copy of the direct byte-buffer only when the class loader is **NOT** a built-in/trusted class loader.
> - For the built-in class loader, skip the copy because the JVM can guarantee that the buffer contents remain intact.
> 
> This approach ensures the integrity of  class bytes processes for untrusted or custom class loaders while minimizing performance impact for trusted or built-in loaders.
> 
> ### Benchmark
> 
> A JMH benchmark has been added to measure the potential cost of the defensive copy. The results indicate that the performance impact is minimal and largely insignificant.
> 
> **Before:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8387.247 ? 1405.681  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  8971.739 ? 1020.288  ns/op
> Finished running test 'micro:org.openjdk.bench.java.lang.ClassLoaderDefineClass'
> Test report is stored in /Users/xuemingshen/jdk26/build/macosx-aarch64/test-results/micro_org_openjdk_bench_java_lang_ClassLoaderDefineClass
> 
> 
> **After:**
> 
> 
> Benchmark                                               Mode  Cnt     Score      Error  Units
> ClassLoaderDefineClass.testDefineClassByteBufferDirect  avgt   15  8521.881 ? 2002.011  ns/op
> ClassLoaderDefineClass.testDefineClassByteBufferHeap    avgt   15  9002.842 ? 1099.635  ns/op
> Finished running test 'mi...

This pull request has now been integrated.

Changeset: 4ca4485e
Author:    Xueming Shen 
URL:       https://git.openjdk.org/jdk/commit/4ca4485e9af10a49ca95710c4e26aa3895835d47
Stats:     432 lines in 3 files changed: 427 ins; 0 del; 5 mod

8365588: defineClass that accepts a ByteBuffer does not work as expected

Reviewed-by: alanb

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

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

From matsaave at openjdk.org  Mon Oct 13 20:34:20 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 13 Oct 2025 20:34:20 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v2]
In-Reply-To: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
Message-ID: 

> Trivial change to remove an unused line of code. Verified with tier1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused argument

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27735/files
  - new: https://git.openjdk.org/jdk/pull/27735/files/d9290dd8..da3fe2d6

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

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

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

From pavel.rappo at gmail.com  Mon Oct 13 20:44:21 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Mon, 13 Oct 2025 21:44:21 +0100
Subject: Duration.MAX_VALUE
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Message-ID: 

Thanks! I think that your experiment confirms that we do _not_ need
subtraction, at least initially. A single, focused method for
saturated addition should be enough. I'll update PR (
https://github.com/openjdk/jdk/pull/27549 ), which you are welcome to
review.

Stephen, are you okay with this?

-Pavel

On Mon, Oct 13, 2025 at 6:56?PM ?amonn McManus  wrote:
>
> On Thu, 9 Oct 2025 at 07:25, Pavel Rappo  wrote:
>>
>> Out of curiosity, how is Instants.saturatedSubtract(Instant, Duration) used?
>
>
> That is an excellent question, and it prompted me to look into saturated addition and subtraction in a bit more detail. As an experiment, I tried running all of Google's internal tests against a modified Instants class where saturatedAdd and saturatedSubtract behaved identically to regular Instant.add/subtract(Duration). That led to hundreds of test failures, although I think there might have been fewer than 10 distinct root causes. Then I retried the failing tests with only saturatedSubtract being changed. All but one of the previously-failing tests now passed. That shows that saturatedAdd has a much wider applicability than saturatedSubtract.
>
> I get the impression from looking at some samples that people are often using saturatedSubtract out of an abundance of caution rather than having a real reason to think the subtraction might overflow. Many of the examples I saw were using fixed-length durations, which could only overflow if being subtracted from Instant.MIN or thereabouts.
>
> The one test that failed with saturatedSubtract was testing code that does something like this:
>
> Instant finalizationTime = ...;
> boolean recentlyFinalized =
>     finalizationTime.isAfter(
>         Instants.saturatedSubtract(now, minAgeForDeletion));
>
> The idea is that something can only be deleted if it was not "recently finalized". If it was finalized less than minAgeForDeletion time ago then it can't be deleted. In the failing test, minAgeForDeletion is Durations.MAX, which signals that something can never be deleted (it will always be recently finalized).
> The code could just as easily do this:
>
> boolean recentlyFinalized =
>     now.isBefore(
>         Instants.saturatedAdd(finalizationTime, minAgeForDeletion));
>
> So I don't think this is a particularly convincing use case for saturatedSubtract. The main reason for having it would be that it might be surprising to have add but not subtract.
>
> ?amonn
>
> On Thu, 9 Oct 2025 at 07:25, Pavel Rappo  wrote:
>>
>> Out of curiosity, how is Instants.saturatedSubtract(Instant, Duration) used?
>>
>> On Wed, Oct 8, 2025 at 2:13?AM ?amonn McManus  wrote:
>> >
>> > Yes, we have utility classes Instants and Durations, and Instants includes methods Instants.saturatedAdd(Instant, Duration) and Instants.saturatedSubtract(Instant, Duration). Each has a modest number of uses in the codebase, about three orders of magnitude less than the number of classes that reference Instant or Duration.
>> >
>> > On Tue, 7 Oct 2025 at 14:18, Pavel Rappo  wrote:
>> >>
>> >> ?amonn, Kurt,
>> >>
>> >> Is there any saturating arithmetic for instant + duration in your code base?
>> >>
>> >>
>> >>
>> >> On Fri, Sep 5, 2025 at 8:58?PM ?amonn McManus  wrote:
>> >> >
>> >> > As promised, Kurt and I have examined some of the uses of our Durations.MAX constant. This is a summary of what we see in a random sample of 30 out of about 700 usages in Google's (giant) codebase.
>> >> >
>> >> > First, about half of the usages specifically concern deadlines. Many of them involve a method that sets an RPC deadline and where it is explicitly documented that you should use Durations.MAX to mean no deadline (or equivalently, infinite deadline).
>> >> >
>> >> > Several other usages concern deadline-adjacent concepts such as time-to-live or cache expiration delay.
>> >> >
>> >> > A number of usages specifically compare a Duration against Durations.MAX to recognize the "infinite duration" value.
>> >> >
>> >> > One usage uses our internal Sleeper interface to do sleeper.sleep(Durations.MAX), for an indefinite sleep (until interrupted).
>> >> >
>> >> > In a couple of places, there is a maximum allowed Duration for some operation, and a user-supplied Duration value is capped by this maximum. When no maximum is needed, the cap is Durations.MAX. This is similar to the "sentinel" use case I mentioned earlier.
>> >> >
>> >> > One case is using Durations.MAX in a test, to ensure that a function works correctly for all Duration values including the largest one. It is testing a Kotlin extension function that allows you to write e.g. 5.minutes:
>> >> >
>> >> >     val n = Durations.MAX.toMinutes()
>> >> >
>> >> >     assertThat(n.minutes).isEqualTo(Duration.ofMinutes(n))
>> >> >
>> >> >     assertFailsWith { (n + 1).minutes }
>> >> >
>> >> >
>> >> > In summary, I think the most interesting use cases fall into these categories:
>> >> >
>> >> > to express an effectively-infinite Duration, possibly accompanied by special-case logic to optimize the exact value Durations.MAX;
>> >> >
>> >> > to express the absence of an optional cap on a user-supplied Duration value;
>> >> >
>> >> > to test that code works correctly even with extreme Duration values.
>> >> >
>> >> >
>> >> > Of these, the first is potentially fragile because of the overflow problems we discussed. The other two seem unproblematic, though.
>> >> >
>> >> >
>> >> >
>> >> > On Thu, 4 Sept 2025 at 15:02, ?amonn McManus  wrote:
>> >> >>
>> >> >> Two typical use cases:
>> >> >>
>> >> >> // 1. Sentinel
>> >> >> Duration min = Duration.MAX;
>> >> >> for (var foo : something()) {
>> >> >>   if (foo.duration().compareTo(min) < 0) {
>> >> >>     min = foo.duration();
>> >> >>   }
>> >> >> }
>> >> >>
>> >> >> // 2. "Forever"
>> >> >> void frob(Optional optionalTimeout) {
>> >> >>   Duration timeout = optionalTimeout.orElse(Duration.MAX);
>> >> >>   Instant start = Instant.now();
>> >> >>   boolean done = false;
>> >> >>   while (!done && startTime.until(Instant.now()).compareTo(timeout) < 0) {...}
>> >> >> }
>> >> >>
>> >> >> The second case illustrates why this is potentially a bit delicate. You better not write this:
>> >> >>
>> >> >> void frob(Optional optionalTimeout) {
>> >> >>   Duration timeout = optionalTimeout.orElse(Duration.MAX);
>> >> >>   Instant deadline = Instant.now().plus(timeout); // oops
>> >> >>   boolean done = false;
>> >> >>   while (!done && Instant.now().isBefore(deadline)) {...}
>> >> >> }
>> >> >>
>> >> >> Like Kevin, I am skeptical about Duration.MIN. If it means the most negative Duration, that is just Duration.MAX.negated(); and if it means the smallest positive Duration, that is just Duration.ofNanos(1).
>> >> >>
>> >> >> On Wed, 3 Sept 2025 at 18:32, Roger Riggs  wrote:
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> I'd be interested in the range of use cases for Duration.MAX or MIN.
>> >> >>>
>> >> >>> But for deadlines, I think the code should compute the deadline from a Duration of its choice based on the use.
>> >> >>> Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that ignores information about the particular use that is relevant. Its just sloppy code that doesn't bother to express how long is long enough to meet operational parameters.
>> >> >>>
>> >> >>> YMMV, Roger
>> >> >>>
>> >> >>> On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote:
>> >> >>>
>> >> >>> Duration.MIN is a whole 'nother bag of worms, because Durations are signed (they can be positive or negative...or zero). Internally we also have Durations.MIN, but it's not public ... and along with it, I left myself a helpful note about naming:
>> >> >>>
>> >> >>>   /** The minimum supported {@code Duration}, approximately -292 billion years. */
>> >> >>>   // Note: before making this constant public, consider that "MIN" might not be a great name (not
>> >> >>>   //       everyone knows that Durations can be negative!).
>> >> >>>   static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE);
>> >> >>>
>> >> >>> This reminds me of Double.MIN_VALUE (which is the smallest _positive_ double value) --- we've seen Double.MIN_VALUE misused so much that we introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias. A large percent of Double.MIN_VALUE users actually want the smallest possible negative value, aka -Double.MAX_VALUE.
>> >> >>>
>> >> >>> If we introduce Duration.MIN, I hope it would not be Duration.ofNanos(1), but rather Duration.ofSeconds(Long.MIN_VALUE).
>> >> >>>
>> >> >>> On Wed, Sep 3, 2025 at 7:59?PM ecki  wrote:
>> >> >>>>
>> >> >>>> If you ask me, I don?t find it very useful, It won?t work for arithmetrics, even the APIs would have a hard time using it (how do you express the deadline) and APIs with a timeout parameter do have a good reason for it, better pick ?possible? values for better self healing and unstuck of systems. In fact I would err on the smaller side in combination with expecting spurious wakeups.
>> >> >>>>
>> >> >>>> BTW, when you introduce MIN as well, maybe also think about min precision, min delta or such. Will it always be 1 nano?
>> >> >>>>
>> >> >>>> Gru?,
>> >> >>>> Bernd
>> >> >>>> --
>> >> >>>> https://bernd.eckenfels.net
>> >> >>>> ________________________________
>> >> >>>> Von: core-libs-dev  im Auftrag von Pavel Rappo 
>> >> >>>> Gesendet: Donnerstag, September 4, 2025 12:41 AM
>> >> >>>> An: Kurt Alfred Kluever 
>> >> >>>> Cc: Stephen Colebourne ; core-libs-dev 
>> >> >>>> Betreff: Re: Duration.MAX_VALUE
>> >> >>>>
>> >> >>>> This is useful; thanks. It would be good to see more of your data.
>> >> >>>>
>> >> >>>> My use case is also duration which practically means **forever**. I
>> >> >>>> pass it to methods that accept timeouts, and expect these methods to
>> >> >>>> correctly interpret it.
>> >> >>>>
>> >> >>>> One example of a practical interpretation is
>> >> >>>> java.util.concurrent.TimeUnit.convert(Duration). This method never
>> >> >>>> overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is
>> >> >>>> roughly 292 years.
>> >> >>>>
>> >> >>>> Would I be okay, if the proposed duration didn't reflect **forever**
>> >> >>>> but instead reflected **long enough**? I think so. But it still
>> >> >>>> somehow feels wrong to make it less than maximum representable value.
>> >> >>>>
>> >> >>>> Personally, I'm not interested in calendar arithmetic, that is, in
>> >> >>>> adding or subtracting durations. Others might be, and that's okay and
>> >> >>>> needs to be factored in. For better or worse, java.time made a choice
>> >> >>>> to be unforgiving in regard to overflow and is very upfront about it.
>> >> >>>> It's not only proposed Duration.MAX. The same thing happens if you try
>> >> >>>> this
>> >> >>>>
>> >> >>>> Instant.MAX.toEpochMilli()
>> >> >>>>
>> >> >>>> I guess my point is that doing calendar arithmetic on an unknown value
>> >> >>>> is probably wrong. Doing it on a known huge/edge-case value is surely
>> >> >>>> wrong. So back to your data. I would be interested to see what
>> >> >>>> triggers overflows for your Durations.MAX.
>> >> >>>>
>> >> >>>> On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever  wrote:
>> >> >>>> >
>> >> >>>> > Hi all,
>> >> >>>> >
>> >> >>>> > Internally at Google, we've had a Durations.MAX constant exposed for the past 7 years. It now has about 700 usages across our depot, which I can try to categorize (at a future date).
>> >> >>>> >
>> >> >>>> > While I haven't performed that analysis yet, I think exposing this constant was a bit of a mistake. People seem to want to use MAX to mean "forever" (often in regards to an RPC deadline). This works fine as long as every single layer that touches the deadline is very careful about overflow. The only reasonable thing you can do with MAX is compareTo() and equals(). Attempting to do any simple math operation (e.g., now+deadline) is going to explode. Additionally, decomposing Duration.MAX explodes for any sub-second precision (e.g., toMillis()).
>> >> >>>> >
>> >> >>>> > As we dug into this, another proposal came up which was something like Durations.VERY_LONG. This duration would be longer than any reasonable finite duration but not long enough to cause an overflow when added to any reasonable time. E.g., a million years would probably satisfy both criteria. This would mean math operations and decompositions won't explode (well, microseconds and nanoseconds still would), and it could safely be used as a relative timeout.
>> >> >>>> >
>> >> >>>> > As I mentioned above, I'd be happy to try to categorize a sample of our 700 existing usages if folks think that would be useful for this proposal.
>> >> >>>> >
>> >> >>>> > Thanks,
>> >> >>>> >
>> >> >>>> > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem team)
>> >> >>>> >
>> >> >>>> > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo  wrote:
>> >> >>>> >>
>> >> >>>> >> If I understood you correctly, you think we should also add
>> >> >>>> >> Duration.MIN. If so, what use case do you envision for it? Or we add
>> >> >>>> >> if purely for symmetry with Instant?
>> >> >>>> >>
>> >> >>>> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo  wrote:
>> >> >>>> >> >
>> >> >>>> >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne  wrote:
>> >> >>>> >> > >
>> >> >>>> >> > > Hmm, yes. Not sure why that didn't get added in Java 8!
>> >> >>>> >> > > The constants would be MAX/MIN as per classes like Instant.
>> >> >>>> >> > > Stephen
>> >> >>>> >> >
>> >> >>>> >> > I thought that naming could be tricky :) The public constant
>> >> >>>> >> > Duration.ZERO and the public method isZero() are already there.
>> >> >>>> >> > However, it does not preclude us from naming a new constant MAX.
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > --
>> >> >>>> > kak
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> kak
>> >> >>>
>> >> >>>

From duke at openjdk.org  Mon Oct 13 20:59:03 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Mon, 13 Oct 2025 20:59:03 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v4]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
Message-ID: 

On Mon, 13 Oct 2025 18:26:40 GMT, Lance Andersen  wrote:

>> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
>> 
>> - Deprecate SQLPermission for removal
>> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
>> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
>> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
>> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
>> 
>> Tiers 1-3 have been run
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Round 3 of formating/typo updates

@LanceAndersen I could not find the JDBC 4.5 MR specification (e.g. at https://jcp.org/en/jsr/detail?id=221), can you provide a link?

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

PR Comment: https://git.openjdk.org/jdk/pull/27693#issuecomment-3399049962

From lancea at openjdk.org  Mon Oct 13 21:10:04 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 13 Oct 2025 21:10:04 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v4]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
 
Message-ID: 

On Mon, 13 Oct 2025 20:55:55 GMT, Johannes D?bler  wrote:

> @LanceAndersen I could not find the JDBC 4.5 MR specification (e.g. at https://jcp.org/en/jsr/detail?id=221), can you provide a link?

The change log will be posted once the CSR has been approved for javadoc changes for the API

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

PR Comment: https://git.openjdk.org/jdk/pull/27693#issuecomment-3399074729

From prappo at openjdk.org  Mon Oct 13 21:12:40 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 13 Oct 2025 21:12:40 GMT
Subject: RFR: 8368856: Add methods for saturating Duration arithmetic to
 Instant [v8]
In-Reply-To: 
References: 
Message-ID: 

> We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR.
> 
> I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`.
> 
> My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`.
> 
> Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`.
> 
> [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html

Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision:

 - Simplify impl
 - Clarify spec
 - Revert "Add Instant.minusSaturating(Duration)"
   
   This reverts commit 35537856f1759c7abbe2b5c5bbb267a90612f729.
 - Add test for null

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27549/files
  - new: https://git.openjdk.org/jdk/pull/27549/files/e7207a08..3bc1e0e2

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

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

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

From jlu at openjdk.org  Mon Oct 13 21:27:14 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 13 Oct 2025 21:27:14 GMT
Subject: RFR: 8369590: LocaleEnhanceTest has incorrectly passing test case
Message-ID: 

This PR corrects _test/jdk/java/util/Locale/LocaleEnhanceTest.java_, which has two test cases under `testBuilderSetLanguageTag()` which accidentally pass. One checks that Locale.setLanguageTag(String) throws ILE for duplicate extensions and the other for duplicate U-extension keys. The test cases are updated to actually test the provided code. When the test cases are fixed, they now fail.

Fixing the behavior to match the expectation of those test cases is consistent with the specification.

>From `Locale.forLanguageTag(String)`,

> 
>      * 
    If the specified language tag contains any ill-formed subtags,
>      * the first such subtag and all following subtags are ignored.  Compare
>      * to {@link Locale.Builder#setLanguageTag(String)} which throws an exception
>      * in this case.

and the RFC specification

> Each singleton subtag MUST appear at most one time in each tag
>        (other than as a private use subtag).  That is, singleton subtags
>        MUST NOT be repeated.  For example, the tag "en-a-bbb-a-ccc" is
>        invalid because the subtag 'a' appears twice.

Since duplicate extensions (and Unicode keys/attributes) are invalid, throwing `IllformedLocaleException` in (the strict) `Locale.Builder` and ignoring in (the lenient) `Locale.forLanguageTag` for such tags would be appropriate. This PR updates the implementation as such.

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

Commit messages:
 - Add duplicate checking for Locale.Builder.setLanguageTag(String)
 - Add duplicate U extension attributes test case
 - Remove testing classes in favor or JUnit (which fixes unintentional passing)

Changes: https://git.openjdk.org/jdk/pull/27775/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27775&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369590
  Stats: 686 lines in 4 files changed: 75 ins; 169 del; 442 mod
  Patch: https://git.openjdk.org/jdk/pull/27775.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27775/head:pull/27775

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

From jlu at openjdk.org  Mon Oct 13 21:27:15 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 13 Oct 2025 21:27:15 GMT
Subject: RFR: 8369590: LocaleEnhanceTest has incorrectly passing test case
In-Reply-To: 
References: 
Message-ID: 

On Mon, 13 Oct 2025 20:55:45 GMT, Justin Lu  wrote:

> This PR corrects _test/jdk/java/util/Locale/LocaleEnhanceTest.java_, which has two test cases under `testBuilderSetLanguageTag()` which accidentally pass. One checks that Locale.setLanguageTag(String) throws ILE for duplicate extensions and the other for duplicate U-extension keys. The test cases are updated to actually test the provided code. When the test cases are fixed, they now fail.
> 
> Fixing the behavior to match the expectation of those test cases is consistent with the specification.
> 
> From `Locale.forLanguageTag(String)`,
> 
>> 
>>      * 
    If the specified language tag contains any ill-formed subtags,
>>      * the first such subtag and all following subtags are ignored.  Compare
>>      * to {@link Locale.Builder#setLanguageTag(String)} which throws an exception
>>      * in this case.
> 
> and the RFC specification
> 
>> Each singleton subtag MUST appear at most one time in each tag
>>        (other than as a private use subtag).  That is, singleton subtags
>>        MUST NOT be repeated.  For example, the tag "en-a-bbb-a-ccc" is
>>        invalid because the subtag 'a' appears twice.
> 
> Since duplicate extensions (and Unicode keys/attributes) are invalid, throwing `IllformedLocaleException` in (the strict) `Locale.Builder` and ignoring in (the lenient) `Locale.forLanguageTag` for such tags would be appropriate. This PR updates the implementation as such.

src/java.base/share/classes/sun/util/locale/InternalLocaleBuilder.java line 212:

> 210: 
> 211:             if (UnicodeLocaleExtension.isSingletonChar(key.value())) {
> 212:                 setUnicodeLocaleExtension(val, true);

This code is called under `Locale.Builder.setExtension(char, String)`, which remains lenient for duplicate U-extension keys and attributes since this existing behavior is confirmed as a test case in _LocaleEnhanceTest_,


        // redundant locale extensions are ignored
        result = builder
            .clear()
            .setExtension('u', "nu-thai-NU-chinese-xx-1234")
            .build()
            .toLanguageTag();
        assertEquals("duplicate keys", "und-u-nu-thai-xx-1234", result);

test/jdk/java/util/Locale/LocaleEnhanceTest.java line 767:

> 765: 
> 766:         // redundant Unicode locale extension keys within an Unicode locale extension cause a failure
> 767:         new BuilderILE() { public void call() { b.setLanguageTag("und-u-nu-thai-NU-chinese-xx-1234"); }};

These lines both relied on the `BuilderILE` testing class. However, since they provided no args to the ctor, the `run()` call does not actually execute the provided code under `call()`. `BuilderILE` and the other helper testing classes are replaced with JUnit in https://github.com/openjdk/jdk/pull/27775/commits/f4927421ad3f7b2647ecd29059e2e64683b9f270.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27775#discussion_r2427333112
PR Review Comment: https://git.openjdk.org/jdk/pull/27775#discussion_r2427320692

From jlu at openjdk.org  Mon Oct 13 21:51:32 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 13 Oct 2025 21:51:32 GMT
Subject: RFR: 8369590: LocaleEnhanceTest has incorrectly passing test case
 [v2]
In-Reply-To: 
References: 
Message-ID: <11DDueNxPmVaTZ2u9WMchm4kWfC5Ims83jkGE3S2RXQ=.03c79e51-6977-45c0-ae6f-c55e03d62598@github.com>

> This PR corrects _test/jdk/java/util/Locale/LocaleEnhanceTest.java_, which has two test cases under `testBuilderSetLanguageTag()` which accidentally pass. One checks that Locale.setLanguageTag(String) throws ILE for duplicate extensions and the other for duplicate U-extension keys. The test cases are updated to actually test the provided code. When the test cases are fixed, they now fail.
> 
> Fixing the behavior to match the expectation of those test cases is consistent with the specification.
> 
> From `Locale.forLanguageTag(String)`,
> 
>> 
>>      * 
    If the specified language tag contains any ill-formed subtags,
>>      * the first such subtag and all following subtags are ignored.  Compare
>>      * to {@link Locale.Builder#setLanguageTag(String)} which throws an exception
>>      * in this case.
> 
> and the RFC specification
> 
>> Each singleton subtag MUST appear at most one time in each tag
>>        (other than as a private use subtag).  That is, singleton subtags
>>        MUST NOT be repeated.  For example, the tag "en-a-bbb-a-ccc" is
>>        invalid because the subtag 'a' appears twice.
> 
> Since duplicate extensions (and Unicode keys/attributes) are invalid, throwing `IllformedLocaleException` in (the strict) `Locale.Builder` and ignoring in (the lenient) `Locale.forLanguageTag` for such tags would be appropriate. This PR updates the implementation as such.

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

  Adding test case to confirm duplicate U-extension attributes for setExtension(char, String)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27775/files
  - new: https://git.openjdk.org/jdk/pull/27775/files/524dd361..f73a15ae

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

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

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

From naoto at openjdk.org  Mon Oct 13 22:29:05 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 Oct 2025 22:29:05 GMT
Subject: RFR: 8369590: LocaleEnhanceTest has incorrectly passing test case
 [v2]
In-Reply-To: <11DDueNxPmVaTZ2u9WMchm4kWfC5Ims83jkGE3S2RXQ=.03c79e51-6977-45c0-ae6f-c55e03d62598@github.com>
References: 
 <11DDueNxPmVaTZ2u9WMchm4kWfC5Ims83jkGE3S2RXQ=.03c79e51-6977-45c0-ae6f-c55e03d62598@github.com>
Message-ID: 

On Mon, 13 Oct 2025 21:51:32 GMT, Justin Lu  wrote:

>> This PR corrects _test/jdk/java/util/Locale/LocaleEnhanceTest.java_, which has two test cases under `testBuilderSetLanguageTag()` which accidentally pass. One checks that Locale.setLanguageTag(String) throws ILE for duplicate extensions and the other for duplicate U-extension keys. The test cases are updated to actually test the provided code. When the test cases are fixed, they now fail.
>> 
>> Fixing the behavior to match the expectation of those test cases is consistent with the specification.
>> 
>> From `Locale.forLanguageTag(String)`,
>> 
>>> 
>>>      * 
    If the specified language tag contains any ill-formed subtags,
>>>      * the first such subtag and all following subtags are ignored.  Compare
>>>      * to {@link Locale.Builder#setLanguageTag(String)} which throws an exception
>>>      * in this case.
>> 
>> and the RFC specification
>> 
>>> Each singleton subtag MUST appear at most one time in each tag
>>>        (other than as a private use subtag).  That is, singleton subtags
>>>        MUST NOT be repeated.  For example, the tag "en-a-bbb-a-ccc" is
>>>        invalid because the subtag 'a' appears twice.
>> 
>> Since duplicate extensions (and Unicode keys/attributes) are invalid, throwing `IllformedLocaleException` in (the strict) `Locale.Builder` and ignoring in (the lenient) `Locale.forLanguageTag` for such tags would be appropriate. This PR updates the implementation as such.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding test case to confirm duplicate U-extension attributes for setExtension(char, String)

IIUC, the quote from the RFC refers to duplicate singletons. For example, it would reject something like `-u-aa-bbb-u-cc-ddd`. So I believe that rule doesn?t apply to cases like `-u-aa-bbb-AA-ccc`. I checked the `-u` extension definition in LDML but couldn?t find any description regarding duplicate keywords.

That said, I think it makes sense to allow them in lenient mode and throw an exception in strict mode. Since this would introduce a behavioral change, I?d expect it to require a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27775#issuecomment-3399242375

From darcy at openjdk.org  Tue Oct 14 01:20:38 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 14 Oct 2025 01:20:38 GMT
Subject: RFR: 8369312: Refactor Float.toHexString() to avoid use of regex
Message-ID: 

Simple refactoring to avoid use the regular expressions. Existing tests in

java/lang/Double/ToHexString.java

cover the float conversions too.

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

Commit messages:
 - JDK-8369312: Refactor Float.toHexString() to avoid use of regex

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

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

From dholmes at openjdk.org  Tue Oct 14 02:21:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Oct 2025 02:21:03 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v2]
In-Reply-To: 
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
 
Message-ID: 

On Mon, 13 Oct 2025 20:34:20 GMT, Matias Saavedra Silva  wrote:

>> Trivial change to remove an unused line of code. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused argument

Renaming etc looks good - thanks. I had assumed this was one of a number of `FindClassXX` methods and so would disappear, but now see it is the primary method and it is just the name and arg that were no longer appropriate.

src/hotspot/share/prims/jvm.cpp line 802:

> 800: JVM_END
> 801: 
> 802: // Find a class with this name in this loader

Suggestion:

// Find a class with this name in this loader.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27735#pullrequestreview-3333662017
PR Review Comment: https://git.openjdk.org/jdk/pull/27735#discussion_r2427736161

From jpai at openjdk.org  Tue Oct 14 04:12:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 14 Oct 2025 04:12:07 GMT
Subject: RFR: 8367157: Remove jrunscript tool [v2]
In-Reply-To: 
References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
 
Message-ID: 

On Tue, 7 Oct 2025 09:23:01 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157.
>> 
>> `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests.
>> 
>> tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - merge latest from master branch
>  - remove tests for jrunscript
>  - remove jrunscript implementation
>  - remove references from tests
>  - remove man page for jrunscript

Thank you everyone for the reviews. The CSR has been approved. I'll go ahead with the integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/27163#issuecomment-3400036193

From jpai at openjdk.org  Tue Oct 14 06:13:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 14 Oct 2025 06:13:18 GMT
Subject: Integrated: 8367157: Remove jrunscript tool
In-Reply-To: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
Message-ID: <44aNxQVFVat-ckzbYc-GUoxHvcERoKgB05VTf47fyWk=.9b8db04c-73d5-4b19-aa29-29d44f6d80e2@github.com>

On Tue, 9 Sep 2025 07:18:25 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157.
> 
> `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests.
> 
> tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note.

This pull request has now been integrated.

Changeset: 2eb0898f
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/2eb0898fef7b7fef7285b7ee1837b73336b9f7be
Stats:     2364 lines in 24 files changed: 0 ins; 2360 del; 4 mod

8367157: Remove jrunscript tool

Reviewed-by: erikj, ayang, ihse, alanb

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

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

From alanb at openjdk.org  Tue Oct 14 06:16:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Oct 2025 06:16:03 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v2]
In-Reply-To: 
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
 
Message-ID: 

On Mon, 13 Oct 2025 20:34:20 GMT, Matias Saavedra Silva  wrote:

>> Trivial change to remove an unused line of code. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused argument

Aside from the JVM_FindClassFromLoader comment, this looks okay to me.

src/hotspot/share/include/jvm.h line 440:

> 438:  */
> 439: JNIEXPORT jclass JNICALL
> 440: JVM_FindClassFromLoader(JNIEnv *env, const char *name, jboolean init,

The function description still lists the caller class, you can remove that.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27735#pullrequestreview-3334042977
PR Review Comment: https://git.openjdk.org/jdk/pull/27735#discussion_r2428019210

From alanb at openjdk.org  Tue Oct 14 06:46:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Oct 2025 06:46:06 GMT
Subject: RFR: 8369312: Refactor Float.toHexString() to avoid use of regex
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Oct 2025 01:13:16 GMT, Joe Darcy  wrote:

> Simple refactoring to avoid use the regular expressions. Existing tests in
> 
> java/lang/Double/ToHexString.java
> 
> cover the float conversions too.

Are you planning to add a micro benchmark to go with this?

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

PR Comment: https://git.openjdk.org/jdk/pull/27780#issuecomment-3400340906

From cstein at openjdk.org  Tue Oct 14 08:57:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 14 Oct 2025 08:57:51 GMT
Subject: Integrated: 8369488: Update to use jtreg 8.1
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein  wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

This pull request has now been integrated.

Changeset: 702179e7
Author:    Christian Stein 
URL:       https://git.openjdk.org/jdk/commit/702179e7858bae1c7c13ad6eda3c4fbffdbb15db
Stats:     11 lines in 9 files changed: 0 ins; 0 del; 11 mod

8369488: Update to use jtreg 8.1

Reviewed-by: iris, erikj, jpai, syan

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

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

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 rgiulietti at openjdk.org  Tue Oct 14 10:48:40 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 14 Oct 2025 10:48:40 GMT
Subject: RFR: 8369312: Refactor Float.toHexString() to avoid use of regex
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Oct 2025 01:13:16 GMT, Joe Darcy  wrote:

> Simple refactoring to avoid use the regular expressions. Existing tests in
> 
> java/lang/Double/ToHexString.java
> 
> cover the float conversions too.

LGTM

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27780#pullrequestreview-3334967757

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 fandreuzzi at openjdk.org  Tue Oct 14 11:00:21 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 14 Oct 2025 11:00:21 GMT
Subject: RFR: 8369817: [TESTBUG] EmptyPath::toString is ignored
Message-ID: 

JUnit ignores `@Test` methods which do not return `void`:


(1) [WARNING] @Test method 'public java.lang.String EmptyPath.toString()' must not return a value. It will not be executed.
    Source: MethodSource [className = 'EmptyPath', methodName = 'toString', methodParameterTypes = '']
            at EmptyPath.toString(SourceFile:0)


I propose to amend the method signature. This looks trivial to me.

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

Commit messages:
 - fix

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

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

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 dholmes at openjdk.org  Tue Oct 14 11:07:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Oct 2025 11:07:47 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 8 Oct 2025 08:15:08 GMT, Alan Bateman  wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - Add testUnreflectExpectingWarning
>  - Merge branch 'master' into JDK-8353835
>  - Add test for -Xlog:jni=debug
>  - Merge branch 'master' into JDK-8353835
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/2ac24bf1...635556aa

Hotspot changes look fine. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3335034246

From jpai at openjdk.org  Tue Oct 14 11:10:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 14 Oct 2025 11:10:31 GMT
Subject: RFR: 8369817: [TESTBUG] EmptyPath::toString is ignored
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Oct 2025 10:53:55 GMT, Francesco Andreuzzi  wrote:

> JUnit ignores `@Test` methods which do not return `void`:
> 
> 
> (1) [WARNING] @Test method 'public java.lang.String EmptyPath.toString()' must not return a value. It will not be executed.
>     Source: MethodSource [className = 'EmptyPath', methodName = 'toString', methodParameterTypes = '']
>             at EmptyPath.toString(SourceFile:0)
> 
> 
> I propose to amend the method signature. This looks trivial to me.

test/jdk/java/io/File/EmptyPath.java line 385:

> 383: 
> 384:     @Test
> 385:     public void callToString() {

Good catch. I checked our CI for this test execution and it too reports this warning in the logs.

I think instead of `callToString()`, we should just rename it to `testToString()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27797#discussion_r2428761000

From ayang at openjdk.org  Tue Oct 14 11:20:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 11:20:41 GMT
Subject: RFR: 8369817: [TESTBUG] EmptyPath::toString is ignored [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 11:17:11 GMT, Francesco Andreuzzi  wrote:

>> JUnit ignores `@Test` methods which do not return `void`:
>> 
>> 
>> (1) [WARNING] @Test method 'public java.lang.String EmptyPath.toString()' must not return a value. It will not be executed.
>>     Source: MethodSource [className = 'EmptyPath', methodName = 'toString', methodParameterTypes = '']
>>             at EmptyPath.toString(SourceFile:0)
>> 
>> 
>> I propose to amend the method signature. This looks trivial to me.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27797#pullrequestreview-3335066360

From fandreuzzi at openjdk.org  Tue Oct 14 11:20:43 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 14 Oct 2025 11:20:43 GMT
Subject: RFR: 8369817: [TESTBUG] EmptyPath::toString is ignored [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 11:07:50 GMT, Jaikiran Pai  wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename
>
> test/jdk/java/io/File/EmptyPath.java line 385:
> 
>> 383: 
>> 384:     @Test
>> 385:     public void callToString() {
> 
> Good catch. I checked our CI for this test execution and it too reports this warning in the logs.
> 
> I think instead of `callToString()`, we should just rename it to `testToString()`.

Sure, renamed in d9e8c387ce17241c34a483ffc15fa6a8124b8c5a

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27797#discussion_r2428771814

From fandreuzzi at openjdk.org  Tue Oct 14 11:20:40 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 14 Oct 2025 11:20:40 GMT
Subject: RFR: 8369817: [TESTBUG] EmptyPath::toString is ignored [v2]
In-Reply-To: 
References: 
Message-ID: 

> JUnit ignores `@Test` methods which do not return `void`:
> 
> 
> (1) [WARNING] @Test method 'public java.lang.String EmptyPath.toString()' must not return a value. It will not be executed.
>     Source: MethodSource [className = 'EmptyPath', methodName = 'toString', methodParameterTypes = '']
>             at EmptyPath.toString(SourceFile:0)
> 
> 
> I propose to amend the method signature. This looks trivial to me.

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

  rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27797/files
  - new: https://git.openjdk.org/jdk/pull/27797/files/9c98329e..d9e8c387

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

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

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

From jpai at openjdk.org  Tue Oct 14 11:20:40 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 14 Oct 2025 11:20:40 GMT
Subject: RFR: 8369817: [TESTBUG] EmptyPath::toString is ignored [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 11:17:11 GMT, Francesco Andreuzzi  wrote:

>> JUnit ignores `@Test` methods which do not return `void`:
>> 
>> 
>> (1) [WARNING] @Test method 'public java.lang.String EmptyPath.toString()' must not return a value. It will not be executed.
>>     Source: MethodSource [className = 'EmptyPath', methodName = 'toString', methodParameterTypes = '']
>>             at EmptyPath.toString(SourceFile:0)
>> 
>> 
>> I propose to amend the method signature. This looks trivial to me.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename

This looks good to me. Please add a "noreg-self" label to the JBS issue (as per the guidelines here https://openjdk.org/guide/#noreg )

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27797#pullrequestreview-3335066084

From vyazici at openjdk.org  Tue Oct 14 11:33:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 14 Oct 2025 11:33:20 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v8]
In-Reply-To: 
References: 
 
Message-ID: <2Ij8EYFqIDDqSIA7QCNejs8yMSVeKeLywF82ayw8DzQ=.7fa24297-a8f0-414c-8253-1e2ffd81b60b@github.com>

On Wed, 8 Oct 2025 08:15:08 GMT, Alan Bateman  wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - Add testUnreflectExpectingWarning
>  - Merge branch 'master' into JDK-8353835
>  - Add test for -Xlog:jni=debug
>  - Merge branch 'master' into JDK-8353835
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/2ac24bf1...635556aa

test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 80:

> 78: 
> 79:     /**
> 80:      * Test executable JAR with code thatyses  Lookup.unreflectSetter to get MH to a

Suggestion:

     * Test executable JAR with code that uses Lookup.unreflectSetter to get MH to a

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2428816748

From vyazici at openjdk.org  Tue Oct 14 11:38:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 14 Oct 2025 11:38:11 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 8 Oct 2025 08:15:08 GMT, Alan Bateman  wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - Add testUnreflectExpectingWarning
>  - Merge branch 'master' into JDK-8353835
>  - Add test for -Xlog:jni=debug
>  - Merge branch 'master' into JDK-8353835
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/2ac24bf1...635556aa

I've reviewed the `test/` changes, and they LGTM.

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

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3335136796

From vklang at openjdk.org  Tue Oct 14 13:06:20 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 14 Oct 2025 13:06:20 GMT
Subject: RFR: 8369656 : Calling CompletableFuture.join() could execute task in
 common pool
Message-ID: 

Addresses the regression regarding pool assistance and includes a regression test for `CompletableFuture::get()`, `CompletableFuture::get(timeout, unit)`, and `CompletableFuture::join()`

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

Commit messages:
 - Reinstating individual imports
 - JDK-8369656 - ensure that caller-assistance only occurs if the pool is shared between caller and callee

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

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

From vklang at openjdk.org  Tue Oct 14 13:06:21 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 14 Oct 2025 13:06:21 GMT
Subject: RFR: 8369656 : Calling CompletableFuture.join() could execute task
 in common pool
In-Reply-To: 
References: 
Message-ID: <1D5tmIedgWOJglszYYxJNV-Oy-EK5JWsOxwUmce1mCo=.190712e8-fca3-4000-b1a8-8a8673d91a20@github.com>

On Tue, 14 Oct 2025 12:59:52 GMT, Viktor Klang  wrote:

> Addresses the regression regarding pool assistance and includes a regression test for `CompletableFuture::get()`, `CompletableFuture::get(timeout, unit)`, and `CompletableFuture::join()`

@DougLea @AlanBateman FYI

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

PR Comment: https://git.openjdk.org/jdk/pull/27800#issuecomment-3401687006

From vklang at openjdk.org  Tue Oct 14 13:10:22 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 14 Oct 2025 13:10:22 GMT
Subject: RFR: 8369656 : Calling CompletableFuture.join() could execute task
 in common pool [v2]
In-Reply-To: 
References: 
Message-ID: 

> Addresses the regression regarding pool assistance and includes a regression test for `CompletableFuture::get()`, `CompletableFuture::get(timeout, unit)`, and `CompletableFuture::join()`

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

  Improving the name of the regtest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27800/files
  - new: https://git.openjdk.org/jdk/pull/27800/files/e57de64f..7fed8f87

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

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

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

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 alanb at openjdk.org  Tue Oct 14 13:47:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Oct 2025 13:47:55 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v9]
In-Reply-To: 
References: 
Message-ID: <3JlQE_SY_oPghJ13xGjdALIADPSp4dajFsMfrw3vCA0=.434d3878-0d61-4518-af3c-636817cbf3dc@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:

 - Fix typo in test comment
 - Merge branch 'master' into JDK-8353835
 - Merge branch 'master' into JDK-8353835
 - Suppress warnings from some tests
 - Change -Xcheck:jni to be warning rather than fatal error
 - Merge branch 'master' into JDK-8353835
 - Simplify filter
 - Merge branch 'master' into JDK-8353835
 - Update Xcheck:jni description
 - Add testUnreflectExpectingWarning
 - ... and 34 more: https://git.openjdk.org/jdk/compare/90cf3a20...1d0cb6c9

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

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=08
  Stats: 4852 lines in 70 files changed: 4667 ins; 54 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

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

From matsaave at openjdk.org  Tue Oct 14 14:55:05 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 14 Oct 2025 14:55:05 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v3]
In-Reply-To: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
Message-ID: 

> Trivial change to remove an unused line of code. Verified with tier1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  David and Alan comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27735/files
  - new: https://git.openjdk.org/jdk/pull/27735/files/da3fe2d6..881c3675

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

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

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

From alanb at openjdk.org  Tue Oct 14 15:56:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Oct 2025 15:56:53 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v3]
In-Reply-To: 
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
 
Message-ID: 

On Tue, 14 Oct 2025 14:55:05 GMT, Matias Saavedra Silva  wrote:

>> This is a cleanup change to remove an unused field `from_class` and the associated argument `caller` from `JVM_FindClassFromCaller` and its callers.  The method `JVM_FindClassFromCaller` has been renamed with these new changes in consideration. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David and Alan comments

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27735#pullrequestreview-3336386436

From darcy at openjdk.org  Tue Oct 14 15:59:58 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 14 Oct 2025 15:59:58 GMT
Subject: RFR: 8369312: Refactor Float.toHexString() to avoid use of regex
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 06:43:05 GMT, Alan Bateman  wrote:

> Are you planning to add a micro benchmark to go with this?

No; this code path is not performance sensitive, but the new code should run faster.

Hex floating-point output, while informative for testing and debugging, is not commonly used. Subnormal values, the subset of numbers affected here, are rarer still, so it is a corner-case squared situation.

>From a recent refactoring in Float16, one of the reviewers questioned the use of regular expressions for this kind of low-level code and it seemed reasonable to replace the idiom with plain string operations.

(If performance were a concern, we would replicate the tricky logic present to handle double subnormals.)

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

PR Comment: https://git.openjdk.org/jdk/pull/27780#issuecomment-3402564984

From darcy at openjdk.org  Tue Oct 14 16:07:16 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 14 Oct 2025 16:07:16 GMT
Subject: Integrated: 8369312: Refactor Float.toHexString() to avoid use of
 regex
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Oct 2025 01:13:16 GMT, Joe Darcy  wrote:

> Simple refactoring to avoid use the regular expressions. Existing tests in
> 
> java/lang/Double/ToHexString.java
> 
> cover the float conversions too.

This pull request has now been integrated.

Changeset: 7ed93cf4
Author:    Joe Darcy 
URL:       https://git.openjdk.org/jdk/commit/7ed93cf40ed4fa1ad545dcb1a33b0d4fdabfa277
Stats:     10 lines in 2 files changed: 4 ins; 0 del; 6 mod

8369312: Refactor Float.toHexString() to avoid use of regex

Reviewed-by: rgiulietti

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

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

From liach at openjdk.org  Tue Oct 14 16:09:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 14 Oct 2025 16:09:09 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v3]
In-Reply-To: 
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
 
Message-ID: 

On Tue, 14 Oct 2025 14:55:05 GMT, Matias Saavedra Silva  wrote:

>> This is a cleanup change to remove an unused field `from_class` and the associated argument `caller` from `JVM_FindClassFromCaller` and its callers.  The method `JVM_FindClassFromCaller` has been renamed with these new changes in consideration. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David and Alan comments

A reasonable cleanup.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27735#pullrequestreview-3336446430

From pchilanomate at openjdk.org  Tue Oct 14 17:18:17 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 14 Oct 2025 17:18:17 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths
Message-ID: 

If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.

As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.

This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.

### Summary of implementation

The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.

If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 

### Notes

`InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `InterpreterMacroAssembler::call_VM_preemptable_helper` and generalized for calls that take more than one argument, and that can return oops and throw exceptions. Method `InterpreterMacroAssembler::call_VM_preemptable` is now a wrapper that calls the helper, following the pattern of `MacroAssembler::call_VM` and `MacroAssembler::call_VM_helper` methods.

As with platform threads, a virtual thread preempted at `wait_uninterruptibly` that is interrupted will not throw IE, and will preserve the interrupted status. Member `_interruptible` was added to `ObjectWaiter` to differentiate this case against `Object.wait`. Also field `interruptableWait` was added to VirtualThread class, mainly to avoid an interrupted virtual thread in `wait_uninterruptibly` to keep looping and submitting the continuation to the scheduler queue until the class is waiting for is initialized.

Currently (and still with this change), when the thread responsible for initializing a class finishes executing the class initializer, it will set the initialization lock to null so the object can be GC'ed. For platform threads blocked waiting on the initialization lock, the `Handle` in `InstanceKlass::initialize_impl` will still protect the object from being collected until the last thread exits the monitor. For preempted virtual threads though, that `Handle` would have already been destroyed. In order to protect the init_lock from being collected while there are still virtual threads using the associated `ObjectMonitor`, the first preempted virtual thread will put the oop in an `OopHandle` in the `ObjectMonitor` (see `ObjectMonitor::set_object_strong()`), which will be released later when the monitor is deflated.

Preempting at `invokestatic` means the top frame in the `stackChunk` can now have the callee?s arguments at the top of the expression stack, which during gc, will need to be processed as part of that frame (no callee yet). Class `SmallRegisterMap` was therefore modified so that we now have two static instances, one where `include_argument_oops()` returns true and is used when processing the top frame on this case, and the regular one where it return false and it?s used everywhere else. Also, because `InterpretedArgumentOopFinder` calculates the address of oops as offsets from the top of the expression stack, we need to correct possible added alignment after the top frame is thawed, since we can safepoint while redoing the VM call. Class `AnchorMark` was added to deal with this.

### Testing

The changes have been running in the Loom pipeline for several months now. They include new test `KlassInit.java` which exercises preemption on different class initialization cases. Also, the current patch has been run through mach5 tiers 1-8. I'll keep running tests periodically until integration time.

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

Commit messages:
 - RISC-V support
 - Fix whitespaces
 - v1

Changes: https://git.openjdk.org/jdk/pull/27802/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369238
  Stats: 1979 lines in 94 files changed: 1628 ins; 86 del; 265 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

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

From rgiulietti at openjdk.org  Tue Oct 14 17:57:06 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 14 Oct 2025 17:57:06 GMT
Subject: RFR: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal
Message-ID: 

Yet another step in modernizing `FloatingDecimal`s floating-point parsing.

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

Commit messages:
 - More complete benchmarks.
 - JMH benchmarks.
 - Adapted tests to more restricted access.
 - Merge branch 'master' into 8366017
 - Many simplifications.
 - Minors.
 - Various enhancements.
 - Simplified full precision.
 - Increase powers of 5 cache by 1.
 - Merge branch 'master' into 8366017
 - ... and 20 more: https://git.openjdk.org/jdk/compare/6d1529cd...5a4d7a6e

Changes: https://git.openjdk.org/jdk/pull/26990/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26990&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366017
  Stats: 2933 lines in 7 files changed: 747 ins; 1427 del; 759 mod
  Patch: https://git.openjdk.org/jdk/pull/26990.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26990/head:pull/26990

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

From rgiulietti at openjdk.org  Tue Oct 14 17:57:08 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 14 Oct 2025 17:57:08 GMT
Subject: RFR: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal
In-Reply-To: 
References: 
Message-ID: 

On Thu, 28 Aug 2025 15:24:21 GMT, Raffaello Giulietti  wrote:

> Yet another step in modernizing `FloatingDecimal`s floating-point parsing.

Parsing proper has been the topic of a [previous PR](https://github.com/openjdk/jdk/pull/22737
). However, the mathematical conversion from the decimal representation itself still relied on existing code.

The plan is to rework the conversion algorithms and end up with a 3 tiers schema.

* The 1st tier implements some simple, efficient fast paths. They apply to a large number of simple decimals, like `1.2345` or `2.3456e-9` (see the code for the details).
* The 2nd tier will implement some more involved fast paths with higher precision arithmetic. The hope is to be able to convert most decimals produced by `Double.toString(double)` in just the 1st or 2nd tier.
* The 3rd is the fall back tier, using full precision arithmetic for long decimals. This tier will undergo a rehaul, reducing its complexity, and relying on `[Mutable]BigInteger` rather than `FDBigInteger`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26990#issuecomment-3234043827

From swen at openjdk.org  Tue Oct 14 17:57:10 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 14 Oct 2025 17:57:10 GMT
Subject: RFR: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal
In-Reply-To: 
References: 
Message-ID: 

On Thu, 28 Aug 2025 15:24:21 GMT, Raffaello Giulietti  wrote:

> Yet another step in modernizing `FloatingDecimal`s floating-point parsing.

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 53:

> 51:     private static final int    SINGLE_EXP_SHIFT  = FloatConsts.SIGNIFICAND_WIDTH - 1;
> 52:     private static final int    SINGLE_FRACT_HOB  = 1 << SINGLE_EXP_SHIFT;
> 53:     private static final int    SINGLE_MAX_DECIMAL_DIGITS = 7;

Suggestion:

    private static final int
            EXP_SHIFT                 = DoubleConsts.SIGNIFICAND_WIDTH - 1,
            MAX_SMALL_BIN_EXP         = 62,
            MIN_SMALL_BIN_EXP         = -63 / 3,
            MAX_DECIMAL_DIGITS        = 15,  // max{n : 10^n <= 2^P}
            FLOG_10_MAX_LONG          = 18,  // max{i : 10^i ? Long.MAX_VALUE}
            SINGLE_EXP_SHIFT          = FloatConsts.SIGNIFICAND_WIDTH - 1,
            SINGLE_FRACT_HOB          = 1 << SINGLE_EXP_SHIFT,
            SINGLE_MAX_DECIMAL_DIGITS = 7;
    private static final long
            FRACT_HOB = 1L << EXP_SHIFT, // assumed High-Order bit
            EXP_ONE   = (long) DoubleConsts.EXP_BIAS << EXP_SHIFT; // exponent of 1.0

How about this style?

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 164:

> 162:     private static final BinaryToASCIIConverter B2AC_NOT_A_NUMBER = new ExceptionalBinaryToASCIIBuffer(NAN_REP);
> 163:     private static final BinaryToASCIIConverter B2AC_POSITIVE_ZERO = new BinaryToASCIIBuffer(false, new byte[] {'0'});
> 164:     private static final BinaryToASCIIConverter B2AC_NEGATIVE_ZERO = new BinaryToASCIIBuffer(true,  new byte[] {'0'});

Suggestion:

    private static final BinaryToASCIIConverter
            B2AC_POSITIVE_INFINITY = new ExceptionalBinaryToASCIIBuffer(INFINITY_REP),
            B2AC_NEGATIVE_INFINITY = new ExceptionalBinaryToASCIIBuffer("-" + INFINITY_REP),
            B2AC_NOT_A_NUMBER      = new ExceptionalBinaryToASCIIBuffer(NAN_REP),
            B2AC_POSITIVE_ZERO     = new BinaryToASCIIBuffer(false, new byte[] {'0'}),
            B2AC_NEGATIVE_ZERO     = new BinaryToASCIIBuffer(true,  new byte[] {'0'});

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 905:

> 903:             new PreparedASCIIToBinaryBuffer(0.0d, 0.0f);
> 904:     private static final PreparedASCIIToBinaryBuffer A2BC_NEGATIVE_ZERO =
> 905:             new PreparedASCIIToBinaryBuffer(-0.0d, -0.0f);

Suggestion:

    private static final PreparedASCIIToBinaryBuffer 
            A2BC_POSITIVE_INFINITY = new PreparedASCIIToBinaryBuffer(Double.POSITIVE_INFINITY, Float.POSITIVE_INFINITY),
            A2BC_NEGATIVE_INFINITY = new PreparedASCIIToBinaryBuffer(Double.NEGATIVE_INFINITY, Float.NEGATIVE_INFINITY),
            A2BC_NOT_A_NUMBER      = new PreparedASCIIToBinaryBuffer(Double.NaN, Float.NaN),
            A2BC_POSITIVE_ZERO     = new PreparedASCIIToBinaryBuffer(0.0d, 0.0f),
            A2BC_NEGATIVE_ZERO     = new PreparedASCIIToBinaryBuffer(-0.0d, -0.0f);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26990#discussion_r2347233355
PR Review Comment: https://git.openjdk.org/jdk/pull/26990#discussion_r2347234167
PR Review Comment: https://git.openjdk.org/jdk/pull/26990#discussion_r2347235787

From rgiulietti at openjdk.org  Tue Oct 14 18:02:05 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 14 Oct 2025 18:02:05 GMT
Subject: RFR: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal
In-Reply-To: 
References: 
Message-ID: <2G6MZQ9HGZ7LCdLu618xb_By5iPqf32Ln9qm11stxxg=.9fdec865-0203-404b-b9af-f20985bb1e4a@github.com>

On Thu, 28 Aug 2025 15:24:21 GMT, Raffaello Giulietti  wrote:

> Yet another step in modernizing `FloatingDecimal`s floating-point parsing.

This work's focus is on:
* Code reduction.
* Extensive documentation of mathematical aspects.
* Enhanced performance.

In particular, parsing outcomes of the `Double.toString(double)` and `Float.toString(float)` methods should be faster.

_Before_

Benchmark                               Mode  Cnt     Score    Error  Units
FloatingPointParse.parseDoubleS1        avgt    9   268.213 ?  0.901  ns/op
FloatingPointParse.parseDoubleS10       avgt    9  1091.924 ? 52.040  ns/op
FloatingPointParse.parseDoubleS2        avgt    9   340.953 ? 10.139  ns/op
FloatingPointParse.parseDoubleS4        avgt    9   499.272 ? 13.940  ns/op
FloatingPointParse.parseDoubleToString  avgt    9   272.870 ?  1.677  ns/op
FloatingPointParse.parseFloatS1         avgt    9    72.291 ?  1.574  ns/op
FloatingPointParse.parseFloatS10        avgt    9   321.380 ? 10.046  ns/op
FloatingPointParse.parseFloatS2         avgt    9   104.538 ?  2.701  ns/op
FloatingPointParse.parseFloatS4         avgt    9   159.879 ?  6.711  ns/op
FloatingPointParse.parseFloatToString   avgt    9   140.413 ?  1.844  ns/op


_After_

Benchmark                               Mode  Cnt    Score   Error  Units
FloatingPointParse.parseDoubleS1        avgt    9   77.753 ? 1.437  ns/op
FloatingPointParse.parseDoubleS10       avgt    9  368.850 ? 0.974  ns/op
FloatingPointParse.parseDoubleS2        avgt    9  112.624 ? 2.094  ns/op
FloatingPointParse.parseDoubleS4        avgt    9  177.373 ? 1.137  ns/op
FloatingPointParse.parseDoubleToString  avgt    9   76.904 ? 1.152  ns/op
FloatingPointParse.parseFloatS1         avgt    9   53.126 ? 0.793  ns/op
FloatingPointParse.parseFloatS10        avgt    9  300.140 ? 1.330  ns/op
FloatingPointParse.parseFloatS2         avgt    9   83.329 ? 0.251  ns/op
FloatingPointParse.parseFloatS4         avgt    9  137.046 ? 2.160  ns/op
FloatingPointParse.parseFloatToString   avgt    9   56.267 ? 0.698  ns/op```

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

PR Comment: https://git.openjdk.org/jdk/pull/26990#issuecomment-3403016460

From mdoerr at openjdk.org  Tue Oct 14 19:30:05 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 14 Oct 2025 19:30:05 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Oct 2025 13:42:18 GMT, Patricio Chilano Mateo  wrote:

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

https://github.com/openjdk/jdk/pull/27676 has been integrated which requires resolution.

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3403294086

From duke at openjdk.org  Tue Oct 14 19:40:37 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 14 Oct 2025 19:40:37 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in FIPS
 197
Message-ID: 

General:
-----------
i) This work is to replace the existing AES cipher under the Cryptix license.

ii) The lookup tables are employed for performance, but also for operating in constant time.

iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.

iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.

Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.

Correctness:
-----------------
The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:

i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass

-intrinsics mode for:

ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass

iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures

iv) jdk_security_infra: passed, with 48 known failures

v) tier1 and tier2: all 110257 tests pass

Security:
-----------
In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.

Performance:
------------------
All AES related benchmarks have been executed against the new and original Cryptix code:

micro:org.openjdk.bench.javax.crypto.AES

micro:org.openjdk.bench.javax.crypto.full.AESBench

micro:org.openjdk.bench.javax.crypto.full.AESExtraBench

micro:org.openjdk.bench.javax.crypto.full.AESGCMBench

micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer

micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream

micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream

micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.

micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)

The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:

i) Default (no JVM options, non-intrinsics) mode:

a) Encryption:  the new code performed better for both architectures tested (x86: +7.6%, arm64: +3.5%)

Analysis: the new code makes some optimizations in the last cipher round with the T2 lookup table that Cryptix may not, hence the better performance in non-intrinsics.

b) Decryption: the new code performed mixed between architectures tested (x86: +8.3%, arm64: -1.1%)

Analysis: the new code performs predominately better, except for decryption on arm64, which we believe is negligible and acceptable to have noticeably better performance with x86 decryption.

ii) Default (no JVM options, intrinsics) mode:

a) Encryption and Decryption:  as expected, both the new code and Cryptix code performed similarly (within the error margins)

Analysis: this is from the fact that the intrinsics related code has not changed with the new changes.

iii) Interpreted-only (-Xint) mode:

a) Encryption: the new code performed better than the Cryptix code for both architectures (x86: +0.6%, arm64: +6.0%).

b) Decryption:  the new code performed slightly worse than the Cryptix code for both architectures (x86: -3.3%, arm64: -2.4%).

Analysis: the design of the new code was focused on instruction efficiency; eliminating unnecessary index variables, rolling out the rounds loop, and using no objects for round and inverse round transforms.  This is especially noticeable in arm64 encryption, but we believe that decryption's slight drop in performance is negligible.

iv) JIT compiler (-Xcomp) mode:

a) Encryption: in this mode, performance is mixed performant between the two architectures tested (x86: +11.7%, arm64: +1.5%).

b) Decryption: performance is decreases for both of the architectures tested (x86: -4.9%, arm64: -3.2%).

Analysis: As with the no options results, we believe that the increase in performance for both architectures in encryption is most likely from the T2 gadgetry that we've implemented.   We believe that the slight performance drop in decryption is negligible.  In any case, the -Xcomp option is primarily used for debugging purposes, ergo we are not as concerned about this slight drop.

Resource utilization:
----------------------------
The new AES code uses similar resources to that of the existing Cryptix code.  Memory allocation has the following characteristics:

i) Peak allocation for both Cryptix and the new code is only a fraction of a percentage point different for both the 1 cipher object and 10 cipher objects test.

Analysis: We believe that this is negligible given the difference in the 20ms to 50ms window of peak allocation.

ii) Total GC pause for Cryptix and the new code only differs by less than 5% for both the 1 object and 10 objects test.

Analysis: This is acceptable behavior given that the benchmark performance for the new code is better overall.

iii) Peak pre-GC allocation for Cryptix and the new code is only a fraction of a percent more for the new code in the 1 object case and is only 2% more for the 10 objects case.

Analysis: These differences indicate ~500 bytes per object discrepancy between the Cryptix and new code, which is also negligible.

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

Commit messages:
 - Implement the rest of the class name changes in intrinsics
 - 8326609: New AES implementation with updates specified in FIPS 197

Changes: https://git.openjdk.org/jdk/pull/27807/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326609
  Stats: 2989 lines in 5 files changed: 1506 ins; 1473 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

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

From duke at openjdk.org  Tue Oct 14 19:48:47 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 14 Oct 2025 19:48:47 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v2]
In-Reply-To: 
References: 
Message-ID: 

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Add vmIntrinsics.hpp updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/1f742c1f..af0f9c4c

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

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

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

From vlivanov at openjdk.org  Tue Oct 14 20:07:13 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 14 Oct 2025 20:07:13 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 19:48:47 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add vmIntrinsics.hpp updates

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43:

> 41:  * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688
> 42:  */
> 43: public final class AESCrypt extends SymmetricCipher {

Should the class be named `AES_Crypt` instead?

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1408:

> 1406:      */
> 1407:     public void encryptBlock(byte[] plain, int pOff, byte[] cipher, int cOff) {
> 1408:         implEncryptBlock(plain, pOff, cipher, cOff);

There are no bounds checks around intrinsic methods. Previous implementation has a comment stating that the checks are placed in caller code (for performance reasons) and declared the methods package-private. It makes sense either to introduce bounds checks here or keep the wrappers package-private.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2430292341
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2430306371

From pchilanomate at openjdk.org  Tue Oct 14 20:23:33 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 14 Oct 2025 20:23:33 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: 
References: 
Message-ID: 

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into JDK-8369238
 - RISC-V support
 - Fix whitespaces
 - v1

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

Changes: https://git.openjdk.org/jdk/pull/27802/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=01
  Stats: 1979 lines in 94 files changed: 1628 ins; 86 del; 265 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

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

From pchilanomate at openjdk.org  Tue Oct 14 20:23:34 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 14 Oct 2025 20:23:34 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 19:27:40 GMT, Martin Doerr  wrote:

> #27676 has been integrated which requires resolution.
>
Thanks, merged with latest master.

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3403481837

From asemenyuk at openjdk.org  Tue Oct 14 20:40:12 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 14 Oct 2025 20:40:12 GMT
Subject: RFR: 8369853: jpackage signing tests fail after JDK-8358723
Message-ID: 

- Open "jdk.jpackage.internal.resources" package for jpackage tests instead of exporting it.
 - Fix a typo in test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherVerifier.java

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

Commit messages:
 - 8369853: jpackage signing tests fail after JDK-8358723

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

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

From asemenyuk at openjdk.org  Tue Oct 14 20:40:12 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 14 Oct 2025 20:40:12 GMT
Subject: RFR: 8369853: jpackage signing tests fail after JDK-8358723
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Oct 2025 20:34:02 GMT, Alexey Semenyuk  wrote:

> - Open "jdk.jpackage.internal.resources" package for jpackage tests instead of exporting it.
>  - Fix a typo in test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherVerifier.java

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/27809#issuecomment-3403527762

From bpb at openjdk.org  Tue Oct 14 20:55:33 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 14 Oct 2025 20:55:33 GMT
Subject: RFR: 8191963: Path.equals() and File.equals() return true for two
 different files on Windows [v3]
In-Reply-To: 
References: 
Message-ID: 

> Replace logic in `java.io.WinNTFileSystems.compare(File,File)` with that from `sun.nio.fs.WindowsPath.compareTo(Path)`.

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

 - 8191963: Make legacy behavior be the default
 - Merge
 - 8191963: Add system property to enable legacy behavior
 - Merge
 - 8191963: Path.equals() and File.equals() return true for two different files on Windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25788/files
  - new: https://git.openjdk.org/jdk/pull/25788/files/a63e13e1..53caf9eb

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

  Stats: 23204 lines in 696 files changed: 15893 ins; 4075 del; 3236 mod
  Patch: https://git.openjdk.org/jdk/pull/25788.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25788/head:pull/25788

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

From almatvee at openjdk.org  Tue Oct 14 20:58:08 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 14 Oct 2025 20:58:08 GMT
Subject: RFR: 8369853: jpackage signing tests fail after JDK-8358723
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Oct 2025 20:34:02 GMT, Alexey Semenyuk  wrote:

> - Open "jdk.jpackage.internal.resources" package for jpackage tests instead of exporting it.
>  - Fix a typo in test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherVerifier.java

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27809#pullrequestreview-3337454858

From bpb at openjdk.org  Tue Oct 14 21:02:02 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 14 Oct 2025 21:02:02 GMT
Subject: RFR: 8191963: Path.equals() and File.equals() return true for two
 different files on Windows [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 6 Oct 2025 16:12:49 GMT, Naoto Sato  wrote:

>>> > [...] system property to restore long standing behavior.
>>> 
>>> Added in [a63e13e](https://github.com/openjdk/jdk/commit/a63e13e1e086d299a4e1326606f3322a42cb5977).
>> 
>> @naotoj, @xuemingshen-oracle, do you have any thoughts on the compatibility impact?
>
>> > > [...] system property to restore long standing behavior.
>> > 
>> > 
>> > Added in [a63e13e](https://github.com/openjdk/jdk/commit/a63e13e1e086d299a4e1326606f3322a42cb5977).
>> 
>> @naotoj, @xuemingshen-oracle, do you have any thoughts on the compatibility impact?
> 
> Would it be safer to make the new behavior as opt-in, as well as making the system property to be windows specific `windowsCompatibleEquals` or something? Making it as the default might be a bit risky to me.
> 
> Also, IIUC the test is comparing cases between 'I', '\u0130' and '\u0131'. Probably we need to cross test with 'i' too.

@naotoj Thanks for the comments.

> Would it be safer to make the new behavior as opt-in,

Commit 53caf9e changes it to opt-in.

> as well as making the system property to be windows specific

Also done in 53caf9e.

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

PR Comment: https://git.openjdk.org/jdk/pull/25788#issuecomment-3403596720

From jlu at openjdk.org  Tue Oct 14 21:11:39 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 14 Oct 2025 21:11:39 GMT
Subject: RFR: 8369590: LocaleEnhanceTest has incorrectly passing test case
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR corrects _test/jdk/java/util/Locale/LocaleEnhanceTest.java_, which has two test cases under `testBuilderSetLanguageTag()` which accidentally pass. One checks that Locale.setLanguageTag(String) throws ILE for duplicate extensions and the other for duplicate U-extension keys. The test cases are updated to actually test the provided code. When the test cases are fixed, they now fail.
> 
> Fixing the behavior to match the expectation of those test cases is consistent with the specification.
> 
> From `Locale.forLanguageTag(String)`,
> 
>> 
>>      * 
    If the specified language tag contains any ill-formed subtags,
>>      * the first such subtag and all following subtags are ignored.  Compare
>>      * to {@link Locale.Builder#setLanguageTag(String)} which throws an exception
>>      * in this case.
> 
> and the RFC specification
> 
>> Each singleton subtag MUST appear at most one time in each tag
>>        (other than as a private use subtag).  That is, singleton subtags
>>        MUST NOT be repeated.  For example, the tag "en-a-bbb-a-ccc" is
>>        invalid because the subtag 'a' appears twice.
> 
> Since duplicate extensions (and Unicode keys/attributes) are invalid, throwing `IllformedLocaleException` in (the strict) `Locale.Builder` and ignoring in (the lenient) `Locale.forLanguageTag` for such tags would be appropriate. This PR updates the implementation as such.

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

  Align setExtension(char, String) + spec updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27775/files
  - new: https://git.openjdk.org/jdk/pull/27775/files/f73a15ae..b3167f13

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

  Stats: 32 lines in 3 files changed: 11 ins; 4 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27775.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27775/head:pull/27775

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

From jlu at openjdk.org  Tue Oct 14 21:11:41 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 14 Oct 2025 21:11:41 GMT
Subject: RFR: 8369590: LocaleEnhanceTest has incorrectly passing test case
 [v2]
In-Reply-To: 
References: 
 <11DDueNxPmVaTZ2u9WMchm4kWfC5Ims83jkGE3S2RXQ=.03c79e51-6977-45c0-ae6f-c55e03d62598@github.com>
 
Message-ID: 

On Mon, 13 Oct 2025 22:26:07 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding test case to confirm duplicate U-extension attributes for setExtension(char, String)
>
> IIUC, the quote from the RFC refers to duplicate singletons. For example, it would reject something like `-u-aa-bbb-u-cc-ddd`. So I believe that rule doesn?t apply to cases like `-u-aa-bbb-AA-ccc`. I checked the `-u` extension definition in LDML but couldn?t find any description regarding duplicate keywords.
> 
> That said, I think it makes sense to allow them in lenient mode and throw an exception in strict mode. Since this would introduce a behavioral change, I?d expect it to require a CSR.

@naotoj CSR is filed and this PR is updated with the appropriate specification updates. `setExtension(char, String)` is also updated to align with `setLanguageTag(String)` on the behavior of duplicate U-extension keys and attributes as we discussed.

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

PR Comment: https://git.openjdk.org/jdk/pull/27775#issuecomment-3403621489

From elliot.barlas at elastic.co  Tue Oct 14 22:07:41 2025
From: elliot.barlas at elastic.co (Elliot Barlas)
Date: Tue, 14 Oct 2025 15:07:41 -0700
Subject: Potential Thread-Safety Bug in XMLEntityManager
Message-ID: 

Hello core-libs-dev!

There appears to be a thread-safety bug in
com.sun.org.apache.xerces.internal.impl.XMLEntityManager related to the
introduction of the following field[1] in the following commit[2].

[1] CatalogResolver fDefCR // the default JDK Catalog Resolver

[2]
https://github.com/openjdk/jdk/commit/93bdc2a6db91a95d6ee52ec92080e586c694dad5

Multiple threads executing the following sample code use the same
underlying javax.xml.catalog.CatalogImpl obtained from
JdkXmlConfig.getInstance().getJdkCatalog(). CatalogImpl is not thread safe.
The resolveEntity method mutates the underlying JDK catalog[3].

[3]
https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java#L279

XMLEntityManager entityManager = new XMLEntityManager();
XMLResourceIdentifier resourceIdentifier = new XMLResourceIdentifierImpl(
        "http://example.com/dtd/sample.dtd",
        "sample.dtd",
        "http://example.com/base/",
        "http://example.com/base/sample.dtd");
entityManager.resolveEntity(resourceIdentifier);

Prior to the commit above, this code did not access a shared JDK
CatalogImpl.

-Elliot Barlas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From asemenyuk at openjdk.org  Tue Oct 14 22:34:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 14 Oct 2025 22:34:10 GMT
Subject: Integrated: 8369853: jpackage signing tests fail after JDK-8358723
In-Reply-To: 
References: 
Message-ID: <9XMmacaobBovMpPN07Os04cMIOKn60jzcTkn7ILAz98=.c2da79e1-1e8b-41bc-bc2f-914e2b7d85f4@github.com>

On Tue, 14 Oct 2025 20:34:02 GMT, Alexey Semenyuk  wrote:

> - Open "jdk.jpackage.internal.resources" package for jpackage tests instead of exporting it.
>  - Fix a typo in test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherVerifier.java

This pull request has now been integrated.

Changeset: 95def24b
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/95def24b025341b5a6b99abdd4d1f3d26a40431c
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8369853: jpackage signing tests fail after JDK-8358723

Reviewed-by: almatvee

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

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

From naoto at openjdk.org  Tue Oct 14 23:06:08 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 Oct 2025 23:06:08 GMT
Subject: RFR: 8191963: Path.equals() and File.equals() return true for two
 different files on Windows [v3]
In-Reply-To: 
References: 
 
Message-ID: <_lEEsOVcD7N_SulWY6mQuB9tirIHmXqJc26AiGiUhW4=.2135a2f8-886e-48fc-9eb0-55244a0a2d9b@github.com>

On Tue, 14 Oct 2025 20:55:33 GMT, Brian Burkhalter  wrote:

>> Replace logic in `java.io.WinNTFileSystems.compare(File,File)` with that from `sun.nio.fs.WindowsPath.compareTo(Path)`.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8191963: Make legacy behavior be the default
>  - Merge
>  - 8191963: Add system property to enable legacy behavior
>  - Merge
>  - 8191963: Path.equals() and File.equals() return true for two different files on Windows

LGTM. Probably someone else might want to review this too

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25788#pullrequestreview-3337818226

From bpb at openjdk.org  Tue Oct 14 23:09:09 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 14 Oct 2025 23:09:09 GMT
Subject: RFR: 8191963: Path.equals() and File.equals() return true for two
 different files on Windows [v3]
In-Reply-To: <_lEEsOVcD7N_SulWY6mQuB9tirIHmXqJc26AiGiUhW4=.2135a2f8-886e-48fc-9eb0-55244a0a2d9b@github.com>
References: 
 
 <_lEEsOVcD7N_SulWY6mQuB9tirIHmXqJc26AiGiUhW4=.2135a2f8-886e-48fc-9eb0-55244a0a2d9b@github.com>
Message-ID: 

On Tue, 14 Oct 2025 23:03:42 GMT, Naoto Sato  wrote:

> LGTM.

Thanks.

> Probably someone else might want to review this too

Yeah, good idea.

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

PR Comment: https://git.openjdk.org/jdk/pull/25788#issuecomment-3403920497

From darcy at openjdk.org  Wed Oct 15 04:45:33 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 15 Oct 2025 04:45:33 GMT
Subject: RFR: 8369858: Remove darcy author tags from jdk tests
Message-ID: 

Updating tests I've wrote to conform to current conventions of not having author tags.

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

Commit messages:
 - JDK-8369858: Remove darcy author tags from jdk tests

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

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

From duke at openjdk.org  Wed Oct 15 05:28:31 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 05:28:31 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v3]
In-Reply-To: 
References: 
Message-ID: 

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with two additional commits since the last revision:

 - encryptBlock/decryptBlock methods set to package-private
 - Revert AESCrypt to AES_Crypt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/af0f9c4c..07003719

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

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

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

From duke at openjdk.org  Wed Oct 15 05:28:34 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 05:28:34 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 14 Oct 2025 19:59:04 GMT, Vladimir Ivanov  wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add vmIntrinsics.hpp updates
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43:
> 
>> 41:  * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688
>> 42:  */
>> 43: public final class AESCrypt extends SymmetricCipher {
> 
> Should the class be named `AES_Crypt` instead?

Yes, you're right.  I'm not sure how it reverted back to AESCrypt.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1408:
> 
>> 1406:      */
>> 1407:     public void encryptBlock(byte[] plain, int pOff, byte[] cipher, int cOff) {
>> 1408:         implEncryptBlock(plain, pOff, cipher, cOff);
> 
> There are no bounds checks around intrinsic methods. Previous implementation has a comment stating that the checks are placed in caller code (for performance reasons) and declared the methods package-private. It makes sense either to introduce bounds checks here or keep the wrappers package-private.

Good catch, I will leave it as package-private then.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2431157744
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2431158083

From duke at openjdk.org  Wed Oct 15 05:51:40 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 05:51:40 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: 
References: 
Message-ID: 

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Add remaining files to be staged

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/07003719..3fc25aef

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

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

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

From alanb at openjdk.org  Wed Oct 15 06:08:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 Oct 2025 06:08:02 GMT
Subject: RFR: 8369858: Remove darcy author tags from jdk tests
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Oct 2025 04:37:50 GMT, Joe Darcy  wrote:

> Updating tests I've wrote to conform to current conventions of not having author tags.

I think it's always okay to remove oneself but I see some of the `@author` tags list others (Stuart, Kumar, even madbot). I didn't check the history but I will guess that you created these tests, others added their name when they modified the test at some point later, is that right?

test/jdk/java/lang/reflect/Generics/getAnnotationTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2004, 2025,Oracle and/or its affiliates. All rights reserved.

The skara bot has spotted the formatting issue here.

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

PR Review: https://git.openjdk.org/jdk/pull/27813#pullrequestreview-3338492969
PR Review Comment: https://git.openjdk.org/jdk/pull/27813#discussion_r2431217576

From scolebourne at joda.org  Wed Oct 15 08:04:25 2025
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 15 Oct 2025 09:04:25 +0100
Subject: Duration.MAX_VALUE
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 at 21:44, Pavel Rappo  wrote:
>
> Thanks! I think that your experiment confirms that we do _not_ need
> subtraction, at least initially. A single, focused method for
> saturated addition should be enough. I'll update PR (
> https://github.com/openjdk/jdk/pull/27549 ), which you are welcome to
> review.
>
> Stephen, are you okay with this?

Given I find the saturating use case a bit marginal, I'm happy to only
see the add variant added.
Stephen

From fandreuzzi at openjdk.org  Wed Oct 15 08:10:06 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 08:10:06 GMT
Subject: RFR: 8369817: [TESTBUG] EmptyPath::toString is ignored [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 14 Oct 2025 11:14:52 GMT, Albert Mingkun Yang  wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename
>
> Marked as reviewed by ayang (Reviewer).

Thanks for the review @albertnetymk and @jaikiran.

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

PR Comment: https://git.openjdk.org/jdk/pull/27797#issuecomment-3405092682

From duke at openjdk.org  Wed Oct 15 08:10:08 2025
From: duke at openjdk.org (duke)
Date: Wed, 15 Oct 2025 08:10:08 GMT
Subject: RFR: 8369817: [TESTBUG] EmptyPath::toString is ignored [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 11:20:40 GMT, Francesco Andreuzzi  wrote:

>> JUnit ignores `@Test` methods which do not return `void`:
>> 
>> 
>> (1) [WARNING] @Test method 'public java.lang.String EmptyPath.toString()' must not return a value. It will not be executed.
>>     Source: MethodSource [className = 'EmptyPath', methodName = 'toString', methodParameterTypes = '']
>>             at EmptyPath.toString(SourceFile:0)
>> 
>> 
>> I propose to amend the method signature. This looks trivial to me.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename

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

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

PR Comment: https://git.openjdk.org/jdk/pull/27797#issuecomment-3405095421

From aturbanov at openjdk.org  Wed Oct 15 08:25:24 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 15 Oct 2025 08:25:24 GMT
Subject: RFR: 8369656 : Calling CompletableFuture.join() could execute task
 in common pool [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 13:10:22 GMT, Viktor Klang  wrote:

>> Addresses the regression regarding pool assistance and includes a regression test for `CompletableFuture::get()`, `CompletableFuture::get(timeout, unit)`, and `CompletableFuture::join()`
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improving the name of the regtest

test/jdk/java/util/concurrent/tck/CompletableFutureTest.java line 5153:

> 5151:                             try {
> 5152:                                 return extractor.pool(cf);
> 5153:                             } catch(Exception ex) {

Suggestion:

                            } catch (Exception ex) {

test/jdk/java/util/concurrent/tck/CompletableFutureTest.java line 5170:

> 5168: 
> 5169:         try (var pool = new ForkJoinPool(2)) {
> 5170:             for(var extractor : extractors) {

Suggestion:

            for (var extractor : extractors) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27800#discussion_r2431584607
PR Review Comment: https://git.openjdk.org/jdk/pull/27800#discussion_r2431585306

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 aturbanov at openjdk.org  Wed Oct 15 08:42:22 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 15 Oct 2025 08:42:22 GMT
Subject: RFR: 8369590: LocaleEnhanceTest has incorrectly passing test case
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 21:11:39 GMT, Justin Lu  wrote:

>> This PR corrects _test/jdk/java/util/Locale/LocaleEnhanceTest.java_, which has two test cases under `testBuilderSetLanguageTag()` which accidentally pass. One checks that Locale.setLanguageTag(String) throws ILE for duplicate extensions and the other for duplicate U-extension keys. The test cases are updated to actually test the provided code. When the test cases are fixed, they now fail.
>> 
>> Fixing the behavior to match the expectation of those test cases is consistent with the specification.
>> 
>> From `Locale.forLanguageTag(String)`,
>> 
>>> 
>>>      * 
    If the specified language tag contains any ill-formed subtags,
>>>      * the first such subtag and all following subtags are ignored.  Compare
>>>      * to {@link Locale.Builder#setLanguageTag(String)} which throws an exception
>>>      * in this case.
>> 
>> and the RFC specification
>> 
>>> Each singleton subtag MUST appear at most one time in each tag
>>>        (other than as a private use subtag).  That is, singleton subtags
>>>        MUST NOT be repeated.  For example, the tag "en-a-bbb-a-ccc" is
>>>        invalid because the subtag 'a' appears twice.
>> 
>> Since duplicate extensions (and Unicode keys/attributes) are invalid, throwing `IllformedLocaleException` in (the strict) `Locale.Builder` and ignoring in (the lenient) `Locale.forLanguageTag` for such tags would be appropriate. This PR updates the implementation as such.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align setExtension(char, String) + spec updates

test/jdk/java/util/Locale/LocaleEnhanceTest.java line 1096:

> 1094:         // null attribute throws NPE
> 1095:         assertThrows(NullPointerException.class,
> 1096:                 () ->  new Builder().addUnicodeLocaleAttribute(null), "null attribute");

Suggestion:

                () -> new Builder().addUnicodeLocaleAttribute(null), "null attribute");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27775#discussion_r2431645260

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 fandreuzzi at openjdk.org  Wed Oct 15 09:21:38 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 09:21:38 GMT
Subject: Integrated: 8369817: [TESTBUG] EmptyPath::toString is ignored
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Oct 2025 10:53:55 GMT, Francesco Andreuzzi  wrote:

> JUnit ignores `@Test` methods which do not return `void`:
> 
> 
> (1) [WARNING] @Test method 'public java.lang.String EmptyPath.toString()' must not return a value. It will not be executed.
>     Source: MethodSource [className = 'EmptyPath', methodName = 'toString', methodParameterTypes = '']
>             at EmptyPath.toString(SourceFile:0)
> 
> 
> I propose to amend the method signature. This looks trivial to me.

This pull request has now been integrated.

Changeset: 008d8d91
Author:    Francesco Andreuzzi 
Committer: Albert Mingkun Yang 
URL:       https://git.openjdk.org/jdk/commit/008d8d914cd4dd4573361390ee31120134338802
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8369817: [TESTBUG] EmptyPath::toString is ignored

Reviewed-by: jpai, ayang

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

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

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 aturbanov at openjdk.org  Wed Oct 15 09:34:00 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 15 Oct 2025 09:34:00 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v4]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
Message-ID: 

On Mon, 13 Oct 2025 18:26:40 GMT, Lance Andersen  wrote:

>> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
>> 
>> - Deprecate SQLPermission for removal
>> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
>> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
>> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
>> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
>> 
>> Tiers 1-3 have been run
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Round 3 of formating/typo updates

src/java.sql/share/classes/java/sql/Connection.java line 1715:

> 1713:      * @since 26
> 1714:      */
> 1715:     default String enquoteLiteral(String val)  throws SQLException {

Suggestion:

    default String enquoteLiteral(String val) throws SQLException {

src/java.sql/share/classes/java/sql/Connection.java line 1716:

> 1714:      */
> 1715:     default String enquoteLiteral(String val)  throws SQLException {
> 1716:         return "'" + val.replace("'", "''") +  "'";

Suggestion:

        return "'" + val.replace("'", "''") + "'";

src/java.sql/share/classes/java/sql/Connection.java line 1830:

> 1828:         }
> 1829:         if (Pattern.compile("[\\p{Alpha}][\\p{Alnum}_]*").matcher(identifier).matches()) {
> 1830:             return alwaysQuote ?  "\"" + identifier + "\"" : identifier;

Suggestion:

            return alwaysQuote ? """ + identifier + """ : identifier;

src/java.sql/share/classes/java/sql/Connection.java line 1950:

> 1948:      * @since 26
> 1949:      */
> 1950:     default String enquoteNCharLiteral(String val)  throws SQLException {

Suggestion:

    default String enquoteNCharLiteral(String val) throws SQLException {

src/java.sql/share/classes/java/sql/Connection.java line 1951:

> 1949:      */
> 1950:     default String enquoteNCharLiteral(String val)  throws SQLException {
> 1951:         return "N'" + val.replace("'", "''") +  "'";

Suggestion:

        return "N'" + val.replace("'", "''") + "'";

test/jdk/java/sql/testng/test/sql/ConnectionTests.java line 173:

> 171:             {"Bruce Wayne", true, "\"Bruce Wayne\""},
> 172:             {"GoodDay$", false, "\"GoodDay$\""},
> 173:             {"GoodDay$", true, "\"GoodDay$\""},};

Suggestion:

            {"GoodDay$", true, ""GoodDay$""},
        };

test/jdk/java/sql/testng/test/sql/ConnectionTests.java line 187:

> 185:             {"Hello" + '\0', false},
> 186:             {"", false},
> 187:             {maxIdentifier + 'a', false},};

Suggestion:

            {maxIdentifier + 'a', false},
        };

test/jdk/java/sql/testng/test/sql/ConnectionTests.java line 208:

> 206:             {maxIdentifier, true},
> 207:             {maxIdentifier + 'a', false},
> 208:             {"", false},};

Suggestion:

            {"", false},
        };

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2431833438
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2431833893
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2431835388
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2431836043
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2431836395
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2431839471
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2431839956
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2431840368

From rgiulietti at openjdk.org  Wed Oct 15 10:13:23 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 15 Oct 2025 10:13:23 GMT
Subject: RFR: 8366478: BigDecimal roots
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
Message-ID: 

On Mon, 8 Sep 2025 16:51:33 GMT, fabioromano1  wrote:

>> An implementation of `BigDecimal.nthRoot(int, MathContext)`.
>
> @rgiulietti Here is the PR.

@fabioromano1 In the comments there are claims about the relative errors. Two questions arise:
* How were the bounds determined? There seems to be no indication in the comments provided so far.
* How much code would be needed to attain correct rounding in all modes?

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

PR Comment: https://git.openjdk.org/jdk/pull/27148#issuecomment-3405630102

From duke at openjdk.org  Wed Oct 15 10:44:42 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 15 Oct 2025 10:44:42 GMT
Subject: RFR: 8366478: BigDecimal roots
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 
Message-ID: <0eyIGTI7YMWSJrXEYQtCztRAWRwnx-Pxiwamou3BVKU=.a577b67a-8723-4c1f-be42-1d26c3fb2baf@github.com>

On Wed, 15 Oct 2025 10:10:43 GMT, Raffaello Giulietti  wrote:

>> @rgiulietti Here is the PR.
>
> @fabioromano1 In the comments there are claims about the relative errors. Two questions arise:
> * How were the bounds determined? There seems to be no indication in the comments provided so far.
> * How much code would be needed to attain correct rounding in all modes?

@rgiulietti 
> * How were the bounds determined? There seems to be no indication in the comments provided so far.

In case of `n < 0` and no halfway rounding, the root's inversion gives an error of 1 ulp, that's why we add one more digit to the integer root, so that the integer root has an error of 0.1 ulps, and therefore the error of the inverted root is 1+0.1 ulps. Same reasoning for halfway rounding gives half of the error just found.
> * How much code would be needed to attain correct rounding in all modes?

If `n > 0`, the PR code already gives correct rounding in all modes, but in case of `n < 0`, I'm afraid there's no way to have always correct rounding, due to table maker's dilemma.

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

PR Comment: https://git.openjdk.org/jdk/pull/27148#issuecomment-3405797048

From dl at openjdk.org  Wed Oct 15 10:55:55 2025
From: dl at openjdk.org (Doug Lea)
Date: Wed, 15 Oct 2025 10:55:55 GMT
Subject: RFR: 8369656 : Calling CompletableFuture.join() could execute task
 in common pool [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 13:10:22 GMT, Viktor Klang  wrote:

>> Addresses the regression regarding pool assistance and includes a regression test for `CompletableFuture::get()`, `CompletableFuture::get(timeout, unit)`, and `CompletableFuture::join()`
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improving the name of the regtest

Thanks for doing this. I just checked some of my misc CF performance tests and as expected, there's no impact.

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

Marked as reviewed by dl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27800#pullrequestreview-3339769503

From alanb at openjdk.org  Wed Oct 15 11:17:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 Oct 2025 11:17:28 GMT
Subject: RFR: 8369656 : Calling CompletableFuture.join() could execute task
 in common pool [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 13:10:22 GMT, Viktor Klang  wrote:

>> Addresses the regression regarding pool assistance and includes a regression test for `CompletableFuture::get()`, `CompletableFuture::get(timeout, unit)`, and `CompletableFuture::join()`
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improving the name of the regtest

Marked as reviewed by alanb (Reviewer).

test/jdk/java/util/concurrent/tck/CompletableFutureTest.java line 5138:

> 5136:     }}
> 5137: 
> 5138:     public void testOnlyAssistsIfInTheSamePool() throws Exception{

The API and implementations speak of helping rather than assisting so if you are editing then maybe rename the method.

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

PR Review: https://git.openjdk.org/jdk/pull/27800#pullrequestreview-3339843773
PR Review Comment: https://git.openjdk.org/jdk/pull/27800#discussion_r2432170451

From azeller at openjdk.org  Wed Oct 15 11:39:58 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Wed, 15 Oct 2025 11:39:58 GMT
Subject: RFR: 8183336: Better cleanup for
 jdk/test/java/lang/module/customfs/ModulesInCustomFileSystem.java
Message-ID: 

We can set the java.io.tmpdir to point to the current directory to avoid polluting the temp directory.
@AlanBateman Thanks for this suggestion.

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

Commit messages:
 - Avoid creating mlibxxx directories in /tmp

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

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

From dholmes at openjdk.org  Wed Oct 15 12:03:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Oct 2025 12:03:09 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v3]
In-Reply-To: 
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
 
Message-ID: <0rnRO_-2MNLAqMn5-9b09DoN7EFJikRtKoNGxF0WKJ8=.75c1f1c4-3e17-4537-84ff-54e3dd3e65a8@github.com>

On Tue, 14 Oct 2025 14:55:05 GMT, Matias Saavedra Silva  wrote:

>> This is a cleanup change to remove an unused field `from_class` and the associated argument `caller` from `JVM_FindClassFromCaller` and its callers.  The method `JVM_FindClassFromCaller` has been renamed with these new changes in consideration. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David and Alan comments

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27735#pullrequestreview-3340007656

From lancea at openjdk.org  Wed Oct 15 12:22:42 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 15 Oct 2025 12:22:42 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v5]
In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
Message-ID: <-SRHLYYigWKWhSCOIfB51hKVNeB6JYDR2hkPKlCUQgE=.4fd148fb-f8c5-4ed9-a2f2-8e2233ae30d6@github.com>

> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
> 
> - Deprecate SQLPermission for removal
> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
> 
> Tiers 1-3 have been run

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

  Address additional spacing comments and add Util class for hosting shared default methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27693/files
  - new: https://git.openjdk.org/jdk/pull/27693/files/1c1c8047..85db0021

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

  Stats: 379 lines in 5 files changed: 307 ins; 37 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/27693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27693/head:pull/27693

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

From vklang at openjdk.org  Wed Oct 15 12:49:46 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 15 Oct 2025 12:49:46 GMT
Subject: RFR: 8369656 : Calling CompletableFuture.join() could execute task
 in common pool [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <2ywT_H_H7L0x8ck_N5bIAeUf8WA6d_plTctYPCekWK4=.91074c52-d08b-4047-9561-84aac21832b7@github.com>

On Wed, 15 Oct 2025 11:14:29 GMT, Alan Bateman  wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improving the name of the regtest
>
> test/jdk/java/util/concurrent/tck/CompletableFutureTest.java line 5138:
> 
>> 5136:     }}
>> 5137: 
>> 5138:     public void testOnlyAssistsIfInTheSamePool() throws Exception{
> 
> The API and implementations speak of helping rather than assisting so if you are editing then maybe rename the method.

Fair enough. I'll update the PR to reflect the correct verbiage :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27800#discussion_r2432427623

From vklang at openjdk.org  Wed Oct 15 12:54:57 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 15 Oct 2025 12:54:57 GMT
Subject: RFR: 8369656 : Calling CompletableFuture.join() could execute task
 in common pool [v3]
In-Reply-To: 
References: 
Message-ID: 

> Addresses the regression regarding pool assistance and includes a regression test for `CompletableFuture::get()`, `CompletableFuture::get(timeout, unit)`, and `CompletableFuture::join()`

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

  Changing name to help instead of assist; also fix some indentation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27800/files
  - new: https://git.openjdk.org/jdk/pull/27800/files/7fed8f87..55f09729

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

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

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

From alanb at openjdk.org  Wed Oct 15 13:19:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 Oct 2025 13:19:50 GMT
Subject: RFR: 8369656 : Calling CompletableFuture.join() could execute task
 in common pool [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 12:54:57 GMT, Viktor Klang  wrote:

>> Addresses the regression regarding pool assistance and includes a regression test for `CompletableFuture::get()`, `CompletableFuture::get(timeout, unit)`, and `CompletableFuture::join()`
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changing name to help instead of assist; also fix some indentation.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27800#pullrequestreview-3340365462

From alanb at openjdk.org  Wed Oct 15 13:22:18 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 Oct 2025 13:22:18 GMT
Subject: RFR: 8183336: Better cleanup for
 jdk/test/java/lang/module/customfs/ModulesInCustomFileSystem.java
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Oct 2025 09:38:08 GMT, Arno Zeller  wrote:

> We can set the java.io.tmpdir to point to the current directory to avoid polluting the temp directory.
> @AlanBateman Thanks for this suggestion.

Do you mind bumping the copyright header to 2025 before you integrate?

Change looks okay. As noted in the JBS issue, this is not an issue when running the tests with "make run-test", it's only an issue when using jtreg directly. There are likely many other tests that also use the tmp file system, it's not just this test.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27821#pullrequestreview-3340377099

From lancea at openjdk.org  Wed Oct 15 13:37:18 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 15 Oct 2025 13:37:18 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v5]
In-Reply-To: <-SRHLYYigWKWhSCOIfB51hKVNeB6JYDR2hkPKlCUQgE=.4fd148fb-f8c5-4ed9-a2f2-8e2233ae30d6@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 <-SRHLYYigWKWhSCOIfB51hKVNeB6JYDR2hkPKlCUQgE=.4fd148fb-f8c5-4ed9-a2f2-8e2233ae30d6@github.com>
Message-ID: 

On Wed, 15 Oct 2025 12:22:42 GMT, Lance Andersen  wrote:

>> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
>> 
>> - Deprecate SQLPermission for removal
>> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
>> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
>> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
>> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
>> 
>> Tiers 1-3 have been run
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address additional spacing comments and add Util class for hosting shared default methods

> On Oct 15, 2025, at 7:14?AM, Eirik Bjorsnos ***@***.***> wrote:
> 
> 
> @eirbjo commented on this pull request.
> 
> In src/java.sql/share/classes/java/sql/Connection.java :
> 
> > +     * @param alwaysQuote indicates if a simple SQL identifier should be
> +     * returned as a quoted identifier
> +     * @return A simple SQL identifier or a delimited identifier
> +     * @throws SQLException if identifier is not a valid identifier
> +     * @throws SQLFeatureNotSupportedException if the datasource does not support
> +     * delimited identifiers
> +     * @throws NullPointerException if identifier is ***@***.*** null}
> +     *
> +     * @since 26
> +     */
> +    default String enquoteIdentifier(String identifier, boolean alwaysQuote) throws SQLException {
> +        int len = identifier.length();
> +        if (len < 1 || len > 128) {
> +            throw new SQLException("Invalid name");
> +        }
> +        if (Pattern.compile("[\\p{Alpha}][\\p{Alnum}_]*").matcher(identifier).matches()) {
> Did you consider using String::matches or Pattern:matches here and elsewhere instead of explicit compilation?
> 

Pattern::matches invokes Pattern::compile and String::matches invokes Pattern::matches so did not see the benefit when we added the methods originally in JDK 9
> ?
> Reply to this email directly, view it on GitHub , or unsubscribe .
> You are receiving this because you were mentioned.
> 

My best,
Lance
--
Lance Andersen
USTA EMA President and CEO
PTR Professional 5A
USPTA Elite Professional
USTA Global Cardio Tennis-Master Trainer
USRSA
Mobile: 978 857-0446
luckydogtennis.com -- luckydogtennis.com/TennisBlog -- cardiotennis.com

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

PR Comment: https://git.openjdk.org/jdk/pull/27693#issuecomment-3406480600

From eirbjo at openjdk.org  Wed Oct 15 13:44:15 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 15 Oct 2025 13:44:15 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v5]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 <-SRHLYYigWKWhSCOIfB51hKVNeB6JYDR2hkPKlCUQgE=.4fd148fb-f8c5-4ed9-a2f2-8e2233ae30d6@github.com>
 
Message-ID: 

On Wed, 15 Oct 2025 13:34:07 GMT, Lance Andersen  wrote:

> Pattern::matches invokes Pattern::compile and String::matches invokes Pattern::matches so did not see the benefit when we added the methods originally in JDK 9

Yeah, it just seemed `String:matches` would be less verbose. I then noticed Roger raising related suggestions about precomplication, which is why I removed my comment from the PR since it seemed no longer relevant.

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

PR Comment: https://git.openjdk.org/jdk/pull/27693#issuecomment-3406512899

From matsaave at openjdk.org  Wed Oct 15 14:12:48 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 15 Oct 2025 14:12:48 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v3]
In-Reply-To: <0rnRO_-2MNLAqMn5-9b09DoN7EFJikRtKoNGxF0WKJ8=.75c1f1c4-3e17-4537-84ff-54e3dd3e65a8@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
 
 <0rnRO_-2MNLAqMn5-9b09DoN7EFJikRtKoNGxF0WKJ8=.75c1f1c4-3e17-4537-84ff-54e3dd3e65a8@github.com>
Message-ID: 

On Wed, 15 Oct 2025 12:00:10 GMT, David Holmes  wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   David and Alan comments
>
> Marked as reviewed by dholmes (Reviewer).

Thank you for the comments and reviews @dholmes-ora @fandreuz @AlanBateman and @liach!

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

PR Comment: https://git.openjdk.org/jdk/pull/27735#issuecomment-3406624739

From matsaave at openjdk.org  Wed Oct 15 14:12:49 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 15 Oct 2025 14:12:49 GMT
Subject: Integrated: 8351595: JVM_FindClassFromCaller: unused var may be
 removed
In-Reply-To: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
Message-ID: 

On Thu, 9 Oct 2025 18:29:36 GMT, Matias Saavedra Silva  wrote:

> This is a cleanup change to remove an unused field `from_class` and the associated argument `caller` from `JVM_FindClassFromCaller` and its callers.  The method `JVM_FindClassFromCaller` has been renamed with these new changes in consideration. Verified with tier1-5 tests.

This pull request has now been integrated.

Changeset: 784af438
Author:    Matias Saavedra Silva 
URL:       https://git.openjdk.org/jdk/commit/784af438efd3f2cd8a4c0518b4aa06d496bd7846
Stats:     15 lines in 4 files changed: 0 ins; 5 del; 10 mod

8351595: JVM_FindClassFromCaller: unused var may be removed

Reviewed-by: dholmes, alanb, liach, fandreuzzi

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

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

From lancea at openjdk.org  Wed Oct 15 14:18:05 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 15 Oct 2025 14:18:05 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v5]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 <-SRHLYYigWKWhSCOIfB51hKVNeB6JYDR2hkPKlCUQgE=.4fd148fb-f8c5-4ed9-a2f2-8e2233ae30d6@github.com>
 
 
Message-ID: 

On Wed, 15 Oct 2025 13:41:58 GMT, Eirik Bj?rsn?s  wrote:

> > Pattern::matches invokes Pattern::compile and String::matches invokes Pattern::matches so did not see the benefit when we added the methods originally in JDK 9
> 
> Yeah, it just seemed `String:matches` would be less verbose. I then noticed Roger raising related suggestions about precomplication, which is why I removed my comment from the PR since it seemed no longer relevant.

Ah that explains why I did not see your comment...

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

PR Comment: https://git.openjdk.org/jdk/pull/27693#issuecomment-3406664178

From duke at openjdk.org  Wed Oct 15 14:27:54 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 15 Oct 2025 14:27:54 GMT
Subject: RFR: 8366478: BigDecimal roots
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 
Message-ID: 

On Wed, 15 Oct 2025 10:10:43 GMT, Raffaello Giulietti  wrote:

>> @rgiulietti Here is the PR.
>
> @fabioromano1 In the comments there are claims about the relative errors. Two questions arise:
> * How were the bounds determined? There seems to be no indication in the comments provided so far.
> * How much code would be needed to attain correct rounding in all modes?

@rgiulietti 
> * How much code would be needed to attain correct rounding in all modes?

The best that can be done is to make the probability of an incorrect rounding as small as desired, but this can be computationally expensive: a probability within $10^{-k}$ means that the integer root must have $k$ more digits, and so the radicand must have $n \cdot k$ more digits.

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

PR Comment: https://git.openjdk.org/jdk/pull/27148#issuecomment-3406716684

From syan at openjdk.org  Wed Oct 15 14:28:20 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 15 Oct 2025 14:28:20 GMT
Subject: RFR: 8343340: Swapping checking do not work for MetricsMemoryTester
 failcount
Message-ID: 

Hi all,

The sub-test failcount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java requires swap memory enable on the test host. But the swap memory check introduced by JDK-8264524 do not work correctly, because it's missing jvm option '-XX:+AlwaysPreTouch', shows as below. This PR add jvm option '-XX:+AlwaysPreTouch' to make the swap memory check work correctly, and use jtreg.SkippedException instead of print waring when this test can not execute.

Change has been verified locally on linux-x64. Test fix only, no risk.


> free -h
total used free shared buff/cache available
Mem: 751Gi 513Gi 229Gi 5.0Mi 8.4Gi 234Gi
Swap: 0B 0B 0B


Without jvm option -XX:+AlwaysPreTouch, the 'java -Xms128m -Xmx128m -version' can start successfully:

> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -Xms128m -Xmx128m -version
openjdk version "26" 2026-03-17
OpenJDK Runtime Environment HJDK-0 (build 26+-42b2999c)
OpenJDK 64-Bit Server VM HJDK-0 (build 26+-42b2999c, mixed mode, sharing)


With jvm option -XX:+AlwaysPreTouch, the 'java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version' can not start and killed by docker(return code is 137):

> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version ; echo $?
137

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

Commit messages:
 - Fix import bug
 - 8343340: Swapping checking do not work for MetricsMemoryTester failcount

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

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

From matsaave at openjdk.org  Wed Oct 15 14:37:55 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 15 Oct 2025 14:37:55 GMT
Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed
 [v2]
In-Reply-To: 
References: 
 <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com>
 
 
Message-ID: 

On Fri, 5 Sep 2025 19:44:34 GMT, Dean Long  wrote:

>> Do we need a test case emulating the scenario described by JVMS, to ensure the particular scenario once covered by ends_in_athrow is still covered?
>
>> Do we need a test case emulating the scenario described by JVMS, to ensure the particular scenario once covered by ends_in_athrow is still covered?
> 
> I think Oracle has enough test coverage in closed tests, but it wouldn't hurt to have more open tests.  All I could find in a quick search was open/test/hotspot/jtreg/runtime/handlerInTry.

Thanks for the reviews @dean-long and @liach!

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

PR Comment: https://git.openjdk.org/jdk/pull/27107#issuecomment-3406766050

From matsaave at openjdk.org  Wed Oct 15 14:37:56 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 15 Oct 2025 14:37:56 GMT
Subject: Integrated: 8364660: ClassVerifier::ends_in_athrow() should be removed
In-Reply-To: 
References: 
Message-ID: 

On Thu, 4 Sep 2025 18:02:29 GMT, Matias Saavedra Silva  wrote:

> The logic located in `ClassVerifier::ends_in_athrow()` is no longer required by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should be handled by the stack map table and its rules for `uninitializedThis`. Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can be removed. Verified with tier1-5 tests.

This pull request has now been integrated.

Changeset: 1bd814c3
Author:    Matias Saavedra Silva 
URL:       https://git.openjdk.org/jdk/commit/1bd814c3b24eb7ef5633ee34bb418e0981ca1708
Stats:     251 lines in 3 files changed: 0 ins; 250 del; 1 mod

8364660: ClassVerifier::ends_in_athrow() should be removed

Reviewed-by: liach, dlong

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

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

From syan at openjdk.org  Wed Oct 15 14:28:21 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 15 Oct 2025 14:28:21 GMT
Subject: RFR: 8343340: Swapping checking do not work for
 MetricsMemoryTester failcount
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Oct 2025 14:18:41 GMT, SendaoYan  wrote:

> Hi all,
> 
> The sub-test failcount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java requires swap memory enable on the test host. But the swap memory check introduced by JDK-8264524 do not work correctly, because it's missing jvm option '-XX:+AlwaysPreTouch', shows as below. This PR add jvm option '-XX:+AlwaysPreTouch' to make the swap memory check work correctly, and use jtreg.SkippedException instead of print waring when this test can not execute.
> 
> Change has been verified locally on linux-x64. Test fix only, no risk.
> 
> 
>> free -h
> total used free shared buff/cache available
> Mem: 751Gi 513Gi 229Gi 5.0Mi 8.4Gi 234Gi
> Swap: 0B 0B 0B
> 
> 
> Without jvm option -XX:+AlwaysPreTouch, the 'java -Xms128m -Xmx128m -version' can start successfully:
> 
>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -Xms128m -Xmx128m -version
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment HJDK-0 (build 26+-42b2999c)
> OpenJDK 64-Bit Server VM HJDK-0 (build 26+-42b2999c, mixed mode, sharing)
> 
> 
> With jvm option -XX:+AlwaysPreTouch, the 'java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version' can not start and killed by docker(return code is 137):
> 
>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version ; echo $?
> 137

@jerboaa @DamonFool Can you review this test bug fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/27823#issuecomment-3406685435

From rgiulietti at openjdk.org  Wed Oct 15 15:20:42 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 15 Oct 2025 15:20:42 GMT
Subject: RFR: 8366478: BigDecimal roots
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 
 
Message-ID: 

On Wed, 15 Oct 2025 14:24:51 GMT, fabioromano1  wrote:

>> @fabioromano1 In the comments there are claims about the relative errors. Two questions arise:
>> * How were the bounds determined? There seems to be no indication in the comments provided so far.
>> * How much code would be needed to attain correct rounding in all modes?
>
> @rgiulietti 
>> * How much code would be needed to attain correct rounding in all modes?
> 
> The best that can be done is to make the probability of an incorrect rounding as small as desired, but this can be computationally expensive: a probability within $10^{-k}$ means that the integer root must have $k$ more digits, and so the radicand must have $n \cdot k$ more digits.

@fabioromano1 I think it is OK to have more efficient code even if the result is not correctly rounded.
Please add some code comment about your error analysis.

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

PR Comment: https://git.openjdk.org/jdk/pull/27148#issuecomment-3406979761

From rriggs at openjdk.org  Wed Oct 15 15:38:18 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 15 Oct 2025 15:38:18 GMT
Subject: RFR: 8368856: Add a method that performs saturating addition of a
 Duration to an Instant [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 13 Oct 2025 21:12:40 GMT, Pavel Rappo  wrote:

>> We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR.
>> 
>> I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`.
>> 
>> My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`.
>> 
>> Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`.
>> 
>> [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html
>
> Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Simplify impl
>  - Clarify spec
>  - Revert "Add Instant.minusSaturating(Duration)"
>    
>    This reverts commit 35537856f1759c7abbe2b5c5bbb267a90612f729.
>  - Add test for null

The single, plusSaturating looks ok.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27549#pullrequestreview-3341063768

From rriggs at openjdk.org  Wed Oct 15 15:38:19 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 15 Oct 2025 15:38:19 GMT
Subject: RFR: 8368856: Add a method that performs saturating addition of a
 Duration to an Instant [v7]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
Message-ID: <_RvCOz4o0wjyoB5H_Cr9IDEyu1IBep6XjoGvUzDHKhU=.b1bc0af9-1f82-4a54-a388-ce775e9dff32@github.com>

On Thu, 9 Oct 2025 19:34:58 GMT, Pavel Rappo  wrote:

>> As specified and implemented, `Duration.plus(long amount, TemporalUnit)` does not make an exception for amount == 0.  For any other value of month or years, the value is an estimate and the exception is thrown.
>> It might be useful to consider a change (as a separate enhancement)
>
>> As specified and implemented, `Duration.plus(long amount, TemporalUnit)` does not make an exception for amount == 0. For any other value of month or years, the value is an estimate and the exception is thrown. It might be useful to consider a change (as a separate enhancement)
> 
> I'm not sure that I completely understand what you are saying. Are you saying that a zero of any unit is still zero and, if added, could result in the initial instant rather than throw an exception if the unit is "incompatible" with `Instant`?
> 
> If so, then it reminds me of the following problem: should an unmodifiable set allow to delete an element which it does not contain? Different APIs decide differently. For example, this throws an exception:
> 
>     Set.of().remove(1)
> 
> Whereas this doesn't:
> 
>     Collections.emptySet().remove(1)
> 
> I don't know java.time deeply enough to lean one way or the other. But my gut feeling tells me that unconditional exception is easier to reason about and is more reliable.

It was a suggestion for a different issue/PR. 
It could allow a Period that has months == 0 and years = 0 but a days != 0 to be added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2433050354

From bpb at openjdk.org  Wed Oct 15 15:42:34 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 15 Oct 2025 15:42:34 GMT
Subject: RFR: 8191963: Path.equals() and File.equals() return true for two
 different files on Windows [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 20:55:33 GMT, Brian Burkhalter  wrote:

>> Replace logic in `java.io.WinNTFileSystems.compare(File,File)` with that from `sun.nio.fs.WindowsPath.compareTo(Path)`.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8191963: Make legacy behavior be the default
>  - Merge
>  - 8191963: Add system property to enable legacy behavior
>  - Merge
>  - 8191963: Path.equals() and File.equals() return true for two different files on Windows

If consensus is reached on this PR, I will proceed to the CSR and then the RN.

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

PR Comment: https://git.openjdk.org/jdk/pull/25788#issuecomment-3407088500

From duke at openjdk.org  Wed Oct 15 15:56:46 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 15 Oct 2025 15:56:46 GMT
Subject: RFR: 8366478: BigDecimal roots [v4]
In-Reply-To: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
Message-ID: 

> An implementation of `BigDecimal.nthRoot(int, MathContext)`.

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

  Comment for error analysis

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27148/files
  - new: https://git.openjdk.org/jdk/pull/27148/files/8f713857..07e0cce4

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

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

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

From asemenyuk at openjdk.org  Wed Oct 15 15:57:31 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 15 Oct 2025 15:57:31 GMT
Subject: RFR: 8356575: Test order in which jpackage fills app image
Message-ID: 

- Test order in which jpackage fills app image
- Fix an issue with jpackage that it would fail to overwrite existing files in the app image. Uncovered by the test.

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

Commit messages:
 - 8356575: Test order in which jpackage fills app image

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

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

From prappo at openjdk.org  Wed Oct 15 16:45:47 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 15 Oct 2025 16:45:47 GMT
Subject: RFR: 8368856: Add a method that performs saturating addition of a
 Duration to an Instant [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 13 Oct 2025 21:12:40 GMT, Pavel Rappo  wrote:

>> We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR.
>> 
>> I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`.
>> 
>> My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`.
>> 
>> Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`.
>> 
>> [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html
>
> Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Simplify impl
>  - Clarify spec
>  - Revert "Add Instant.minusSaturating(Duration)"
>    
>    This reverts commit 35537856f1759c7abbe2b5c5bbb267a90612f729.
>  - Add test for null

> /reviewers 2 reviewer

Don't worry, it had already been like that for some time :-) https://github.com/openjdk/jdk/pull/27549#issuecomment-3374476578

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

PR Comment: https://git.openjdk.org/jdk/pull/27549#issuecomment-3407377180

From rrich at openjdk.org  Wed Oct 15 17:06:10 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 15 Oct 2025 17:06:10 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 20:23:33 GMT, Patricio Chilano Mateo  wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into JDK-8369238
>  - RISC-V support
>  - Fix whitespaces
>  - v1

Great enhancement indeed @pchilano! The ppc part of it is almost finished. Unfortunately I'm stuck with a problem in verification code already in initial testing. Please see my comment on `verify_frame_kind`.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1751:

> 1749:                   RegisterMap::ProcessFrames::skip,
> 1750:                   RegisterMap::WalkContinuation::skip);
> 1751:       frame fr = top.sender(®_map);

I think there's a problem here. I get an assertion on ppc if `top` is a heap frame (calling from `log_preempt_after_freeze`) because in `frame::sender_raw()` we don't take the path we normally would for a frame on heap. Instead `sender_for_compiled_frame()` is called which uses a constructor that asserts alignment of `sp` (see [here](https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L81-L86)). The assertion fails because `_on_heap` is false but should be `true`.

I think in `sender_raw` `map->in_cont()` should return true if this frame is on heap.

It's not quite easy to fix though since `top` can also be on stack.

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

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3341440114
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2433336330

From naoto at openjdk.org  Wed Oct 15 17:30:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Oct 2025 17:30:53 GMT
Subject: RFR: 8369590: LocaleEnhanceTest has incorrectly passing test case
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <8UUWtXMN_CGEU_bQKvMXONleEgOgipFjFg9nKDb8ozM=.a6bfa378-8794-49e0-b61c-64da61897bed@github.com>

On Tue, 14 Oct 2025 21:11:39 GMT, Justin Lu  wrote:

>> This PR corrects _test/jdk/java/util/Locale/LocaleEnhanceTest.java_, which has two test cases under `testBuilderSetLanguageTag()` which accidentally pass. One checks that Locale.setLanguageTag(String) throws ILE for duplicate extensions and the other for duplicate U-extension keys. The test cases are updated to actually test the provided code. When the test cases are fixed, they now fail.
>> 
>> Fixing the behavior to match the expectation of those test cases is consistent with the specification.
>> 
>> From `Locale.forLanguageTag(String)`,
>> 
>>> 
>>>      * 
    If the specified language tag contains any ill-formed subtags,
>>>      * the first such subtag and all following subtags are ignored.  Compare
>>>      * to {@link Locale.Builder#setLanguageTag(String)} which throws an exception
>>>      * in this case.
>> 
>> and the RFC specification
>> 
>>> Each singleton subtag MUST appear at most one time in each tag
>>>        (other than as a private use subtag).  That is, singleton subtags
>>>        MUST NOT be repeated.  For example, the tag "en-a-bbb-a-ccc" is
>>>        invalid because the subtag 'a' appears twice.
>> 
>> Since duplicate extensions (and Unicode keys/attributes) are invalid, throwing `IllformedLocaleException` in (the strict) `Locale.Builder` and ignoring in (the lenient) `Locale.forLanguageTag` for such tags would be appropriate. This PR updates the implementation as such.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align setExtension(char, String) + spec updates

LGTM. Glad to see those test clean-ups, especiallly getting rid of the proprietary test framework

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27775#pullrequestreview-3341556118

From wxiao at openjdk.org  Wed Oct 15 17:34:55 2025
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 15 Oct 2025 17:34:55 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v5]
In-Reply-To: 
References: 
Message-ID: 

> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
> 
> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
> 
> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
> 
> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.

Weibing Xiao 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 26 additional commits since the last revision:

 - update the code
 - Merge branch 'master' of github.com:openjdk/jdk into JDK-8362268
 - Merge branch 'master' into JDK-8362268
 - Merge branch 'master' of github.com:weibxiao/jdk
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'master' of github.com:openjdk/jdk
 - Merge branch 'openjdk:master' into master
 - Merge branch 'master' of github.com:openjdk/jdk
 - Merge branch 'master' of github.com:openjdk/jdk
 - ... and 16 more: https://git.openjdk.org/jdk/compare/b031257e...4dd20668

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26566/files
  - new: https://git.openjdk.org/jdk/pull/26566/files/77b418d4..4dd20668

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

  Stats: 271102 lines in 4269 files changed: 197659 ins; 48393 del; 25050 mod
  Patch: https://git.openjdk.org/jdk/pull/26566.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26566/head:pull/26566

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

From duke at openjdk.org  Wed Oct 15 17:46:56 2025
From: duke at openjdk.org (Josiah Noel)
Date: Wed, 15 Oct 2025 17:46:56 GMT
Subject: RFR: 7105350: HttpExchange's attributes are the same as
 HttpContext's attributes [v10]
In-Reply-To: 
References: 
Message-ID: 

> Now ExchangeImpl will default to having a separate attribute map for the request duration.

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

  Update module-info.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27652/files
  - new: https://git.openjdk.org/jdk/pull/27652/files/1164702a..061e504b

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

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

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

From darcy at openjdk.org  Wed Oct 15 17:49:07 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 15 Oct 2025 17:49:07 GMT
Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 06:05:30 GMT, Alan Bateman  wrote:

> I think it's always okay to remove oneself but I see some of the `@author` tags list others (Stuart, Kumar, even madbot). I didn't check the history but I will guess that you created these tests, others added their name when they modified the test at some point later, is that right?

Yeah, I wasn't sure of the best way forward for the files will shared authorship and was going to check with Stuart, etc.

A few of the shared test files I was the primary author. For some of the old java.math files, madbot was the initial author and I updated the tests later.

I can restored the listed author tags for people other than myself if we're not comfortable at this point in just removing author tags.

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

PR Comment: https://git.openjdk.org/jdk/pull/27813#issuecomment-3407596375

From darcy at openjdk.org  Wed Oct 15 17:49:05 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 15 Oct 2025 17:49:05 GMT
Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2]
In-Reply-To: 
References: 
Message-ID: 

> Updating tests I've wrote to conform to current conventions of not having author tags.

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

  Fix formatting typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27813/files
  - new: https://git.openjdk.org/jdk/pull/27813/files/10aef0dc..4f5360da

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

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

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

From valeriep at openjdk.org  Wed Oct 15 17:58:38 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 17:58:38 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 05:51:40 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add remaining files to be staged

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43:

> 41:  * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688
> 42:  */
> 43: public final class AES_Crypt extends SymmetricCipher {

This internal class does not need to be public? I'd assume it's only used within the same package?

test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 53:

> 51:     public void setup() throws Exception {
> 52:         SecretKeySpec keySpec = new SecretKeySpec(new byte[]{-80, -103, -1, 68, -29, -94, 61, -52, 93, -59, -128, 105, 110, 88, 44, 105}, "AES");
> 53:         IvParameterSpec iv = new IvParameterSpec(new byte[]{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00});

Is the all-0s IV intentional?

test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 82:

> 80:     public byte[] testUseAesIntrinsics() throws Exception {
> 81:         return cipher.doFinal(ct);
> 82:     }

These 3 methods look same to me except for the method names?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433490853
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433487319
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433483607

From naoto at openjdk.org  Wed Oct 15 18:09:11 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Oct 2025 18:09:11 GMT
Subject: RFR: 8368856: Add a method that performs saturating addition of a
 Duration to an Instant [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 13 Oct 2025 21:12:40 GMT, Pavel Rappo  wrote:

>> We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR.
>> 
>> I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`.
>> 
>> My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`.
>> 
>> Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`.
>> 
>> [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html
>
> Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Simplify impl
>  - Clarify spec
>  - Revert "Add Instant.minusSaturating(Duration)"
>    
>    This reverts commit 35537856f1759c7abbe2b5c5bbb267a90612f729.
>  - Add test for null

src/java.base/share/classes/java/time/Instant.java line 797:

> 795:      * If the result is "earlier" than {@link Instant#MIN}, this method returns
> 796:      * {@code MIN}. If the result is "later" than {@link Instant#MAX}, it
> 797:      * returns {@code MAX}. Otherwise it returns {@code this.}{@link #plus plus(duration)}.

Since there are multiple overloaded methods for `plus`, It'd be safer to specify argument to the method reference `#plus`. (It seems to work as `plus(TemporalAmount)` is the first candidate)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2433512742

From rgiulietti at openjdk.org  Wed Oct 15 18:09:33 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 15 Oct 2025 18:09:33 GMT
Subject: RFR: 8341914: The j.u.Formatter doc for TemporalAccessor should be
 enhanced
Message-ID: 

Doc only change.

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

Commit messages:
 - 8341914: The j.u.Formatter doc for TemporalAccessor should be enhanced

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

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

From rgiulietti at openjdk.org  Wed Oct 15 18:20:36 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 15 Oct 2025 18:20:36 GMT
Subject: RFR: 8341914: The j.u.Formatter doc for TemporalAccessor should be
 enhanced [v2]
In-Reply-To: 
References: 
Message-ID: 

> Doc only change.

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

  Add the 'c' conversion as well.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27830/files
  - new: https://git.openjdk.org/jdk/pull/27830/files/b3c6a01a..c51f19f6

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

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

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

From asemenyuk at openjdk.org  Wed Oct 15 18:24:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 15 Oct 2025 18:24:02 GMT
Subject: RFR: 8356575: Test order in which jpackage fills app image [v2]
In-Reply-To: 
References: 
Message-ID: 

> - Test order in which jpackage fills app image
> - Fix an issue with jpackage that it would fail to overwrite existing files in the app image. Uncovered by the test.

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

  Refactor. Simplify and make it pass on Windows and Linux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27826/files
  - new: https://git.openjdk.org/jdk/pull/27826/files/e0fd1823..15c5d6fa

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

  Stats: 111 lines in 1 file changed: 51 ins; 22 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/27826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27826/head:pull/27826

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

From rriggs at openjdk.org  Wed Oct 15 18:28:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 15 Oct 2025 18:28:38 GMT
Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2]
In-Reply-To: 
References: 
 
Message-ID: <0YnCZqVcEN1uNGmfF-ffhV-8KQBG7_24JAlWwoblRw4=.500106dc-aac8-46d3-9540-47b7551bdc2a@github.com>

On Wed, 15 Oct 2025 17:49:05 GMT, Joe Darcy  wrote:

>> Updating tests I've wrote to conform to current conventions of not having author tags.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting typo

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27813#pullrequestreview-3341746324

From iris at openjdk.org  Wed Oct 15 18:34:48 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 15 Oct 2025 18:34:48 GMT
Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 17:49:05 GMT, Joe Darcy  wrote:

>> Updating tests I've wrote to conform to current conventions of not having author tags.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting typo

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27813#pullrequestreview-3341762902

From lancea at openjdk.org  Wed Oct 15 18:34:48 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 15 Oct 2025 18:34:48 GMT
Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 17:49:05 GMT, Joe Darcy  wrote:

>> Updating tests I've wrote to conform to current conventions of not having author tags.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting typo

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27813#pullrequestreview-3341768330

From rriggs at openjdk.org  Wed Oct 15 18:35:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 15 Oct 2025 18:35:58 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v15]
In-Reply-To: <8XswExrj9izeP9hR_qXXu2UKSuecQfLskrrJ4D7fcLg=.e6dfe129-f413-484d-a2aa-993c223b4a9c@github.com>
References: 
 
 <8XswExrj9izeP9hR_qXXu2UKSuecQfLskrrJ4D7fcLg=.e6dfe129-f413-484d-a2aa-993c223b4a9c@github.com>
Message-ID: <-tmbhxV8xtEnUq4ylyaC1Bx2OUPGkLvCmmrMV5n2zRY=.1de5ebb2-6456-4d38-96b7-b6f0b0668a77@github.com>

On Wed, 8 Oct 2025 05:26:37 GMT, Alan Bateman  wrote:

>> Roger Riggs 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 22 additional commits since the last revision:
>> 
>>  - The ProcessCloseTest is modified to be able to test the logic
>>    around close() waiting for the process to exit and the specified
>>    behavior of interrupting the waitFor.
>>  - Close is modified to wait for the process to terminate before returning.
>>    Please review the revised javadoc.
>>    As suggested in review comments, waiting for the process to terminate
>>    allows a more orderly cleanup by the application.
>>    The streams are closed and close uses `waitFor()` with an unlimited timeout
>>    for the process to terminate.
>>    While waiting the thread can be `interrupted` to exit the `waitFor`.
>>    If/when `waitFor` is interrupted, the process is destroyedForcibly on
>>    all platforms. When close() returns, the thread interrupt will pending
>>    and can be handled by the caller.
>>    If a watchdog timeout is desired on close(), a separate thread
>>    can schedule an interrupt at a suitable time after close is called.
>>  - Review comment improvements to make expected behavior clearer.
>>  - Merge branch 'master' into 8364361-process-autocloseable
>>  - Clarify the use of waitFor after close() or T-W-R exit.
>>  - Additional review feedback.
>>    Updated to emphasize reading the data from the streams and calling waitFor
>>    to allow for normal termination.
>>  - Merge branch 'master' into 8364361-process-autocloseable
>>  - Address review comments for code and javadoc in Process, the test and the example.
>>    Reinforced that calling waitFor should occur before calling close to wait for termination and get the exitStatus.
>>    Corrected the error message check for invalid handles on Windows.
>>    Update test to allow normal completion when exceptions may be expected.
>>    Correct the expected message on Windows for an invalid handle exception.
>>  - Update close() to use "terminate" consistently.
>>  - Remove volatile from "closed" field; updates are guarded by synchronized.
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/e422ebfa...6f8f7327
>
> src/java.base/share/classes/java/lang/Process.java line 235:
> 
>> 233:                 destroyForcibly();
>> 234:                 // Re-assert the interrupt
>> 235:                 Thread.currentThread().interrupt();
> 
> I think this is still problematic as code after the t-w-r can't be guaranteed that the child has terminated. So I think it needs a loop that ends when waitFor completes without an exception (destroyForcibly would only be called on the first interrupt of course).

@AlanBateman can you comment on the possibility of looping indefinitely and not be interruptible if the OS process cannot be destroyed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2433581550

From wxiao at openjdk.org  Wed Oct 15 18:40:39 2025
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 15 Oct 2025 18:40:39 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v5]
In-Reply-To: 
References: 
 
Message-ID: <5jvW2mPcnGEjhnL3fn2_xOqtzZzX_SD3UEYAZlSlIKw=.b34ffb32-9ee3-412b-8256-b57bccf73716@github.com>

On Wed, 15 Oct 2025 17:34:55 GMT, Weibing Xiao  wrote:

>> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
>> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
>> 
>> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
>> 
>> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
>> 
>> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.
>
> Weibing Xiao 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 26 additional commits since the last revision:
> 
>  - update the code
>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8362268
>  - Merge branch 'master' into JDK-8362268
>  - Merge branch 'master' of github.com:weibxiao/jdk
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'master' of github.com:openjdk/jdk
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'master' of github.com:openjdk/jdk
>  - Merge branch 'master' of github.com:openjdk/jdk
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/340509e1...4dd20668

Updated the code to address the review comments.
Add some of my extra analysis as below,

In JDK, at the line https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/java.naming/share/classes/com/sun/jndi/ldap/sasl/SaslInputStream.java#L127, the buffer length was larger than default value 65536, it would trigger the exception. At the line of 451 of Connnection.java, the exception was caught.  Connection::cleanup got called. At line https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L657, the method of closeOpenedSocket will close the output stream. For Sasl implementation, this output stream is SaslOutputStream.java.  So that SaslOutputStream::close is used to close the stream. Inside this method, GssKrb5Client::dispose was called, its implementation is base class GssKrb5Base::dispose, which is disposing the GSS Context and set it to be null. At mean time, Sasl output stream was till in the middle to handle the buffer by using GssKrb5Base::wrap. Since Gss Con
 text already set to be null, it caused the NPE at line of https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140.

JNDI connection was created inside the constructor o LdapClient.java. When Connection object was created, the output stream and input stream was created also. For Sasl implementation, it was SaslnputStream and SaslOutputStream. Both resources were created inside LdapClient when Connection object was created. It seems ok to close them in LdapClient.java.  Consider locking the connection, the change was called inside LdapClient::close, which was using ReentrantLock to control the access. Hope to get more info to refine the code here.

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

PR Comment: https://git.openjdk.org/jdk/pull/26566#issuecomment-3407777489

From rriggs at openjdk.org  Wed Oct 15 18:47:31 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 15 Oct 2025 18:47:31 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v3]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
 
 
Message-ID: <3w3hwUcfvbApFWI9zRajbDlD1Vhc2x0APkrEZkuA0b8=.0a8555af-0fb4-4d5c-b816-f6c8a83b4fc7@github.com>

On Mon, 13 Oct 2025 17:12:00 GMT, Lance Andersen  wrote:

>> src/java.sql/share/classes/java/sql/Connection.java line 1816:
>> 
>>> 1814:      * @param alwaysQuote indicates if a simple SQL identifier should be
>>> 1815:      * returned as a quoted identifier
>>> 1816:      * @return A simple SQL identifier or a delimited identifier
>> 
>> Is there a difference between a "quoted identifier" and a "delimited identifier"?
>> The terminology should be consistent (with the jdbc spec).
>
> A quoted identifier is a form of a delimited identifier and are often interchangeable(depending on the database).  The intent here was to be specific as some databases did not support  quotes

It would be in improvement to consistently use "delimited" identifier within the javadoc of this method.
See the "alwaysQuote" @param tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2433607462

From valeriep at openjdk.org  Wed Oct 15 18:48:29 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 18:48:29 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: 
References: 
 
Message-ID: <-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com>

On Wed, 15 Oct 2025 05:51:40 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add remaining files to be staged

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 55:

> 53: 
> 54:     private static final int AES_256_ROUNDS = 14;
> 55:     private static final int AES_256_NKEYS = 32;

The `AES_XXX_NKEYS` constants (valued 16, 24, 32) are also defined in `AESConstants` class, maybe we can just refer to that class instead of duplicate the definition here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433608974

From valeriep at openjdk.org  Wed Oct 15 18:53:55 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 18:53:55 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com>
References: 
 
 <-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com>
Message-ID: <8Hb0rpkClUOY9-wId7h9oVsyZx6Q1BfCKKEshQ8u6PA=.c3a9339b-0567-47bb-a2f2-92836e1af493@github.com>

On Wed, 15 Oct 2025 18:45:24 GMT, Valerie Peng  wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add remaining files to be staged
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 55:
> 
>> 53: 
>> 54:     private static final int AES_256_ROUNDS = 14;
>> 55:     private static final int AES_256_NKEYS = 32;
> 
> The `AES_XXX_NKEYS` constants (valued 16, 24, 32) are also defined in `AESConstants` class, maybe we can just refer to that class instead of duplicate the definition here?

Or, merge the values defined in `AESConstants` into this class. Either way is fine with me as long as no duplicated values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433622686

From rriggs at openjdk.org  Wed Oct 15 19:00:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 15 Oct 2025 19:00:59 GMT
Subject: RFR: 8341914: The j.u.Formatter doc for TemporalAccessor should be
 enhanced [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 18:20:36 GMT, Raffaello Giulietti  wrote:

>> Doc only change.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the 'c' conversion as well.

The PR comment should be more complete than just "doc only change". It should describe the scope and intent.
It makes the emails and PR easier to grok without having to read the code.

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

PR Comment: https://git.openjdk.org/jdk/pull/27830#issuecomment-3407837104

From rriggs at openjdk.org  Wed Oct 15 19:15:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 15 Oct 2025 19:15:52 GMT
Subject: RFR: 8341914: The j.u.Formatter doc for TemporalAccessor should be
 enhanced [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 18:20:36 GMT, Raffaello Giulietti  wrote:

>> Doc only change.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the 'c' conversion as well.

A bit more background would be useful here.
The mention of TemporalAccessor in the context of timezone formatting characters seems out of place or too specific.
It would be more appropriate to highlight that data dependent requirement in the section on Date/Time formatting.

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

PR Comment: https://git.openjdk.org/jdk/pull/27830#issuecomment-3407905758

From prappo at openjdk.org  Wed Oct 15 19:33:13 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 15 Oct 2025 19:33:13 GMT
Subject: RFR: 8368856: Add a method that performs saturating addition of a
 Duration to an Instant [v9]
In-Reply-To: 
References: 
Message-ID: 

> We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR.
> 
> I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`.
> 
> My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`.
> 
> Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`.
> 
> [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html

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

  Address feedback and fine tune the spec
  
  Good catch, Naoto! Double checked by make docs-jdk-api.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27549/files
  - new: https://git.openjdk.org/jdk/pull/27549/files/3bc1e0e2..3b964ce8

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

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

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

From pchilanomate at openjdk.org  Wed Oct 15 19:35:50 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 15 Oct 2025 19:35:50 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 15 Oct 2025 16:54:42 GMT, Richard Reingruber  wrote:

>> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge branch 'master' into JDK-8369238
>>  - RISC-V support
>>  - Fix whitespaces
>>  - v1
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1751:
> 
>> 1749:                   RegisterMap::ProcessFrames::skip,
>> 1750:                   RegisterMap::WalkContinuation::skip);
>> 1751:       frame fr = top.sender(®_map);
> 
> I think there's a problem here. I get an assertion on ppc if `top` is a heap frame (calling from `log_preempt_after_freeze`) because in `frame::sender_raw()` we don't take the path we normally would for a frame on heap. Instead `sender_for_compiled_frame()` is called which uses a constructor that asserts alignment of `sp` (see [here](https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L81-L86)). The assertion fails because `_on_heap` is false but should be `true`.
> 
> I think in `sender_raw` `map->in_cont()` should return true if this frame is on heap.
> 
> It's not quite easy to fix though since `top` can also be on stack.

Right, it should be walked as a heap frame. Could you verify if this patch fixes the issue?


diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
index 86c56fe583f..fb1f66c60f4 100644
--- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp
+++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
@@ -196,7 +196,7 @@ static bool do_verify_after_thaw(JavaThread* thread, stackChunkOop chunk, output
 static void log_frames(JavaThread* thread, bool dolog = true);
 static void log_frames_after_thaw(JavaThread* thread, ContinuationWrapper& cont, intptr_t* sp);
 static void print_frame_layout(const frame& f, bool callee_complete, outputStream* st = tty);
-static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr);
+static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr, stackChunkOop chunk = nullptr);

 #define assert_pfl(p, ...) \
 do {                                           \
@@ -1723,7 +1723,7 @@ bool FreezeBase::check_valid_fast_path() {
   return true;
 }

-static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr) {
+static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr, stackChunkOop chunk) {
   Method* m;
   const char* code_name;
   int bci;
@@ -1747,7 +1747,13 @@ static void verify_frame_kind(const frame& top, Continuation::preempt_kind preem
       RegisterMap reg_map(current,
                   RegisterMap::UpdateMap::skip,
                   RegisterMap::ProcessFrames::skip,
-                  RegisterMap::WalkContinuation::skip);
+                  RegisterMap::WalkContinuation::include);
+      if (top.is_heap_frame()) {
+        assert(chunk != nullptr, "");
+        reg_map.set_stack_chunk(chunk);
+        top = chunk->relativize(top);
+        top.set_frame_index(0);
+      }
       frame fr = top.sender(®_map);
       vframe*  vf  = vframe::new_vframe(&fr, ®_map, current);
       compiledVFrame* cvf = compiledVFrame::cast(vf);
@@ -1803,7 +1809,7 @@ static void log_preempt_after_freeze(ContinuationWrapper& cont) {
   Method* m = nullptr;
   const char* code_name = nullptr;
   int bci = InvalidFrameStateBci;
-  verify_frame_kind(top_frame, pk, &m, &code_name, &bci);
+  verify_frame_kind(top_frame, pk, &m, &code_name, &bci, cont.tail());
   assert(m != nullptr && code_name != nullptr && bci != InvalidFrameStateBci, "should be set");

   ResourceMark rm(current);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2433721003

From naoto at openjdk.org  Wed Oct 15 19:41:28 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Oct 2025 19:41:28 GMT
Subject: RFR: 8341914: The j.u.Formatter doc for TemporalAccessor should be
 enhanced [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 18:20:36 GMT, Raffaello Giulietti  wrote:

>> Doc only change.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the 'c' conversion as well.

Would this only apply to time zone? What if `LocalDate` is passed as a `TemporalAccessor` and the conversion requests hour or minute? Could this be more generic?

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

PR Comment: https://git.openjdk.org/jdk/pull/27830#issuecomment-3407984637

From asemenyuk at openjdk.org  Wed Oct 15 19:55:25 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 15 Oct 2025 19:55:25 GMT
Subject: RFR: 8356575: Test order in which jpackage fills app image [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 18:24:02 GMT, Alexey Semenyuk  wrote:

>> - Test order in which jpackage fills app image
>> - Fix an issue with jpackage that it would fail to overwrite existing files in the app image. Uncovered by the test.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor. Simplify and make it pass on Windows and Linux

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/27826#issuecomment-3408026553

From lancea at openjdk.org  Wed Oct 15 20:04:45 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 15 Oct 2025 20:04:45 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v6]
In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
Message-ID: 

> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
> 
> - Deprecate SQLPermission for removal
> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
> 
> Tiers 1-3 have been run

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

  Move fields from package-private to private

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27693/files
  - new: https://git.openjdk.org/jdk/pull/27693/files/85db0021..398b0f42

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

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

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

From duke at openjdk.org  Wed Oct 15 20:17:25 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Wed, 15 Oct 2025 20:17:25 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v6]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
Message-ID: 

On Wed, 15 Oct 2025 20:04:45 GMT, Lance Andersen  wrote:

>> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
>> 
>> - Deprecate SQLPermission for removal
>> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
>> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
>> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
>> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
>> 
>> Tiers 1-3 have been run
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move fields from package-private to private

src/java.sql/share/classes/java/sql/Statement.java line 1408:

> 1406:      */
> 1407:      default String enquoteLiteral(String val) throws SQLException {
> 1408:          return SQLUtils.enquoteLiteral(val);

Suggestion: `return getConnection().enquoteLiteral(val);` to allow JDBC driver implementors have a single site to override behavior

src/java.sql/share/classes/java/sql/Statement.java line 1627:

> 1625:     */
> 1626:     default String enquoteNCharLiteral(String val) throws SQLException {
> 1627:         return SQLUtils.enquoteNCharLiteral(val);

Suggestion: `return getConnection().enquoteNCharLiteral(val);` to allow JDBC driver implementors have a single site to override behavior

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2433814167
PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2433815844

From naoto at openjdk.org  Wed Oct 15 20:18:33 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Oct 2025 20:18:33 GMT
Subject: RFR: 8368856: Add a method that performs saturating addition of a
 Duration to an Instant [v9]
In-Reply-To: 
References: 
 
Message-ID: <49qRYBiRaVp2pOOaRXKoP1-_SAPhaW-9v8auS-abS94=.27131092-30ea-4963-9899-d74fd428988e@github.com>

On Wed, 15 Oct 2025 19:33:13 GMT, Pavel Rappo  wrote:

>> We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR.
>> 
>> I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`.
>> 
>> My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`.
>> 
>> Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`.
>> 
>> [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback and fine tune the spec
>   
>   Good catch, Naoto! Double checked by make docs-jdk-api.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27549#pullrequestreview-3342086727

From lancea at openjdk.org  Wed Oct 15 20:23:24 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 15 Oct 2025 20:23:24 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v6]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
 
Message-ID: 

On Wed, 15 Oct 2025 20:14:47 GMT, Johannes D?bler  wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move fields from package-private to private
>
> src/java.sql/share/classes/java/sql/Statement.java line 1627:
> 
>> 1625:     */
>> 1626:     default String enquoteNCharLiteral(String val) throws SQLException {
>> 1627:         return SQLUtils.enquoteNCharLiteral(val);
> 
> Suggestion: `return getConnection().enquoteNCharLiteral(val);` to allow JDBC driver implementors have a single site to override behavior

No plans to do that in the default implementation.  Driver vendors can/should optimize as needed based on their driver implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2433830284

From jlu at openjdk.org  Wed Oct 15 20:37:16 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 15 Oct 2025 20:37:16 GMT
Subject: RFR: 8369590: LocaleEnhanceTest has incorrectly passing test case
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR corrects _test/jdk/java/util/Locale/LocaleEnhanceTest.java_, which has two test cases under `testBuilderSetLanguageTag()` which accidentally pass. One checks that Locale.setLanguageTag(String) throws ILE for duplicate extensions and the other for duplicate U-extension keys. The test cases are updated to actually test the provided code. When the test cases are fixed, they now fail.
> 
> Fixing the behavior to match the expectation of those test cases is consistent with the specification.
> 
> From `Locale.forLanguageTag(String)`,
> 
>> 
>>      * 
    If the specified language tag contains any ill-formed subtags,
>>      * the first such subtag and all following subtags are ignored.  Compare
>>      * to {@link Locale.Builder#setLanguageTag(String)} which throws an exception
>>      * in this case.
> 
> and the RFC specification
> 
>> Each singleton subtag MUST appear at most one time in each tag
>>        (other than as a private use subtag).  That is, singleton subtags
>>        MUST NOT be repeated.  For example, the tag "en-a-bbb-a-ccc" is
>>        invalid because the subtag 'a' appears twice.
> 
> Since duplicate extensions (and Unicode keys/attributes) are invalid, throwing `IllformedLocaleException` in (the strict) `Locale.Builder` and ignoring in (the lenient) `Locale.forLanguageTag` for such tags would be appropriate. This PR updates the implementation as such.

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

  Spacing fix in LocaleEnhanceTest.java
  
  Co-authored-by: Andrey Turbanov 

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27775/files
  - new: https://git.openjdk.org/jdk/pull/27775/files/b3167f13..b0cfd59b

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

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

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

From prr at openjdk.org  Wed Oct 15 20:37:37 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 15 Oct 2025 20:37:37 GMT
Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 17:49:05 GMT, Joe Darcy  wrote:

>> Updating tests I've wrote to conform to current conventions of not having author tags.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting typo

In the client area, when updating a test, as a TOO we usually remove the author tag regardless of who it references.

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

PR Comment: https://git.openjdk.org/jdk/pull/27813#issuecomment-3408178799

From valeriep at openjdk.org  Wed Oct 15 20:48:45 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 20:48:45 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 05:51:40 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add remaining files to be staged

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 920:

> 918:             if (prevKey != null) {
> 919:                 Arrays.fill(prevKey, (byte) 0);
> 920:             }

Can be moved down to be right before `prevKey = key.clone()` call? This way, `sessionK` assignments are together and not separated by this call

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433898660

From rgiulietti at openjdk.org  Wed Oct 15 20:49:44 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 15 Oct 2025 20:49:44 GMT
Subject: RFR: 8341914: The j.u.Formatter doc for TemporalAccessor should be
 enhanced [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 18:20:36 GMT, Raffaello Giulietti  wrote:

>> Doc only change.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the 'c' conversion as well.

The `Formatter` documentation related to dates/times has 3 tables: for times, for dates, and for "common date/time compositions".

All conversion character for dates are applicable to all dates/datetimes (but not to times-only instances).

Something similar should hold for conversion characters of times/datetimes: they should be applicable to all times/datetimes (and not to date-only instances). But `z` and `Z` represent an exception, as they apply only if time zone information is available.

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

PR Comment: https://git.openjdk.org/jdk/pull/27830#issuecomment-3408216496

From weijun at openjdk.org  Wed Oct 15 20:50:59 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Oct 2025 20:50:59 GMT
Subject: Integrated: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep
In-Reply-To: 
References: 
Message-ID: 

On Wed, 10 Sep 2025 15:43:52 GMT, Weijun Wang  wrote:

> Allow password hiding even if there is no `System.console`. A manual test is included.

This pull request has now been integrated.

Changeset: a7a3a660
Author:    Weijun Wang 
URL:       https://git.openjdk.org/jdk/commit/a7a3a660e33fabc025ebe887f5605741be9ca8c3
Stats:     335 lines in 6 files changed: 287 ins; 12 del; 36 mod

8354469: Keytool exposes the password in plain text when command is piped using | grep

Reviewed-by: mullan, smarks, naoto, hchao

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

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

From prappo at openjdk.org  Wed Oct 15 20:59:16 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 15 Oct 2025 20:59:16 GMT
Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2]
In-Reply-To: 
References: 
 
Message-ID: <2BNYfDZc1RzYpFEuLNLxzz1ItvUDwUuJpGjaPwSdLKE=.db26af23-419b-4855-a035-c79c7b270ea4@github.com>

On Wed, 15 Oct 2025 17:49:05 GMT, Joe Darcy  wrote:

>> Updating tests I've wrote to conform to current conventions of not having author tags.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting typo

This is a very self-deprecating change. We should ask Dr. Deprecator what he thinks about it, especially since he's acquainted with Stuart Marks, whose authorship is also being removed.

In all seriousness, people can be touchy about changes like this. FWIW, when we made a similar change in the `jdk.javadoc` area, we carefully captured authors being removed; see https://bugs.openjdk.org/browse/JDK-8235435

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

PR Comment: https://git.openjdk.org/jdk/pull/27813#issuecomment-3408249260

From scolebourne at openjdk.org  Wed Oct 15 21:07:54 2025
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Wed, 15 Oct 2025 21:07:54 GMT
Subject: RFR: 8368856: Add a method that performs saturating addition of a
 Duration to an Instant [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 19:33:13 GMT, Pavel Rappo  wrote:

>> We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR.
>> 
>> I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`.
>> 
>> My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`.
>> 
>> Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`.
>> 
>> [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback and fine tune the spec
>   
>   Good catch, Naoto! Double checked by make docs-jdk-api.

Marked as reviewed by scolebourne (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27549#pullrequestreview-3342268793

From duke at openjdk.org  Wed Oct 15 21:28:33 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Wed, 15 Oct 2025 21:28:33 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v6]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
 
 
Message-ID: 

On Wed, 15 Oct 2025 20:20:57 GMT, Lance Andersen  wrote:

>> src/java.sql/share/classes/java/sql/Statement.java line 1627:
>> 
>>> 1625:     */
>>> 1626:     default String enquoteNCharLiteral(String val) throws SQLException {
>>> 1627:         return SQLUtils.enquoteNCharLiteral(val);
>> 
>> Suggestion: `return getConnection().enquoteNCharLiteral(val);` to allow JDBC driver implementors have a single site to override behavior
>
> No plans to do that in the default implementation.  Driver vendors can/should optimize as needed based on their driver implementation.

Hi @LanceAndersen,
don*t know what you mean with " Driver vendors can/should optimize as needed based on their driver implementation."
My idea was that in JDBC 4.5 the default methods Statement.enquoteNCharLiteral and Statement.enquoteIdentifier could call the new corresponding default methods in Connection, therefore easing life of JDBC vendor or test libraries to have a **_single_** site to override.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2434000788

From duke at openjdk.org  Wed Oct 15 21:31:23 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 21:31:23 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: <7faVZ8RHcws5sOoA1rfBrE3f7ON__bKvBCra2R3rLNU=.dfd5d4f3-7506-4d99-9ba5-ccb0b4ca0184@github.com>

On Wed, 15 Oct 2025 17:54:37 GMT, Valerie Peng  wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add remaining files to be staged
>
> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 53:
> 
>> 51:     public void setup() throws Exception {
>> 52:         SecretKeySpec keySpec = new SecretKeySpec(new byte[]{-80, -103, -1, 68, -29, -94, 61, -52, 93, -59, -128, 105, 110, 88, 44, 105}, "AES");
>> 53:         IvParameterSpec iv = new IvParameterSpec(new byte[]{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00});
> 
> Is the all-0s IV intentional?

Yes, it's in keeping with the other benchmarks (e.g., test/micro/org/openjdk/bench/javax/crypto/AES.java).

> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 82:
> 
>> 80:     public byte[] testUseAesIntrinsics() throws Exception {
>> 81:         return cipher.doFinal(ct);
>> 82:     }
> 
> These 3 methods look same to me except for the method names?

The forked arguments will test different levels of optimizations:
testBaseline: no optimizations
testUseAes: AES optimizations
testUseAesIntrinsics: AES machine instructions

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434006387
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434001817

From almatvee at openjdk.org  Wed Oct 15 22:37:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 15 Oct 2025 22:37:57 GMT
Subject: RFR: 8356575: Test order in which jpackage fills app image [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 18:24:02 GMT, Alexey Semenyuk  wrote:

>> - Test order in which jpackage fills app image
>> - Fix an issue with jpackage that it would fail to overwrite existing files in the app image. Uncovered by the test.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor. Simplify and make it pass on Windows and Linux

Looks good. I do not see test case which covers `.jpackage.xml`. Can we add one?

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

PR Review: https://git.openjdk.org/jdk/pull/27826#pullrequestreview-3342562373

From asemenyuk at openjdk.org  Wed Oct 15 23:03:41 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 15 Oct 2025 23:03:41 GMT
Subject: RFR: 8356575: Test order in which jpackage fills app image [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 15 Oct 2025 22:35:22 GMT, Alexander Matveev  wrote:

> Looks good. I do not see test case which covers `.jpackage.xml`. Can we add one?

`testAppImageFile()` test case covers ".jpackage.xml" file. It creates a custom ".jpackage.xml" in the input app content directory and verifies jpackage ignores it and writes the default ".jpackage.xml" file into the output app image:


[19:17:07.408] TRACE: Create [C:\scratch\testAppImageFile\app-content\app.jpackage.xml] text file...
[19:17:07.408] TRACE: This is not a valid XML content
[19:17:07.408] TRACE: Done
...
[19:17:07.513] TRACE: exec: Execute [c:\work_dir\windows-x64.jdk\jdk-26\bin\jpackage.exe --input testAppImageFile\input --dest testAppImageFile\output --name Foo --type app-image --main-jar hello.jar --main-class Hello --win-console --app-content testAppImageFile\app-content\app --runtime-image testAppImageFile\fake_runtime -J-Djlink.debug=true --verbose](20); inherit out+err...
...
[19:17:08.353] TRACE: assertStringListEquals(): Check jpackage didn't modify ${APP_CONTENT}=[C:\scratch\testAppImageFile\app-content\app]
[19:17:08.353] TRACE: assertStringListEquals(1, #)
[19:17:08.353] TRACE: assertStringListEquals(2, .jpackage.xml#2025-10-15T19:17:07.4085145Z)
...
[19:17:08.355] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
[19:17:08.355] TRACE: assertStringListEquals(1, testAppImageFile\output\Foo\app.jpackage.xml)
...
[19:17:08.408] TRACE: Parse [testAppImageFile\output\Foo\app.jpackage.xml] file...

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

PR Comment: https://git.openjdk.org/jdk/pull/27826#issuecomment-3408582012

From duke at openjdk.org  Wed Oct 15 23:04:10 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 23:04:10 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: 
References: 
Message-ID: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/3fc25aef..f48160cf

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

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

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

From duke at openjdk.org  Wed Oct 15 23:04:11 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 23:04:11 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 15 Oct 2025 17:55:58 GMT, Valerie Peng  wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add remaining files to be staged
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43:
> 
>> 41:  * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688
>> 42:  */
>> 43: public final class AES_Crypt extends SymmetricCipher {
> 
> This internal class does not need to be public? I'd assume it's only used within the same package?

You're right, it doesn't appear to be used externally.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 920:
> 
>> 918:             if (prevKey != null) {
>> 919:                 Arrays.fill(prevKey, (byte) 0);
>> 920:             }
> 
> Can be moved down to be right before `prevKey = key.clone()` call? This way, `sessionK` assignments are together and not separated by this call

It can be and I agree.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434164829
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434165068

From duke at openjdk.org  Wed Oct 15 23:04:13 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 23:04:13 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <8Hb0rpkClUOY9-wId7h9oVsyZx6Q1BfCKKEshQ8u6PA=.c3a9339b-0567-47bb-a2f2-92836e1af493@github.com>
References: 
 
 <-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com>
 <8Hb0rpkClUOY9-wId7h9oVsyZx6Q1BfCKKEshQ8u6PA=.c3a9339b-0567-47bb-a2f2-92836e1af493@github.com>
Message-ID: 

On Wed, 15 Oct 2025 18:51:29 GMT, Valerie Peng  wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 55:
>> 
>>> 53: 
>>> 54:     private static final int AES_256_ROUNDS = 14;
>>> 55:     private static final int AES_256_NKEYS = 32;
>> 
>> The `AES_XXX_NKEYS` constants (valued 16, 24, 32) are also defined in `AESConstants` class, maybe we can just refer to that class instead of duplicate the definition here?
>
> Or, merge the values defined in `AESConstants` into this class. Either way is fine with me as long as no duplicated values.

I've made the update that references the AESConstants to avoid duplication.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434164972

From almatvee at openjdk.org  Wed Oct 15 23:07:21 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 15 Oct 2025 23:07:21 GMT
Subject: RFR: 8356575: Test order in which jpackage fills app image [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 18:24:02 GMT, Alexey Semenyuk  wrote:

>> - Test order in which jpackage fills app image
>> - Fix an issue with jpackage that it would fail to overwrite existing files in the app image. Uncovered by the test.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor. Simplify and make it pass on Windows and Linux

Marked as reviewed by almatvee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27826#pullrequestreview-3342603219

From valeriep at openjdk.org  Wed Oct 15 23:31:03 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 23:31:03 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <7faVZ8RHcws5sOoA1rfBrE3f7ON__bKvBCra2R3rLNU=.dfd5d4f3-7506-4d99-9ba5-ccb0b4ca0184@github.com>
References: 
 
 
 <7faVZ8RHcws5sOoA1rfBrE3f7ON__bKvBCra2R3rLNU=.dfd5d4f3-7506-4d99-9ba5-ccb0b4ca0184@github.com>
Message-ID: <-4wxYGqcPRXJYZEXd91_MPCBd491IFjd7TOnMP_HdxE=.060bb090-1084-4a3b-8315-2116e73e69df@github.com>

On Wed, 15 Oct 2025 21:26:33 GMT, Shawn M Emery  wrote:

>> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 82:
>> 
>>> 80:     public byte[] testUseAesIntrinsics() throws Exception {
>>> 81:         return cipher.doFinal(ct);
>>> 82:     }
>> 
>> These 3 methods look same to me except for the method names?
>
> The forked arguments will test different levels of optimizations:
> testBaseline: no optimizations
> testUseAes: AES optimizations
> testUseAesIntrinsics: AES machine instructions

Ah, I see, some has "+" vs some uses "-". My eye sights are getting worse. (sigh)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434206251

From smarks at openjdk.org  Wed Oct 15 23:35:10 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 15 Oct 2025 23:35:10 GMT
Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2]
In-Reply-To: 
References: 
 
Message-ID: <9EdKIXagldkPpMhdKBUbIVr3m8lHBGLXkRPvIWl2Y-Q=.f4bffa4f-1eb5-4263-a2bd-fbc16dc5e919@github.com>

On Wed, 15 Oct 2025 17:49:05 GMT, Joe Darcy  wrote:

>> Updating tests I've wrote to conform to current conventions of not having author tags.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting typo

test/jdk/java/io/Serializable/cloneArray/CloneArray.java line 28:

> 26:  * @bug 6990094
> 27:  * @summary Verify ObjectInputStream.cloneArray works on many kinds of arrays
> 28:  * @author Stuart Marks, Joseph D. Darcy

No objection to removing my name too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27813#discussion_r2434209645

From bpb at openjdk.org  Wed Oct 15 23:38:40 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 15 Oct 2025 23:38:40 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v5]
In-Reply-To: 
References: 
Message-ID: 

> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.

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

 - 8355342: Fall back to canonicalize0() result if drive letter converted to a long / UNC prefix
 - Merge
 - Merge
 - 8355342: Corrected a comment
 - 8355342: Add missing space in constant declaration
 - 8355342: Fix possible sneaky NullPointerException
 - 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27324/files
  - new: https://git.openjdk.org/jdk/pull/27324/files/0f29a4f3..ebe88f73

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

  Stats: 191105 lines in 2481 files changed: 151635 ins; 23944 del; 15526 mod
  Patch: https://git.openjdk.org/jdk/pull/27324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27324/head:pull/27324

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

From bpb at openjdk.org  Wed Oct 15 23:51:06 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 15 Oct 2025 23:51:06 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 23:38:40 GMT, Brian Burkhalter  wrote:

>> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - 8355342: Fall back to canonicalize0() result if drive letter converted to a long / UNC prefix
>  - Merge
>  - Merge
>  - 8355342: Corrected a comment
>  - 8355342: Add missing space in constant declaration
>  - 8355342: Fix possible sneaky NullPointerException
>  - 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format

Commit ebe88f7 changes `WinNTFileSystem::canonicalize` to fall back to the result of `canonicalize0` if `getFinalPath` converts a drive letter + `:` to a path beginning with `\`.  I have investigated and tested various Windows API functions and there does not appear to be a way to determine to exactly which path prefix a drive letter will be mapped by `GetFinalPathNameByHandleW`. No changes to the test are needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3408658546

From valeriep at openjdk.org  Thu Oct 16 00:21:12 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:21:12 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: 
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: <5aAa7y5hs9zHT05sehzUaDmSXY31QDQPj_ioD9V9nK8=.78641e57-e2df-4f8b-9c0b-35a56fbea7db@github.com>

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 896:

> 894:         if (key.length == AESConstants.AES_KEYSIZES[0]) {
> 895:             rounds = AES_128_ROUNDS;
> 896:             nk = AESConstants.AES_KEYSIZES[0]/WB;

Looks like we can get rid of `nk` as the `genRKeys(byte[])` method can calculate/derive it based on the specified `key` argument, i.e. `key.length >> 2` or `key.length / WB`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434256434

From prr at openjdk.org  Thu Oct 16 00:24:03 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Oct 2025 00:24:03 GMT
Subject: RFR: 8369858: Remove darcy author tags from jdk tests [v2]
In-Reply-To: <2BNYfDZc1RzYpFEuLNLxzz1ItvUDwUuJpGjaPwSdLKE=.db26af23-419b-4855-a035-c79c7b270ea4@github.com>
References: 
 
 <2BNYfDZc1RzYpFEuLNLxzz1ItvUDwUuJpGjaPwSdLKE=.db26af23-419b-4855-a035-c79c7b270ea4@github.com>
Message-ID: 

On Wed, 15 Oct 2025 20:56:57 GMT, Pavel Rappo  wrote:

> This is a very self-deprecating change. We should ask Dr. Deprecator what he thinks about it, especially since he's acquainted with Stuart Marks, whose authorship is also being removed.


Joe isn't being deprecated for removal. If he were there'd need to be a CSR, and I expect he'd pend it ?

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

PR Comment: https://git.openjdk.org/jdk/pull/27813#issuecomment-3408712064

From valeriep at openjdk.org  Thu Oct 16 00:42:05 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:42:05 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: 
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: 

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 954:

> 952:             }
> 953:             w[i] = w[i - nk] ^ tmp;
> 954:         }

Looks like most of these local variables can be removed? Since you are not changing the value of `len`, you can just use `WB`. `rW` is only used inside the if-block from line 944-948, so it can be declared on line 945.  Line 946-948 can be merged on one line, e.g. `tmp = subByte(rW, SBOX) ^ RCON[(i / nk) - 1];` and no need for `subWord` and `g`. Same goes for line 950 and 951.
Also, the value of `WB * (rounds + 1)` is used twice, this can be stored in a local variable say `wLen`, so it's only calculated once.
Same goes for the `i * WB` value from line 937-940

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434276514

From valeriep at openjdk.org  Thu Oct 16 00:45:03 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:45:03 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: 
References: 
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
 
Message-ID: <2Qva3E5Ux0iHeg_Xx_yDV06gkjVmtIQL0J1aL2oSkmE=.28ead96c-2f65-4501-b44d-97898d032d6a@github.com>

On Thu, 16 Oct 2025 00:38:09 GMT, Valerie Peng  wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 954:
> 
>> 952:             }
>> 953:             w[i] = w[i - nk] ^ tmp;
>> 954:         }
> 
> Looks like most of these local variables can be removed? Since you are not changing the value of `len`, you can just use `WB`. `rW` is only used inside the if-block from line 944-948, so it can be declared on line 945.  Line 946-948 can be merged on one line, e.g. `tmp = subByte(rW, SBOX) ^ RCON[(i / nk) - 1];` and no need for `subWord` and `g`. Same goes for line 950 and 951.
> Also, the value of `WB * (rounds + 1)` is used twice, this can be stored in a local variable say `wLen`, so it's only calculated once.
> Same goes for the `i * WB` value from line 937-940

On the second thought, instead of calculating `i * WB` value, You can use another local variable to store this index and increment it by 4 for each iteration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434280527

From valeriep at openjdk.org  Thu Oct 16 00:51:02 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:51:02 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: 
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: 

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 932:

> 930:      * @return w the cipher round keys.
> 931:      */
> 932:     private int[] genRKeys(byte[] key, int nk) {

nit: The spec names this "keyExpansion" and documents it under section 5.2. Could we include this in the method javadoc? Also, how about "genRoundKeys" or "doKeyExpansion" as method name? `nk` can be derived from `key` and maybe no need for extra argument?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434286447

From valeriep at openjdk.org  Thu Oct 16 00:54:10 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:54:10 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: 
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: 

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 932:

> 930:      * @return w the cipher round keys.
> 931:      */
> 932:     private int[] genRKeys(byte[] key, int nk) {

This method can be static?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434289681

From lmesnik at openjdk.org  Thu Oct 16 02:00:34 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 02:00:34 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from ProblemList-Virtual, 
 use requires instead
Message-ID: 

The problemlist entries for incompatible tests are replaced with requires tag.
Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.

Tested by running these tests with virtual test tthread factory.

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

Commit messages:
 - copyrights updated
 - the jdk part
 - the hotspot part

Changes: https://git.openjdk.org/jdk/pull/27834/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27834&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348844
  Stats: 61 lines in 16 files changed: 15 ins; 33 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27834.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27834/head:pull/27834

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

From swen at openjdk.org  Thu Oct 16 02:08:13 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 16 Oct 2025 02:08:13 GMT
Subject: RFR: 8369312: Refactor Float.toHexString() to avoid use of regex
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Oct 2025 01:13:16 GMT, Joe Darcy  wrote:

> Simple refactoring to avoid use the regular expressions. Existing tests in
> 
> java/lang/Double/ToHexString.java
> 
> cover the float conversions too.

The exponent -1022 is at the end, so the following implementation might be better.

return s.endsWith("-1022") ? s.substring(0, s.length() - 5).concat("-126") : s;

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

PR Comment: https://git.openjdk.org/jdk/pull/27780#issuecomment-3408896057

From lmesnik at openjdk.org  Thu Oct 16 02:09:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 02:09:46 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: 
References: 
Message-ID: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>

> The problemlist entries for incompatible tests are replaced with requires tag.
> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
> 
> Tested by running these tests with virtual test tthread factory.

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

 - copyrights updated
 - more tests removed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27834/files
  - new: https://git.openjdk.org/jdk/pull/27834/files/2c882158..eafa8d21

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

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

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

From dholmes at openjdk.org  Thu Oct 16 02:29:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Oct 2025 02:29:01 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
References: 
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
Message-ID: 

On Thu, 16 Oct 2025 02:09:46 GMT, Leonid Mesnik  wrote:

>> The problemlist entries for incompatible tests are replaced with requires tag.
>> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
>> 
>> Tested by running these tests with virtual test tthread factory.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights updated
>  - more tests removed

Seems reasonable.

Would be good to know why some tests have stopped failing though.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3342855898

From almatvee at openjdk.org  Thu Oct 16 02:39:35 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 16 Oct 2025 02:39:35 GMT
Subject: RFR: 8356578: Test --mac-entitlements
Message-ID: 

- Added test to cover `--mac-entitlements`.
- Added verification for entitlements from `--resource-dir`.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into JDK-8356578
 - 8356578: Test --mac-entitlements

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

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

From lmesnik at openjdk.org  Thu Oct 16 02:43:01 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 02:43:01 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: 
References: 
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 
Message-ID: 

On Thu, 16 Oct 2025 02:26:08 GMT, David Holmes  wrote:

> Seems reasonable.
> 
> Would be good to know why some tests have stopped failing though.
> 
> Thanks
Thank you for reveiw.
For most if not all cases the reason is Security Manager removal. The tests failed to obtain permissions from virtual threads.

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

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3408951683

From duke at openjdk.org  Thu Oct 16 04:04:23 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 04:04:23 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v6]
In-Reply-To: 
References: 
Message-ID: 

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/f48160cf..fbf2117f

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

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

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

From duke at openjdk.org  Thu Oct 16 04:04:25 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 04:04:25 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <5aAa7y5hs9zHT05sehzUaDmSXY31QDQPj_ioD9V9nK8=.78641e57-e2df-4f8b-9c0b-35a56fbea7db@github.com>
References: 
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
 <5aAa7y5hs9zHT05sehzUaDmSXY31QDQPj_ioD9V9nK8=.78641e57-e2df-4f8b-9c0b-35a56fbea7db@github.com>
Message-ID: 

On Thu, 16 Oct 2025 00:18:08 GMT, Valerie Peng  wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 896:
> 
>> 894:         if (key.length == AESConstants.AES_KEYSIZES[0]) {
>> 895:             rounds = AES_128_ROUNDS;
>> 896:             nk = AESConstants.AES_KEYSIZES[0]/WB;
> 
> Looks like we can get rid of `nk` as the `genRKeys(byte[])` method can calculate/derive it based on the specified `key` argument, i.e. `key.length >> 2` or `key.length / WB`

Sounds reasonable.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 932:
> 
>> 930:      * @return w the cipher round keys.
>> 931:      */
>> 932:     private int[] genRKeys(byte[] key, int nk) {
> 
> nit: The spec names this "keyExpansion" and documents it under section 5.2. Could we include this in the method javadoc? Also, how about "genRoundKeys" or "doKeyExpansion" as method name? `nk` can be derived from `key` and maybe no need for extra argument?

Actually I used Stallings' cryptography book specifically for the round key concepts, hence the variable name mismatch at least for 128 bit keys.  But after your suggestions is does look more like FIPS 192-upd 1 so I will reference the section ;)  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 932:
> 
>> 930:      * @return w the cipher round keys.
>> 931:      */
>> 932:     private int[] genRKeys(byte[] key, int nk) {
> 
> This method can be static if you pass the `rounds` value as a method argument.

Yes and subWord() would also need to be static for this change.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434497086
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434497821
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434498001

From duke at openjdk.org  Thu Oct 16 04:04:27 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 04:04:27 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <2Qva3E5Ux0iHeg_Xx_yDV06gkjVmtIQL0J1aL2oSkmE=.28ead96c-2f65-4501-b44d-97898d032d6a@github.com>
References: 
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
 
 <2Qva3E5Ux0iHeg_Xx_yDV06gkjVmtIQL0J1aL2oSkmE=.28ead96c-2f65-4501-b44d-97898d032d6a@github.com>
Message-ID: 

On Thu, 16 Oct 2025 00:42:20 GMT, Valerie Peng  wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 954:
>> 
>>> 952:             }
>>> 953:             w[i] = w[i - nk] ^ tmp;
>>> 954:         }
>> 
>> Looks like most of these local variables can be removed? Since you are not changing the value of `len`, you can just use `WB`. `rW` is only used inside the if-block from line 944-948, so it can be declared on line 945.  Line 946-948 can be merged on one line, e.g. `tmp = subByte(rW, SBOX) ^ RCON[(i / nk) - 1];` and no need for `subWord` and `g`. Same goes for line 950 and 951.
>> Also, the value of `WB * (rounds + 1)` is used twice, this can be stored in a local variable say `wLen`, so it's only calculated once.
>> Same goes for the `i * WB` value from line 937-940
>
> On the second thought, instead of calculating `i * WB` value, You can use another local variable to store this index and increment it by 4 for each iteration.

I've made these changes and used the 2nd approach for indexing key.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434497439

From valeriep at openjdk.org  Thu Oct 16 04:52:04 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 04:52:04 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: 
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: 

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1032:

> 1030:      * @return the substituted word.
> 1031:      */
> 1032:     private int subByte(int state, byte[][] sub) {

Given the input and output are both `int` type, i.e. word, maybe it's better named as `subWord` ? This also matches the pseudocode routine name used in the spec. 
This method also can be made static. It seems that `sub` is always the static `SBOX`, maybe we don't have to use an argument to pass it? 
nit: the variable name `state` is a bit misleading as we are only using part of it. A state is consisting of 4 words and the input here is only 1 word.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434562796

From duke at openjdk.org  Thu Oct 16 05:14:44 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 05:14:44 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v7]
In-Reply-To: 
References: 
Message-ID: 

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/fbf2117f..9f00c355

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

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

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

From duke at openjdk.org  Thu Oct 16 05:14:44 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 05:14:44 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: 
References: 
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
 
Message-ID: 

On Thu, 16 Oct 2025 04:49:11 GMT, Valerie Peng  wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1032:
> 
>> 1030:      * @return the substituted word.
>> 1031:      */
>> 1032:     private int subByte(int state, byte[][] sub) {
> 
> Given the input and output are both `int` type, i.e. word, maybe it's better named as `subWord` ? This also matches the pseudocode routine name used in the spec. 
> This method also can be made static. It seems that `sub` is always the static `SBOX`, maybe we don't have to use an argument to pass it? 
> nit: the variable name `state` is a bit misleading as we are only using part of it. A state is consisting of 4 words and the input here is only 1 word.

Good, it was a byte operation, but evolved to a word.
Last commit made it a static.
Yes, before I switched over to a LUT for the inverse mix column transform of the inverse key expansion it needed both, but doesn't anymore.
I'll switch from state to word then.
Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434594049

From alanb at openjdk.org  Thu Oct 16 05:35:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 05:35:03 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: 
References: 
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 
 
Message-ID: 

On Thu, 16 Oct 2025 02:40:12 GMT, Leonid Mesnik  wrote:

>> Seems reasonable.
>> 
>> Would be good to know why some tests have stopped failing though.
>> 
>> Thanks
>
>> Seems reasonable.
>> 
>> Would be good to know why some tests have stopped failing though.
>> 
>> Thanks
> Thank you for reveiw.
> For most if not all cases the reason is Security Manager removal. The tests failed to obtain permissions from virtual threads.

@lmesnik - would I be correct to say that you are on a mission to get rid of ProblemList-Virtual completely? Just to mention that there are a number of tests that already skip when the test main thread is a virtual thread. We may need to track these down and replace them with `@requires test.thread.factory == null` so that it is cleared from the test description.

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

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3409239412

From alanb at openjdk.org  Thu Oct 16 05:39:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 05:39:01 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: 
References: 
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 
 
Message-ID: 

On Thu, 16 Oct 2025 02:40:12 GMT, Leonid Mesnik  wrote:

> For most if not all cases the reason is Security Manager removal. The tests failed to obtain permissions from virtual threads.

Right, virtual threads did not capture the caller context (inherited AccessControlContext) and had no permissions when executing code that performed a privileged action. This is why some of the pre-existing tests that ran with a security manager couldn't run with JTREG_TEST_THREAD_FACTORY=Virtual.

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

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3409247117

From lmesnik at openjdk.org  Thu Oct 16 05:57:01 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 05:57:01 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: 
References: 
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 
 
Message-ID: 

On Thu, 16 Oct 2025 02:40:12 GMT, Leonid Mesnik  wrote:

>> Seems reasonable.
>> 
>> Would be good to know why some tests have stopped failing though.
>> 
>> Thanks
>
>> Seems reasonable.
>> 
>> Would be good to know why some tests have stopped failing though.
>> 
>> Thanks
> Thank you for reveiw.
> For most if not all cases the reason is Security Manager removal. The tests failed to obtain permissions from virtual threads.

> @lmesnik - would I be correct to say that you are on a mission to get rid of ProblemList-Virtual completely? Just to mention that there are a number of tests that already skip when the test main thread is a virtual thread. We may need to track these down and replace them with `@requires test.thread.factory == null` so that it is cleared from the test description.

I am going to mark with requires all incompatible tests. There are some tests that manually check if virtual thread is enabled and the tests that already have virtual thread cases. I'll clean up them later.

However, the ProblemList-Virtual  will remain. It should contains the test that fail because of bugs. Including RFE to improve test to support virtual threads.
 The
`@requires test.thread.factory == null` 
means that test is incompatible with thread factory and unlikely is going to be fixed for this mode.

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

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3409283143

From alanb at openjdk.org  Thu Oct 16 06:06:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 06:06:07 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
References: 
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
Message-ID: 

On Thu, 16 Oct 2025 02:09:46 GMT, Leonid Mesnik  wrote:

>> The problemlist entries for incompatible tests are replaced with requires tag.
>> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
>> 
>> Tested by running these tests with virtual test tthread factory.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights updated
>  - more tests removed

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3343180403

From alanb at openjdk.org  Thu Oct 16 06:06:08 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 06:06:08 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: 
References: 
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 
 
 
Message-ID: <7DwLsAuTCiYYr6lPN9vlLT8SzjWMRoHphbFDuLQjenU=.8296b6bd-8460-440c-a4c8-daf3dfd49325@github.com>

On Thu, 16 Oct 2025 05:54:38 GMT, Leonid Mesnik  wrote:

> However, the ProblemList-Virtual will remain. It should contains the test that fail because of bugs. Including RFE to improve test to support virtual threads.

Thanks for the clarification.

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

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3409309033

From syan at openjdk.org  Thu Oct 16 06:08:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 16 Oct 2025 06:08:03 GMT
Subject: RFR: 8183336: Better cleanup for
 jdk/test/java/lang/module/customfs/ModulesInCustomFileSystem.java
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Oct 2025 09:38:08 GMT, Arno Zeller  wrote:

> We can set the java.io.tmpdir to point to the current directory to avoid polluting the temp directory.
> @AlanBateman Thanks for this suggestion.

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/27821#pullrequestreview-3343184911

From syan at openjdk.org  Thu Oct 16 06:27:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 16 Oct 2025 06:27:02 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
References: 
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
Message-ID: 

On Thu, 16 Oct 2025 02:09:46 GMT, Leonid Mesnik  wrote:

>> The problemlist entries for incompatible tests are replaced with requires tag.
>> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
>> 
>> Tested by running these tests with virtual test tthread factory.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights updated
>  - more tests removed

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3343230765

From rrich at openjdk.org  Thu Oct 16 07:18:11 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 16 Oct 2025 07:18:11 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 15 Oct 2025 19:33:26 GMT, Patricio Chilano Mateo  wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1751:
>> 
>>> 1749:                   RegisterMap::ProcessFrames::skip,
>>> 1750:                   RegisterMap::WalkContinuation::skip);
>>> 1751:       frame fr = top.sender(®_map);
>> 
>> I think there's a problem here. I get an assertion on ppc if `top` is a heap frame (calling from `log_preempt_after_freeze`) because in `frame::sender_raw()` we don't take the path we normally would for a frame on heap. Instead `sender_for_compiled_frame()` is called which uses a constructor that asserts alignment of `sp` (see [here](https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L81-L86)). The assertion fails because `_on_heap` is false but should be `true`.
>> 
>> I think in `sender_raw` `map->in_cont()` should return true if this frame is on heap.
>> 
>> It's not quite easy to fix though since `top` can also be on stack.
>
> Right, it should be walked as a heap frame. Could you verify if this patch fixes the issue?
> 
> 
> diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
> index 86c56fe583f..fb1f66c60f4 100644
> --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp
> +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
> @@ -196,7 +196,7 @@ static bool do_verify_after_thaw(JavaThread* thread, stackChunkOop chunk, output
>  static void log_frames(JavaThread* thread, bool dolog = true);
>  static void log_frames_after_thaw(JavaThread* thread, ContinuationWrapper& cont, intptr_t* sp);
>  static void print_frame_layout(const frame& f, bool callee_complete, outputStream* st = tty);
> -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr);
> +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr, stackChunkOop chunk = nullptr);
> 
>  #define assert_pfl(p, ...) \
>  do {                                           \
> @@ -1723,7 +1723,7 @@ bool FreezeBase::check_valid_fast_path() {
>    return true;
>  }
> 
> -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr) {
> +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr, stackChunkOop chunk) {
>    Method* m;
>    const char* code_name;
>    int bci;
> @@ -1747,7 +1747,13 @@ static void verify_frame_kind(const frame& top, Continuation::preempt_kind preem
>        RegisterMap reg_map(current,
>                    RegisterMap::UpdateMap::skip,
>                    RegisterMap::ProcessFrames::skip,
> -                  RegisterMap::WalkContinuation::skip);
> +                  RegisterMap::WalkContinuation::include);
> +      if (top.is_heap_frame()) {
> +        assert(chunk != nullptr, "");
> +        reg_map.set_stack_chunk(chunk);
> +        top = chunk->relativize(top);
> +        top.set_frame_index(0);
> +      }
>        frame fr = top.sender(®_map);
>        vframe*  vf  = vframe::new_vframe(&fr, ®_map, current);
>        compiledVFrame* cvf = compiledVFrame::cast(vf);
> @@ -1803,7 +1809,7 @@ static void log_preempt_after_freeze(ContinuationWrapper& cont) {
>    Method* m = nullptr;
>    const char* code_name = nu...

Your patch fixes the issue. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2434828305

From vklang at openjdk.org  Thu Oct 16 08:31:19 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 16 Oct 2025 08:31:19 GMT
Subject: Integrated: 8369656 : Calling CompletableFuture.join() could execute
 task in common pool
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Oct 2025 12:59:52 GMT, Viktor Klang  wrote:

> Addresses the regression regarding pool assistance and includes a regression test for `CompletableFuture::get()`, `CompletableFuture::get(timeout, unit)`, and `CompletableFuture::join()`

This pull request has now been integrated.

Changeset: b5b83247
Author:    Viktor Klang 
URL:       https://git.openjdk.org/jdk/commit/b5b83247da9caea30c88b69543e350783663bc46
Stats:     47 lines in 2 files changed: 43 ins; 0 del; 4 mod

8369656: Calling CompletableFuture.join() could execute task in common pool

Reviewed-by: alanb, dl

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

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

From aph at openjdk.org  Thu Oct 16 09:08:13 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 16 Oct 2025 09:08:13 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 20:23:33 GMT, Patricio Chilano Mateo  wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into JDK-8369238
>  - RISC-V support
>  - Fix whitespaces
>  - v1

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 209:

> 207:     // the last_sp saved in the frame (remove possible alignment added while
> 208:     // thawing, see ThawBase::finish_thaw()). We also need to clear the last_sp
> 209:     // saved in the frame as it is not expected to be set in case we preempt again.

A bit stronger?
Suggestion:

    // saved in the frame because it must be clear if we freeze again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2435147223

From azeller at openjdk.org  Thu Oct 16 09:22:51 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 16 Oct 2025 09:22:51 GMT
Subject: RFR: 8183336: Better cleanup for
 jdk/test/java/lang/module/customfs/ModulesInCustomFileSystem.java [v2]
In-Reply-To: 
References: 
Message-ID: 

> We can set the java.io.tmpdir to point to the current directory to avoid polluting the temp directory.
> @AlanBateman Thanks for this suggestion.

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

  Update Copyright header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27821/files
  - new: https://git.openjdk.org/jdk/pull/27821/files/3d87b1b8..7917f1a4

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

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

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

From azeller at openjdk.org  Thu Oct 16 09:25:40 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 16 Oct 2025 09:25:40 GMT
Subject: RFR: 8183336: Better cleanup for
 jdk/test/java/lang/module/customfs/ModulesInCustomFileSystem.java [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 13:19:29 GMT, Alan Bateman  wrote:

> Do you mind bumping the copyright header to 2025 before you integrate?
Thanks - I forgot this. It is done now.

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

PR Comment: https://git.openjdk.org/jdk/pull/27821#issuecomment-3409972000

From alanb at openjdk.org  Thu Oct 16 09:33:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 09:33:10 GMT
Subject: RFR: 8183336: Better cleanup for
 jdk/test/java/lang/module/customfs/ModulesInCustomFileSystem.java [v2]
In-Reply-To: 
References: 
 
Message-ID: <3E5jx_5ASogFZR-d8SwoGdtizLJbFWxM_pepFjU9g0A=.f0ff08f6-df82-4654-9e10-8985b928c7ce@github.com>

On Thu, 16 Oct 2025 09:22:51 GMT, Arno Zeller  wrote:

>> We can set the java.io.tmpdir to point to the current directory to avoid polluting the temp directory.
>> @AlanBateman Thanks for this suggestion.
>
> Arno Zeller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Copyright header

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27821#pullrequestreview-3343894965

From alanb at openjdk.org  Thu Oct 16 09:59:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 09:59:49 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v15]
In-Reply-To: <8XswExrj9izeP9hR_qXXu2UKSuecQfLskrrJ4D7fcLg=.e6dfe129-f413-484d-a2aa-993c223b4a9c@github.com>
References: 
 
 <8XswExrj9izeP9hR_qXXu2UKSuecQfLskrrJ4D7fcLg=.e6dfe129-f413-484d-a2aa-993c223b4a9c@github.com>
Message-ID: 

On Wed, 8 Oct 2025 05:26:37 GMT, Alan Bateman  wrote:

>> Roger Riggs 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 22 additional commits since the last revision:
>> 
>>  - The ProcessCloseTest is modified to be able to test the logic
>>    around close() waiting for the process to exit and the specified
>>    behavior of interrupting the waitFor.
>>  - Close is modified to wait for the process to terminate before returning.
>>    Please review the revised javadoc.
>>    As suggested in review comments, waiting for the process to terminate
>>    allows a more orderly cleanup by the application.
>>    The streams are closed and close uses `waitFor()` with an unlimited timeout
>>    for the process to terminate.
>>    While waiting the thread can be `interrupted` to exit the `waitFor`.
>>    If/when `waitFor` is interrupted, the process is destroyedForcibly on
>>    all platforms. When close() returns, the thread interrupt will pending
>>    and can be handled by the caller.
>>    If a watchdog timeout is desired on close(), a separate thread
>>    can schedule an interrupt at a suitable time after close is called.
>>  - Review comment improvements to make expected behavior clearer.
>>  - Merge branch 'master' into 8364361-process-autocloseable
>>  - Clarify the use of waitFor after close() or T-W-R exit.
>>  - Additional review feedback.
>>    Updated to emphasize reading the data from the streams and calling waitFor
>>    to allow for normal termination.
>>  - Merge branch 'master' into 8364361-process-autocloseable
>>  - Address review comments for code and javadoc in Process, the test and the example.
>>    Reinforced that calling waitFor should occur before calling close to wait for termination and get the exitStatus.
>>    Corrected the error message check for invalid handles on Windows.
>>    Update test to allow normal completion when exceptions may be expected.
>>    Correct the expected message on Windows for an invalid handle exception.
>>  - Update close() to use "terminate" consistently.
>>  - Remove volatile from "closed" field; updates are guarded by synchronized.
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/51c4b310...6f8f7327
>
> src/java.base/share/classes/java/lang/Process.java line 235:
> 
>> 233:                 destroyForcibly();
>> 234:                 // Re-assert the interrupt
>> 235:                 Thread.currentThread().interrupt();
> 
> I think this is still problematic as code after the t-w-r can't be guaranteed that the child has terminated. So I think it needs a loop that ends when waitFor completes without an exception (destroyForcibly would only be called on the first interrupt of course).

> @AlanBateman can you comment on the possibility of looping indefinitely and not be interruptible if the OS process cannot be destroyed.

AutoCloseable and Closeable.close are specified to release the resources. If Process.close completes normally (no exception) then users should expect that all resources have been released and the process has terminated.

In the current proposal, and assuming no interrupt, close waits indefinitely for the process to terminate. If close completes normally then you know the process has terminated. Someone might put code after the t-w-r to delete files or do other cleanup.  It's similar to ExecutorService where close waits for all tasks to complete. So I think this part is okay.

If interrupted while waiting then close should continue to wait or throw. I think the current proposal, to complete normally but leave the process behind, is problematic and surprising. Having close throw (probably IOException) is a bit problematic too as there isn't much you can do. We regularly see libraries ignoring the IOException thrown by close, including from writable streams where close is screaming that it was unable to flush buffered bytes. So while it wouldn't be terrible to throw, it may be better to keep close simple and be uninterruptible (meaning it would be complete normally when the process terminates and with the interrupt status set). Working through a few use-cases where you might use t-w-r with Process would help to validate the direction

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2435298830

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 shaojin.wensj at alibaba-inc.com  Thu Oct 16 12:50:58 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Thu, 16 Oct 2025 20:50:58 +0800
Subject: =?UTF-8?B?UmVmYWN0b3IgRG91YmxlLnRvSGV4U3RyaW5nIHRvIGVsaW1pbmF0ZSByZWdleCBhbmQgU3Ry?=
 =?UTF-8?B?aW5nQnVpbGRlcg==?=
Message-ID: <70b9eee5-39b0-424c-ac54-abbfc18b9618.shaojin.wensj@alibaba-inc.com>

Referencing jddarcy's 8369312: Refactor Float.toHexString() to avoid use of regex (https://github.com/openjdk/jdk/pull/27780 ), we can further eliminate the regex and StringBuilder in Double.toHexString to improve performance.
To make my proposal easier to understand, I've prepared a draft PR: https://github.com/openjdk/jdk/pull/27811 
-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lancea at openjdk.org  Thu Oct 16 13:51:28 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 16 Oct 2025 13:51:28 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v6]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
 
 
 
Message-ID: 

On Wed, 15 Oct 2025 21:26:05 GMT, Johannes D?bler  wrote:

>> No plans to do that in the default implementation.  Driver vendors can/should optimize as needed based on their driver implementation.
>
> Hi @LanceAndersen,
> don*t know what you mean with " Driver vendors can/should optimize as needed based on their driver implementation."
> My idea was that in JDBC 4.5 the default methods Statement.enquoteNCharLiteral and Statement.enquoteIdentifier could call the new corresponding default methods in Connection, therefore easing life of JDBC vendor or test libraries to have a **_single_** site to override.

Hi,

Thank you for your suggestion, but I have no plans to make the suggested change:

- The methods were added to the JDBC as of JDK 9, ~10 years ago
 - drivers that have implemented  these methods would have already added them to their Statement implementation
 - Most implementations of Statement would have more efficient access to the Connection object should they decide to move their implementation to their Connection implementation 
 -  It would be trivial to refactor these methods to their Connection implementation or another package-private class

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2435995943

From azeller at openjdk.org  Thu Oct 16 14:39:16 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 16 Oct 2025 14:39:16 GMT
Subject: RFR: 8183336: Better cleanup for
 jdk/test/java/lang/module/customfs/ModulesInCustomFileSystem.java [v2]
In-Reply-To: <3E5jx_5ASogFZR-d8SwoGdtizLJbFWxM_pepFjU9g0A=.f0ff08f6-df82-4654-9e10-8985b928c7ce@github.com>
References: 
 
 <3E5jx_5ASogFZR-d8SwoGdtizLJbFWxM_pepFjU9g0A=.f0ff08f6-df82-4654-9e10-8985b928c7ce@github.com>
Message-ID: 

On Thu, 16 Oct 2025 09:30:27 GMT, Alan Bateman  wrote:

>> Arno Zeller has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Copyright header
>
> Marked as reviewed by alanb (Reviewer).

@AlanBateman @sendaoYan Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27821#issuecomment-3411214690

From duke at openjdk.org  Thu Oct 16 14:39:18 2025
From: duke at openjdk.org (duke)
Date: Thu, 16 Oct 2025 14:39:18 GMT
Subject: RFR: 8183336: Better cleanup for
 jdk/test/java/lang/module/customfs/ModulesInCustomFileSystem.java [v2]
In-Reply-To: 
References: 
 
Message-ID: <2-rNckr4iNm9S4QEQgUeyR7EhOumhqmmyW0YP4gos00=.87e54a9b-17fc-47b5-a185-370bc2f0f266@github.com>

On Thu, 16 Oct 2025 09:22:51 GMT, Arno Zeller  wrote:

>> We can set the java.io.tmpdir to point to the current directory to avoid polluting the temp directory.
>> @AlanBateman Thanks for this suggestion.
>
> Arno Zeller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Copyright header

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

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

PR Comment: https://git.openjdk.org/jdk/pull/27821#issuecomment-3411227964

From azeller at openjdk.org  Thu Oct 16 15:18:07 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 16 Oct 2025 15:18:07 GMT
Subject: Integrated: 8183336: Better cleanup for
 jdk/test/java/lang/module/customfs/ModulesInCustomFileSystem.java
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Oct 2025 09:38:08 GMT, Arno Zeller  wrote:

> We can set the java.io.tmpdir to point to the current directory to avoid polluting the temp directory.
> @AlanBateman Thanks for this suggestion.

This pull request has now been integrated.

Changeset: 87092ef1
Author:    Arno Zeller 
Committer: Matthias Baesken 
URL:       https://git.openjdk.org/jdk/commit/87092ef1d97e00ddb6674b0e309f2f904d307604
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8183336: Better cleanup for jdk/test/java/lang/module/customfs/ModulesInCustomFileSystem.java

Reviewed-by: alanb, syan

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

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

From sgehwolf at openjdk.org  Thu Oct 16 15:31:20 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 16 Oct 2025 15:31:20 GMT
Subject: RFR: 8343340: Swapping checking do not work for
 MetricsMemoryTester failcount
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Oct 2025 14:18:41 GMT, SendaoYan  wrote:

> Hi all,
> 
> The sub-test failcount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java requires swap memory enable on the test host. But the swap memory check introduced by JDK-8264524 do not work correctly, because it's missing jvm option '-XX:+AlwaysPreTouch', shows as below. This PR add jvm option '-XX:+AlwaysPreTouch' to make the swap memory check work correctly, and use jtreg.SkippedException instead of print waring when this test can not execute.
> 
> Change has been verified locally on linux-x64. Test fix only, no risk.
> 
> 
>> free -h
> total used free shared buff/cache available
> Mem: 751Gi 513Gi 229Gi 5.0Mi 8.4Gi 234Gi
> Swap: 0B 0B 0B
> 
> 
> Without jvm option -XX:+AlwaysPreTouch, the 'java -Xms128m -Xmx128m -version' can start successfully:
> 
>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -Xms128m -Xmx128m -version
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment HJDK-0 (build 26+-42b2999c)
> OpenJDK 64-Bit Server VM HJDK-0 (build 26+-42b2999c, mixed mode, sharing)
> 
> 
> With jvm option -XX:+AlwaysPreTouch, the 'java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version' can not start and killed by docker(return code is 137):
> 
>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version ; echo $?
> 137

Please amend the comment on line 114 to something like this:


        // Check whether swapping really works for this test
        // On some systems there is no swap space enabled. And running
        // 'java -Xms{mem-limit} -Xmx{mem-limit} -XX:+AlwaysPreTouch -version'
        // would fail due to swap space size being 0. Note that when swap is
        // properly enabled on the system the container gets the same amount
        // of swap as is configured for memory. Thus, 2x{mem-limit} is the actual
        // memory and swap bound for this pre-test.

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

PR Review: https://git.openjdk.org/jdk/pull/27823#pullrequestreview-3345562755

From lancea at openjdk.org  Thu Oct 16 15:36:13 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 16 Oct 2025 15:36:13 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v7]
In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
Message-ID: 

> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
> 
> - Deprecate SQLPermission for removal
> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
> 
> Tiers 1-3 have been run

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

  Minor wordsmithing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27693/files
  - new: https://git.openjdk.org/jdk/pull/27693/files/398b0f42..6d77719e

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

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

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

From rriggs at openjdk.org  Thu Oct 16 15:53:45 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 16 Oct 2025 15:53:45 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v7]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
Message-ID: 

On Thu, 16 Oct 2025 15:36:13 GMT, Lance Andersen  wrote:

>> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
>> 
>> - Deprecate SQLPermission for removal
>> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
>> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
>> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
>> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
>> 
>> Tiers 1-3 have been run
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor wordsmithing

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27693#pullrequestreview-3345655276

From pchilanomate at openjdk.org  Thu Oct 16 16:13:43 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 16 Oct 2025 16:13:43 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 16 Oct 2025 07:15:33 GMT, Richard Reingruber  wrote:

>> Right, it should be walked as a heap frame. Could you verify if this patch fixes the issue?
>> 
>> 
>> diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
>> index 86c56fe583f..fb1f66c60f4 100644
>> --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp
>> +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
>> @@ -196,7 +196,7 @@ static bool do_verify_after_thaw(JavaThread* thread, stackChunkOop chunk, output
>>  static void log_frames(JavaThread* thread, bool dolog = true);
>>  static void log_frames_after_thaw(JavaThread* thread, ContinuationWrapper& cont, intptr_t* sp);
>>  static void print_frame_layout(const frame& f, bool callee_complete, outputStream* st = tty);
>> -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr);
>> +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr, stackChunkOop chunk = nullptr);
>> 
>>  #define assert_pfl(p, ...) \
>>  do {                                           \
>> @@ -1723,7 +1723,7 @@ bool FreezeBase::check_valid_fast_path() {
>>    return true;
>>  }
>> 
>> -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr) {
>> +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr, stackChunkOop chunk) {
>>    Method* m;
>>    const char* code_name;
>>    int bci;
>> @@ -1747,7 +1747,13 @@ static void verify_frame_kind(const frame& top, Continuation::preempt_kind preem
>>        RegisterMap reg_map(current,
>>                    RegisterMap::UpdateMap::skip,
>>                    RegisterMap::ProcessFrames::skip,
>> -                  RegisterMap::WalkContinuation::skip);
>> +                  RegisterMap::WalkContinuation::include);
>> +      if (top.is_heap_frame()) {
>> +        assert(chunk != nullptr, "");
>> +        reg_map.set_stack_chunk(chunk);
>> +        top = chunk->relativize(top);
>> +        top.set_frame_index(0);
>> +      }
>>        frame fr = top.sender(®_map);
>>        vframe*  vf  = vframe::new_vframe(&fr, ®_map, current);
>>        compiledVFrame* cvf = compiledVFrame::cast(vf);
>> @@ -1803,7 +1809,7 @@ static void log_preempt_after_freeze(...
>
> Your patch fixes the issue. Thanks!

Great, pushed fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2436600849

From pchilanomate at openjdk.org  Thu Oct 16 16:26:09 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 16 Oct 2025 16:26:09 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 16 Oct 2025 09:05:24 GMT, Andrew Haley  wrote:

>> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge branch 'master' into JDK-8369238
>>  - RISC-V support
>>  - Fix whitespaces
>>  - v1
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 209:
> 
>> 207:     // the last_sp saved in the frame (remove possible alignment added while
>> 208:     // thawing, see ThawBase::finish_thaw()). We also need to clear the last_sp
>> 209:     // saved in the frame as it is not expected to be set in case we preempt again.
> 
> A bit stronger?
> Suggestion:
> 
>     // saved in the frame because it must be clear if we freeze again.

Just to add more context, not clearing last_sp will make this assert [1] fire if we freeze again. That assert is mostly a verification check, because we know the interpreter doesn?t set last_sp for the top frame when calling into the VM. But I don?t see a fundamental reason why it must be cleared (removing the assert and not clearing last_sp works). I don?t see any other code that checks last_sp needs to be cleared for the top frame (other than in the interpreter before calling into the VM).
How about changing that last sentence with: `We also clear last_sp to match the behavior when calling the VM from the interpreter (we check for this in FreezeBase::prepare_freeze_interpreted_top_frame).`

[1] https://github.com/openjdk/jdk/blob/87092ef1d97e00ddb6674b0e309f2f904d307604/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L136

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2436641958

From pchilanomate at openjdk.org  Thu Oct 16 16:13:42 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 16 Oct 2025 16:13:42 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: 
References: 
Message-ID: 

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  fix verify_frame_kind

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27802/files
  - new: https://git.openjdk.org/jdk/pull/27802/files/79fce80f..ac557152

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

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

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

From rgiulietti at openjdk.org  Thu Oct 16 16:28:57 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 16 Oct 2025 16:28:57 GMT
Subject: RFR: 8366478: BigDecimal roots [v4]
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
Message-ID: <5P0UWZILeXnLAmlzpbJ6bGIQPEFi-pxKe-yrC13tniI=.9b697af9-13ec-424c-a949-29d07500847b@github.com>

On Wed, 15 Oct 2025 15:56:46 GMT, fabioromano1  wrote:

>> An implementation of `BigDecimal.nthRoot(int, MathContext)`.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment for error analysis

src/java.base/share/classes/java/math/BigDecimal.java line 2160:

> 2158:      *
> 2159:      * 
    The preferred scale of the returned result is equal to
> 2160:      * {@code this.scale()/n}. The value of the returned result is

I think the preferred scale should be ceiling(this.scale() / n).
The IEEE 754 standard has a preferred exponent (negated scale) of floor(exp(this) / n).

src/java.base/share/classes/java/math/BigDecimal.java line 2181:

> 2179:      * @param mc the context to use.
> 2180:      * @return the {@code n}th root of {@code this}.
> 2181:      * @throws ArithmeticException if {@code n == 0 || n == Integer.MIN_VALUE}.

Just out of curiosity, is there a technical reason for the restriction on MIN_VALUE?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2436648335
PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2436648498

From darcy at openjdk.org  Thu Oct 16 16:41:27 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 16 Oct 2025 16:41:27 GMT
Subject: Integrated: 8369858: Remove darcy author tags from jdk tests
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Oct 2025 04:37:50 GMT, Joe Darcy  wrote:

> Updating tests I've wrote to conform to current conventions of not having author tags.

This pull request has now been integrated.

Changeset: 7e032409
Author:    Joe Darcy 
URL:       https://git.openjdk.org/jdk/commit/7e03240974cd66c471f5d02e14fd77971fe6d173
Stats:     130 lines in 63 files changed: 0 ins; 67 del; 63 mod

8369858: Remove darcy author tags from jdk tests

Reviewed-by: rriggs, iris, lancea

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

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

From darcy at openjdk.org  Thu Oct 16 17:35:58 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 16 Oct 2025 17:35:58 GMT
Subject: RFR: 8370028: Remove author tags from mathematical classes
Message-ID: 

Removing my author tags under `/src` and other authors tags in those files.
---------
### Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
- [x] Change must not contain extraneous whitespace
- [x] Commit message must refer to an issue

### Error
 ?? The pull request body must not be empty.



### Reviewing

    Using git

Checkout this PR locally: \
`$ git fetch https://git.openjdk.org/jdk.git pull/27852/head:pull/27852` \
`$ git checkout pull/27852`

Update a local copy of the PR: \
`$ git checkout pull/27852` \
`$ git pull https://git.openjdk.org/jdk.git pull/27852/head`


    

    Using Skara CLI tools

Checkout this PR locally: \
`$ git pr checkout 27852`

View PR using the GUI difftool: \
`$ git pr show -t 27852`


    

    Using diff file

Download this PR as a diff file: \
https://git.openjdk.org/jdk/pull/27852.diff


    

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

Commit messages:
 - JDK-8370028: Remove author tags from mathematical classes

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

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

From bpb at openjdk.org  Thu Oct 16 17:45:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 16 Oct 2025 17:45:13 GMT
Subject: RFR: 8370028: Remove author tags from mathematical classes
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 17:22:21 GMT, Joe Darcy  wrote:

> Removing my author tags under `/src` and other authors tags in those files.
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
>  ?? The pull request body must not be empty.
> 
> 
> 
> ### Reviewing
> 
    Using git
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/27852/head:pull/27852` \
> `$ git checkout pull/27852`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/27852` \
> `$ git pull https://git.openjdk.org/jdk.git pull/27852/head`
> 
> 
    
> 
    Using Skara CLI tools
> 
> Checkout this PR locally: \
> `$ git pr checkout 27852`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 27852`
> 
> 
    
> 
    Using diff file
> 
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/27852.diff
> 
> 
    

Better to get rid of the evidence. ;-)

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27852#pullrequestreview-3346174670

From duke at openjdk.org  Thu Oct 16 19:39:42 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 16 Oct 2025 19:39:42 GMT
Subject: RFR: 8366478: BigDecimal roots [v4]
In-Reply-To: <5P0UWZILeXnLAmlzpbJ6bGIQPEFi-pxKe-yrC13tniI=.9b697af9-13ec-424c-a949-29d07500847b@github.com>
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 <5P0UWZILeXnLAmlzpbJ6bGIQPEFi-pxKe-yrC13tniI=.9b697af9-13ec-424c-a949-29d07500847b@github.com>
Message-ID: <4_ZUCTwJrdVM8JpeVpluYHtngQjZ5Bb3h_0ljRTU9w8=.e8e60474-9c15-4af2-909e-080c4e5b9257@github.com>

On Thu, 16 Oct 2025 16:25:40 GMT, Raffaello Giulietti  wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment for error analysis
>
> src/java.base/share/classes/java/math/BigDecimal.java line 2160:
> 
>> 2158:      *
>> 2159:      * 
    The preferred scale of the returned result is equal to
>> 2160:      * {@code this.scale()/n}. The value of the returned result is
> 
> I think the preferred scale should be ceiling(this.scale() / n).
> The IEEE 754 standard has a preferred exponent (negated scale) of floor(exp(this) / n).

Yes, but this is inconsistent with the definition of _preferred scale_ for `BigDecimal.sqrt()`.

> src/java.base/share/classes/java/math/BigDecimal.java line 2181:
> 
>> 2179:      * @param mc the context to use.
>> 2180:      * @return the {@code n}th root of {@code this}.
>> 2181:      * @throws ArithmeticException if {@code n == 0 || n == Integer.MIN_VALUE}.
> 
> Just out of curiosity, is there a technical reason for the restriction on MIN_VALUE?

Yes, `|Integer.MIN_VALUE|` is out of range of `int`s, so it cannot be used as a degree for `BigInteger.nthRoot(int)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2437243194
PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2437253304

From almatvee at openjdk.org  Thu Oct 16 19:42:29 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 16 Oct 2025 19:42:29 GMT
Subject: RFR: 8356578: Test --mac-entitlements
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 02:32:41 GMT, Alexander Matveev  wrote:

> - Added test to cover `--mac-entitlements`.
> - Added verification for entitlements from `--resource-dir`.

@alexeysemenyukoracle Please review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27835#issuecomment-3412579683

From valeriep at openjdk.org  Thu Oct 16 20:04:35 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 20:04:35 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 16 Oct 2025 05:14:44 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1040:

> 1038:      * @param p [in] the plaintext to be encrypted.
> 1039:      * @param po [in] the plaintext offset in the array of bytes.
> 1040:      * @param c [out] the encrypted ciphertext output.

nit: ciphertext already implied to be encrypted. Maybe no need for the "encrypted" adj.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1157:

> 1155:             ti3 = T0[a3 >>> 24] ^ T1[(a0 >> 16) & 0xFF]
> 1156:                     ^ T2[(a1 >> 8) & 0xFF] ^ T3[a2 & 0xFF] ^ K[w + 7];
> 1157:             w += 8;

No need for w, since you already checked the `rounds` value, you can directly reference K inside this block, i.e. K[40] - K[47]. Same goes for the next block for AES-256, i.e. directly reference K[48]-K[55].

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1195:

> 1193:                 ^ T3[(ti0 >> 16) & 0xFF] & 0xFF0000
> 1194:                 ^ T0[(ti1 >> 8) & 0xFF] & 0xFF00
> 1195:                 ^ T1[ti2 & 0xFF] & 0xFF ^ K[w+3];

Here you always use the last 4 elements of `K`, so you can just use `w = K.length - 4` and no need to keep tracking it in the earlier 2 blocks.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1220:

> 1218:      * @param c [in] the ciphertext to be decrypted.
> 1219:      * @param co [in] the ciphertext offset in the array of bytes.
> 1220:      * @param p [out] the decrypted plaintext output.

nit: same comment for removing "decrypted" adj.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437316942
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437308268
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437313179
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437325831

From duke at openjdk.org  Thu Oct 16 20:04:37 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 20:04:37 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 16 Oct 2025 19:55:12 GMT, Valerie Peng  wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1157:
> 
>> 1155:             ti3 = T0[a3 >>> 24] ^ T1[(a0 >> 16) & 0xFF]
>> 1156:                     ^ T2[(a1 >> 8) & 0xFF] ^ T3[a2 & 0xFF] ^ K[w + 7];
>> 1157:             w += 8;
> 
> No need for w, since you already checked the `rounds` value, you can directly reference K inside this block, i.e. K[40] - K[47]. Same goes for the next block for AES-256, i.e. directly reference K[48]-K[55].

I would still need w for lines 1180 - 1195 though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437324027

From duke at openjdk.org  Thu Oct 16 20:22:20 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 20:22:20 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: 
References: 
Message-ID: 

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/9f00c355..a5991a2f

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

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

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

From duke at openjdk.org  Thu Oct 16 20:22:22 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 20:22:22 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 16 Oct 2025 19:58:40 GMT, Valerie Peng  wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1040:
> 
>> 1038:      * @param p [in] the plaintext to be encrypted.
>> 1039:      * @param po [in] the plaintext offset in the array of bytes.
>> 1040:      * @param c [out] the encrypted ciphertext output.
> 
> nit: ciphertext already implied to be encrypted. Maybe no need for the "encrypted" adj.

Agreed.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1195:
> 
>> 1193:                 ^ T3[(ti0 >> 16) & 0xFF] & 0xFF0000
>> 1194:                 ^ T0[(ti1 >> 8) & 0xFF] & 0xFF00
>> 1195:                 ^ T1[ti2 & 0xFF] & 0xFF ^ K[w+3];
> 
> Here you always use the last 4 elements of `K`, so you can just use `w = K.length - 4` and no need to keep tracking it in the earlier 2 blocks.

Agreed.  I've changed decryption as well.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1220:
> 
>> 1218:      * @param c [in] the ciphertext to be decrypted.
>> 1219:      * @param co [in] the ciphertext offset in the array of bytes.
>> 1220:      * @param p [out] the decrypted plaintext output.
> 
> nit: same comment for removing "decrypted" adj.

Agreed.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437361415
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437361126
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437362009

From bpb at openjdk.org  Thu Oct 16 21:38:24 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 16 Oct 2025 21:38:24 GMT
Subject: RFR: 8369997: Tests that use custom scheduler should use
 jdk.test.lib.thread.VThreadScheduler
In-Reply-To: 
References: 
Message-ID: <9HboOfUDk4418ghUH5KuXIqO-uKrhJlWcbJEvPBpdbM=.1a07fe3b-ac3e-44a9-bc76-7a3475a1a159@github.com>

On Thu, 16 Oct 2025 21:31:27 GMT, Brian Burkhalter  wrote:

> Straightforward update of some tests which use core reflection to set the `Thread.Builder` scheduler.

The tests are copied from the [loom repository](https://github.com/openjdk/loom) with only minor cleanup of the import statements in two of the tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/27855#issuecomment-3412939050

From bpb at openjdk.org  Thu Oct 16 21:38:23 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 16 Oct 2025 21:38:23 GMT
Subject: RFR: 8369997: Tests that use custom scheduler should use
 jdk.test.lib.thread.VThreadScheduler
Message-ID: 

Straightforward update of some tests which use core reflection to set the `Thread.Builder` scheduler.

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

Commit messages:
 - 8369997: Tests that use custom scheduler should use jdk.test.lib.thread.VThreadScheduler

Changes: https://git.openjdk.org/jdk/pull/27855/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27855&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369997
  Stats: 69 lines in 3 files changed: 9 ins; 53 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27855.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27855/head:pull/27855

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

From jlu at openjdk.org  Thu Oct 16 21:56:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Oct 2025 21:56:33 GMT
Subject: RFR: 8369590: LocaleEnhanceTest has incorrectly passing test case
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR corrects _test/jdk/java/util/Locale/LocaleEnhanceTest.java_, which has two test cases under `testBuilderSetLanguageTag()` which accidentally pass. One checks that Locale.setLanguageTag(String) throws ILE for duplicate extensions and the other for duplicate U-extension keys. The test cases are updated to actually test the provided code. When the test cases are fixed, they now fail.
> 
> Fixing the behavior to match the expectation of those test cases is consistent with the specification.
> 
> From `Locale.forLanguageTag(String)`,
> 
>> 
>>      * 
    If the specified language tag contains any ill-formed subtags,
>>      * the first such subtag and all following subtags are ignored.  Compare
>>      * to {@link Locale.Builder#setLanguageTag(String)} which throws an exception
>>      * in this case.
> 
> and the RFC specification
> 
>> Each singleton subtag MUST appear at most one time in each tag
>>        (other than as a private use subtag).  That is, singleton subtags
>>        MUST NOT be repeated.  For example, the tag "en-a-bbb-a-ccc" is
>>        invalid because the subtag 'a' appears twice.
> 
> Since duplicate extensions (and Unicode keys/attributes) are invalid, throwing `IllformedLocaleException` in (the strict) `Locale.Builder` and ignoring in (the lenient) `Locale.forLanguageTag` for such tags would be appropriate. This PR updates the implementation as such.

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

  Remove impl changes. Simply update test to reflect duplicate ignoring behavior

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27775/files
  - new: https://git.openjdk.org/jdk/pull/27775/files/b0cfd59b..62c9aa5b

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

  Stats: 78 lines in 4 files changed: 4 ins; 38 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/27775.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27775/head:pull/27775

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

From jlu at openjdk.org  Thu Oct 16 21:56:34 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Oct 2025 21:56:34 GMT
Subject: RFR: 8369590: LocaleEnhanceTest has incorrectly passing test case
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 20:37:16 GMT, Justin Lu  wrote:

>> This PR corrects _test/jdk/java/util/Locale/LocaleEnhanceTest.java_, which has two test cases under `testBuilderSetLanguageTag()` which accidentally pass. One checks that Locale.setLanguageTag(String) throws ILE for duplicate extensions and the other for duplicate U-extension keys. The test cases are updated to actually test the provided code. When the test cases are fixed, they now fail.
>> 
>> Fixing the behavior to match the expectation of those test cases is consistent with the specification.
>> 
>> From `Locale.forLanguageTag(String)`,
>> 
>>> 
>>>      * 
    If the specified language tag contains any ill-formed subtags,
>>>      * the first such subtag and all following subtags are ignored.  Compare
>>>      * to {@link Locale.Builder#setLanguageTag(String)} which throws an exception
>>>      * in this case.
>> 
>> and the RFC specification
>> 
>>> Each singleton subtag MUST appear at most one time in each tag
>>>        (other than as a private use subtag).  That is, singleton subtags
>>>        MUST NOT be repeated.  For example, the tag "en-a-bbb-a-ccc" is
>>>        invalid because the subtag 'a' appears twice.
>> 
>> Since duplicate extensions (and Unicode keys/attributes) are invalid, throwing `IllformedLocaleException` in (the strict) `Locale.Builder` and ignoring in (the lenient) `Locale.forLanguageTag` for such tags would be appropriate. This PR updates the implementation as such.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spacing fix in LocaleEnhanceTest.java
>   
>   Co-authored-by: Andrey Turbanov 

As discussed, while it would be nice to enforce these duplicate cases, we do not guarantee validity of BCP47 tags. (Primarily, checking against the registry.) Duplicates falls under "valid", not "well-formed" and `Locale.Builder` should not have partial conformance of validity. Rather, the faulty test case should be updated to reflect the existing duplicate behavior. Additional tests to affirm existing behavior are added for duplicate U extension attributes as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/27775#issuecomment-3412979930

From naoto at openjdk.org  Thu Oct 16 22:15:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 16 Oct 2025 22:15:04 GMT
Subject: RFR: 8369590: LocaleEnhanceTest has incorrectly passing test case
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 16 Oct 2025 21:56:33 GMT, Justin Lu  wrote:

>> This PR corrects _test/jdk/java/util/Locale/LocaleEnhanceTest.java_, which has two test cases under `testBuilderSetLanguageTag()` which accidentally pass. One checks that Locale.setLanguageTag(String) throws ILE for duplicate extensions and the other for duplicate U-extension keys. The test cases are updated to actually test the provided code. When the test cases are fixed, they now fail.
>> 
>> Fixing the behavior to match the expectation of those test cases is consistent with the specification.
>> 
>> From `Locale.forLanguageTag(String)`,
>> 
>>> 
>>>      * 
    If the specified language tag contains any ill-formed subtags,
>>>      * the first such subtag and all following subtags are ignored.  Compare
>>>      * to {@link Locale.Builder#setLanguageTag(String)} which throws an exception
>>>      * in this case.
>> 
>> and the RFC specification
>> 
>>> Each singleton subtag MUST appear at most one time in each tag
>>>        (other than as a private use subtag).  That is, singleton subtags
>>>        MUST NOT be repeated.  For example, the tag "en-a-bbb-a-ccc" is
>>>        invalid because the subtag 'a' appears twice.
>> 
>> Since duplicate extensions (and Unicode keys/attributes) are invalid, throwing `IllformedLocaleException` in (the strict) `Locale.Builder` and ignoring in (the lenient) `Locale.forLanguageTag` for such tags would be appropriate. This PR updates the implementation as such.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove impl changes. Simply update test to reflect duplicate ignoring behavior

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27775#pullrequestreview-3347175094

From sspitsyn at openjdk.org  Thu Oct 16 23:03:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 23:03:07 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
References: 
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
Message-ID: 

On Thu, 16 Oct 2025 02:09:46 GMT, Leonid Mesnik  wrote:

>> The problemlist entries for incompatible tests are replaced with requires tag.
>> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
>> 
>> Tested by running these tests with virtual test tthread factory.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights updated
>  - more tests removed

The fix looks good in general but I've posted a question.

Marked as reviewed by sspitsyn (Reviewer).

test/jdk/ProblemList-Virtual.txt line 63:

> 61: java/util/Properties/StoreReproducibilityTest.java 0000000 generic-all
> 62: javax/management/ImplementationVersion/ImplVersionTest.java 0000000 generic-all
> 63: javax/management/remote/mandatory/version/ImplVersionTest.java 0000000 generic-all

Q: The following tests removed from this Problem-List do not have the required tweaks:

-java/lang/invoke/condy/CondyNestedResolutionTest.java
-jdk/jfr/startupargs/TestDumpOnExit.java
-java/util/Properties/StoreReproducibilityTest.java
-javax/management/ImplementationVersion/ImplVersionTest.java
-javax/management/remote/mandatory/version/ImplVersionTest.java

Is it intentional? Do I miss anything? Could you, please, explain a little bit?

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

PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3347252960
PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3347261953
PR Review Comment: https://git.openjdk.org/jdk/pull/27834#discussion_r2437646036

From sspitsyn at openjdk.org  Thu Oct 16 23:03:08 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 23:03:08 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: 
References: 
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 
Message-ID: 

On Thu, 16 Oct 2025 22:57:34 GMT, Serguei Spitsyn  wrote:

>> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - copyrights updated
>>  - more tests removed
>
> test/jdk/ProblemList-Virtual.txt line 63:
> 
>> 61: java/util/Properties/StoreReproducibilityTest.java 0000000 generic-all
>> 62: javax/management/ImplementationVersion/ImplVersionTest.java 0000000 generic-all
>> 63: javax/management/remote/mandatory/version/ImplVersionTest.java 0000000 generic-all
> 
> Q: The following tests removed from this Problem-List do not have the required tweaks:
> 
> -java/lang/invoke/condy/CondyNestedResolutionTest.java
> -jdk/jfr/startupargs/TestDumpOnExit.java
> -java/util/Properties/StoreReproducibilityTest.java
> -javax/management/ImplementationVersion/ImplVersionTest.java
> -javax/management/remote/mandatory/version/ImplVersionTest.java
> 
> Is it intentional? Do I miss anything? Could you, please, explain a little bit?

I see you already explained this in the description. Sorry for the noise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27834#discussion_r2437658480

From sspitsyn at openjdk.org  Thu Oct 16 23:27:00 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 23:27:00 GMT
Subject: RFR: 8369997: Tests that use custom scheduler should use
 jdk.test.lib.thread.VThreadScheduler
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 21:31:27 GMT, Brian Burkhalter  wrote:

> Straightforward update of some tests which use core reflection to set the `Thread.Builder` scheduler.

Looks good. Thank you for taking care about it.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27855#pullrequestreview-3347328531

From duke at openjdk.org  Thu Oct 16 23:32:17 2025
From: duke at openjdk.org (Elliot Barlas)
Date: Thu, 16 Oct 2025 23:32:17 GMT
Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 22 Nov 2023 17:10:06 GMT, Joe Wang  wrote:

>> I'm happy with the addition of the JDK built-in catalog, the inclusion of the DTD defined by Java SE, and the docs updates.
>
>> I'm happy with the addition of the JDK built-in catalog, the inclusion of the DTD defined by Java SE, and the docs updates.
> 
> Thanks again, Alan, I really appreciate it! Finally got all pieces together, a nice foundation for the next.

Hi @JoeWang-Java , I believe there is a thread-safety issue with this change.

The change to `XMLEntityManager` introduced a reference to the JDK catalog singleton. Multiple, independent entity managers can, therefore, concurrently access the shared JDK catalog, which is not thread-safe. This can result in invalid data states and unexpected exceptions within the JDK catalog instance.

I sent an email to `core-libs-dev` about this issue yesterday, as well: https://mail.openjdk.org/pipermail/core-libs-dev/2025-October/153319.html

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

PR Comment: https://git.openjdk.org/jdk/pull/16719#issuecomment-3408356230

From swen at openjdk.org  Thu Oct 16 23:45:17 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 16 Oct 2025 23:45:17 GMT
Subject: RFR: 8370013: Refactor Double.toHexString to eliminate regex and
 StringBuilder
Message-ID: 

This PR refactors the Double.toHexString method to improve its performance by eliminating the use of StringBuilder and regex operations. The new implementation uses a direct byte array approach to construct the hex string representation, which avoids the overhead of StringBuilder operations and regex pattern matching.

Existing tests in `java/lang/Double/ToHexString.java` cover the float conversions too.

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

Commit messages:
 - copyright
 - copyright
 - speed up Double.toHexString
 - add toHexString benchmark

Changes: https://git.openjdk.org/jdk/pull/27811/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27811&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370013
  Stats: 91 lines in 2 files changed: 56 ins; 21 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/27811.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27811/head:pull/27811

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

From swen at openjdk.org  Thu Oct 16 23:45:17 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 16 Oct 2025 23:45:17 GMT
Subject: RFR: 8370013: Refactor Double.toHexString to eliminate regex and
 StringBuilder
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Oct 2025 23:26:00 GMT, Shaojin Wen  wrote:

> This PR refactors the Double.toHexString method to improve its performance by eliminating the use of StringBuilder and regex operations. The new implementation uses a direct byte array approach to construct the hex string representation, which avoids the overhead of StringBuilder operations and regex pattern matching.
> 
> Existing tests in `java/lang/Double/ToHexString.java` cover the float conversions too.

The test results run under Mac Book M1 Pro are as follows

# before 3f11c4307ee1ca918926c8c522d2fc496947980e
-Benchmark            Mode  Cnt    Score    Error  Units
-Doubles.toHexString  avgt   15  228.383 ? 17.172  ns/op

# after c18f7632f2f2cf0752b3f4651d4cadf95bb859c6
+Benchmark            Mode  Cnt   Score   Error  Units
+Doubles.toHexString  avgt   15  15.138 ? 1.070  ns/op

More than 10 times performance improvement

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

PR Comment: https://git.openjdk.org/jdk/pull/27811#issuecomment-3404024458

From rgiulietti at openjdk.org  Thu Oct 16 23:45:18 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 16 Oct 2025 23:45:18 GMT
Subject: RFR: 8370013: Refactor Double.toHexString to eliminate regex and
 StringBuilder
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 00:02:58 GMT, Shaojin Wen  wrote:

>> This PR refactors the Double.toHexString method to improve its performance by eliminating the use of StringBuilder and regex operations. The new implementation uses a direct byte array approach to construct the hex string representation, which avoids the overhead of StringBuilder operations and regex pattern matching.
>> 
>> Existing tests in `java/lang/Double/ToHexString.java` cover the float conversions too.
>
> The test results run under Mac Book M1 Pro are as follows
> 
> # before 3f11c4307ee1ca918926c8c522d2fc496947980e
> -Benchmark            Mode  Cnt    Score    Error  Units
> -Doubles.toHexString  avgt   15  228.383 ? 17.172  ns/op
> 
> # after c18f7632f2f2cf0752b3f4651d4cadf95bb859c6
> +Benchmark            Mode  Cnt   Score   Error  Units
> +Doubles.toHexString  avgt   15  15.138 ? 1.070  ns/op
> 
> More than 10 times performance improvement

@wenshao Seems like a nice improvement.
Will have a closer look in the next days.

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

PR Comment: https://git.openjdk.org/jdk/pull/27811#issuecomment-3411442135

From rriggs at openjdk.org  Fri Oct 17 01:32:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Oct 2025 01:32:55 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v16]
In-Reply-To: 
References: 
Message-ID: 

> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
> 
> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
> 
> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.

Roger Riggs 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 24 additional commits since the last revision:

 - Merge branch 'master' into 8364361-process-autocloseable
 - Modify close to waitFor process to exit.
   If the waitFor is interrupted, destroy the process (forcibly).
   Wait indefinately for the process to terminate.
   
   Updated tests with exit status indicating waiting for termination
   due to reduction in racy exits.
 - The ProcessCloseTest is modified to be able to test the logic
   around close() waiting for the process to exit and the specified
   behavior of interrupting the waitFor.
 - Close is modified to wait for the process to terminate before returning.
   Please review the revised javadoc.
   As suggested in review comments, waiting for the process to terminate
   allows a more orderly cleanup by the application.
   The streams are closed and close uses `waitFor()` with an unlimited timeout
   for the process to terminate.
   While waiting the thread can be `interrupted` to exit the `waitFor`.
   If/when `waitFor` is interrupted, the process is destroyedForcibly on
   all platforms. When close() returns, the thread interrupt will pending
   and can be handled by the caller.
   If a watchdog timeout is desired on close(), a separate thread
   can schedule an interrupt at a suitable time after close is called.
 - Review comment improvements to make expected behavior clearer.
 - Merge branch 'master' into 8364361-process-autocloseable
 - Clarify the use of waitFor after close() or T-W-R exit.
 - Additional review feedback.
   Updated to emphasize reading the data from the streams and calling waitFor
   to allow for normal termination.
 - Merge branch 'master' into 8364361-process-autocloseable
 - Address review comments for code and javadoc in Process, the test and the example.
   Reinforced that calling waitFor should occur before calling close to wait for termination and get the exitStatus.
   Corrected the error message check for invalid handles on Windows.
   Update test to allow normal completion when exceptions may be expected.
   Correct the expected message on Windows for an invalid handle exception.
 - ... and 14 more: https://git.openjdk.org/jdk/compare/968f39cf...daefd795

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26649/files
  - new: https://git.openjdk.org/jdk/pull/26649/files/6f8f7327..daefd795

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=14-15

  Stats: 25187 lines in 538 files changed: 16551 ins; 6932 del; 1704 mod
  Patch: https://git.openjdk.org/jdk/pull/26649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26649/head:pull/26649

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

From rriggs at openjdk.org  Fri Oct 17 01:39:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Oct 2025 01:39:06 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v15]
In-Reply-To: 
References: 
 
 <8XswExrj9izeP9hR_qXXu2UKSuecQfLskrrJ4D7fcLg=.e6dfe129-f413-484d-a2aa-993c223b4a9c@github.com>
 
Message-ID: 

On Thu, 16 Oct 2025 09:56:09 GMT, Alan Bateman  wrote:

>> src/java.base/share/classes/java/lang/Process.java line 235:
>> 
>>> 233:                 destroyForcibly();
>>> 234:                 // Re-assert the interrupt
>>> 235:                 Thread.currentThread().interrupt();
>> 
>> I think this is still problematic as code after the t-w-r can't be guaranteed that the child has terminated. So I think it needs a loop that ends when waitFor completes without an exception (destroyForcibly would only be called on the first interrupt of course).
>
>> @AlanBateman can you comment on the possibility of looping indefinitely and not be interruptible if the OS process cannot be destroyed.
> 
> AutoCloseable and Closeable.close are specified to release the resources. If Process.close completes normally (no exception) then users should expect that all resources have been released and the process has terminated.
> 
> In the current proposal, and assuming no interrupt, close waits indefinitely for the process to terminate. If close completes normally then you know the process has terminated. Someone might put code after the t-w-r to delete files or do other cleanup.  It's similar to ExecutorService where close waits for all tasks to complete. So I think this part is okay.
> 
> If interrupted while waiting then close should continue to wait or throw. I think the current proposal, to complete normally but leave the process behind, is problematic and surprising. Having close throw (probably IOException) is a bit problematic too as there isn't much you can do. We regularly see libraries ignoring the IOException thrown by close, including from writable streams where close is screaming that it was unable to flush buffered bytes. So while it wouldn't be terrible to throw, it may be better to keep close simple and be uninterruptible (meaning it would be complete normally when the process terminates and with the interrupt status set). Working through a few use-cases where you might use t-w-r with Process would help to validate the direction

Yes, that works fine as long as the OS can eventually terminate the process.
I was conerned that the OS may not be able to destroy the process without external intervention and the application would look like it is hung in `Process.close()`.  
I've seen a few zombie processes on Linux that `kill -9` can't get rid of. The advice in that case is to manually kill the parent of the hung process so `init` can take over as the parent and reap the process status.
The recent commit implements the loop to wait forever for the process to terminate; that covers the cases that can be setup with testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2437986275

From rriggs at openjdk.org  Fri Oct 17 01:46:48 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Oct 2025 01:46:48 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v17]
In-Reply-To: 
References: 
Message-ID: 

> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
> 
> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
> 
> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.

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

  Incremental update to make it clear that if it is necessary
  to forcibly destroy the process, close continues to wait for the
  process to terminate.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26649/files
  - new: https://git.openjdk.org/jdk/pull/26649/files/daefd795..0e59fe7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=15-16

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

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

From rriggs at openjdk.org  Fri Oct 17 01:48:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Oct 2025 01:48:04 GMT
Subject: RFR: 8370028: Remove author tags from mathematical classes
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 17:22:21 GMT, Joe Darcy  wrote:

> Removing my author tags under `/src` and other authors tags in those files.
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
>  ?? The pull request body must not be empty.
> 
> 
> 
> ### Reviewing
> 
    Using git
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/27852/head:pull/27852` \
> `$ git checkout pull/27852`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/27852` \
> `$ git pull https://git.openjdk.org/jdk.git pull/27852/head`
> 
> 
    
> 
    Using Skara CLI tools
> 
> Checkout this PR locally: \
> `$ git pr checkout 27852`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 27852`
> 
> 
    
> 
    Using diff file
> 
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/27852.diff
> 
> 
    

Looks good.  Author tags don't age well.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27852#pullrequestreview-3347675872

From darcy at openjdk.org  Fri Oct 17 04:45:02 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Oct 2025 04:45:02 GMT
Subject: RFR: 8366478: BigDecimal roots [v4]
In-Reply-To: <4_ZUCTwJrdVM8JpeVpluYHtngQjZ5Bb3h_0ljRTU9w8=.e8e60474-9c15-4af2-909e-080c4e5b9257@github.com>
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 <5P0UWZILeXnLAmlzpbJ6bGIQPEFi-pxKe-yrC13tniI=.9b697af9-13ec-424c-a949-29d07500847b@github.com>
 <4_ZUCTwJrdVM8JpeVpluYHtngQjZ5Bb3h_0ljRTU9w8=.e8e60474-9c15-4af2-909e-080c4e5b9257@github.com>
Message-ID: 

On Thu, 16 Oct 2025 19:34:14 GMT, fabioromano1  wrote:

> Yes, but this is inconsistent with the definition of _preferred scale_ for `BigDecimal.sqrt()`.

Looks like I included a bug with BigDecimals.sqrt with respect to scaling then. While I noted a correct translation of the IEEE 754 requirement in 

https://bugs.openjdk.org/browse/JDK-4851777?focusedId=13847551&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13847551

that did not get carried over to the BigDecimal.sqrt spec or implementation.

I've filed https://bugs.openjdk.org/browse/JDK-8370057; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2438356254

From valeriep at openjdk.org  Fri Oct 17 05:44:04 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 05:44:04 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: 
References: 
 
Message-ID: <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>

On Thu, 16 Oct 2025 20:22:20 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 911:

> 909:             }
> 910:             sessionK[0] = genRoundKeys(key, rounds);
> 911:             sessionK[1] = invGenRoundKeys();

Given the decryption round keys are somewhat based on the encryption round keys, we could combine these two methods into one, e.g.

 private static int[][] genRoundKeys(byte[] key, int rounds) {
        int[][] ks = new int[2][]; // key schedule

        int wLen = (rounds + 1) * WB;
        int nk = key.length / WB;

        // generate the round keys for encryption
        int[] w = new int[wLen];
        for (int i = 0, j = 0; i < nk; i++, j+=4) {
            w[i] = ((key[j] & 0xFF) << 24)
                    | ((key[j + 1] & 0xFF) << 16)
                    | ((key[j + 2] & 0xFF) << 8)
                    | (key[j + 3] & 0xFF);
        }
        for (int i = nk; i < wLen; i++) {
            int tmp = w[i - 1];
            if (i % nk == 0) {
                int rW = (tmp << 8) & 0xFFFFFF00 | (tmp >>> 24);
                tmp = subWord(rW) ^ RCON[(i / nk) - 1];
            } else if ((nk > 6) && ((i % nk) == WB)) {
                tmp = subWord(tmp);
            }
            w[i] = w[i - nk] ^ tmp;
        }
        ks[0] = w;

        // generate the decryption round keys based on encryption ones
        int[] dw = new int[wLen];
        int[] temp = new int[WB];

        // Intrinsics requires the inverse key expansion to be reverse order
        // except for the first and last round key as the first two round keys
        // are without a mix column transform.
        for (int i = 1; i < rounds; i++) {
            System.arraycopy(w, i * WB, temp, 0, WB);
            invMixRKey(temp);
            System.arraycopy(temp, 0, dw, wLen - (i * WB), WB);
        }
        // dw[0...3] <- w[0...3] AND dw[4...7] <- w[(wLen - 4)...(wLen -1)]
        System.arraycopy(w, 0, dw, 0, WB);
        System.arraycopy(w, wLen - WB, dw, WB, WB);
        ks[1] = dw;
        Arrays.fill(temp, 0);

        return ks;
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438441223

From alanb at openjdk.org  Fri Oct 17 06:07:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Oct 2025 06:07:01 GMT
Subject: RFR: 8369997: Tests that use custom scheduler should use
 jdk.test.lib.thread.VThreadScheduler
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 21:31:27 GMT, Brian Burkhalter  wrote:

> Straightforward update of some tests which use core reflection to set the `Thread.Builder` scheduler.

Thanks for doing this, these test changes have been sitting in the loom repo for a long time.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27855#pullrequestreview-3348423461

From valeriep at openjdk.org  Fri Oct 17 06:17:06 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 06:17:06 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 16 Oct 2025 20:22:20 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 958:

> 956:      * @return the processed round key row.
> 957:      */
> 958:     private static int invMix(int[] state, int idx) {

It seems that we can just use an `int` argument and make the callers do the array dereferencing. This way we can get rid of the temporary buffer inside `invMixRKey(int[])` as passing an integer to `invMix(int)` method will not affect the array, e.g.

    private static void invMixRKey(int[] state) {
        state[0] = invMix(state[0]);
        state[1] = invMix(state[1]);
        state[2] = invMix(state[2]);
        state[3] = invMix(state[3]);
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438501716

From valeriep at openjdk.org  Fri Oct 17 06:30:02 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 06:30:02 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: 
References: 
 
Message-ID: <56BA-l6ZrdSY0IRWxXme_AM_CWW_vtBSrzYqIA4oZaE=.b9011356-c376-455a-8964-4534f9db6035@github.com>

On Thu, 16 Oct 2025 20:22:20 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 976:

> 974:      * @param state [in, out] the round key for inverse mix column processing.
> 975:      */
> 976:     private static void invMixRKey(int[] state) {

nit: name the method "invMixColumns(int[])". This name matches the spec psuedo code and goes better with the "state" argument name. Or use "invMixRoundKey(int[] roundKey)"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438537870

From dholmes at openjdk.org  Fri Oct 17 06:53:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Oct 2025 06:53:20 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 16 Oct 2025 16:13:42 GMT, Patricio Chilano Mateo  wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix verify_frame_kind

Great piece of work @pchilano ! I've taken an initial pass through the main class/thread/objectMonitor pieces.

src/hotspot/share/interpreter/linkResolver.cpp line 1122:

> 1120:       resolved_klass->initialize(CHECK);
> 1121:     } else if (static_mode == StaticMode::initialize_klass_preemptable) {
> 1122:       resolved_klass->initialize_preemptable(CHECK);

Why is this not CHECK_AND_CLEAR_PREEMPTED?

src/hotspot/share/interpreter/linkResolver.hpp line 192:

> 190: };
> 191: 
> 192: enum class StaticMode : uint8_t {

Need to think of a better name for this ... `ClassInitMode`?

src/hotspot/share/interpreter/linkResolver.hpp line 195:

> 193:   dont_initialize_klass,
> 194:   initialize_klass,
> 195:   initialize_klass_preemptable

And maybe more concisely:
Suggestion:

  dont_init
  init
  init_preemptable

?

src/hotspot/share/oops/instanceKlass.cpp line 1284:

> 1282:   // Block preemption once we are the initializer thread. Unmounting now
> 1283:   // would complicate the reentrant case (identity is platform thread).
> 1284:   NoPreemptMark npm(THREAD);

How does this affect unrelated "preemption" that may occur in the Java code called as part of ``?

src/hotspot/share/oops/klass.hpp line 583:

> 581:   // initializes the klass
> 582:   virtual void initialize(TRAPS);
> 583:   virtual void initialize_preemptable(TRAPS);

Can we not define these on `instanceKlass` instead of `klass`? Seems really odd to declare virtual methods for which the base class version should never be called (they should be pure virtuals in that case I would think?).

src/hotspot/share/runtime/continuationEntry.cpp line 117:

> 115:   assert(thread->has_last_Java_frame(), "Wrong place to use this assertion");
> 116: 
> 117:   if (preempted) return true;

I don't see the point of adding a new parameter just so the method can check it and return immediately. Shouldn't the caller be checking this?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 196:

> 194: static void do_deopt_after_thaw(JavaThread* thread);
> 195: static bool do_verify_after_thaw(JavaThread* thread, stackChunkOop chunk, outputStream* st);
> 196: static void log_frames(JavaThread* thread, bool dolog = true);

Suggestion:

static void log_frames(JavaThread* thread, bool do_log = true);

src/hotspot/share/runtime/javaThread.hpp line 492:

> 490:   // throw IE at the end of thawing before returning to Java.
> 491:   bool _pending_interrupted_exception;
> 492:   // We allow preemption on some klass initializion calls.

Suggestion:

  // We allow preemption on some klass initialization calls.

src/hotspot/share/runtime/javaThread.hpp line 507:

> 505: 
> 506:   bool at_preemptable_init() { return _at_preemptable_init; }
> 507:   void set_at_preemptable_init(bool b) { _at_preemptable_init = b; }

If you are going align 503 and 504 then you may as well align these two lines as well

src/hotspot/share/runtime/javaThread.hpp line 522:

> 520:     JavaThread* _thread;
> 521:    public:
> 522:     AtRedoVMCall(JavaThread *t) : _thread(t) {

Suggestion:

    AtRedoVMCall(JavaThread* t) : _thread(t) {

src/hotspot/share/runtime/javaThread.hpp line 524:

> 522:     AtRedoVMCall(JavaThread *t) : _thread(t) {
> 523:       _thread->_interp_at_preemptable_vmcall_cnt++;
> 524:       assert(_thread->_interp_at_preemptable_vmcall_cnt > 0, "");

Suggestion:

      assert(_thread->_interp_at_preemptable_vmcall_cnt > 0, "Unexpected count: %d", _thread->_interp_at_preemptable_vmcall_cnt);

src/hotspot/share/runtime/javaThread.hpp line 528:

> 526:     ~AtRedoVMCall() {
> 527:       _thread->_interp_at_preemptable_vmcall_cnt--;
> 528:       assert(_thread->_interp_at_preemptable_vmcall_cnt >= 0, "");

Suggestion:

    assert(_thread->_interp_at_preemptable_vmcall_cnt > 0, "Unexpected count: %d", _thread->_interp_at_preemptable_vmcall_cnt);

src/hotspot/share/runtime/objectMonitor.cpp line 315:

> 313: }
> 314: 
> 315: // Keep object protected during ObjectLocker preemption.

I don't understand why this is necessary.

src/hotspot/share/runtime/synchronizer.cpp line 489:

> 487:     if (_thread->preempting()) {
> 488:       // If preemption was cancelled we acquired the monitor after freezing
> 489:       // the frames. Redoing the vm call later?in thaw will require us to

I don't quite follow the control flow here - at what point have we frozen any frames? Was that deep inside `enter`?

src/hotspot/share/runtime/synchronizer.hpp line 230:

> 228:   bool    _skip_exit;
> 229:  public:
> 230:   ObjectLocker(Handle obj, TRAPS);

I wonder if we should declare `PREEMPTABLE_TRAPS` as an indicator that the only exception expected to come out of a call is the preempted-exception?

src/java.base/share/classes/java/lang/VirtualThread.java line 172:

> 170: 
> 171:     // true when waiting in Object.wait, false for VM internal uninterruptible Object.wait
> 172:     private volatile boolean interruptableWait;

Suggestion:

    private volatile boolean interruptibleWait;

src/java.base/share/classes/java/lang/VirtualThread.java line 605:

> 603:         if (s == WAITING || s == TIMED_WAITING) {
> 604:             int newState;
> 605:             boolean interruptable = interruptableWait;

Suggestion:

            boolean interruptible = interruptibleWait;

src/java.base/share/classes/jdk/internal/vm/PreemptedException.java line 31:

> 29:  * Internal exception used only by the VM.
> 30:  */
> 31: public class PreemptedException extends Exception {

Should probably extend `RuntimeException` so that it is not considered a checked-exception

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

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3348320781
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438580798
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438444689
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438447733
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438469910
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438473899
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438480176
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438482435
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438506706
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438516134
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438518828
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438523339
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438524180
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438533049
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438542039
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438549455
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438568359
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438568876
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438571309

From duke at openjdk.org  Fri Oct 17 06:56:43 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 06:56:43 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v9]
In-Reply-To: 
References: 
Message-ID: 

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/a5991a2f..2ce35b97

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

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

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

From duke at openjdk.org  Fri Oct 17 06:56:46 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 06:56:46 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
References: 
 
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
Message-ID: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>

On Fri, 17 Oct 2025 05:41:25 GMT, Valerie Peng  wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 911:
> 
>> 909:             }
>> 910:             sessionK[0] = genRoundKeys(key, rounds);
>> 911:             sessionK[1] = invGenRoundKeys();
> 
> Given the decryption round keys are somewhat based on the encryption round keys, we could combine these two methods into one, e.g.
> 
>  private static int[][] genRoundKeys(byte[] key, int rounds) {
>         int[][] ks = new int[2][]; // key schedule
> 
>         int wLen = (rounds + 1) * WB;
>         int nk = key.length / WB;
> 
>         // generate the round keys for encryption
>         int[] w = new int[wLen];
>         for (int i = 0, j = 0; i < nk; i++, j+=4) {
>             w[i] = ((key[j] & 0xFF) << 24)
>                     | ((key[j + 1] & 0xFF) << 16)
>                     | ((key[j + 2] & 0xFF) << 8)
>                     | (key[j + 3] & 0xFF);
>         }
>         for (int i = nk; i < wLen; i++) {
>             int tmp = w[i - 1];
>             if (i % nk == 0) {
>                 int rW = (tmp << 8) & 0xFFFFFF00 | (tmp >>> 24);
>                 tmp = subWord(rW) ^ RCON[(i / nk) - 1];
>             } else if ((nk > 6) && ((i % nk) == WB)) {
>                 tmp = subWord(tmp);
>             }
>             w[i] = w[i - nk] ^ tmp;
>         }
>         ks[0] = w;
> 
>         // generate the decryption round keys based on encryption ones
>         int[] dw = new int[wLen];
>         int[] temp = new int[WB];
> 
>         // Intrinsics requires the inverse key expansion to be reverse order
>         // except for the first and last round key as the first two round keys
>         // are without a mix column transform.
>         for (int i = 1; i < rounds; i++) {
>             System.arraycopy(w, i * WB, temp, 0, WB);
>             invMixRKey(temp);
>             System.arraycopy(temp, 0, dw, wLen - (i * WB), WB);
>         }
>         // dw[0...3] <- w[0...3] AND dw[4...7] <- w[(wLen - 4)...(wLen -1)]
>         System.arraycopy(w, 0, dw, 0, WB);
>         System.arraycopy(w, wLen - WB, dw, WB, WB);
>         ks[1] = dw;
>         Arrays.fill(temp, 0);
> 
>         return ks;
>     }

These two methods were only the few that I was able to make that were compact and singular in purpose (gen round key, gen inverse round key) code as the coding style guidelines espouse.  The rest of the methods' construction were dictated by performance improvements, where compactness came at the cost of interpreter speed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 958:
> 
>> 956:      * @return the processed round key row.
>> 957:      */
>> 958:     private static int invMix(int[] state, int idx) {
> 
> It seems that we can just use an `int` argument and make the callers do the array dereferencing. This way we can get rid of the temporary buffer inside `invMixRKey(int[])` as passing an integer to `invMix(int)` method will not affect the array, e.g.
> 
>     private static void invMixRKey(int[] state) {
>         state[0] = invMix(state[0]);
>         state[1] = invMix(state[1]);
>         state[2] = invMix(state[2]);
>         state[3] = invMix(state[3]);
>     }

I've removed this method and inlined this logic in the invGenRoundKeys method.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 976:
> 
>> 974:      * @param state [in, out] the round key for inverse mix column processing.
>> 975:      */
>> 976:     private static void invMixRKey(int[] state) {
> 
> nit: name the method "invMixColumns(int[])". This name matches the spec psuedo code and goes better with the "state" argument name. Or use "invMixRoundKey(int[] roundKey)"?

I've removed this method and inlined this logic in the invGenRoundKeys method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438587221
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438587085
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438586207

From valeriep at openjdk.org  Fri Oct 17 07:07:11 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 07:07:11 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
References: 
 
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
Message-ID: <3IhmbTDiDNPdMTe_K1OZx6sC67UGjObzOXwX8Ekp7pA=.0e742e44-4dba-4680-8f24-7321f8516071@github.com>

On Fri, 17 Oct 2025 06:52:39 GMT, Shawn M Emery  wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 958:
>> 
>>> 956:      * @return the processed round key row.
>>> 957:      */
>>> 958:     private static int invMix(int[] state, int idx) {
>> 
>> It seems that we can just use an `int` argument and make the callers do the array dereferencing. This way we can get rid of the temporary buffer inside `invMixRKey(int[])` as passing an integer to `invMix(int)` method will not affect the array, e.g.
>> 
>>     private static void invMixRKey(int[] state) {
>>         state[0] = invMix(state[0]);
>>         state[1] = invMix(state[1]);
>>         state[2] = invMix(state[2]);
>>         state[3] = invMix(state[3]);
>>     }
>
> I've removed this method and inlined this logic in the invGenRoundKeys method.

Sure, this works as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438612714

From duke at openjdk.org  Fri Oct 17 08:14:05 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 17 Oct 2025 08:14:05 GMT
Subject: RFR: 8366478: BigDecimal roots [v4]
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 <5P0UWZILeXnLAmlzpbJ6bGIQPEFi-pxKe-yrC13tniI=.9b697af9-13ec-424c-a949-29d07500847b@github.com>
 <4_ZUCTwJrdVM8JpeVpluYHtngQjZ5Bb3h_0ljRTU9w8=.e8e60474-9c15-4af2-909e-080c4e5b9257@github.com>
 
Message-ID: <48zm4PDa6JiRXWtstE5CNiO5_RkJrILld65oOSpuXiI=.d483b500-01d8-4bdb-8000-6ab1b537c231@github.com>

On Fri, 17 Oct 2025 04:41:54 GMT, Joe Darcy  wrote:

>> Yes, but this is inconsistent with the definition of _preferred scale_ for `BigDecimal.sqrt()`.
>
>> Yes, but this is inconsistent with the definition of _preferred scale_ for `BigDecimal.sqrt()`.
> 
> Looks like I included a bug with BigDecimals.sqrt with respect to scaling then. While I noted a correct translation of the IEEE 754 requirement in 
> 
> https://bugs.openjdk.org/browse/JDK-4851777?focusedId=13847551&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13847551
> 
> that did not get carried over to the BigDecimal.sqrt spec or implementation.
> 
> I've filed https://bugs.openjdk.org/browse/JDK-8370057; thanks.

@jddarcy @rgiulietti Since `Bigecimal.nthRoot()` will affect the implementation of `BigDecimal.sqrt()`, should the bug be resolved in this PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2438784970

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 rgiulietti at openjdk.org  Fri Oct 17 11:28:04 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 17 Oct 2025 11:28:04 GMT
Subject: RFR: 8366478: BigDecimal roots [v4]
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 <5P0UWZILeXnLAmlzpbJ6bGIQPEFi-pxKe-yrC13tniI=.9b697af9-13ec-424c-a949-29d07500847b@github.com>
 <4_ZUCTwJrdVM8JpeVpluYHtngQjZ5Bb3h_0ljRTU9w8=.e8e60474-9c15-4af2-909e-080c4e5b9257@github.com>
 
Message-ID: 

On Fri, 17 Oct 2025 04:41:54 GMT, Joe Darcy  wrote:

>> Yes, but this is inconsistent with the definition of _preferred scale_ for `BigDecimal.sqrt()`.
>
>> Yes, but this is inconsistent with the definition of _preferred scale_ for `BigDecimal.sqrt()`.
> 
> Looks like I included a bug with BigDecimals.sqrt with respect to scaling then. While I noted a correct translation of the IEEE 754 requirement in 
> 
> https://bugs.openjdk.org/browse/JDK-4851777?focusedId=13847551&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13847551
> 
> that did not get carried over to the BigDecimal.sqrt spec or implementation.
> 
> I've filed https://bugs.openjdk.org/browse/JDK-8370057; thanks.

I leave that decision to @jddarcy.
But for consistency with IEEE 754, we should use `ceilDiv(this.scale(), n)` even for `n = 2`.

@fabioromano1 I guess that implementation-wise it would be an easy change?

Also, should we perhaps rename the method to `rootn()`, as in IEEE 754? We still have time before RDP 1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2439454149

From rgiulietti at openjdk.org  Fri Oct 17 11:28:05 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 17 Oct 2025 11:28:05 GMT
Subject: RFR: 8366478: BigDecimal roots [v4]
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 <5P0UWZILeXnLAmlzpbJ6bGIQPEFi-pxKe-yrC13tniI=.9b697af9-13ec-424c-a949-29d07500847b@github.com>
 <4_ZUCTwJrdVM8JpeVpluYHtngQjZ5Bb3h_0ljRTU9w8=.e8e60474-9c15-4af2-909e-080c4e5b9257@github.com>
 
 
Message-ID: 

On Fri, 17 Oct 2025 11:23:58 GMT, Raffaello Giulietti  wrote:

>>> Yes, but this is inconsistent with the definition of _preferred scale_ for `BigDecimal.sqrt()`.
>> 
>> Looks like I included a bug with BigDecimals.sqrt with respect to scaling then. While I noted a correct translation of the IEEE 754 requirement in 
>> 
>> https://bugs.openjdk.org/browse/JDK-4851777?focusedId=13847551&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13847551
>> 
>> that did not get carried over to the BigDecimal.sqrt spec or implementation.
>> 
>> I've filed https://bugs.openjdk.org/browse/JDK-8370057; thanks.
>
> I leave that decision to @jddarcy.
> But for consistency with IEEE 754, we should use `ceilDiv(this.scale(), n)` even for `n = 2`.
> 
> @fabioromano1 I guess that implementation-wise it would be an easy change?
> 
> Also, should we perhaps rename the method to `rootn()`, as in IEEE 754? We still have time before RDP 1.

... renaming both in `BigInteger` and `BigDecimal`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2439459568

From alanb at openjdk.org  Fri Oct 17 11:31:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Oct 2025 11:31:06 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v15]
In-Reply-To: 
References: 
 
 <8XswExrj9izeP9hR_qXXu2UKSuecQfLskrrJ4D7fcLg=.e6dfe129-f413-484d-a2aa-993c223b4a9c@github.com>
 
 
Message-ID: 

On Fri, 17 Oct 2025 01:36:49 GMT, Roger Riggs  wrote:

>>> @AlanBateman can you comment on the possibility of looping indefinitely and not be interruptible if the OS process cannot be destroyed.
>> 
>> AutoCloseable and Closeable.close are specified to release the resources. If Process.close completes normally (no exception) then users should expect that all resources have been released and the process has terminated.
>> 
>> In the current proposal, and assuming no interrupt, close waits indefinitely for the process to terminate. If close completes normally then you know the process has terminated. Someone might put code after the t-w-r to delete files or do other cleanup.  It's similar to ExecutorService where close waits for all tasks to complete. So I think this part is okay.
>> 
>> If interrupted while waiting then close should continue to wait or throw. I think the current proposal, to complete normally but leave the process behind, is problematic and surprising. Having close throw (probably IOException) is a bit problematic too as there isn't much you can do. We regularly see libraries ignoring the IOException thrown by close, including from writable streams where close is screaming that it was unable to flush buffered bytes. So while it wouldn't be terrible to throw, it may be better to keep close simple and be uninterruptible (meaning it would be complete normally when the process terminates and with the interrupt status set). Working through a few use-cases where you might use t-w-r with Process would help to validate the direction
>
> Yes, that works fine as long as the OS can eventually terminate the process.
> I was conerned that the OS may not be able to destroy the process without external intervention and the application would look like it is hung in `Process.close()`.  
> I've seen a few zombie processes on Linux that `kill -9` can't get rid of. The advice in that case is to manually kill the parent of the hung process so `init` can take over as the parent and reap the process status.
> The recent commit implements the loop to wait forever for the process to terminate; that covers the cases that can be setup with testing.

Thanks for the update. I have sympathy for zombie scenario but it would be too surprising for close to completely normally in that case. So I think the updated proposal looks reasonable and we should see what we can do to improve diagnosability when blocked indefinitely in close.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2439476760

From rgiulietti at openjdk.org  Fri Oct 17 11:34:22 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 17 Oct 2025 11:34:22 GMT
Subject: RFR: 8366478: BigDecimal roots [v4]
In-Reply-To: <4_ZUCTwJrdVM8JpeVpluYHtngQjZ5Bb3h_0ljRTU9w8=.e8e60474-9c15-4af2-909e-080c4e5b9257@github.com>
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 <5P0UWZILeXnLAmlzpbJ6bGIQPEFi-pxKe-yrC13tniI=.9b697af9-13ec-424c-a949-29d07500847b@github.com>
 <4_ZUCTwJrdVM8JpeVpluYHtngQjZ5Bb3h_0ljRTU9w8=.e8e60474-9c15-4af2-909e-080c4e5b9257@github.com>
Message-ID: 

On Thu, 16 Oct 2025 19:36:46 GMT, fabioromano1  wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 2181:
>> 
>>> 2179:      * @param mc the context to use.
>>> 2180:      * @return the {@code n}th root of {@code this}.
>>> 2181:      * @throws ArithmeticException if {@code n == 0 || n == Integer.MIN_VALUE}.
>> 
>> Just out of curiosity, is there a technical reason for the restriction on MIN_VALUE?
>
> Yes, `|Integer.MIN_VALUE|` is out of range of `int`s, so it cannot be used as a degree for `BigInteger.nthRoot(int)`.

I'm not sure I get your point: how come is`MIN_VALUE` out of `int` range?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2439488233

From alanb at openjdk.org  Fri Oct 17 11:35:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Oct 2025 11:35:11 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v17]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 17 Oct 2025 01:46:48 GMT, Roger Riggs  wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incremental update to make it clear that if it is necessary
>   to forcibly destroy the process, close continues to wait for the
>   process to terminate.

src/java.base/share/classes/java/lang/Process.java line 180:

> 178: 
> 179:     /**
> 180:      * Close all writer and reader streams immediately and wait for the process to terminate.

It might read a bit better to say "reader and write streams" and drop the word immediately.

src/java.base/share/classes/java/lang/Process.java line 194:

> 192:      * Closing an already closed stream usually has no effect but is specific to the stream.
> 193:      * If an {@code IOException} occurs when closing a stream it is thrown
> 194:      * when this method returns. Additional {@code IOExceptions}

What would you think of replacing "when this method returns" with "after the process has terminated"?

src/java.base/share/classes/java/lang/Process.java line 201:

> 199:      * process to terminate. If interrupted while {@linkplain #waitFor waiting for termination}
> 200:      * the process is {@linkplain #destroyForcibly() forcibly destroyed} and continues to wait
> 201:      * for the process to terminate.

"and continues to wait" would be clearer if expanded to "and this method continues to wait ..."

src/java.base/share/classes/java/lang/Process.java line 247:

> 245: 
> 246:     // Wait for the process to terminate, return true if the wait is interrupted.
> 247:     private boolean waitForInterrupted() {

tryWait that returns true when wait completes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2439481775
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2439484992
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2439489107
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2439493529

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 duke at openjdk.org  Fri Oct 17 11:56:06 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 17 Oct 2025 11:56:06 GMT
Subject: RFR: 8366478: BigDecimal roots [v4]
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 <5P0UWZILeXnLAmlzpbJ6bGIQPEFi-pxKe-yrC13tniI=.9b697af9-13ec-424c-a949-29d07500847b@github.com>
 <4_ZUCTwJrdVM8JpeVpluYHtngQjZ5Bb3h_0ljRTU9w8=.e8e60474-9c15-4af2-909e-080c4e5b9257@github.com>
 
Message-ID: 

On Fri, 17 Oct 2025 11:31:16 GMT, Raffaello Giulietti  wrote:

> I'm not sure I get your point: how come is`MIN_VALUE` out of `int` range?

`|Integer.MIN_VALUE|` is the absolute value of `Integer.MIN_VALUE`, so `Math.absExact(Integer.MIN_VALUE)` throws an `ArithmeticException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2439592350

From duke at openjdk.org  Fri Oct 17 11:59:03 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 17 Oct 2025 11:59:03 GMT
Subject: RFR: 8366478: BigDecimal roots [v4]
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 <5P0UWZILeXnLAmlzpbJ6bGIQPEFi-pxKe-yrC13tniI=.9b697af9-13ec-424c-a949-29d07500847b@github.com>
 <4_ZUCTwJrdVM8JpeVpluYHtngQjZ5Bb3h_0ljRTU9w8=.e8e60474-9c15-4af2-909e-080c4e5b9257@github.com>
 
Message-ID: 

On Fri, 17 Oct 2025 04:41:54 GMT, Joe Darcy  wrote:

>> Yes, but this is inconsistent with the definition of _preferred scale_ for `BigDecimal.sqrt()`.
>
>> Yes, but this is inconsistent with the definition of _preferred scale_ for `BigDecimal.sqrt()`.
> 
> Looks like I included a bug with BigDecimals.sqrt with respect to scaling then. While I noted a correct translation of the IEEE 754 requirement in 
> 
> https://bugs.openjdk.org/browse/JDK-4851777?focusedId=13847551&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13847551
> 
> that did not get carried over to the BigDecimal.sqrt spec or implementation.
> 
> I've filed https://bugs.openjdk.org/browse/JDK-8370057; thanks.

> I leave that decision to @jddarcy. But for consistency with IEEE 754, we should use `ceilDiv(this.scale(), n)` even for `n = 2`.
> 
> @fabioromano1 I guess that implementation-wise it would be an easy change?

Yes, it is simply `Math.ceilDiv(this.scale, n)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2439608610

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 epeter at openjdk.org  Fri Oct 17 13:02:04 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 17 Oct 2025 13:02:04 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 17 Oct 2025 06:56:43 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 44:

> 42: 
> 43:     @Param("10000000")
> 44:     private int count;

Drive-by comment / question:
Did you do all benchmarking with this single (quite large) size? How are the results for much smaller sizes? It may be worth it to just get a nice plot that goes over a range of sizes, to see if it behaves as expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2439948821

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 dfuchs at openjdk.org  Fri Oct 17 14:20:07 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 17 Oct 2025 14:20:07 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v5]
In-Reply-To: 
References: 
 
Message-ID: <-MxJhdamHj4NGqunHTNpIhyrbFSHx3wzuxL_EhH8ErM=.48bc2423-5517-47b1-b1ec-a51e13ab5fd0@github.com>

On Wed, 15 Oct 2025 17:34:55 GMT, Weibing Xiao  wrote:

>> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
>> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
>> 
>> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
>> 
>> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
>> 
>> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.
>
> Weibing Xiao 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 26 additional commits since the last revision:
> 
>  - update the code
>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8362268
>  - Merge branch 'master' into JDK-8362268
>  - Merge branch 'master' of github.com:weibxiao/jdk
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'master' of github.com:openjdk/jdk
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'master' of github.com:openjdk/jdk
>  - Merge branch 'master' of github.com:openjdk/jdk
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/614738ee...4dd20668

I am not quite sure I understand how this fix works. If all tests are passing then it may be OK. I hope it isn't going to re-introduce a resource leak though. Synchronization/locking must be fixed however, and I have suggseted some changes below that will ensure it integrates correctly with the locking strategy in the Connection class.

It would be good to get @AlekseiEfimov review.

src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java line 464:

> 462:                     // Not being pooled; continue with closing
> 463:                     conn.cleanup(reqCtls, false);
> 464:                     closeOpenedResource();

Please replace these two lines with:

`conn.cleanupAndClose(reqCtls);`

Then add a method in Connection:


    void cleanupAndClose(Control[] reqCtls) {
        lock.lock();
        try {

            cleanup(reqCtls, false);

            // 8313657 socket is not closed until GC is run
            // it caused the bug 8362268, hence moved here

            if (outStream != null) {
                outStream.close();
            }

            if (!sock.isClosed()) {
                sock.close();
            }
        } catch (IOException ignored) {
            // we're closing, ignore IO.
        } finally {
            lock.unlock();
        }
    }

src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java line 497:

> 495:         } catch (IOException ioEx) {
> 496:             //ignore the error;
> 497:         }

Please revert this change. Use conn.cleanupAnadClose(...) instead.

src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java line 512:

> 510:         }
> 511:         conn.cleanup(null, false);
> 512:         closeOpenedResource();

same here. replace these two lines with:

`conn.cleanupAndClose(null);`

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

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26566#pullrequestreview-3350556027
PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2440169793
PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2440180557
PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2440177815

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 rriggs at openjdk.org  Fri Oct 17 14:39:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Oct 2025 14:39:50 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v18]
In-Reply-To: 
References: 
Message-ID: 

> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
> 
> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
> 
> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.

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

  Adopt review suggestions for javadoc wording.
  Refactor the utility method to wait for the process, return true on termination, false on interrupt.
  Various updates to the test related to logging of output when a test fails.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26649/files
  - new: https://git.openjdk.org/jdk/pull/26649/files/0e59fe7d..f65dcf65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=16-17

  Stats: 102 lines in 2 files changed: 43 ins; 25 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/26649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26649/head:pull/26649

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

From rriggs at openjdk.org  Fri Oct 17 14:39:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Oct 2025 14:39:51 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v17]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 17 Oct 2025 11:32:22 GMT, Alan Bateman  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Incremental update to make it clear that if it is necessary
>>   to forcibly destroy the process, close continues to wait for the
>>   process to terminate.
>
> src/java.base/share/classes/java/lang/Process.java line 247:
> 
>> 245: 
>> 246:     // Wait for the process to terminate, return true if the wait is interrupted.
>> 247:     private boolean waitForInterrupted() {
> 
> tryWait that returns true when wait completes?

ok, (But the code flow is only interested in the failure case not the success of wait)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2440240876

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 bpb at openjdk.org  Fri Oct 17 15:15:22 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Oct 2025 15:15:22 GMT
Subject: Integrated: 8369997: Tests that use custom scheduler should use
 jdk.test.lib.thread.VThreadScheduler
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 21:31:27 GMT, Brian Burkhalter  wrote:

> Straightforward update of some tests which use core reflection to set the `Thread.Builder` scheduler.

This pull request has now been integrated.

Changeset: cc6f8f13
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/cc6f8f1307476886aa3c43a2b966fc7bff2be04e
Stats:     69 lines in 3 files changed: 9 ins; 53 del; 7 mod

8369997: Tests that use custom scheduler should use jdk.test.lib.thread.VThreadScheduler

Reviewed-by: sspitsyn, alanb

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

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

From lmesnik at openjdk.org  Fri Oct 17 16:06:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Oct 2025 16:06:43 GMT
Subject: Integrated: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 01:55:09 GMT, Leonid Mesnik  wrote:

> The problemlist entries for incompatible tests are replaced with requires tag.
> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
> 
> Tested by running these tests with virtual test tthread factory.

This pull request has now been integrated.

Changeset: 28bf9176
Author:    Leonid Mesnik 
URL:       https://git.openjdk.org/jdk/commit/28bf9176b8d460242bb7cedfb3bde5c6294c56fb
Stats:     70 lines in 18 files changed: 17 ins; 38 del; 15 mod

8348844: Remove remaining JVMTI tests from ProblemList-Virtual, use requires instead

Reviewed-by: dholmes, alanb, syan, sspitsyn

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

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

From jlu at openjdk.org  Fri Oct 17 16:22:20 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Oct 2025 16:22:20 GMT
Subject: Integrated: 8369590: LocaleEnhanceTest has incorrectly passing test
 case
In-Reply-To: 
References: 
Message-ID: 

On Mon, 13 Oct 2025 20:55:45 GMT, Justin Lu  wrote:

> This PR corrects _test/jdk/java/util/Locale/LocaleEnhanceTest.java_, which has two test cases under `testBuilderSetLanguageTag()` which accidentally pass. One checks that Locale.setLanguageTag(String) throws ILE for duplicate extensions and the other for duplicate U-extension keys. The test cases are updated to actually test the provided code. When the test cases are fixed, they now fail. They should instead be updated to check that the duplicates are ignored.

This pull request has now been integrated.

Changeset: 1e5e17a1
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/1e5e17a10a001c189f6ab19f61efca2d08cb0301
Stats:     654 lines in 1 file changed: 56 ins; 169 del; 429 mod

8369590: LocaleEnhanceTest has incorrectly passing test case

Reviewed-by: naoto

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

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

From darcy at openjdk.org  Fri Oct 17 16:26:58 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Oct 2025 16:26:58 GMT
Subject: RFR: 8366478: BigDecimal roots [v4]
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 <5P0UWZILeXnLAmlzpbJ6bGIQPEFi-pxKe-yrC13tniI=.9b697af9-13ec-424c-a949-29d07500847b@github.com>
 <4_ZUCTwJrdVM8JpeVpluYHtngQjZ5Bb3h_0ljRTU9w8=.e8e60474-9c15-4af2-909e-080c4e5b9257@github.com>
 
Message-ID: 

On Fri, 17 Oct 2025 04:41:54 GMT, Joe Darcy  wrote:

>> Yes, but this is inconsistent with the definition of _preferred scale_ for `BigDecimal.sqrt()`.
>
>> Yes, but this is inconsistent with the definition of _preferred scale_ for `BigDecimal.sqrt()`.
> 
> Looks like I included a bug with BigDecimals.sqrt with respect to scaling then. While I noted a correct translation of the IEEE 754 requirement in 
> 
> https://bugs.openjdk.org/browse/JDK-4851777?focusedId=13847551&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13847551
> 
> that did not get carried over to the BigDecimal.sqrt spec or implementation.
> 
> I've filed https://bugs.openjdk.org/browse/JDK-8370057; thanks.

> I leave that decision to @jddarcy. But for consistency with IEEE 754, we should use `ceilDiv(this.scale(), n)` even for `n = 2`.
> 
> @fabioromano1 I guess that implementation-wise it would be an easy change?
> 
> Also, should we perhaps rename the method to `rootn()`, as in IEEE 754? We still have time before RDP 1.

The BigDecimal.sqrt scale bug should be resolved in its own issue; it will require a CSR for compatibility analysis.

The IEEE 754 terminology is guidance, but not one we strictly have to follow if we have cause not to.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2440529185

From rgiulietti at openjdk.org  Fri Oct 17 16:26:58 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 17 Oct 2025 16:26:58 GMT
Subject: RFR: 8366478: BigDecimal roots [v4]
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 <5P0UWZILeXnLAmlzpbJ6bGIQPEFi-pxKe-yrC13tniI=.9b697af9-13ec-424c-a949-29d07500847b@github.com>
 <4_ZUCTwJrdVM8JpeVpluYHtngQjZ5Bb3h_0ljRTU9w8=.e8e60474-9c15-4af2-909e-080c4e5b9257@github.com>
 
 
Message-ID: 

On Fri, 17 Oct 2025 16:21:03 GMT, Joe Darcy  wrote:

>>> Yes, but this is inconsistent with the definition of _preferred scale_ for `BigDecimal.sqrt()`.
>> 
>> Looks like I included a bug with BigDecimals.sqrt with respect to scaling then. While I noted a correct translation of the IEEE 754 requirement in 
>> 
>> https://bugs.openjdk.org/browse/JDK-4851777?focusedId=13847551&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13847551
>> 
>> that did not get carried over to the BigDecimal.sqrt spec or implementation.
>> 
>> I've filed https://bugs.openjdk.org/browse/JDK-8370057; thanks.
>
>> I leave that decision to @jddarcy. But for consistency with IEEE 754, we should use `ceilDiv(this.scale(), n)` even for `n = 2`.
>> 
>> @fabioromano1 I guess that implementation-wise it would be an easy change?
>> 
>> Also, should we perhaps rename the method to `rootn()`, as in IEEE 754? We still have time before RDP 1.
> 
> The BigDecimal.sqrt scale bug should be resolved in its own issue; it will require a CSR for compatibility analysis.
> 
> The IEEE 754 terminology is guidance, but not one we strictly have to follow if we have cause not to.

OK, so let's go with the truncated division for now, since `sqrt()` delegates to `ntRoot()`.
As for the name, shall we replace it with `rootn()`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2440536555

From asemenyuk at openjdk.org  Fri Oct 17 17:07:41 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 17 Oct 2025 17:07:41 GMT
Subject: RFR: 8356575: Test order in which jpackage fills app image [v3]
In-Reply-To: 
References: 
Message-ID: <_jaH7PzS7CZSFCayya12ZKBo5nZTZDd9dpgfucpUDV8=.9879049f-ad10-4584-b30d-60ea7ba28634@github.com>

> - Test order in which jpackage fills app image
> - Fix an issue with jpackage that it would fail to overwrite existing files in the app image. Uncovered by the test.

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

  Use Files.mismatch() to check if the content of two files mismatch or not. Add TKit.assertMismatchFileContent() and TKit.assertSameFileContent() helper functions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27826/files
  - new: https://git.openjdk.org/jdk/pull/27826/files/15c5d6fa..0db2749f

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

  Stats: 63 lines in 3 files changed: 35 ins; 24 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27826/head:pull/27826

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

From asemenyuk at openjdk.org  Fri Oct 17 17:07:42 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 17 Oct 2025 17:07:42 GMT
Subject: RFR: 8356575: Test order in which jpackage fills app image [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 18:24:02 GMT, Alexey Semenyuk  wrote:

>> - Test order in which jpackage fills app image
>> - Fix an issue with jpackage that it would fail to overwrite existing files in the app image. Uncovered by the test.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor. Simplify and make it pass on Windows and Linux

Use `Files.mismatch()` instead of comparing file digests in the test.

@sashamatveev, please review again

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

PR Comment: https://git.openjdk.org/jdk/pull/27826#issuecomment-3416381506

From duke at openjdk.org  Fri Oct 17 17:22:06 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 17:22:06 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v9]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 17 Oct 2025 12:59:42 GMT, Emanuel Peter  wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 44:
> 
>> 42: 
>> 43:     @Param("10000000")
>> 44:     private int count;
> 
> Drive-by comment / question:
> Did you do all benchmarking with this single (quite large) size? How are the results for much smaller sizes? It may be worth it to just get a nice plot that goes over a range of sizes, to see if it behaves as expected.

The benchmarks listed in the PR description execute tests for data sizes ranging from 16 to 10_000_000 bytes for decryption and encryption.  The difference in performance between the old and new code were within SE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2440660231

From asemenyuk at openjdk.org  Fri Oct 17 17:30:32 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 17 Oct 2025 17:30:32 GMT
Subject: RFR: 8370120: Make jpackage tests output more stable
Message-ID: <3JVlJYJMu1LyY1t2y8eDX0fkBaE6u8XZbTg-KDGoPH8=.2c7f084b-f1b3-46bd-90c1-422c1f56f421@github.com>

- Make jpackage tests output more stable.
 - Make jpackage output more stable.
 - Add more action to the script derandomizing jpackage test logs.

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

Commit messages:
 - Update "cleaning" shell scripts
 - Stable jpackage/test logs

Changes: https://git.openjdk.org/jdk/pull/27870/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27870&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370120
  Stats: 112 lines in 12 files changed: 63 ins; 14 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/27870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27870/head:pull/27870

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

From rotanolexandr842 at gmail.com  Fri Oct 17 18:45:19 2025
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Fri, 17 Oct 2025 21:45:19 +0300
Subject: My expirience with gatherers
Message-ID: 

Greetings to the core libs folks. I have been using Gatherers extensively
for my job in a past few months, and would like to share some of the
gatherers that I have been extensively using, so maybe some of them may be
a source of inspiration for evolving the Gatherers class.

1. eagerlyConsume()
Implementation:

public static  Gatherer eagerlyConsume() {
    return Gatherer.of(
        ArrayList::new,
        (list, val, downstream) -> {
            list.add(val);
            return true;
        },
        (left, right) -> {
            left.addAll(right);
            return left;
        },
        (list, downstream) -> {
            for (var item : list) {
                downstream.push(item);
            }
        }
    );
}

Purpose: many times, i need to perform a concurrent mapping of jpa entities
to dtos. Unfortunately, mapConcurrent does not accept custom executors,
which i need in order to propagate auth, transaction and other contexts.
So, therefore, I previously have used following pattern:

stream().map(COmpletableFuture.supplyAsync(...,
executor)).toList().stream().map(CompletableFuture::join)

toList is required here to eagerly start all futures, as otherwise the will
actually launch sequentially due to the pulling nature of streams. With
gatherer, on the other hand, i can achieve following:
stream().map(COmpletableFuture.supplyAsync(..., executor))..gather
(eagerlyConsume()) .map(CompletableFuture::join), which looks much more
readable, and (presumably, haven't actually verified it) should have better
performance

2. ofCollector
Implementation:

public  Gatherer ofCollector(Collector collector) {
    return Gatherer.of(
        collector.supplier(),
        (a, t, _) -> {
            collector.accumulator().accept(a, t);
            return true;
        },
        collector.combiner(),
        (state, downstream) ->
downstream.push(collector.finisher().apply(state))
    );
}

Pretty self explanatory, this is just an adapter of collector to gatherer,
allowing arbitrary collector-defined folds

3. collectThenFlatten & co
Implementations:

public static > Gatherer
collectThenFlatten(Collector collector) {
    return Gatherer.of(
        collector.supplier(),
        (a, t, _) -> {
            collector.accumulator().accept(a, t);
            return true;
        },
        collector.combiner(),
        (state, downstream) -> {
            for (var item : collector.finisher().apply(state)) {
                downstream.push(item);
            }
        }
    );
}

public static > Gatherer> collectThenFlattenEntries(Collector
collector) {
    return Gatherer.of(
        collector.supplier(),
        (a, t, _) -> {
            collector.accumulator().accept(a, t);
            return true;
        },
        collector.combiner(),
        (state, downstream) -> {
            for (var entry : collector.finisher().apply(state).entrySet()) {
                downstream.push(entry);
            }
        }
    );
}

These are more specialized adapters of collector adapters, mostly a
convenience for avoiding flatMapping results, THough, I would like to note
that collectThenFlattenEntries is mostly used specifically with groupingBy
collector, to avoid following nasty chains:

collect(groupingBy(...)).entrySet().stream()

Maybe it's just my personal preferences, but i really dislike this back n
forth from stream to map, then to set and to stream again, so this gatherer
seems pretty pleasant to use

That's basically all that I wanted to share regarding this topic, hope this
experience will have some value for core libs maintainers

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From asemenyuk at openjdk.org  Fri Oct 17 19:15:01 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 17 Oct 2025 19:15:01 GMT
Subject: RFR: 8370120: Make jpackage tests output more stable
In-Reply-To: <3JVlJYJMu1LyY1t2y8eDX0fkBaE6u8XZbTg-KDGoPH8=.2c7f084b-f1b3-46bd-90c1-422c1f56f421@github.com>
References: <3JVlJYJMu1LyY1t2y8eDX0fkBaE6u8XZbTg-KDGoPH8=.2c7f084b-f1b3-46bd-90c1-422c1f56f421@github.com>
Message-ID: 

On Fri, 17 Oct 2025 17:20:01 GMT, Alexey Semenyuk  wrote:

> - Make jpackage tests output more stable.
>  - Make jpackage output more stable.
>  - Add more action to the script derandomizing jpackage test logs.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/27870#issuecomment-3416775779

From asemenyuk at openjdk.org  Fri Oct 17 19:34:21 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 17 Oct 2025 19:34:21 GMT
Subject: RFR: 8370134: Fix minor jpackage issues
Message-ID: 

Fix minor jpackage issues

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

Commit messages:
 - Fix incorrect configuration of BuildEnv instance in msi/exe bundlers. The directory for cooking app image when bundling msi/exe packages is supposed to be "${TMP}/image", but it was "${TMP}/image/${AppName}", which is correct for app image bundling, but not for msi/exe bundling. The issue doesn't have any functional impact.
 - FromParams: always set module path for jlink. Fix a regression from JDK-8333664.
 - Arguments: remove debug arguments logging

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

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

From asemenyuk at openjdk.org  Fri Oct 17 19:43:37 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 17 Oct 2025 19:43:37 GMT
Subject: RFR: 8370136: Support async execution of jpackage tests
Message-ID: 

$subj

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

Commit messages:
 - Support async test execution in jpackage test lib

Changes: https://git.openjdk.org/jdk/pull/27877/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27877&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370136
  Stats: 362 lines in 7 files changed: 215 ins; 63 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/27877.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27877/head:pull/27877

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

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  Fri Oct 17 20:07:05 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 20:07:05 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v10]
In-Reply-To: 
References: 
Message-ID: 

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/2ce35b97..1102c609

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

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

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

From duke at openjdk.org  Fri Oct 17 20:07:06 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 20:07:06 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
References: 
 
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
Message-ID: 

On Fri, 17 Oct 2025 06:52:44 GMT, Shawn M Emery  wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 911:
>> 
>>> 909:             }
>>> 910:             sessionK[0] = genRoundKeys(key, rounds);
>>> 911:             sessionK[1] = invGenRoundKeys();
>> 
>> Given the decryption round keys are somewhat based on the encryption round keys, we could combine these two methods into one, e.g.
>> 
>>  private static int[][] genRoundKeys(byte[] key, int rounds) {
>>         int[][] ks = new int[2][]; // key schedule
>> 
>>         int wLen = (rounds + 1) * WB;
>>         int nk = key.length / WB;
>> 
>>         // generate the round keys for encryption
>>         int[] w = new int[wLen];
>>         for (int i = 0, j = 0; i < nk; i++, j+=4) {
>>             w[i] = ((key[j] & 0xFF) << 24)
>>                     | ((key[j + 1] & 0xFF) << 16)
>>                     | ((key[j + 2] & 0xFF) << 8)
>>                     | (key[j + 3] & 0xFF);
>>         }
>>         for (int i = nk; i < wLen; i++) {
>>             int tmp = w[i - 1];
>>             if (i % nk == 0) {
>>                 int rW = (tmp << 8) & 0xFFFFFF00 | (tmp >>> 24);
>>                 tmp = subWord(rW) ^ RCON[(i / nk) - 1];
>>             } else if ((nk > 6) && ((i % nk) == WB)) {
>>                 tmp = subWord(tmp);
>>             }
>>             w[i] = w[i - nk] ^ tmp;
>>         }
>>         ks[0] = w;
>> 
>>         // generate the decryption round keys based on encryption ones
>>         int[] dw = new int[wLen];
>>         int[] temp = new int[WB];
>> 
>>         // Intrinsics requires the inverse key expansion to be reverse order
>>         // except for the first and last round key as the first two round keys
>>         // are without a mix column transform.
>>         for (int i = 1; i < rounds; i++) {
>>             System.arraycopy(w, i * WB, temp, 0, WB);
>>             invMixRKey(temp);
>>             System.arraycopy(temp, 0, dw, wLen - (i * WB), WB);
>>         }
>>         // dw[0...3] <- w[0...3] AND dw[4...7] <- w[(wLen - 4)...(wLen -1)]
>>         System.arraycopy(w, 0, dw, 0, WB);
>>         System.arraycopy(w, wLen - WB, dw, WB, WB);
>>         ks[1] = dw;
>>         Arrays.fill(temp, 0);
>> 
>>         return ks;
>>     }
>
> These two methods were only the few that I was able to make that were compact and singular in purpose (gen round key, gen inverse round key) code as the coding style guidelines espouse.  The rest of the methods' construction were dictated by performance improvements, where compactness came at the cost of interpreter speed.

I did make changes based on your code to eliminate len and updates to variable names.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441096947

From valeriep at openjdk.org  Fri Oct 17 20:21:02 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 20:21:02 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: 
References: 
 
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
 
Message-ID: 

On Fri, 17 Oct 2025 20:01:21 GMT, Shawn M Emery  wrote:

>> These two methods were only the few that I was able to make that were compact and singular in purpose (gen round key, gen inverse round key) code as the coding style guidelines espouse.  The rest of the methods' construction were dictated by performance improvements, where compactness came at the cost of interpreter speed.
>
> I did make changes based on your code to eliminate len and updates to variable names.

Yes, I take a second look and maybe a smaller adjustments would work as well. E.g,
1) nit: method name `invGenRoundKeys`  -> `genInvRoundKeys`
2) make this method static by passing `sessionKey[0]` and `rounds` as arguments,
3) no need for `len` since it's always `WB`
4) for the intermediate buffer of 4 words, can we not use `w` as this name is used in both the spec and genRoundKeys method as "Word array for the key schedule". It'd help people understand the code better if we adopt the same naming convention in "Algorithm 5 Pseudocode for KEYEXPANSIONEIC()", e.g. `temp` for the intermediate buffer and `dw` for the final result.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441139964

From darcy at openjdk.org  Fri Oct 17 20:42:12 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Oct 2025 20:42:12 GMT
Subject: Integrated: 8370028: Remove author tags from mathematical classes
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 17:22:21 GMT, Joe Darcy  wrote:

> Removing my author tags under `/src` and other authors tags in those files.
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
>  ?? The pull request body must not be empty.
> 
> 
> 
> ### Reviewing
> 
    Using git
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/27852/head:pull/27852` \
> `$ git checkout pull/27852`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/27852` \
> `$ git pull https://git.openjdk.org/jdk.git pull/27852/head`
> 
> 
    
> 
    Using Skara CLI tools
> 
> Checkout this PR locally: \
> `$ git pr checkout 27852`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 27852`
> 
> 
    
> 
    Using diff file
> 
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/27852.diff
> 
> 
    

This pull request has now been integrated.

Changeset: 0cc88e4a
Author:    Joe Darcy 
URL:       https://git.openjdk.org/jdk/commit/0cc88e4ad4ded970433eed25778a7290ddf9b0fa
Stats:     47 lines in 13 files changed: 0 ins; 45 del; 2 mod

8370028: Remove author tags from mathematical classes

Reviewed-by: bpb, rriggs

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

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

From valeriep at openjdk.org  Fri Oct 17 21:15:04 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 21:15:04 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 17 Oct 2025 20:07:05 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 45:

> 43: final class AES_Crypt extends SymmetricCipher {
> 44: 
> 45:     // Number of words in a block

nit: from the usage, e.g. `int nk = key.length / WB`;, it seems WB means "number of bytes in a word".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441263128

From valeriep at openjdk.org  Fri Oct 17 21:39:05 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 21:39:05 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 17 Oct 2025 20:07:05 GMT, Shawn M Emery  wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 134:

> 132:     };
> 133: 
> 134:     private static final int[] T0 = {

nit: add comment for all these precomputed lookup tables and their usage.

Are these tables publicly available somewhere? I checked both spec in the class header and they don't have these included. I wonder if they are made available somewhere which corresponds with the current impl code better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441320498

From lancea at openjdk.org  Fri Oct 17 22:12:25 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 17 Oct 2025 22:12:25 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v8]
In-Reply-To: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
Message-ID: 

> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
> 
> - Deprecate SQLPermission for removal
> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
> 
> Tiers 1-3 have been run

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

  Minor wordsmithing based on approved CSR feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27693/files
  - new: https://git.openjdk.org/jdk/pull/27693/files/6d77719e..385dc016

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

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

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

From duke at openjdk.org  Fri Oct 17 22:19:26 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 22:19:26 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v11]
In-Reply-To: 
References: 
Message-ID: 

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/1102c609..e0741b17

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

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

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

From duke at openjdk.org  Fri Oct 17 22:19:28 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 22:19:28 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 17 Oct 2025 21:12:21 GMT, Valerie Peng  wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 45:
> 
>> 43: final class AES_Crypt extends SymmetricCipher {
>> 44: 
>> 45:     // Number of words in a block
> 
> nit: from the usage, e.g. `int nk = key.length / WB`;, it seems WB means "number of bytes in a word".

I agree, it should be bytes per word for number of keys (nk) calculation, so BW?  I want to preserved words per block (WB) for maintainability (e.g., if we decide to implement Rijndael-256, where WB = 8).  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 134:
> 
>> 132:     };
>> 133: 
>> 134:     private static final int[] T0 = {
> 
> nit: add comment for all these precomputed lookup tables and their usage.
> 
> Are these tables publicly available somewhere? I checked both spec in the class header and they don't have these included. I wonder if they are made available somewhere which corresponds with the current impl code better.

I generated the tables separately, but their usage is referenced in the original specification cited in section 5.2.1.  If made comments indicating of such.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441377285
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441377328

From duke at openjdk.org  Fri Oct 17 22:25:44 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Fri, 17 Oct 2025 22:25:44 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v9]
In-Reply-To: 
References: 
Message-ID: 

> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
> 
> Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior.

Benjamin Peterson 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 15 additional commits since the last revision:

 - add test showing loading symlinked libraries with various combinations
 - revert dll_load fix
 - Merge branch 'master' into nativelibraries-fix
 - add cast
 - use os::malloc
 - Merge branch 'master' into nativelibraries-fix
 - fix compilation
 - fix grammar
 - add dot in os::dll_load rather than NativeLibraries.java
 - Merge remote-tracking branch 'origin/master' into nativelibraries-fix
 - ... and 5 more: https://git.openjdk.org/jdk/compare/3ebbd323...09de5608

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24694/files
  - new: https://git.openjdk.org/jdk/pull/24694/files/d571e826..09de5608

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

  Stats: 26638 lines in 664 files changed: 15736 ins; 8292 del; 2610 mod
  Patch: https://git.openjdk.org/jdk/pull/24694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694

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

From iklam at openjdk.org  Fri Oct 17 22:27:35 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Oct 2025 22:27:35 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
Message-ID: 

By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.

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

Commit messages:
 - 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets

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

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

From asemenyuk at openjdk.org  Fri Oct 17 22:37:00 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 17 Oct 2025 22:37:00 GMT
Subject: RFR: 8370136: Support async execution of jpackage tests
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Oct 2025 19:36:58 GMT, Alexey Semenyuk  wrote:

> $subj
> 
> In a nutshell, wrap static fields of TKit and JPackageCommand classes into inheritable thread-local wrappers.
> 
> As a side effect of this change, had to rework the "WinNoRestartTest.java" test to explicitly start a worker thread instead of using ExecutorService because it doesn't work well with the new inheritable thread-local wrappers.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/27877#issuecomment-3417428462

From asemenyuk at openjdk.org  Fri Oct 17 22:38:03 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 17 Oct 2025 22:38:03 GMT
Subject: RFR: 8370134: Fix minor jpackage issues
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Oct 2025 19:27:16 GMT, Alexey Semenyuk  wrote:

> Fix minor jpackage issues

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/27876#issuecomment-3417429880

From skuksenko at openjdk.org  Fri Oct 17 22:43:26 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Fri, 17 Oct 2025 22:43:26 GMT
Subject: RFR: 8370150: Add StrictMath microbenchmarks to cover FDLIBM
 algorithms
Message-ID: <-zFdpTE0II7muIj0FtbT62bOtCWDDxJgQiOt65ehpZM=.37ddba8f-bb12-471c-8134-1e72c25f2fc2@github.com>

Add StrictMath microbenchmarks to cover FDLIBM algorithms

The methods that require fdlibm semantics are sin, cos, tan, asin, acos, atan, exp, log, log10, cbrt, atan2, pow, sinh, cosh, tanh, hypot, expm1, and log1p.

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

Commit messages:
 - 8370150: Add StrictMath microbenchmarks to cover FDLIBM algorithms

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

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

From almatvee at openjdk.org  Fri Oct 17 22:44:02 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 17 Oct 2025 22:44:02 GMT
Subject: RFR: 8356575: Test order in which jpackage fills app image [v3]
In-Reply-To: <_jaH7PzS7CZSFCayya12ZKBo5nZTZDd9dpgfucpUDV8=.9879049f-ad10-4584-b30d-60ea7ba28634@github.com>
References: 
 <_jaH7PzS7CZSFCayya12ZKBo5nZTZDd9dpgfucpUDV8=.9879049f-ad10-4584-b30d-60ea7ba28634@github.com>
Message-ID: 

On Fri, 17 Oct 2025 17:07:41 GMT, Alexey Semenyuk  wrote:

>> - Test order in which jpackage fills app image
>> - Fix an issue with jpackage that it would fail to overwrite existing files in the app image. Uncovered by the test.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Files.mismatch() to check if the content of two files mismatch or not. Add TKit.assertMismatchFileContent() and TKit.assertSameFileContent() helper functions.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27826#pullrequestreview-3352312824

From skuksenko at openjdk.org  Fri Oct 17 22:47:21 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Fri, 17 Oct 2025 22:47:21 GMT
Subject: RFR: 8370150: Add StrictMath microbenchmarks to cover FDLIBM
 algorithms [v2]
In-Reply-To: <-zFdpTE0II7muIj0FtbT62bOtCWDDxJgQiOt65ehpZM=.37ddba8f-bb12-471c-8134-1e72c25f2fc2@github.com>
References: <-zFdpTE0II7muIj0FtbT62bOtCWDDxJgQiOt65ehpZM=.37ddba8f-bb12-471c-8134-1e72c25f2fc2@github.com>
Message-ID: <5CjWG5Fl98CgY2kHSsl3Zt_Rq3kMX5K_5tYp99F7x8s=.f3039e96-b4ad-4943-a475-139e0060a514@github.com>

> Add StrictMath microbenchmarks to cover FDLIBM algorithms
> 
> The methods that require fdlibm semantics are sin, cos, tan, asin, acos, atan, exp, log, log10, cbrt, atan2, pow, sinh, cosh, tanh, hypot, expm1, and log1p.

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

  Update StrictMathExtraBench.java
  
  Fix copyright format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27881/files
  - new: https://git.openjdk.org/jdk/pull/27881/files/457a9bed..3ad3f541

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

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

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

From asemenyuk at openjdk.org  Fri Oct 17 22:47:32 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 17 Oct 2025 22:47:32 GMT
Subject: RFR: 8370123: Minor jpackage refactoring
Message-ID: 

Minor changes, no functional impact.

- Move warning logging from MacBaseInstallerBundler to MacPackageBuilder, MacPkgPackageBuilder
- ApplicationBuilder: add externalApplication() and mainLauncherClassName() methods
- `AppImageSigner.normalizeAppImageLayout()` -> `AppImageSigner.copyWithUnresolvedAppImageLayout()`
- Add `JLinkRuntimeBuilder.ensureBaseModuleInModulePath()`; move code away from StandardBundlerParam; remove redundant "warning.no.jdk.modules.found" string ID
- Add `OverridableResource.probe()` method
- Remove dead and "odd" code from IOUtils

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

Commit messages:
 - JLinkRuntimeBuilder: remove trailing whitespace
 - JLinkRuntimeBuilder: add a comment
 - IOUtils: remove dead code; remove getFileName(), getParent() functions.
 - ApplicationLaunchers: minor
 - OverridableResource: add probe() method
 - Add JLinkRuntimeBuilder.ensureBaseModuleInModulePath()
 - AppImageSigner: better function name
 - ApplicationBuilder: add externalApplication() and mainLauncherClassName() methods
 - MacPackageBuilder, MacPkgPackageBuilder: move warning logging from MacBaseInstallerBundler

Changes: https://git.openjdk.org/jdk/pull/27873/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27873&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370123
  Stats: 295 lines in 16 files changed: 109 ins; 166 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27873.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27873/head:pull/27873

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

From asemenyuk at openjdk.org  Fri Oct 17 22:47:33 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 17 Oct 2025 22:47:33 GMT
Subject: RFR: 8370123: Minor jpackage refactoring
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Oct 2025 18:06:46 GMT, Alexey Semenyuk  wrote:

> Minor changes, no functional impact.
> 
> - Move warning logging from MacBaseInstallerBundler to MacPackageBuilder, MacPkgPackageBuilder
> - ApplicationBuilder: add externalApplication() and mainLauncherClassName() methods
> - `AppImageSigner.normalizeAppImageLayout()` -> `AppImageSigner.copyWithUnresolvedAppImageLayout()`
> - Add `JLinkRuntimeBuilder.ensureBaseModuleInModulePath()`; move code away from StandardBundlerParam; remove redundant "warning.no.jdk.modules.found" string ID
> - Add `OverridableResource.probe()` method
> - Remove dead and "odd" code from IOUtils

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/27873#issuecomment-3417438642

From bpb at openjdk.org  Fri Oct 17 22:54:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Oct 2025 22:54:17 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v6]
In-Reply-To: 
References: 
Message-ID: <5UJjW6DfpJVVEPFb8ODJ3aaw-Bf3ob2JjrdQb_NOwO0=.e11f5806-66a6-4f89-8b22-3ef6176c9611@github.com>

> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.

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

  8355342: Do not check for backslash as third character of input pathname string

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27324/files
  - new: https://git.openjdk.org/jdk/pull/27324/files/ebe88f73..68af87c7

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

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

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

From bpb at openjdk.org  Fri Oct 17 22:54:18 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Oct 2025 22:54:18 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v6]
In-Reply-To: <5UJjW6DfpJVVEPFb8ODJ3aaw-Bf3ob2JjrdQb_NOwO0=.e11f5806-66a6-4f89-8b22-3ef6176c9611@github.com>
References: 
 <5UJjW6DfpJVVEPFb8ODJ3aaw-Bf3ob2JjrdQb_NOwO0=.e11f5806-66a6-4f89-8b22-3ef6176c9611@github.com>
Message-ID: 

On Fri, 17 Oct 2025 22:50:59 GMT, Brian Burkhalter  wrote:

>> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355342: Do not check for backslash as third character of input pathname string

src/java.base/windows/classes/java/io/WinNTFileSystem.java line 504:

> 502:                 finalPath = fp;
> 503:             }
> 504:         } catch (IOException ignored) {

I don't know that there should be a `try-catch` here as it looks like `getFinalPath` throws (an `Error`) if any only if memory runs out, in which case we're done anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27324#discussion_r2441409842

From asemenyuk at openjdk.org  Fri Oct 17 23:01:26 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 17 Oct 2025 23:01:26 GMT
Subject: Integrated: 8356575: Test order in which jpackage fills app image
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Oct 2025 15:51:43 GMT, Alexey Semenyuk  wrote:

> - Test order in which jpackage fills app image
> - Fix an issue with jpackage that it would fail to overwrite existing files in the app image. Uncovered by the test.

This pull request has now been integrated.

Changeset: 49b17dd5
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/49b17dd5c97bf967c01166542cfccf4b196cf8a9
Stats:     394 lines in 4 files changed: 391 ins; 1 del; 2 mod

8356575: Test order in which jpackage fills app image

Reviewed-by: almatvee

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

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

From darcy at openjdk.org  Fri Oct 17 23:17:31 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Oct 2025 23:17:31 GMT
Subject: RFR: 8370057: Correct scale handling of BigDecimal.sqrt
Message-ID: 

Correct scale handling of BigDecimal.sqrt to conform to IEEE 754.

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

Commit messages:
 - JDK-8370057: Correct scale handling of BigDecimal.sqrt

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

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

From duke at openjdk.org  Sat Oct 18 00:09:03 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Sat, 18 Oct 2025 00:09:03 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <2X1KarQP2qTQoWGxVrAYpgUY4golsCfR8KoJqbCWnWw=.85896efa-5d1c-4df3-88df-e397892e7ff4@github.com>
References: 
 
 
 <2X1KarQP2qTQoWGxVrAYpgUY4golsCfR8KoJqbCWnWw=.85896efa-5d1c-4df3-88df-e397892e7ff4@github.com>
Message-ID: 

On Wed, 8 Oct 2025 12:36:23 GMT, Alan Bateman  wrote:

> A better starting point for discussion would be a test that exercises System.loadLibrary with the a library name that locates a DLL through a sym link to a final target that doesn't have the .dll suffix.

To this end, I have updated the PR to add a test `test/jdk/java/lang/ClassLoader/loadLibrarySymlinks/LoadLibrarySymlinksTest.java`. This test exercises the 3 cases discussed in https://mail.openjdk.org/pipermail/core-libs-dev/2025-October/152992.html.

Unix platforms pass this test as expected. Since I reverted all of my proposed fixes, Windows fails handling the `test2.dll -> barename` case:

java.lang.UnsatisfiedLinkError: D:\\a\\jdk\\jdk\\build\\run-test-prebuilt\\test-support\\jtreg_test_jdk_tier1_part1\\scratch\\barename: Can't find dependent libraries
        at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
        at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:326)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:187)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:129)
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2282)
        at java.base/java.lang.Runtime.load0(Runtime.java:767)
        at java.base/java.lang.System.load(System.java:1646)
        at LoadLibrarySymlinksTest.main(LoadLibrarySymlinksTest.java:48)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
        at java.base/java.lang.Thread.run(Thread.java:1474)

JavaTest Message: Test threw exception: java.lang.UnsatisfiedLinkError


I hope this aids in understanding the issue and review my proposed fix(es).

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

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3417543831

From duke at openjdk.org  Sat Oct 18 00:17:12 2025
From: duke at openjdk.org (duke)
Date: Sat, 18 Oct 2025 00:17:12 GMT
Subject: Withdrawn: 8355522: Remove the `java.locale.useOldISOCodes` system
 property
In-Reply-To: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
Message-ID: 

On Mon, 21 Jul 2025 22:56:50 GMT, Naoto Sato  wrote:

> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well

This pull request has been closed without being integrated.

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

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

From almatvee at openjdk.org  Sat Oct 18 00:30:01 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 18 Oct 2025 00:30:01 GMT
Subject: RFR: 8370120: Make jpackage tests output more stable
In-Reply-To: <3JVlJYJMu1LyY1t2y8eDX0fkBaE6u8XZbTg-KDGoPH8=.2c7f084b-f1b3-46bd-90c1-422c1f56f421@github.com>
References: <3JVlJYJMu1LyY1t2y8eDX0fkBaE6u8XZbTg-KDGoPH8=.2c7f084b-f1b3-46bd-90c1-422c1f56f421@github.com>
Message-ID: 

On Fri, 17 Oct 2025 17:20:01 GMT, Alexey Semenyuk  wrote:

> - Make jpackage tests output more stable.
>  - Make jpackage output more stable.
>  - Add more action to the script derandomizing jpackage test logs.

Looks good overall with minor comments.

test/jdk/tools/jpackage/clean_test_output.sh line 105:

> 103:       -e 's|taskkill /F /PID [0-9]\{1,\}|taskkill /F /PID |'
> 104: 
> 105:       # Convert PID value in `The process with PID 5640 has been terminated`

I am confused with this comment. Should we use something more generic then 5640. Same below for 57182ms.

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

PR Review: https://git.openjdk.org/jdk/pull/27870#pullrequestreview-3352415380
PR Review Comment: https://git.openjdk.org/jdk/pull/27870#discussion_r2441473583

From asemenyuk at openjdk.org  Sat Oct 18 00:50:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 18 Oct 2025 00:50:09 GMT
Subject: RFR: 8356578: Test --mac-entitlements
In-Reply-To: 
References: 
Message-ID: <0NEfkoMl-w1BCHqIXGF__uILsq34v90WoCSRo5IibWc=.ef499d2f-4d9c-48dc-9d72-19128909bc6d@github.com>

On Thu, 16 Oct 2025 02:32:41 GMT, Alexander Matveev  wrote:

> - Added test to cover `--mac-entitlements`.
> - Added verification for entitlements from `--resource-dir`.

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherVerifier.java line 353:

> 351:         } else {
> 352:             expected = DefaultEntitlements.STANDARD;
> 353:         }

How about changing the whole thing to this:

        var customFile = Optional.ofNullable(cmd.getArgumentValue("--mac-entitlements")).map(Path::of);
        if (customFile.isEmpty()) {
            // Try from the resource dir.
            var resourceDirFile = Optional.ofNullable(cmd.getArgumentValue("--resource-dir")).map(Path::of).map(resourceDir -> {
                return resourceDir.resolve(cmd.name() + ".entitlements");
            }).filter(Files::exists);
            if (resourceDirFile.isPresent()) {
                customFile = resourceDirFile; 
            }
        }

        Map expected;
        if (customFile.isPresent()) {
            expected = new PListReader(Files.readAllBytes(customFile.orElseThrow())).toMap(true);
        } else if (cmd.hasArgument("--mac-app-store")) {
            expected = DefaultEntitlements.APP_STORE;
        } else {
            expected = DefaultEntitlements.STANDARD;
        }

?

Less code duplication.

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

PR Review: https://git.openjdk.org/jdk/pull/27835#pullrequestreview-3350699816
PR Review Comment: https://git.openjdk.org/jdk/pull/27835#discussion_r2440279577

From asemenyuk at openjdk.org  Sat Oct 18 00:55:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 18 Oct 2025 00:55:02 GMT
Subject: RFR: 8370120: Make jpackage tests output more stable
In-Reply-To: 
References: <3JVlJYJMu1LyY1t2y8eDX0fkBaE6u8XZbTg-KDGoPH8=.2c7f084b-f1b3-46bd-90c1-422c1f56f421@github.com>
 
Message-ID: <2z8kswxVF7rD05OongWeP-_YiCOzUzD6yfYBl7gZpPM=.c94c8738-87d4-43cd-9ee4-b050cbb86adb@github.com>

On Sat, 18 Oct 2025 00:20:30 GMT, Alexander Matveev  wrote:

>> - Make jpackage tests output more stable.
>>  - Make jpackage output more stable.
>>  - Add more action to the script derandomizing jpackage test logs.
>
> test/jdk/tools/jpackage/clean_test_output.sh line 105:
> 
>> 103:       -e 's|taskkill /F /PID [0-9]\{1,\}|taskkill /F /PID |'
>> 104: 
>> 105:       # Convert PID value in `The process with PID 5640 has been terminated`
> 
> I am confused with this comment. Should we use something more generic then 5640. Same below for 57182ms.

It is just a line from the log used as a comment to give a clue what the sed expression is doing. It will replace the sequence of any digits with `` token, not just "5640".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27870#discussion_r2441487154

From almatvee at openjdk.org  Sat Oct 18 01:00:04 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 18 Oct 2025 01:00:04 GMT
Subject: RFR: 8370134: Fix minor jpackage issues
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Oct 2025 19:27:16 GMT, Alexey Semenyuk  wrote:

> Fix minor jpackage issues.
> 
> - Remove debug output of the passed-in arguments.
> - Restore passing the default value of "--module-path" jlink option.
> - Restore the directory structure for building an app image for msi and exe packaging.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27876#pullrequestreview-3352436782

From almatvee at openjdk.org  Sat Oct 18 01:04:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 18 Oct 2025 01:04:05 GMT
Subject: RFR: 8370120: Make jpackage tests output more stable
In-Reply-To: <3JVlJYJMu1LyY1t2y8eDX0fkBaE6u8XZbTg-KDGoPH8=.2c7f084b-f1b3-46bd-90c1-422c1f56f421@github.com>
References: <3JVlJYJMu1LyY1t2y8eDX0fkBaE6u8XZbTg-KDGoPH8=.2c7f084b-f1b3-46bd-90c1-422c1f56f421@github.com>
Message-ID: 

On Fri, 17 Oct 2025 17:20:01 GMT, Alexey Semenyuk  wrote:

> - Make jpackage tests output more stable.
>  - Make jpackage output more stable.
>  - Add more action to the script derandomizing jpackage test logs.

Marked as reviewed by almatvee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27870#pullrequestreview-3352437239

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 asemenyuk at openjdk.org  Sat Oct 18 01:14:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 18 Oct 2025 01:14:10 GMT
Subject: Integrated: 8370134: Fix minor jpackage issues
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Oct 2025 19:27:16 GMT, Alexey Semenyuk  wrote:

> Fix minor jpackage issues.
> 
> - Remove debug output of the passed-in arguments.
> - Restore passing the default value of "--module-path" jlink option.
> - Restore the directory structure for building an app image for msi and exe packaging.

This pull request has now been integrated.

Changeset: b0af41d6
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/b0af41d667f2fb5da37b4dd263486b34a15df0f3
Stats:     10 lines in 4 files changed: 5 ins; 0 del; 5 mod

8370134: Fix minor jpackage issues

Reviewed-by: almatvee

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

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

From asemenyuk at openjdk.org  Sat Oct 18 01:17:14 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 18 Oct 2025 01:17:14 GMT
Subject: Integrated: 8370120: Make jpackage tests output more stable
In-Reply-To: <3JVlJYJMu1LyY1t2y8eDX0fkBaE6u8XZbTg-KDGoPH8=.2c7f084b-f1b3-46bd-90c1-422c1f56f421@github.com>
References: <3JVlJYJMu1LyY1t2y8eDX0fkBaE6u8XZbTg-KDGoPH8=.2c7f084b-f1b3-46bd-90c1-422c1f56f421@github.com>
Message-ID: 

On Fri, 17 Oct 2025 17:20:01 GMT, Alexey Semenyuk  wrote:

> - Make jpackage tests output more stable.
>  - Make jpackage output more stable.
>  - Add more action to the script derandomizing jpackage test logs.

This pull request has now been integrated.

Changeset: eff6439e
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/eff6439e75d79c67370e79638024296e01101b48
Stats:     112 lines in 12 files changed: 63 ins; 14 del; 35 mod

8370120: Make jpackage tests output more stable

Reviewed-by: almatvee

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

PR: https://git.openjdk.org/jdk/pull/27870

From asemenyuk at openjdk.org  Sat Oct 18 02:17:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 18 Oct 2025 02:17:15 GMT
Subject: RFR: 8370156: Fix jpackage IconTest
Message-ID: 

Rework IconTest.

Verified it produces the output as expected.

-------------

Commit messages:
 - Rollback JDK-8370100 specific patch
 - AdditionalLauncher: make getAdditionalLauncherProperties() public; LauncherIconVerifier: make setters unambiguous; Add ConfigurationTarget
 - IconTest: revamp

Changes: https://git.openjdk.org/jdk/pull/27883/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27883&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370156
  Stats: 331 lines in 4 files changed: 179 ins; 68 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/27883.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27883/head:pull/27883

PR: https://git.openjdk.org/jdk/pull/27883

From asemenyuk at openjdk.org  Sat Oct 18 02:25:36 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 18 Oct 2025 02:25:36 GMT
Subject: RFR: 8370156: Fix jpackage IconTest [v2]
In-Reply-To: 
References: 
Message-ID: <-SLDJGQSK1szAwtprCKjJ6tv6f06cU_8Brc8O-FwGMM=.317ab58f-1f78-431e-b409-4bbb81c8ae14@github.com>

> Rework IconTest.
> 
> Verified it produces the output as expected.

Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge with the master
 - Merge branch 'master' into JDK-8370156
 - Rollback JDK-8370100 specific patch
 - AdditionalLauncher: make getAdditionalLauncherProperties() public; LauncherIconVerifier: make setters unambiguous; Add ConfigurationTarget
 - IconTest: revamp

-------------

Changes: https://git.openjdk.org/jdk/pull/27883/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27883&range=01
  Stats: 315 lines in 4 files changed: 173 ins; 62 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/27883.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27883/head:pull/27883

PR: https://git.openjdk.org/jdk/pull/27883

From liach at openjdk.org  Sat Oct 18 02:51:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 18 Oct 2025 02:51:01 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam  wrote:

> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.

src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 69:

> 67: public class SharedSecrets {
> 68:     // This field is not necessarily stable
> 69:     private static JavaAWTFontAccess javaAWTFontAccess;

Does aot initialization work with this field?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2441536894

From iklam at openjdk.org  Sat Oct 18 04:06:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 18 Oct 2025 04:06:00 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 18 Oct 2025 02:48:42 GMT, Chen Liang  wrote:

>> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.
>
> src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 69:
> 
>> 67: public class SharedSecrets {
>> 68:     // This field is not necessarily stable
>> 69:     private static JavaAWTFontAccess javaAWTFontAccess;
> 
> Does aot initialization work with this field?

I think this field is safe. There are two places that could set it, but they will always set it to an instance of `JavaAWTFontAccessImpl`, which is stateless.

https://github.com/openjdk/jdk/blob/eff6439e75d79c67370e79638024296e01101b48/src/java.desktop/share/classes/java/awt/font/NumericShaper.java#L148-L149

https://github.com/openjdk/jdk/blob/eff6439e75d79c67370e79638024296e01101b48/src/java.desktop/share/classes/java/awt/font/TextAttribute.java#L251-L252

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2441561760

From liach at openjdk.org  Sat Oct 18 04:18:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 18 Oct 2025 04:18:00 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam  wrote:

> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.

Archiving the accessors should be fine.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27880#pullrequestreview-3352526259

From asemenyuk at openjdk.org  Sat Oct 18 04:34:54 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 18 Oct 2025 04:34:54 GMT
Subject: RFR: 8370123: Minor jpackage refactoring [v2]
In-Reply-To: 
References: 
Message-ID: 

> Minor changes, no functional impact.
> 
> - ApplicationBuilder: add externalApplication() and mainLauncherClassName() methods
> - `AppImageSigner.normalizeAppImageLayout()` -> `AppImageSigner.copyWithUnresolvedAppImageLayout()`
> - Add `JLinkRuntimeBuilder.ensureBaseModuleInModulePath()`; move code away from StandardBundlerParam; remove redundant "warning.no.jdk.modules.found" string ID
> - Add `OverridableResource.probe()` method
> - Remove dead and "odd" code from IOUtils

Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge branch 'master' into JDK-8370123
 - JLinkRuntimeBuilder: remove trailing whitespace
 - JLinkRuntimeBuilder: add a comment
 - IOUtils: remove dead code; remove getFileName(), getParent() functions.
 - ApplicationLaunchers: minor
 - OverridableResource: add probe() method
 - Add JLinkRuntimeBuilder.ensureBaseModuleInModulePath()
 - AppImageSigner: better function name
 - ApplicationBuilder: add externalApplication() and mainLauncherClassName() methods

-------------

Changes: https://git.openjdk.org/jdk/pull/27873/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27873&range=01
  Stats: 241 lines in 13 files changed: 83 ins; 141 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27873.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27873/head:pull/27873

PR: https://git.openjdk.org/jdk/pull/27873

From asemenyuk at openjdk.org  Sat Oct 18 04:37:33 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 18 Oct 2025 04:37:33 GMT
Subject: RFR: 8370126: Improve jpackage signing testing
Message-ID: 

- Rework the SigningPackageTwoStepTest test to cover the case of bundling an unsigned predefined app image into a signed .pkg installer; make it verify expected warnings in the jpackage output.

- All jpackage tests will verify that without "--mac-sign" option, jpackage produces app images with a valid "adhoc" signature.

Additionally:
- Fix jpackage to make it emit messages expected in the updated SigningPackageTwoStepTest test.
- Add helper code for signing testing.
- Automatically unlock jpackage test keychains in all signing tests.
- Add a workaround for the `/usr/bin/codesign?-verify` command, which sometimes fails if executed without `sudo`.

-------------

Commit messages:
 - MacSignVerify: add a comment
 - Add javadoc
 - MacPackageBuilder, MacPkgPackageBuilder: move warning logging from MacBaseInstallerBundler
 - Update copyright year
 - Better keychain configuration in the signing tests; Unlock test keychains in signing tests; MacSignTest: better test coverage; MacSign: make MacSign.ResolvedKeychain more usable; JPackageCommand, MacHelper: add sign helpers and verify signature of jpackage output if it is unsigned; MacSignVerify: add functions to verify signed output of JPackageCommand instances; Rework SigningPackageTwoStepTest for better coverage. Add a workaround for `/usr/bin/codesign --verify` command that sometimes fails if executed without `sudo`.

Changes: https://git.openjdk.org/jdk/pull/27875/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27875&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370126
  Stats: 816 lines in 15 files changed: 549 ins; 139 del; 128 mod
  Patch: https://git.openjdk.org/jdk/pull/27875.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27875/head:pull/27875

PR: https://git.openjdk.org/jdk/pull/27875

From asemenyuk at openjdk.org  Sat Oct 18 04:37:34 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 18 Oct 2025 04:37:34 GMT
Subject: RFR: 8370126: Improve jpackage signing testing
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Oct 2025 18:45:16 GMT, Alexey Semenyuk  wrote:

> - Rework the SigningPackageTwoStepTest test to cover the case of bundling an unsigned predefined app image into a signed .pkg installer; make it verify expected warnings in the jpackage output.
> 
> - All jpackage tests will verify that without "--mac-sign" option, jpackage produces app images with a valid "adhoc" signature.
> 
> Additionally:
> - Fix jpackage to make it emit messages expected in the updated SigningPackageTwoStepTest test.
> - Add helper code for signing testing.
> - Automatically unlock jpackage test keychains in all signing tests.
> - Add a workaround for the `/usr/bin/codesign?-verify` command, which sometimes fails if executed without `sudo`.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27875#issuecomment-3417795860

From asemenyuk at openjdk.org  Sat Oct 18 04:39:01 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 18 Oct 2025 04:39:01 GMT
Subject: RFR: 8370156: Fix jpackage IconTest [v2]
In-Reply-To: <-SLDJGQSK1szAwtprCKjJ6tv6f06cU_8Brc8O-FwGMM=.317ab58f-1f78-431e-b409-4bbb81c8ae14@github.com>
References: 
 <-SLDJGQSK1szAwtprCKjJ6tv6f06cU_8Brc8O-FwGMM=.317ab58f-1f78-431e-b409-4bbb81c8ae14@github.com>
Message-ID: 

On Sat, 18 Oct 2025 02:25:36 GMT, Alexey Semenyuk  wrote:

>> Rework IconTest.
>> 
>> Verified it produces the output as expected.
>> 
>> It still will not catch [JDK-8370155](https://bugs.openjdk.org/browse/JDK-8370155). However, this is deliberate to avoid significant changes in the test and implementation in a single commit.
>
> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge with the master
>  - Merge branch 'master' into JDK-8370156
>  - Rollback JDK-8370100 specific patch
>  - AdditionalLauncher: make getAdditionalLauncherProperties() public; LauncherIconVerifier: make setters unambiguous; Add ConfigurationTarget
>  - IconTest: revamp

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27883#issuecomment-3417798241

From sherman at openjdk.org  Sat Oct 18 08:44:57 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Sat, 18 Oct 2025 08:44:57 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v3]
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
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
> 
> See CSR https://bugs.openjd...

Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:

  performance update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27628/files
  - new: https://git.openjdk.org/jdk/pull/27628/files/9d9997dc..59b7a4fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=01-02

  Stats: 601 lines in 7 files changed: 285 ins; 242 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/27628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27628/head:pull/27628

PR: https://git.openjdk.org/jdk/pull/27628

From sherman at openjdk.org  Sat Oct 18 08:44:59 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Sat, 18 Oct 2025 08:44:59 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v2]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
 
Message-ID: 

On Fri, 10 Oct 2025 19:49:19 GMT, Jean-No?l Rouvignac  wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor api doc updates
>
> test/micro/org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java line 89:
> 
>> 87: 
>> 88:     @Benchmark
>> 89:     public int lowerrCF() {
> 
> Suggestion:
> 
>     public int lowerCF() {

fixed in the new test source code

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2441835525

From sherman at openjdk.org  Sat Oct 18 08:54:01 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Sat, 18 Oct 2025 08:54:01 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v3]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
Message-ID: 

On Tue, 7 Oct 2025 22:10:50 GMT, Roger Riggs  wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   performance update
>
> src/java.base/share/classes/java/lang/StringLatin1.java line 194:
> 
>> 192:         char[] folded2 = null;
>> 193:         int k1 = 0, k2 = 0, fk1 = 0, fk2 = 0;
>> 194:         while ((k1 < len1 || folded1 != null && fk1 < folded1.length) &&
> 
> Many suggestions come to mind here on the algorithm, to optimize performance.
> For example, many strings will have identical prefixes. Using Arrays.mismatch could quickly skip over the identical prefix.
> Consider using code points (or a long, packing 4 chars) for the folded replacements, to avoid having to step through chars in char arrays.  CaseFolding.foldIfDefined could return the full expansion as a long.
> It may be profitable to use Arrays.mismatch again after expanded characters are determined to be equal.
> 
> Take another look at the data structure storing and doing the lookup of foldIfDefined both to increase the lookup performance.

With the following changes

- Use int[] / code point storage instead of char[] / char for folding data.
- Add a fast path for Latin-1 vs. Latin-1 comparisons.
- Speed up the UTF-16 path as well.

The only remaining ?slow? path is Latin-1 vs. UTF-16 for now.
Would appreciate some eagle eyes on the new fast-path implementation.  The tests suggest it?s working as expected :-)

**StringCompareToFoldCase.latin1UTF16          avgt   15  23.959 ? 2.357  ns/op
StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.455 ? 0.104  ns/op
StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  32.782 ? 0.962  ns/op
StringCompareToFoldCase.latin1UTF16FC        avgt   15  32.581 ? 0.725  ns/op**


Benchmark                                    Mode  Cnt   Score   Error  Units
StringCompareToFoldCase.asciiLower           avgt   15  17.983 ? 0.208  ns/op
StringCompareToFoldCase.asciiLowerEQ         avgt   15   9.986 ? 0.254  ns/op
StringCompareToFoldCase.asciiLowerEQFC       avgt   15  10.781 ? 0.161  ns/op
StringCompareToFoldCase.asciiLowerFC         avgt   15  10.274 ? 0.136  ns/op
StringCompareToFoldCase.asciiUpperLower      avgt   15  12.465 ? 0.409  ns/op
StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  10.961 ? 0.407  ns/op
StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   9.157 ? 0.166  ns/op
StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   9.228 ? 0.254  ns/op
StringCompareToFoldCase.asciiWithDFFC        avgt   15  57.603 ? 1.540  ns/op
StringCompareToFoldCase.greekLower           avgt   15  39.593 ? 0.128  ns/op
StringCompareToFoldCase.greekLowerEQ         avgt   15  39.249 ? 0.032  ns/op
StringCompareToFoldCase.greekLowerEQFC       avgt   15  13.993 ? 0.346  ns/op
StringCompareToFoldCase.greekLowerFC         avgt   15  14.030 ? 0.454  ns/op
StringCompareToFoldCase.greekUpperLower      avgt   15   7.137 ? 0.130  ns/op
StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.496 ? 0.104  ns/op
StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   6.203 ? 0.316  ns/op
StringCompareToFoldCase.greekUpperLowerFC    avgt   15   6.235 ? 0.256  ns/op
StringCompareToFoldCase.latin1UTF16          avgt   15  23.959 ? 2.357  ns/op
StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.455 ? 0.104  ns/op
StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  32.782 ? 0.962  ns/op
StringCompareToFoldCase.latin1UTF16FC        avgt   15  32.581 ? 0.725  ns/op
StringCompareToFoldCase.supLower             avgt   15  54.918 ? 0.809  ns/op
StringCompareToFoldCase.supLowerEQ           avgt   15  55.080 ? 0.511  ns/op
StringCompareToFoldCase.supLowerEQFC         avgt   15  14.085 ? 0.996  ns/op
StringCompareToFoldCase.supLowerFC           avgt   15  13.907 ? 0.612  ns/op
StringCompareToFoldCase.supUpperLower        avgt   15  14.479 ? 0.175  ns/op
StringCompareToFoldCase.supUpperLowerEQ      avgt   15  14.645 ? 0.059  ns/op
StringCompareToFoldCase.supUpperLowerEQFC    avgt   15   9.200 ? 0.310  ns/op
StringCompareToFoldCase.supUpperLowerFC      avgt   15   9.041 ? 0.248  ns/op

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2441849469

From duke at openjdk.org  Sat Oct 18 16:29:03 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 18 Oct 2025 16:29:03 GMT
Subject: RFR: 8366478: BigDecimal roots
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 
 
 
Message-ID: <2x2hhXQ16C64qoOqKmJC_AA7Bc__FtWxql86nQl-98w=.7689033c-a303-4d4b-8fa7-48df73a91736@github.com>

On Wed, 15 Oct 2025 15:17:56 GMT, Raffaello Giulietti  wrote:

>> @rgiulietti 
>>> * How much code would be needed to attain correct rounding in all modes?
>> 
>> The best that can be done is to make the probability of an incorrect rounding as small as desired, but this can be computationally expensive: a probability within $10^{-k}$ means that the integer root must have $k$ more digits, and so the radicand must have $n \cdot k$ more digits.
>
> @fabioromano1 I think it is OK to have more efficient code even if the result is not correctly rounded.
> Please add some code comment about your error analysis.

@rgiulietti
> * How much code would be needed to attain correct rounding in all modes?

I found a way to make the procedure for correct rounding deterministic, but it would complicate the code a lot, and of course it would be potentially expensive in terms of running time, since the number of additional digits to compute is finite but not bounded by a constant. So, if it were to be implemented, the choice to have a correct rounding could be left to the user.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27148#issuecomment-3418630905

From rgiulietti at openjdk.org  Sat Oct 18 17:52:03 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 18 Oct 2025 17:52:03 GMT
Subject: RFR: 8366478: BigDecimal roots
In-Reply-To: <2x2hhXQ16C64qoOqKmJC_AA7Bc__FtWxql86nQl-98w=.7689033c-a303-4d4b-8fa7-48df73a91736@github.com>
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 
 
 
 
 <2x2hhXQ16C64qoOqKmJC_AA7Bc__FtWxql86nQl-98w=.7689033c-a303-4d4b-8fa7-48df73a91736@github.com>
Message-ID: 

On Sat, 18 Oct 2025 16:26:42 GMT, fabioromano1  wrote:

>> @fabioromano1 I think it is OK to have more efficient code even if the result is not correctly rounded.
>> Please add some code comment about your error analysis.
>
> @rgiulietti
>> * How much code would be needed to attain correct rounding in all modes?
> 
> I found a way to make the procedure for correct rounding deterministic, but it would complicate the code a lot, and of course it would be potentially expensive in terms of running time, since the number of additional digits to compute is finite but not bounded by a constant. So, if it were to be implemented, I think the choice to have a correct rounding should be left to the user.

@fabioromano1 Thanks for investigating. I'd stick with the current solution for now.

BTW, @jddarcy opened a [PR](https://github.com/openjdk/jdk/pull/27882) for the preferred scale in `sqrt()`, so there might be a need to change the spec and implementation slightly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27148#issuecomment-3418697999

From dl at openjdk.org  Sat Oct 18 18:17:40 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 18 Oct 2025 18:17:40 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v14]
In-Reply-To: 
References: 
Message-ID: 

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Fix push, refactor deactivate

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/cf5f844e..a1596050

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=12-13

  Stats: 141 lines in 1 file changed: 53 ins; 43 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

PR: https://git.openjdk.org/jdk/pull/26479

From duke at openjdk.org  Sun Oct 19 02:18:43 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Sun, 19 Oct 2025 02:18:43 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v12]
In-Reply-To: 
References: 
Message-ID: <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/e0741b17..5ea6933b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=10-11

  Stats: 19 lines in 1 file changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

PR: https://git.openjdk.org/jdk/pull/27807

From duke at openjdk.org  Sun Oct 19 02:18:44 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Sun, 19 Oct 2025 02:18:44 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: 
References: 
 
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
 
 
Message-ID: <7kU60fP_Aw4oiwfwMN48YfFwC70wVObcHQpSXqZvyC4=.5094fe4c-de7e-4a96-8000-121a9db66ae5@github.com>

On Fri, 17 Oct 2025 20:18:24 GMT, Valerie Peng  wrote:

>> I did make changes based on your code to eliminate len and updates to variable names.
>
> Yes, I take a second look and maybe a smaller adjustments would work as well. E.g,
> 1) nit: method name `invGenRoundKeys`  -> `genInvRoundKeys`
> 2) make this method static by passing `sessionKey[0]` and `rounds` as arguments,
> 3) no need for `len` since it's always `WB`
> 4) for the intermediate buffer of 4 words, can we not use `w` as this name is used in both the spec and genRoundKeys method as "Word array for the key schedule". It'd help people understand the code better if we adopt the same naming convention in "Algorithm 5 Pseudocode for KEYEXPANSIONEIC()", e.g. `temp` for the intermediate buffer and `dw` for the final result.

Sorry, missed this comment in the melee.  Re: 1) method name, agreed; 2) to static, agreed; 3) remove len, prior commit; 4) variable name alignment, agreed.  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2442722654

From alanb at openjdk.org  Sun Oct 19 07:03:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 19 Oct 2025 07:03:06 GMT
Subject: RFR: 8369432: Add Support for JDBC 4.5 MR [v8]
In-Reply-To: 
References: <2Br2xZeZ9tcaovbPf8ztcQLyrjL2oGwg26qRtpRgsmQ=.60f59d39-e500-42e7-9f2a-e3adda527431@github.com>
 
Message-ID: 

On Fri, 17 Oct 2025 22:12:25 GMT, Lance Andersen  wrote:

>> This PR adds support for the upcoming JDBC 4.5 MR which provides the following  updates to the JDBC specification:
>> 
>> - Deprecate SQLPermission for removal
>> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support AutoClosable
>> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
>> - Add the quoted identifier methods that **were added previously to the Statement interface in JDK 9** to the Connection interface
>>   - It is the exact same verbiage & default methods used when these methods were added to the Statement interface
>> - Clarify the Timestamp::hashCode method which incorrectly indicates that nanos are not used when calculating the hash
>> 
>> Tiers 1-3 have been run
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor wordsmithing based on approved CSR feedback

src/java.sql/share/classes/java/sql/Connection.java line 1722:

> 1720: 
> 1721:     /**
> 1722:      * Returns a SQL identifier. If {@code identifier} is a simple SQL identifier:

"simple SQL identifier" is used in several places, is there anywhere that (at least first) usages could link to see the definition of this?

src/java.sql/share/classes/java/sql/package-info.java line 176:

> 174:  * 
> 175:  *
> 176:  *     
    {@code java.sql} and {@code javax.sql} Features Introduced in the JDBC 4.5 API
    

The title is consistent with the other updates but I'm wondering why it hasn't been switched to "module java.sql".

src/java.sql/share/classes/java/sql/package-info.java line 347:

> 345:  *
> 346:  * 

Why does ZERO deserves a discussion as a special case? Isn't ZERO already covered by the general contract?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2466979110

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 duke at openjdk.org  Mon Oct 27 20:50:15 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 27 Oct 2025 20:50:15 GMT
Subject: RFR: 8366478: BigDecimal roots [v25]
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 <46-VBAJRLDdG66FU6IxuHzbl8XD_V7L_YIzA9FAYOnE=.46304352-888c-4dd9-8157-cb27a5e3248b@github.com>
 
Message-ID: 

On Mon, 27 Oct 2025 20:23:39 GMT, Raffaello Giulietti  wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update method name in comments
>
> src/java.base/share/classes/java/math/BigDecimal.java line 2169:
> 
>> 2167:      * {@code ZERO}, {@code ZERO.rootn(n, mc).equals(ZERO)} is true with
>> 2168:      * any {@code MathContext} as an argument.
>> 2169:      * 
> 
> Why does ZERO deserves a discussion as a special case? Isn't ZERO already covered by the general contract?

Simply to mimic `sqrt()` spec, no particular reason.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2467034526

From rgiulietti at openjdk.org  Mon Oct 27 20:58:12 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 27 Oct 2025 20:58:12 GMT
Subject: RFR: 8366478: BigDecimal roots [v25]
In-Reply-To: 
References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com>
 <46-VBAJRLDdG66FU6IxuHzbl8XD_V7L_YIzA9FAYOnE=.46304352-888c-4dd9-8157-cb27a5e3248b@github.com>
 
 
Message-ID: 

On Mon, 27 Oct 2025 20:47:52 GMT, fabioromano1  wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 2169:
>> 
>>> 2167:      * {@code ZERO}, {@code ZERO.rootn(n, mc).equals(ZERO)} is true with
>>> 2168:      * any {@code MathContext} as an argument.
>>> 2169:      * 
>> 
>> Why does ZERO deserves a discussion as a special case? Isn't ZERO already covered by the general contract?
>
> Simply to mimic `sqrt()` spec, no particular reason.

I reviewed the CSR. If you have nothing to add/modify you can "finalize" it, hence moving it to "finalized".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27148#discussion_r2467057476

From bpb at openjdk.org  Mon Oct 27 21:17:25 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Oct 2025 21:17:25 GMT
Subject: Integrated: 8370387: Remove handling of InterruptedIOException from
 java.io classes
In-Reply-To: 
References: 
Message-ID: <68i14WeXZ73a-vVF32tSt4C2fdh1u6Ow37WZ6qWMM4s=.3008e422-dbe4-458f-b704-a1689953d41a@github.com>

On Wed, 22 Oct 2025 18:26:16 GMT, Brian Burkhalter  wrote:

> Remove catching `InterruptedIOException` and throw `IOException` in response to `InterruptedException` instead of throwing `InterruptedIOException`.

This pull request has now been integrated.

Changeset: 2f613911
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/2f613911d58478913dc482e1500d3fbab74408b9
Stats:     38 lines in 2 files changed: 0 ins; 36 del; 2 mod

8370387: Remove handling of InterruptedIOException from java.io classes

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/27941

From bpb at openjdk.org  Mon Oct 27 21:18:18 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Oct 2025 21:18:18 GMT
Subject: RFR: 8370633: Remove dead code for Windows file path
 canonicalization functions
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 25 Oct 2025 06:52:30 GMT, Alan Bateman  wrote:

> Can you make sure to do a test run with the changes? (a build test isn't enough).

Tier 1-3 tests passed. I also previously did a find+grep on the code base and didn't spot anything.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27981#issuecomment-3453367406

From bpb at openjdk.org  Mon Oct 27 21:18:19 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Oct 2025 21:18:19 GMT
Subject: Integrated: 8370633: Remove dead code for Windows file path
 canonicalization functions
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Oct 2025 19:21:38 GMT, Brian Burkhalter  wrote:

> Remove the unused, vestigial functions `wcanonicalizeWithPrefix` and `Java_java_io_WinNTFileSystem_canonicalizeWithPrefix0`. With this change, the build in the CI succeeds on Windows.

This pull request has now been integrated.

Changeset: 4e8e55db
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/4e8e55db602702715135d28a3a3b160e2101593b
Stats:     94 lines in 2 files changed: 0 ins; 94 del; 0 mod

8370633: Remove dead code for Windows file path canonicalization functions

Reviewed-by: alanb, iris

-------------

PR: https://git.openjdk.org/jdk/pull/27981

From davidalayachew at gmail.com  Mon Oct 27 21:19:34 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 27 Oct 2025 17:19:34 -0400
Subject: Could we add \a as an escape sequence for bell?
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

Woah, thanks.

So, in your second example, it's literally complaining because, as far as
the Java compiler is concerned, I typed in a literal new line in between
the single quotes, right? Like this?

System.out.println('
');

Correct?

Very important context, ty vm.

So, \7 is fine because that actually is an escape sequence. Much like \n
and friends.

But \uXXXX gets turned into the literal bytes, which means that something
like a new line gets treated as if I literally pressed the new line button
on my keyboard, which means that it's treated not as a new line character
in my string, but as a new line character in my source file itself lol.

Ty vm.


On Mon, Oct 27, 2025, 9:44?AM Pavel Rappo  wrote:

> Correcting a typo*:
>
>     jshell> System.out.println('\u000A')
>     |  Error:
>     |  illegal line end in character literal
>     |  System.out.println('\u000A')
>     |
>
>
> On Mon, Oct 27, 2025 at 1:32?PM Pavel Rappo  wrote:
> >
> > A word of caution. While in this use case the difference is probably
> > non-essential, Unicode escapes (e.g. \u0007) are __not__ a kind of
> > escape sequences (e.g. \7). The former are translated into raw bytes
> > __before__ the compiler goes any further. The latter are recognised by
> > the compiler only in context of character literals, strings, or text
> > blocks.
> >
> > To illustrate the difference, let's consider "line feed" (0xA):
> >
> >     jshell> System.out.println('\n')
> >
> >
> >
> >     jshell> System.out.println('\000A')
> >     |  Error:
> >     |  unclosed character literal
> >     |  System.out.println('\000A')
> >     |                     ^
> >
> > While the former is recognised within the context of a character
> > literal, the latter just breaks the source code in a similar way as if
> > the source code had the actual line feed in it.
> >
> > Unicode escapes allow you to simply input a Unicode character "by
> > reference". This is convenient in some cases, such as when your
> > environment cannot output these characters conveniently or display
> > them properly.
> >
> > -Pavel
> >
> > On Mon, Oct 27, 2025 at 12:56?PM David Alayachew
> >  wrote:
> > >
> > > Ah, I misread the JLS Language Grammar!
> > >
> > > I was aware of \u0007, but not \7. I see now that that works. Then
> nevermind, that meets my needs just fine. No need for my suggestion.
> > >
> > > The 4 digit unicode is fine, a good escape hatch, but also easy to
> forget, since my brain interprets all 4 digits as significant. And char
> bell = 7; is also unideal. But a 1 digit escape works perfectly for me.
> Would have preferred \a, but \7 is more explicit and easier to look up.
> > >
> > > Ty vm!
> > >
> > > On Mon, Oct 27, 2025, 6:15?AM Andrew Dinn  wrote:
> > >>
> > >>
> > >>
> > >> On 26/10/2025 17:26, David Alayachew wrote:
> > >> > Also, here is the JLS 25 entry about escape sequences -- https://
> > >> > docs.oracle.com/javase/specs/jls/se25/html/jls-3.html#jls-3.10.7
> > >> > <
> https://docs.oracle.com/javase/specs/jls/se25/html/jls-3.html#jls-3.10.7>
> > >> >
> > >> > All I really want is for that to be added to the list, so that I
> can do
> > >> > it the same as I would in other languages. It sounds like an
> in-place
> > >> > replacement done by the compiler.
> > >>
> > >> What is wrong with using \u0007 or \7? (as documented in the html page
> > >> you cited).
> > >>
> > >> regards,
> > >>
> > >>
> > >> Andrew Dinn
> > >> -----------
> > >> Red Hat Distinguished Engineer
> > >> He/Him/His
> > >> IBM UK Limited
> > >> Registered in England and Wales with number 741598
> > >> Registered office: Building C, IBM Hursley Office, Hursley Park Road,
> > >> Winchester, Hampshire SO21 2JN
> > >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From coleenp at openjdk.org  Mon Oct 27 21:30:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Oct 2025 21:30:22 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Oct 2025 19:44:53 GMT, Patricio Chilano Mateo  wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment in anchor_mark_set_pd

I had a very small comment that I noticed, but this looks great.  Excellent work solving this class initialization problem for virtual threads.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1796:

> 1794: }
> 1795: 
> 1796: static void log_preempt_after_freeze(ContinuationWrapper& cont) {

Does this modify ContinuationWrapper?  I don't see how it does.  If not, it should be a const reference.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2680:

> 2678: }
> 2679: 
> 2680: intptr_t* ThawBase::redo_vmcall(JavaThread* current, frame& top) {

Does this modify "top"?  Else should be a const reference too. Looks like a lot of references are non-const.  If these methods don't modify their non-const reference parameters, I think you should have a cleanup pass to fix these to be const references.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3385513965
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2467117304
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2467122440

From almatvee at openjdk.org  Mon Oct 27 22:37:04 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 27 Oct 2025 22:37:04 GMT
Subject: RFR: 8370100: Redundant .png files in Linux app-image cause
 unnecessary bloat [v2]
In-Reply-To: 
References: 
 
 <-j2FC7AvA-AmlRRrcfmMKr9ngYyjCXoFUOVp2ngeF9E=.cdeb2f80-b0e7-4220-8b35-f2bf78424aa6@github.com>
 
Message-ID: 

On Sat, 25 Oct 2025 14:48:04 GMT, Alexey Semenyuk  wrote:

>> src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackagingPipeline.java line 62:
>> 
>>> 60:         pkg.ifPresent(_ -> {
>>> 61:             builder.task(LinuxAppImageTaskID.LAUNCHER_ICONS).noaction().add();
>>> 62:         });
>> 
>> Can you explain what this code do? We already have `LAUNCHER_ICONS` task at line 55. Why we need a second one and without action?
>
> This is the same task but with a disabled action. Task graph doesn't allow multiple tasks with the same ID.
> 
> By default, the `LAUNCHER_ICONS` task copies launcher icon files to the app image. However, when bundling a native package, this action should not be executed because the `DesktopIntegration` class adds launcher icons to the package.
> 
> Before this change, jpackage copied launcher icon files twice when building a native package: in `LAUNCHER_ICONS` task and in `DesktopIntegration` class.
> 
> Function name `add()` is confusing. Should be `apply()` or `commit()`.

Thanks for explanation. Make sense now. Should we do something like:

if (pkg.isEmpty()) {
.task(LinuxAppImageTaskID.LAUNCHER_ICONS)
                        .addDependent(BuildApplicationTaskID.CONTENT)
                        .applicationAction(LinuxPackagingPipeline::writeLauncherIcons).add();
}

Add task only for application image vs adding it always and then overwriting with noaction()?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27928#discussion_r2467274568

From liach at openjdk.org  Mon Oct 27 22:39:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 Oct 2025 22:39:07 GMT
Subject: RFR: 8368172: Make java.time.format.DateTimePrintContext immutable
 [v6]
In-Reply-To: <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com>
References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com>
 <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com>
Message-ID: 

On Thu, 2 Oct 2025 03:08:32 GMT, Shaojin Wen  wrote:

>> I propose to make j.t.f.DateTimePrintContext immutable.
>> 
>> Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method.
>> 
>> Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadoc for optional parameter in DateTimePrinterParser#format method

I think this is a good change. This allows DateTimePrintContext to be refactored to a value class later, which may unlock more optimization opportunities.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26913#pullrequestreview-3385723601

From liach at openjdk.org  Mon Oct 27 22:46:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 Oct 2025 22:46:02 GMT
Subject: RFR: 8368172: Make java.time.format.DateTimePrintContext immutable
 [v6]
In-Reply-To: <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com>
References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com>
 <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com>
Message-ID: <_oV91W9qIUrqzO5uHqYvXqwdZ4Fk_hd1XiP-rmy-WX8=.e68558ee-b549-4b6e-954b-724520968577@github.com>

On Thu, 2 Oct 2025 03:08:32 GMT, Shaojin Wen  wrote:

>> I propose to make j.t.f.DateTimePrintContext immutable.
>> 
>> Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method.
>> 
>> Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadoc for optional parameter in DateTimePrinterParser#format method

I have sent an internal CI run for this patch after merging latest mainline. Let's make sure the build looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26913#issuecomment-3453612817

From pavel.rappo at gmail.com  Mon Oct 27 22:53:19 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Mon, 27 Oct 2025 22:53:19 +0000
Subject: Could we add \a as an escape sequence for bell?
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Mon, Oct 27, 2025 at 9:19?PM David Alayachew
 wrote:
>
> Woah, thanks.
>
> So, in your second example, it's literally complaining because, as far as the Java compiler is concerned, I typed in a literal new line in between the single quotes, right? Like this?
>
> System.out.println('
> ');
>
> Correct?

Yes.

> Very important context, ty vm.
>
> So, \7 is fine because that actually is an escape sequence. Much like \n and friends.

Yes. BTW, another way to write down \n would be \12:

    jshell> Integer.toOctalString('\n')
    $1 ==> "12"

    jshell> '\n' == '\12'
    $2 ==> true

> But \uXXXX gets turned into the literal bytes, which means that something like a new line gets treated as if I literally pressed the new line button on my keyboard, which means that it's treated not as a new line character in my string, but as a new line character in my source file itself lol.
>
> Ty vm.

Like I said, escape sequences are only recognised in certain context.
But unicode escapes are recognised everywhere. For example, \n does
not mean anything in a javadoc comment, On the other hand, \u000A
means the same thing wherever it appears: source, javadoc, or your
copyright header. Still, \n and \u000A are not the same:

    jshell> '\n' == '\u000A'

    |  Error:
    |  illegal line end in character literal
    |  '\n' == '\u000A'
    |          ^

-Pavel


-Pavel

> On Mon, Oct 27, 2025, 9:44?AM Pavel Rappo  wrote:
>>
>> Correcting a typo*:
>>
>>     jshell> System.out.println('\u000A')
>>     |  Error:
>>     |  illegal line end in character literal
>>     |  System.out.println('\u000A')
>>     |
>>
>>
>> On Mon, Oct 27, 2025 at 1:32?PM Pavel Rappo  wrote:
>> >
>> > A word of caution. While in this use case the difference is probably
>> > non-essential, Unicode escapes (e.g. \u0007) are __not__ a kind of
>> > escape sequences (e.g. \7). The former are translated into raw bytes
>> > __before__ the compiler goes any further. The latter are recognised by
>> > the compiler only in context of character literals, strings, or text
>> > blocks.
>> >
>> > To illustrate the difference, let's consider "line feed" (0xA):
>> >
>> >     jshell> System.out.println('\n')
>> >
>> >
>> >
>> >     jshell> System.out.println('\000A')
>> >     |  Error:
>> >     |  unclosed character literal
>> >     |  System.out.println('\000A')
>> >     |                     ^
>> >
>> > While the former is recognised within the context of a character
>> > literal, the latter just breaks the source code in a similar way as if
>> > the source code had the actual line feed in it.
>> >
>> > Unicode escapes allow you to simply input a Unicode character "by
>> > reference". This is convenient in some cases, such as when your
>> > environment cannot output these characters conveniently or display
>> > them properly.
>> >
>> > -Pavel
>> >
>> > On Mon, Oct 27, 2025 at 12:56?PM David Alayachew
>> >  wrote:
>> > >
>> > > Ah, I misread the JLS Language Grammar!
>> > >
>> > > I was aware of \u0007, but not \7. I see now that that works. Then nevermind, that meets my needs just fine. No need for my suggestion.
>> > >
>> > > The 4 digit unicode is fine, a good escape hatch, but also easy to forget, since my brain interprets all 4 digits as significant. And char bell = 7; is also unideal. But a 1 digit escape works perfectly for me. Would have preferred \a, but \7 is more explicit and easier to look up.
>> > >
>> > > Ty vm!
>> > >
>> > > On Mon, Oct 27, 2025, 6:15?AM Andrew Dinn  wrote:
>> > >>
>> > >>
>> > >>
>> > >> On 26/10/2025 17:26, David Alayachew wrote:
>> > >> > Also, here is the JLS 25 entry about escape sequences -- https://
>> > >> > docs.oracle.com/javase/specs/jls/se25/html/jls-3.html#jls-3.10.7
>> > >> > 
>> > >> >
>> > >> > All I really want is for that to be added to the list, so that I can do
>> > >> > it the same as I would in other languages. It sounds like an in-place
>> > >> > replacement done by the compiler.
>> > >>
>> > >> What is wrong with using \u0007 or \7? (as documented in the html page
>> > >> you cited).
>> > >>
>> > >> regards,
>> > >>
>> > >>
>> > >> Andrew Dinn
>> > >> -----------
>> > >> Red Hat Distinguished Engineer
>> > >> He/Him/His
>> > >> IBM UK Limited
>> > >> Registered in England and Wales with number 741598
>> > >> Registered office: Building C, IBM Hursley Office, Hursley Park Road,
>> > >> Winchester, Hampshire SO21 2JN
>> > >>
>>

From asemenyuk at openjdk.org  Mon Oct 27 23:02:01 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 27 Oct 2025 23:02:01 GMT
Subject: RFR: 8370100: Redundant .png files in Linux app-image cause
 unnecessary bloat [v2]
In-Reply-To: 
References: 
 
 <-j2FC7AvA-AmlRRrcfmMKr9ngYyjCXoFUOVp2ngeF9E=.cdeb2f80-b0e7-4220-8b35-f2bf78424aa6@github.com>
 
 
Message-ID: <_Hpdb66cEs9kYPX9m8kCVv6quDotUjcHtU2EPO5nvtg=.f1b95ede-5f0f-4ede-baf8-3c9d41066c14@github.com>

On Mon, 27 Oct 2025 22:33:57 GMT, Alexander Matveev  wrote:

>> This is the same task but with a disabled action. Task graph doesn't allow multiple tasks with the same ID.
>> 
>> By default, the `LAUNCHER_ICONS` task copies launcher icon files to the app image. However, when bundling a native package, this action should not be executed because the `DesktopIntegration` class adds launcher icons to the package.
>> 
>> Before this change, jpackage copied launcher icon files twice when building a native package: in `LAUNCHER_ICONS` task and in `DesktopIntegration` class.
>> 
>> Function name `add()` is confusing. Should be `apply()` or `commit()`.
>
> Thanks for explanation. Make sense now. Should we do something like:
> 
> if (pkg.isEmpty()) {
> .task(LinuxAppImageTaskID.LAUNCHER_ICONS)
>                         .addDependent(BuildApplicationTaskID.CONTENT)
>                         .applicationAction(LinuxPackagingPipeline::writeLauncherIcons).add();
> }
> 
> Add task only for application image vs adding it always and then overwriting with noaction()?

We can do this, but this will complicate building the task graph by making the set of nodes and edges conditional.

It is simpler to build the graph unconditionally, but configure actions for the nodes conditionally.

E.g.: mac packaging task graph is way more sophisticated in terms of branching, see - [MacPackagingPipeline.build()](https://github.com/openjdk/jdk/blob/2f613911d58478913dc482e1500d3fbab74408b9/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java#L104). but its initialization is quite stratighforward.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27928#discussion_r2467352699

From bpb at openjdk.org  Mon Oct 27 23:24:35 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Oct 2025 23:24:35 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v8]
In-Reply-To: 
References: 
Message-ID: 

> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - 8355342: Derive final path only for reparse points
 - Merge
 - 8355342: Remove unused, vestigial code
 - 8355342: Do not check for backslash as third character of input pathname string
 - 8355342: Fall back to canonicalize0() result if drive letter converted to a long / UNC prefix
 - Merge
 - Merge
 - 8355342: Corrected a comment
 - 8355342: Add missing space in constant declaration
 - 8355342: Fix possible sneaky NullPointerException
 - ... and 1 more: https://git.openjdk.org/jdk/compare/253f1dfc...e4cad2b1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27324/files
  - new: https://git.openjdk.org/jdk/pull/27324/files/d88320a6..e4cad2b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=06-07

  Stats: 35449 lines in 890 files changed: 19072 ins; 11590 del; 4787 mod
  Patch: https://git.openjdk.org/jdk/pull/27324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27324/head:pull/27324

PR: https://git.openjdk.org/jdk/pull/27324

From davidalayachew at gmail.com  Mon Oct 27 23:54:33 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 27 Oct 2025 19:54:33 -0400
Subject: Could we add \a as an escape sequence for bell?
In-Reply-To: 
References: 
 
 
 
 
 
 
 
Message-ID: 

??

David Alayachew reacted via Gmail


On Mon, Oct 27, 2025 at 6:53?PM Pavel Rappo  wrote:

> On Mon, Oct 27, 2025 at 9:19?PM David Alayachew
>  wrote:
> >
> > Woah, thanks.
> >
> > So, in your second example, it's literally complaining because, as far
> as the Java compiler is concerned, I typed in a literal new line in between
> the single quotes, right? Like this?
> >
> > System.out.println('
> > ');
> >
> > Correct?
>
> Yes.
>
> > Very important context, ty vm.
> >
> > So, \7 is fine because that actually is an escape sequence. Much like \n
> and friends.
>
> Yes. BTW, another way to write down \n would be \12:
>
>     jshell> Integer.toOctalString('\n')
>     $1 ==> "12"
>
>     jshell> '\n' == '\12'
>     $2 ==> true
>
> > But \uXXXX gets turned into the literal bytes, which means that
> something like a new line gets treated as if I literally pressed the new
> line button on my keyboard, which means that it's treated not as a new line
> character in my string, but as a new line character in my source file
> itself lol.
> >
> > Ty vm.
>
> Like I said, escape sequences are only recognised in certain context.
> But unicode escapes are recognised everywhere. For example, \n does
> not mean anything in a javadoc comment, On the other hand, \u000A
> means the same thing wherever it appears: source, javadoc, or your
> copyright header. Still, \n and \u000A are not the same:
>
>     jshell> '\n' == '\u000A'
>
>     |  Error:
>     |  illegal line end in character literal
>     |  '\n' == '\u000A'
>     |          ^
>
> -Pavel
>
>
> -Pavel
>
> > On Mon, Oct 27, 2025, 9:44?AM Pavel Rappo  wrote:
> >>
> >> Correcting a typo*:
> >>
> >>     jshell> System.out.println('\u000A')
> >>     |  Error:
> >>     |  illegal line end in character literal
> >>     |  System.out.println('\u000A')
> >>     |
> >>
> >>
> >> On Mon, Oct 27, 2025 at 1:32?PM Pavel Rappo 
> wrote:
> >> >
> >> > A word of caution. While in this use case the difference is probably
> >> > non-essential, Unicode escapes (e.g. \u0007) are __not__ a kind of
> >> > escape sequences (e.g. \7). The former are translated into raw bytes
> >> > __before__ the compiler goes any further. The latter are recognised by
> >> > the compiler only in context of character literals, strings, or text
> >> > blocks.
> >> >
> >> > To illustrate the difference, let's consider "line feed" (0xA):
> >> >
> >> >     jshell> System.out.println('\n')
> >> >
> >> >
> >> >
> >> >     jshell> System.out.println('\000A')
> >> >     |  Error:
> >> >     |  unclosed character literal
> >> >     |  System.out.println('\000A')
> >> >     |                     ^
> >> >
> >> > While the former is recognised within the context of a character
> >> > literal, the latter just breaks the source code in a similar way as if
> >> > the source code had the actual line feed in it.
> >> >
> >> > Unicode escapes allow you to simply input a Unicode character "by
> >> > reference". This is convenient in some cases, such as when your
> >> > environment cannot output these characters conveniently or display
> >> > them properly.
> >> >
> >> > -Pavel
> >> >
> >> > On Mon, Oct 27, 2025 at 12:56?PM David Alayachew
> >> >  wrote:
> >> > >
> >> > > Ah, I misread the JLS Language Grammar!
> >> > >
> >> > > I was aware of \u0007, but not \7. I see now that that works. Then
> nevermind, that meets my needs just fine. No need for my suggestion.
> >> > >
> >> > > The 4 digit unicode is fine, a good escape hatch, but also easy to
> forget, since my brain interprets all 4 digits as significant. And char
> bell = 7; is also unideal. But a 1 digit escape works perfectly for me.
> Would have preferred \a, but \7 is more explicit and easier to look up.
> >> > >
> >> > > Ty vm!
> >> > >
> >> > > On Mon, Oct 27, 2025, 6:15?AM Andrew Dinn  wrote:
> >> > >>
> >> > >>
> >> > >>
> >> > >> On 26/10/2025 17:26, David Alayachew wrote:
> >> > >> > Also, here is the JLS 25 entry about escape sequences -- https://
> >> > >> > docs.oracle.com/javase/specs/jls/se25/html/jls-3.html#jls-3.10.7
> >> > >> > <
> https://docs.oracle.com/javase/specs/jls/se25/html/jls-3.html#jls-3.10.7>
> >> > >> >
> >> > >> > All I really want is for that to be added to the list, so that I
> can do
> >> > >> > it the same as I would in other languages. It sounds like an
> in-place
> >> > >> > replacement done by the compiler.
> >> > >>
> >> > >> What is wrong with using \u0007 or \7? (as documented in the html
> page
> >> > >> you cited).
> >> > >>
> >> > >> regards,
> >> > >>
> >> > >>
> >> > >> Andrew Dinn
> >> > >> -----------
> >> > >> Red Hat Distinguished Engineer
> >> > >> He/Him/His
> >> > >> IBM UK Limited
> >> > >> Registered in England and Wales with number 741598
> >> > >> Registered office: Building C, IBM Hursley Office, Hursley Park
> Road,
> >> > >> Winchester, Hampshire SO21 2JN
> >> > >>
> >>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/vnd.google.email-reaction+json
Size: 39 bytes
Desc: not available
URL: 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From almatvee at openjdk.org  Tue Oct 28 00:43:04 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 28 Oct 2025 00:43:04 GMT
Subject: RFR: 8370100: Redundant .png files in Linux app-image cause
 unnecessary bloat [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Oct 2025 21:42:25 GMT, Alexey Semenyuk  wrote:

>> Don't put the default icon (.png) files in the app image on Linux.
>> 
>> A simple fix would be to add a condition to `LinuxPackagingPipeline.writeLauncherIcons()` without changing interfaces in the model. However, this would leave unaddressed a long-standing issue with `ApplicationImageUtils.createLauncherIconResource()` function that requires the main launcher to calculate an icon resource for an additional launcher. At the packaging phase, any `Launcher` instance should be self-sufficient. Fixing `ApplicationImageUtils.createLauncherIconResource()` required adding a new interface `ResourceDirLauncherIcon` to the model and changing the semantics of the `DefaultLauncherIcon` interface.
>> 
>> A new `ApplicationBuilder.normalizeLauncherProperty()` function has been added to calculate the value of an additional launcher's property from the value of this property in the main launcher. The function is supposed to calculate a description, shortcuts, an icon, and any future launcher property. For now, it is used to calculate the launcher icon.
>
> Alexey Semenyuk 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 eight new commits since the last revision:
> 
>  - DefaultLauncherIcon: blessed-modifier-order.sh  fix
>  - FileAssociations: revert redundant change
>  - Fix fa icon verification on Linux
>  - LinuxPackagingPipeline, WinPackagingPipeline: remove unused normalizeShortcuts() methods
>  - IconTest: revamp
>  - LinuxHelper: revamp
>  - Don't add the default launcher icon to app image on Linux
>  - Make Launcher interface provide complete information about the source of the launcher icon; Before this change, the function getting a resource for an additional launcher icon took both the additional launcher and the main launcher as input. Now its result doesn't depend on the main launcher.

Looks good. Thanks for detailed explanation.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27928#pullrequestreview-3386074642

From asemenyuk at openjdk.org  Tue Oct 28 03:13:12 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 28 Oct 2025 03:13:12 GMT
Subject: Integrated: 8370100: Redundant .png files in Linux app-image cause
 unnecessary bloat
In-Reply-To: 
References: 
Message-ID: 

On Wed, 22 Oct 2025 04:36:25 GMT, Alexey Semenyuk  wrote:

> Don't put the default icon (.png) files in the app image on Linux.
> 
> A simple fix would be to add a condition to `LinuxPackagingPipeline.writeLauncherIcons()` without changing interfaces in the model. However, this would leave unaddressed a long-standing issue with `ApplicationImageUtils.createLauncherIconResource()` function that requires the main launcher to calculate an icon resource for an additional launcher. At the packaging phase, any `Launcher` instance should be self-sufficient. Fixing `ApplicationImageUtils.createLauncherIconResource()` required adding a new interface `ResourceDirLauncherIcon` to the model and changing the semantics of the `DefaultLauncherIcon` interface.
> 
> A new `ApplicationBuilder.normalizeLauncherProperty()` function has been added to calculate the value of an additional launcher's property from the value of this property in the main launcher. The function is supposed to calculate a description, shortcuts, an icon, and any future launcher property. For now, it is used to calculate the launcher icon.

This pull request has now been integrated.

Changeset: 327b7c3c
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/327b7c3cd854bea3ffce557b981df535d5ed04bf
Stats:     565 lines in 25 files changed: 431 ins; 49 del; 85 mod

8370100: Redundant .png files in Linux app-image cause unnecessary bloat

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/27928

From iklam at openjdk.org  Tue Oct 28 04:06:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 04:06:41 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v2]
In-Reply-To: 
References: 
Message-ID: 

> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Added StatelessOopsFinder

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27880/files
  - new: https://git.openjdk.org/jdk/pull/27880/files/a886aa85..c6ea93c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=00-01

  Stats: 217 lines in 4 files changed: 211 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27880/head:pull/27880

PR: https://git.openjdk.org/jdk/pull/27880

From iklam at openjdk.org  Tue Oct 28 04:06:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 04:06:41 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Oct 2025 08:48:40 GMT, Per Minborg  wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added StatelessOopsFinder
>
> src/hotspot/share/cds/cdsHeapVerifier.cpp line 186:
> 
>> 184:     if (fd->signature()->starts_with("Ljdk/internal/access/") &&
>> 185:         fd->signature()->ends_with("Access;")) {
>> 186:       // The jdk/internal/access/*Access classes carry no states so they can be safely
> 
> This might be true for the time being, but adding such an assumption is a constraint for the future and should be documented. Perhaps we should have an interface `Access` that the various access classes implement, and where we could document this and other constraints of the access classes.

I removed this hard-coded check and instead added `CDSHeapVerifier::add_shared_secret_accessors()`, which requires all AOT-initialized accessors to be stateless.

I also added a negative test case for `SharedSecrets::javaObjectInputFilterAccess`, which is not stateless so it cannot be initialized in the AOT assembly phase.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2467807545

From iklam at openjdk.org  Tue Oct 28 04:06:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 04:06:41 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v2]
In-Reply-To: 
References: 
 
 
 
 <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com>
 
 
Message-ID: 

On Mon, 27 Oct 2025 13:25:56 GMT, ExE Boss  wrote:

> The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess.

I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2467809826

From iklam at openjdk.org  Tue Oct 28 04:10:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 04:10:01 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v2]
In-Reply-To: 
References: 
 
 
 
 <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com>
 
 
 
Message-ID: 

On Tue, 28 Oct 2025 04:03:00 GMT, Ioi Lam  wrote:

>> The?`ObjectInputStreamReadString` interface should?just be?merged into?`ObjectInputStreamAccess`:
>> 
>> SharedSecrets.setJavaObjectInputStreamAccess(new ObjectInputStreamAccess() {
>> 	public void checkArray(ObjectInputStream ois, Class arrayType, int arrayLength) throws ObjectStreamException {
>> 		ois.checkArray(arrayType, arrayLength);
>> 	}
>> 
>> 	public String readString(ObjectInputStream ois) throws IOException {
>> 		return ois.readString();
>> 	}
>> });
>
>> The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess.
> 
> I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE?

> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase?

@DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See `CDSHeapVerifier::SharedSecretsAccessorFinder::do_field()`. This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2467814022

From iklam at openjdk.org  Tue Oct 28 04:15:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 04:15:39 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v3]
In-Reply-To: 
References: 
Message-ID: 

> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into 8368199-add-aot-safe-class-initializer-annotation-to-shared-secrets
 - Added StatelessOopsFinder
 - 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27880/files
  - new: https://git.openjdk.org/jdk/pull/27880/files/c6ea93c3..6ae1172a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=01-02

  Stats: 20837 lines in 485 files changed: 12666 ins; 4954 del; 3217 mod
  Patch: https://git.openjdk.org/jdk/pull/27880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27880/head:pull/27880

PR: https://git.openjdk.org/jdk/pull/27880

From shaojin.wensj at alibaba-inc.com  Tue Oct 28 06:32:30 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Tue, 28 Oct 2025 14:32:30 +0800
Subject: =?UTF-8?B?5Zue5aSN77yaUHJvcG9zZSB0byByZW1vdmUgc3VwcG9ydCBmb3IgQ29tcGFjdFN0cmluZ3Mg?=
 =?UTF-8?B?b2Zm?=
In-Reply-To: 
References: ,
 
Message-ID: <08d048b2-5eb1-4db1-a169-a45e9f617b62.shaojin.wensj@alibaba-inc.com>

Thanks to Alan for your feedback. 
Based on Chen Liang's suggestion, I submitted a new draft PR https://github.com/openjdk/jdk/pull/27995  to add a warning message to the ComactStrings option. 
-
Shaojin Wen
------------------------------------------------------------------
????Alan Bateman 
?????2025?10?26?(??) 14:32
????"???(??)"; "core-libs-dev"
????Re: Propose to remove support for CompactStrings off
On 25/10/2025 11:53, wenshao wrote:
Initially, the option to disable CompactStrings was provided for performance reasons. 
However, with some optimizations for UTF8 scenarios and Latin1, disabling CompactStrings no longer has any performance benefits. I propose removing the related code to make it simpler and easier to maintain.
 Thanks for bringing up this topic. I don't think it can be removed without notice, any removal would at least need to start with deprecating the CompactStrings VM option.
 It would be useful to get list of the cases that dependent on -XX:-CompactString/equivalent. It was initially a contingency in the event of a performance or functional issue but I think we are past all that. Things to check are the 32-bit ARM port, is that this relevant? Other ports? IBM ports appear to care about -CompactString, maybe only with their own VM?
 -Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alan.bateman at oracle.com  Tue Oct 28 06:56:06 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 28 Oct 2025 06:56:06 +0000
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlByb3Bvc2UgdG8gcmVtb3ZlIHN1cHBvcnQgZm9y?=
 =?UTF-8?Q?_CompactStrings_off?=
In-Reply-To: <08d048b2-5eb1-4db1-a169-a45e9f617b62.shaojin.wensj@alibaba-inc.com>
References: 
 
 <08d048b2-5eb1-4db1-a169-a45e9f617b62.shaojin.wensj@alibaba-inc.com>
Message-ID: 

On 28/10/2025 06:32, wenshao wrote:
>
> Thanks to Alan for your feedback.
>
> Based on Chen Liang's suggestion, I submitted a new draft PR 
> https://github.com/openjdk/jdk/pull/27995 
>  
> to add a warning message to the ComactStrings option.

I think? first step has to be establish what or who might be using 
-XX:-CompactStrings in 2025. This means looking into the status of 
ports. Andrew Haley is going to check with folks in IBM as some of the 
bug reports for the -CompactString code paths come from ports there.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

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:18:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 07:18:07 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Oct 2025 23:24:35 GMT, Brian Burkhalter  wrote:

>> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - 8355342: Derive final path only for reparse points
>  - Merge
>  - 8355342: Remove unused, vestigial code
>  - 8355342: Do not check for backslash as third character of input pathname string
>  - 8355342: Fall back to canonicalize0() result if drive letter converted to a long / UNC prefix
>  - Merge
>  - Merge
>  - 8355342: Corrected a comment
>  - 8355342: Add missing space in constant declaration
>  - 8355342: Fix possible sneaky NullPointerException
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/642989f9...e4cad2b1

The updated approach in e4cad2b1 to get the final path when a reparse point is encountered looks good. That removes the use of GetFinalPathNameByHandle for the common cases where there is no sym link. It also aligns the behavior with Path::toRealPath. I'll do a detailed pass over the changes (to check for any overflows and other details) as soon as I can.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3454946923

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: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 jpai at openjdk.org  Tue Oct 28 10:07:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Oct 2025 10:07:57 GMT
Subject: RFR: 8370775: ModulePatcher$JarResourceFinder.getByteBuffer() does not
 close the InputStream after reading the bytes
Message-ID: 

Can I please get a review of this code which closes the `InputStream` upon usage in `ModulePatcher$JarResourceFinder.getByteBuffer()`?

As noted in https://bugs.openjdk.org/browse/JDK-8370775, this is a minor clean up to this part of the code.

tier testing is currently in progress with this change.

-------------

Commit messages:
 - 8370775: ModulePatcher.getByteBuffer() does not close the InputStream after reading the bytes

Changes: https://git.openjdk.org/jdk/pull/28014/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28014&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370775
  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28014.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28014/head:pull/28014

PR: https://git.openjdk.org/jdk/pull/28014

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 alanb at openjdk.org  Tue Oct 28 10:11:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 10:11:12 GMT
Subject: RFR: 8370775: ModulePatcher$JarResourceFinder.getByteBuffer() does
 not close the InputStream after reading the bytes
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 09:59:58 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this code which closes the `InputStream` upon usage in `ModulePatcher$JarResourceFinder.getByteBuffer()`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8370775, this is a minor clean up to this part of the code.
> 
> tier testing is currently in progress with this change.

src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 470:

> 468:                 @Override
> 469:                 public ByteBuffer getByteBuffer() throws IOException {
> 470:                     try (InputStream is = getInputStream()) {

Can you rename "is" to "in", only because "is" isn't a great name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28014#discussion_r2468863392

From jpai at openjdk.org  Tue Oct 28 10:17:38 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Oct 2025 10:17:38 GMT
Subject: RFR: 8370775: ModulePatcher$JarResourceFinder.getByteBuffer() does
 not close the InputStream after reading the bytes [v2]
In-Reply-To: 
References: 
Message-ID: 

> Can I please get a review of this code which closes the `InputStream` upon usage in `ModulePatcher$JarResourceFinder.getByteBuffer()`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8370775, this is a minor clean up to this part of the code.
> 
> tier testing is currently in progress with this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Alan's suggestion - rename "is" to "in"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28014/files
  - new: https://git.openjdk.org/jdk/pull/28014/files/83d95b09..f7f0c4f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28014&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28014&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28014.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28014/head:pull/28014

PR: https://git.openjdk.org/jdk/pull/28014

From jpai at openjdk.org  Tue Oct 28 10:17:40 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Oct 2025 10:17:40 GMT
Subject: RFR: 8370775: ModulePatcher$JarResourceFinder.getByteBuffer() does
 not close the InputStream after reading the bytes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 10:08:55 GMT, Alan Bateman  wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Alan's suggestion - rename "is" to "in"
>
> src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 470:
> 
>> 468:                 @Override
>> 469:                 public ByteBuffer getByteBuffer() throws IOException {
>> 470:                     try (InputStream is = getInputStream()) {
> 
> Can you rename "is" to "in", only because "is" isn't a great name.

Done, in the updated version of this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28014#discussion_r2468881063

From alanb at openjdk.org  Tue Oct 28 10:21:08 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 10:21:08 GMT
Subject: RFR: 8370775: ModulePatcher$JarResourceFinder.getByteBuffer() does
 not close the InputStream after reading the bytes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 10:17:38 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this code which closes the `InputStream` upon usage in `ModulePatcher$JarResourceFinder.getByteBuffer()`?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8370775, this is a minor clean up to this part of the code.
>> 
>> tier testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's suggestion - rename "is" to "in"

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28014#pullrequestreview-3387888096

From fandreuzzi at openjdk.org  Tue Oct 28 10:21:09 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 28 Oct 2025 10:21:09 GMT
Subject: RFR: 8370775: ModulePatcher$JarResourceFinder.getByteBuffer() does
 not close the InputStream after reading the bytes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 10:17:38 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this code which closes the `InputStream` upon usage in `ModulePatcher$JarResourceFinder.getByteBuffer()`?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8370775, this is a minor clean up to this part of the code.
>> 
>> tier testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's suggestion - rename "is" to "in"

Marked as reviewed by fandreuzzi (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28014#pullrequestreview-3387889109

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 rgiulietti at openjdk.org  Tue Oct 28 11:03:00 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 28 Oct 2025 11:03:00 GMT
Subject: RFR: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal [v6]
In-Reply-To: 
References: 
Message-ID: 

> Yet another step in modernizing `FloatingDecimal`s floating-point parsing.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:

 - Merge branch 'master' into 8366017
 - Added test for all float->String->float roundtrips.
 - Merge branch 'master' into 8366017
 - Added tests to exercise fast paths.
 - Fix a rare bug.
 - Merge branch 'master' into 8366017
 - More complete benchmarks.
 - JMH benchmarks.
 - Adapted tests to more restricted access.
 - Merge branch 'master' into 8366017
 - ... and 26 more: https://git.openjdk.org/jdk/compare/96259936...c3485864

-------------

Changes: https://git.openjdk.org/jdk/pull/26990/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26990&range=05
  Stats: 3008 lines in 9 files changed: 817 ins; 1395 del; 796 mod
  Patch: https://git.openjdk.org/jdk/pull/26990.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26990/head:pull/26990

PR: https://git.openjdk.org/jdk/pull/26990

From abimpoudis at openjdk.org  Tue Oct 28 12:46:30 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 28 Oct 2025 12:46:30 GMT
Subject: RFR: 8359145: Implement JEP 530: Primitive Types in Patterns,
 instanceof, and switch (Fourth Preview) [v2]
In-Reply-To: 
References: 
Message-ID: 

> Draft PR for Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

Aggelos Biboudis 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:

  8359145: JEP 530: Implement Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27637/files
  - new: https://git.openjdk.org/jdk/pull/27637/files/d15b13e7..f1448e1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27637&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27637&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27637/head:pull/27637

PR: https://git.openjdk.org/jdk/pull/27637

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 viktor.klang at oracle.com  Tue Oct 28 13:12:09 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 28 Oct 2025 14:12:09 +0100
Subject: InputStream/OutputStream concurrency guarantees
In-Reply-To: 
References: 
 
 
 
Message-ID: <5848207d-a5f7-48c8-81c8-826de122af48@oracle.com>

Also, since there aren't any consistency effects in place, it is not 
deterministic which changes made by the writer would be seen by the 
reader/copier.

On 2025-10-27 18:35, Pavel Rappo wrote:
> In the absence of "frozen arrays" -- which I'm not even sure could be
> useful here -- we cannot guarantee that a shared byte[] passed to
> OutputStream.write is not meddled with from outside, no matter if
> synchronization or defensive copy is used. To clarify the latter
> point: the array may be changed while it's being copied, which is no
> different from it being changed while it is being written from.
>
> If someone is flipping bytes while OutputStream.write has not yet
> returned, then I reckon it's a programming bug or an adversarial
> attack, which was probably enabled by such bug. Not sure if there was
> any other answer expected.
>
> -Pavel
>
> On Mon, Oct 27, 2025 at 5:02?PM Alan Bateman  wrote:
>>
>>
>> On 27/10/2025 11:47, Pavel Rappo wrote:
>>
>> The specification of the read/write methods, their classes, and the
>> package is silent on multithreading. In which case you should always
>> assume that the methods are **not** thread-safe.
>>
>> Right, although there are some APIs that do specify that input or output streams are safe for used by concurrent threads, e.g. the input/output streams returned by the Channels class that support interop between channels and input/output streams.
>>
>> Another more subtle aspect to the topic is async close. With many input/output streams it doesn't make any sense to attempt to use them from concurrent threads but async close when there is a blocker read/writer is something that has to be supported in some cases.
>>
>> In any access, I read Florian's mail as asking something else. I read the mail as concurrent access to the byte[], e.g. someone flipping bytes while someone is calling write.
>>
>> -Alan

-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle


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 heidinga at openjdk.org  Tue Oct 28 14:01:34 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 28 Oct 2025 14:01:34 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v3]
In-Reply-To: 
References: 
 
 
 
 <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com>
 
 
 
 
Message-ID: 

On Tue, 28 Oct 2025 04:06:57 GMT, Ioi Lam  wrote:

>>> The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess.
>> 
>> I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE?
>
>> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase?
> 
> @DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See `CDSHeapVerifier::SharedSecretsAccessorFinder::do_field()`. This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors.

Can you update the comment on `SharedSecrets.java` to indicate that lambdas aren't safe to pre-initialize in this context?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2469685015

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 mbaesken at openjdk.org  Tue Oct 28 15:13:08 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 28 Oct 2025 15:13:08 GMT
Subject: RFR: 8370393: Cleanup handling of ancient Windows versions from
 GetJavaProperties java_props_md
Message-ID: 

There are some ancient Windows versions still handled in GetJavaProperties :

https://github.com/openjdk/jdk/blob/master/src/java.base/windows/native/libjava/java_props_md.c#L456

We compile currently with Windows 8+ settings :


# _WIN32_WINNT=0x0602 means access APIs for Windows 8 and above. See
# https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170
ALWAYS_DEFINES="-DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0602 \


So everything older than Windows 8 could most likely be removed.

-------------

Commit messages:
 - JDK-8370393

Changes: https://git.openjdk.org/jdk/pull/28022/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28022&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370393
  Stats: 54 lines in 1 file changed: 0 ins; 53 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28022.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28022/head:pull/28022

PR: https://git.openjdk.org/jdk/pull/28022

From mbaesken at openjdk.org  Tue Oct 28 15:13:08 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 28 Oct 2025 15:13:08 GMT
Subject: RFR: 8370393: Cleanup handling of ancient Windows versions from
 GetJavaProperties java_props_md
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 15:05:14 GMT, Matthias Baesken  wrote:

> There are some ancient Windows versions still handled in GetJavaProperties :
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/windows/native/libjava/java_props_md.c#L456
> 
> We compile currently with Windows 8+ settings :
> 
> 
> # _WIN32_WINNT=0x0602 means access APIs for Windows 8 and above. See
> # https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170
> ALWAYS_DEFINES="-DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0602 \
> 
> 
> So everything older than Windows 8 could most likely be removed.

I noticed that we handle some pre Windows 8 versions here too
https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L1957

Should I remove/adjust this too in this PR (and change the PR/JBS issue title)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28022#issuecomment-3456979676

From bpb at openjdk.org  Tue Oct 28 15:26:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 28 Oct 2025 15:26:52 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 28 Oct 2025 07:15:43 GMT, Alan Bateman  wrote:

> [...] to check for any overflows [...]

I am intending to re-check that as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3457056986

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 kfarrell at openjdk.org  Tue Oct 28 15:48:54 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Tue, 28 Oct 2025 15:48:54 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v22]
In-Reply-To: 
References: 
Message-ID: 

> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
> 
> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
> 
> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
> 
> 
> - random-byte-only - 99.8%
> - higher-precision - 3.5%
> - counter-based - 0%
> 
> 
> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
> 
> - random-byte-only   143.487 ? 10.932  ns/op
> - higher-precision      149.651 ?  8.438 ns/op
> - counter-based         245.036 ?  2.943  ns/op
> 
> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  spec updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25303/files
  - new: https://git.openjdk.org/jdk/pull/25303/files/b2239d8c..1be228fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=20-21

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303

PR: https://git.openjdk.org/jdk/pull/25303

From alanb at openjdk.org  Tue Oct 28 15:59:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 15:59:57 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v22]
In-Reply-To: 
References: 
 
Message-ID: <1kF9CUy1axM7i3nNMXwHMhE_VmIZUI8NXxzKCCqRBls=.df5a19ee-a1d3-490d-a69c-18a2523ea716@github.com>

On Tue, 28 Oct 2025 15:48:54 GMT, Kieran Farrell  wrote:

>> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
>> 
>> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>> 
>> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
>> 
>> 
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>> 
>> 
>> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
>> 
>> - random-byte-only   143.487 ? 10.932  ns/op
>> - higher-precision      149.651 ?  8.438 ns/op
>> - counter-based         245.036 ?  2.943  ns/op
>> 
>> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spec updates

New method + spec look good.

We should create a follow-up issue to re-visit the switch from UUID in the first sentence/paragraph to "global identifiers" in the second paragraph.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25303#pullrequestreview-3389547486

From liach at openjdk.org  Tue Oct 28 16:59:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 Oct 2025 16:59:27 GMT
Subject: RFR: 8370839: Tests to verify peculiar Proxy dispatching behaviors
Message-ID: 

java.lang.reflect.Proxy has some surprising behaviors associated with protected methods in Object and covariant/contravariant overrides in interfaces. Such behaviors should have tests, so that they are not accidentally perturbed in Proxy updates.

-------------

Commit messages:
 - 8370839: Tests to verify peculiar Proxy dispatching behaviors

Changes: https://git.openjdk.org/jdk/pull/28023/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28023&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370839
  Stats: 230 lines in 2 files changed: 230 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28023.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28023/head:pull/28023

PR: https://git.openjdk.org/jdk/pull/28023

From liach at openjdk.org  Tue Oct 28 17:04:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 Oct 2025 17:04:46 GMT
Subject: Withdrawn: 8370838: Proxy invocation handler dispatching specification
 should be self-contained
In-Reply-To: 
References: 
Message-ID: 

On Wed, 22 Oct 2025 21:41:49 GMT, Chen Liang  wrote:

> The `method` parameter documentation for `InvocationHandler::invoke` does not indicate that it may be one of the 3 Object methods `hashCode`, `equals`, or `toString`. This doc-only improvement clarifies that, links to the Proxy section about declaring class selection, and updates the "the interface method" occurrences to be "the invoked method" to reflect the method may be from `Object`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/27943

From liach at openjdk.org  Tue Oct 28 18:03:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 Oct 2025 18:03:55 GMT
Subject: RFR: 4397513: (reflect) InvocationHandler.invoke javadoc slightly
 misleading for "method" parameter
Message-ID: 

Update occurrences of the not-exactly-correct "interface method" to "invoked method" because 3 Object methods are proxied too. In addition, update the description about the declaring class of the method to be more accurate so that it doesn't clash with the "duplicate method" section in Proxy.

-------------

Commit messages:
 - 4397513: (reflect) InvocationHandler.invoke javadoc slightly misleading for "method" parameter

Changes: https://git.openjdk.org/jdk/pull/28024/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28024&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-4397513
  Stats: 11 lines in 1 file changed: 0 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28024.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28024/head:pull/28024

PR: https://git.openjdk.org/jdk/pull/28024

From liach at openjdk.org  Tue Oct 28 18:31:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 Oct 2025 18:31:08 GMT
Subject: RFR: 8370839: Tests to verify peculiar Proxy dispatching behaviors
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> java.lang.reflect.Proxy has some surprising behaviors associated with protected methods in Object, covariant/contravariant overrides in interfaces, and package-private types in method signatures. Such behaviors should have tests, so that they are not accidentally perturbed in Proxy updates.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into test/proxy-dispatches
 - Tweaks
 - 8370839: Tests to verify peculiar Proxy dispatching behaviors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28023/files
  - new: https://git.openjdk.org/jdk/pull/28023/files/5166e236..1c6bba31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28023&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28023&range=00-01

  Stats: 2782 lines in 113 files changed: 1442 ins; 1010 del; 330 mod
  Patch: https://git.openjdk.org/jdk/pull/28023.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28023/head:pull/28023

PR: https://git.openjdk.org/jdk/pull/28023

From iklam at openjdk.org  Tue Oct 28 18:51:40 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 18:51:40 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v4]
In-Reply-To: 
References: 
Message-ID: 

> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Updated comments about @AOTSafeClassInitializer in SharedSecrets.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27880/files
  - new: https://git.openjdk.org/jdk/pull/27880/files/6ae1172a..3121fd11

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=02-03

  Stats: 15 lines in 1 file changed: 12 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27880/head:pull/27880

PR: https://git.openjdk.org/jdk/pull/27880

From iklam at openjdk.org  Tue Oct 28 18:51:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 18:51:41 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v4]
In-Reply-To: 
References: 
 
 
 
 <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com>
 
 
 
 
 
Message-ID: 

On Tue, 28 Oct 2025 13:57:46 GMT, Dan Heidinga  wrote:

>>> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase?
>> 
>> @DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See `CDSHeapVerifier::SharedSecretsAccessorFinder::do_field()`. This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors.
>
> Can you update the comment on `SharedSecrets.java` to indicate that lambdas aren't safe to pre-initialize in this context?

I updated the comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2470693374

From heidinga at openjdk.org  Tue Oct 28 18:57:01 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 28 Oct 2025 18:57:01 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 18:51:40 GMT, Ioi Lam  wrote:

>> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments about @AOTSafeClassInitializer in SharedSecrets.java

Marked as reviewed by heidinga (no project role).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27880#pullrequestreview-3390359439

From pchilanomate at openjdk.org  Tue Oct 28 19:37:34 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 28 Oct 2025 19:37:34 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v10]
In-Reply-To: 
References: 
Message-ID: 

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  add const to references

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27802/files
  - new: https://git.openjdk.org/jdk/pull/27802/files/13124869..3bf8ebd6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=08-09

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

PR: https://git.openjdk.org/jdk/pull/27802

From pchilanomate at openjdk.org  Tue Oct 28 19:37:38 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 28 Oct 2025 19:37:38 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v9]
In-Reply-To: 
References: 
 
 
Message-ID: <7x8l5QaY7Dw_gSI4vFPP0OEHg7FrZ5MbdBj45TpIMjM=.d272b08d-26e8-4b20-8a43-5ad9f1990e69@github.com>

On Mon, 27 Oct 2025 21:20:39 GMT, Coleen Phillimore  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment in anchor_mark_set_pd
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1796:
> 
>> 1794: }
>> 1795: 
>> 1796: static void log_preempt_after_freeze(ContinuationWrapper& cont) {
> 
> Does this modify ContinuationWrapper?  I don't see how it does.  If not, it should be a const reference.

Done.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2680:
> 
>> 2678: }
>> 2679: 
>> 2680: intptr_t* ThawBase::redo_vmcall(JavaThread* current, frame& top) {
> 
> Does this modify "top"?  Else should be a const reference too. Looks like a lot of references are non-const.  If these methods don't modify their non-const reference parameters, I think you should have a cleanup pass to fix these to be const references.

It?s used in `AnchorMark` to set `_top_frame`, which can?t be const because of the `interpreter_frame_set_last_sp` usage. I fixed `push_return_frame` too, let me know if you spotted other ones.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2470809959
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2470811686

From pchilanomate at openjdk.org  Tue Oct 28 19:37:36 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 28 Oct 2025 19:37:36 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Oct 2025 19:44:53 GMT, Patricio Chilano Mateo  wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment in anchor_mark_set_pd

Thanks for the review Coleen!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3458170668

From coleenp at openjdk.org  Tue Oct 28 19:55:14 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 28 Oct 2025 19:55:14 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v9]
In-Reply-To: <7x8l5QaY7Dw_gSI4vFPP0OEHg7FrZ5MbdBj45TpIMjM=.d272b08d-26e8-4b20-8a43-5ad9f1990e69@github.com>
References: 
 
 
 <7x8l5QaY7Dw_gSI4vFPP0OEHg7FrZ5MbdBj45TpIMjM=.d272b08d-26e8-4b20-8a43-5ad9f1990e69@github.com>
Message-ID: 

On Tue, 28 Oct 2025 19:33:07 GMT, Patricio Chilano Mateo  wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1796:
>> 
>>> 1794: }
>>> 1795: 
>>> 1796: static void log_preempt_after_freeze(ContinuationWrapper& cont) {
>> 
>> Does this modify ContinuationWrapper?  I don't see how it does.  If not, it should be a const reference.
>
> Done.

Thank you!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2470859813

From sherman at openjdk.org  Tue Oct 28 19:58:23 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 28 Oct 2025 19:58:23 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v6]
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
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
> 
> See CSR https://bugs.openjd...

Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:

  small update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27628/files
  - new: https://git.openjdk.org/jdk/pull/27628/files/c98543ff..74b4d83e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=04-05

  Stats: 48 lines in 3 files changed: 4 ins; 23 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27628/head:pull/27628

PR: https://git.openjdk.org/jdk/pull/27628

From sherman at openjdk.org  Tue Oct 28 20:03:36 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 28 Oct 2025 20:03:36 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v4]
In-Reply-To: <_5e7Ota89HOgtcpsy4umlfF1EL1f3Xiyt2lmG1gN_DM=.6a3718d0-4cb3-49d6-82ca-16d6ad7bf8bc@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
 <_5e7Ota89HOgtcpsy4umlfF1EL1f3Xiyt2lmG1gN_DM=.6a3718d0-4cb3-49d6-82ca-16d6ad7bf8bc@github.com>
Message-ID: 

On Wed, 22 Oct 2025 20:28:53 GMT, Roger Riggs  wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test case update
>
> make/jdk/src/classes/build/tools/generatecharacter/GenerateCaseFolding.java line 1:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Please rename this build tool to avoid ambiguity in the naming of CaseFolding.java.

renamed to GenerateCaseFolding.java

> src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 1:
> 
>> 1: /*
> 
> Significant performance improvements could be had by handling single (simple) char -> char folding separately avoiding the overhead of iterating over single character arrays.

1:1 mapping and 1:M mapping are handled separate now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2470873697
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2470879134

From sherman at openjdk.org  Tue Oct 28 20:17:49 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 28 Oct 2025 20:17:49 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v6]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
 
Message-ID: 

On Sat, 18 Oct 2025 08:50:48 GMT, Xueming Shen  wrote:

>> src/java.base/share/classes/java/lang/StringLatin1.java line 194:
>> 
>>> 192:         char[] folded2 = null;
>>> 193:         int k1 = 0, k2 = 0, fk1 = 0, fk2 = 0;
>>> 194:         while ((k1 < len1 || folded1 != null && fk1 < folded1.length) &&
>> 
>> Many suggestions come to mind here on the algorithm, to optimize performance.
>> For example, many strings will have identical prefixes. Using Arrays.mismatch could quickly skip over the identical prefix.
>> Consider using code points (or a long, packing 4 chars) for the folded replacements, to avoid having to step through chars in char arrays.  CaseFolding.foldIfDefined could return the full expansion as a long.
>> It may be profitable to use Arrays.mismatch again after expanded characters are determined to be equal.
>> 
>> Take another look at the data structure storing and doing the lookup of foldIfDefined both to increase the lookup performance.
>
> With the following changes
> 
> - Use int[] / code point storage instead of char[] / char for folding data.
> - Add a fast path for Latin-1 vs. Latin-1 comparisons.
> - Speed up the UTF-16 path as well.
> 
> The only remaining ?slow? path is Latin-1 vs. UTF-16 for now.
> Would appreciate some eagle eyes on the new fast-path implementation.  The tests suggest it?s working as expected :-)
> 
> **StringCompareToFoldCase.latin1UTF16          avgt   15  23.959 ? 2.357  ns/op
> StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.455 ? 0.104  ns/op
> StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  32.782 ? 0.962  ns/op
> StringCompareToFoldCase.latin1UTF16FC        avgt   15  32.581 ? 0.725  ns/op**
> 
> 
> Benchmark                                    Mode  Cnt   Score   Error  Units
> StringCompareToFoldCase.asciiLower           avgt   15  17.983 ? 0.208  ns/op
> StringCompareToFoldCase.asciiLowerEQ         avgt   15   9.986 ? 0.254  ns/op
> StringCompareToFoldCase.asciiLowerEQFC       avgt   15  10.781 ? 0.161  ns/op
> StringCompareToFoldCase.asciiLowerFC         avgt   15  10.274 ? 0.136  ns/op
> StringCompareToFoldCase.asciiUpperLower      avgt   15  12.465 ? 0.409  ns/op
> StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  10.961 ? 0.407  ns/op
> StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   9.157 ? 0.166  ns/op
> StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   9.228 ? 0.254  ns/op
> StringCompareToFoldCase.asciiWithDFFC        avgt   15  57.603 ? 1.540  ns/op
> StringCompareToFoldCase.greekLower           avgt   15  39.593 ? 0.128  ns/op
> StringCompareToFoldCase.greekLowerEQ         avgt   15  39.249 ? 0.032  ns/op
> StringCompareToFoldCase.greekLowerEQFC       avgt   15  13.993 ? 0.346  ns/op
> StringCompareToFoldCase.greekLowerFC         avgt   15  14.030 ? 0.454  ns/op
> StringCompareToFoldCase.greekUpperLower      avgt   15   7.137 ? 0.130  ns/op
> StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.496 ? 0.104  ns/op
> StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   6.203 ? 0.316  ns/op
> StringCompareToFoldCase.greekUpperLowerFC    avgt   15   6.235 ? 0.256  ns/op
> StringCompareToFoldCase.latin1UTF16          avgt   15  23.959 ? 2.357  ns/op
> StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.455 ? 0.104  ns/op
> StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  32.782 ? 0.962  ns/op
> StringCompareToFoldCase.latin1UTF16FC        avgt   15  32.581 ? 0.725  ns/op
> StringCompareToFoldCase.supLower             avgt   15  54.918 ? 0.809  ns/op
> StringCompa...

Experimenting with Arrays.mismatch at the beginning of the array iteration as 


        int k = ArraysSupport.mismatch(value, other, lim);
        if (k < 0)
            return len - olen;
        for (; k < lim; k++) {
            ....
        }


The benchmark results suggest that it does help 'dramatically' when the compared strings share with the same prefix.  For example those "UpperLower" test cases (which shares the same upper cases text prefix. However it is also relatively expensive, with a 20%-ish overhead when the strings do not share the same string text but are case-insensitively equals.  I would suggest let's leave it out for now?

### With Arrays.mismatch


Benchmark                                    Mode  Cnt   Score   Error  Units
StringCompareToFoldCase.asciiLower           avgt   15  15.044 ? 0.751  ns/op
StringCompareToFoldCase.asciiLowerEQ         avgt   15  10.033 ? 0.366  ns/op
StringCompareToFoldCase.asciiLowerEQFC       avgt   15  12.094 ? 0.288  ns/op
StringCompareToFoldCase.asciiLowerFC         avgt   15  12.513 ? 0.290  ns/op
StringCompareToFoldCase.asciiUpperLower      avgt   15  11.716 ? 0.471  ns/op
StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  11.120 ? 0.458  ns/op
StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   7.544 ? 0.103  ns/op
StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   7.384 ? 0.167  ns/op
StringCompareToFoldCase.asciiWithDFFC        avgt   15  54.949 ? 1.260  ns/op
StringCompareToFoldCase.greekLower           avgt   15  39.492 ? 0.124  ns/op
StringCompareToFoldCase.greekLowerEQ         avgt   15  39.266 ? 0.071  ns/op
StringCompareToFoldCase.greekLowerEQFC       avgt   15  28.049 ? 0.292  ns/op
StringCompareToFoldCase.greekLowerFC         avgt   15  28.272 ? 0.115  ns/op
StringCompareToFoldCase.greekUpperLower      avgt   15   7.103 ? 0.052  ns/op
StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.439 ? 0.079  ns/op
StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   2.716 ? 0.138  ns/op
StringCompareToFoldCase.greekUpperLowerFC    avgt   15   2.628 ? 0.051  ns/op
StringCompareToFoldCase.latin1UTF16          avgt   15  23.147 ? 0.094  ns/op
StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.626 ? 0.081  ns/op
StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  38.453 ? 0.697  ns/op
StringCompareToFoldCase.latin1UTF16FC        avgt   15  38.464 ? 0.441  ns/op
StringCompareToFoldCase.supLower             avgt   15  54.443 ? 0.162  ns/op
StringCompareToFoldCase.supLowerEQ           avgt   15  54.980 ? 0.232  ns/op
StringCompareToFoldCase.supLowerEQFC         avgt   15  25.552 ? 0.163  ns/op
StringCompareToFoldCase.supLowerFC           avgt   15  25.477 ? 0.215  ns/op
StringCompareToFoldCase.supUpperLower        avgt   15  14.525 ? 0.071  ns/op
StringCompareToFoldCase.supUpperLowerEQ      avgt   15  14.691 ? 0.082  ns/op
StringCompareToFoldCase.supUpperLowerEQFC    avgt   15   2.748 ? 0.166  ns/op
StringCompareToFoldCase.supUpperLowerFC      avgt   15   2.616 ? 0.029  ns/op


vs

### Without Arrays.mismatch


Benchmark                                    Mode  Cnt   Score   Error  Units
StringCompareToFoldCase.asciiLower           avgt   15  15.793 ? 1.080  ns/op
StringCompareToFoldCase.asciiLowerEQ         avgt   15   9.862 ? 0.221  ns/op
StringCompareToFoldCase.asciiLowerEQFC       avgt   15  10.681 ? 0.133  ns/op
StringCompareToFoldCase.asciiLowerFC         avgt   15  10.220 ? 0.105  ns/op
StringCompareToFoldCase.asciiUpperLower      avgt   15  11.996 ? 0.649  ns/op
StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  10.823 ? 0.353  ns/op
StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   9.199 ? 0.347  ns/op
StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   9.033 ? 0.144  ns/op
StringCompareToFoldCase.asciiWithDFFC        avgt   15  54.892 ? 1.049  ns/op
StringCompareToFoldCase.greekLower           avgt   15  39.568 ? 0.107  ns/op
StringCompareToFoldCase.greekLowerEQ         avgt   15  39.287 ? 0.068  ns/op
StringCompareToFoldCase.greekLowerEQFC       avgt   15  22.800 ? 0.347  ns/op
StringCompareToFoldCase.greekLowerFC         avgt   15  22.794 ? 0.317  ns/op
StringCompareToFoldCase.greekUpperLower      avgt   15   7.147 ? 0.072  ns/op
StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.499 ? 0.106  ns/op
StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   6.958 ? 0.204  ns/op
StringCompareToFoldCase.greekUpperLowerFC    avgt   15   7.179 ? 0.188  ns/op
StringCompareToFoldCase.latin1UTF16          avgt   15  25.787 ? 1.940  ns/op
StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.602 ? 0.106  ns/op
StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  31.317 ? 0.668  ns/op
StringCompareToFoldCase.latin1UTF16FC        avgt   15  30.881 ? 0.622  ns/op
StringCompareToFoldCase.supLower             avgt   15  55.771 ? 0.718  ns/op
StringCompareToFoldCase.supLowerEQ           avgt   15  55.444 ? 0.535  ns/op
StringCompareToFoldCase.supLowerEQFC         avgt   15  31.180 ? 0.184  ns/op
StringCompareToFoldCase.supLowerFC           avgt   15  31.269 ? 0.465  ns/op
StringCompareToFoldCase.supUpperLower        avgt   15  14.386 ? 0.150  ns/op
StringCompareToFoldCase.supUpperLowerEQ      avgt   15  14.780 ? 0.104  ns/op
StringCompareToFoldCase.supUpperLowerEQFC    avgt   15  13.733 ? 0.284  ns/op
StringCompareToFoldCase.supUpperLowerFC      avgt   15  13.607 ? 0.166  ns/op

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2470912393

From rriggs at openjdk.org  Tue Oct 28 21:41:36 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Oct 2025 21:41:36 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v4]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
 <_5e7Ota89HOgtcpsy4umlfF1EL1f3Xiyt2lmG1gN_DM=.6a3718d0-4cb3-49d6-82ca-16d6ad7bf8bc@github.com>
 
Message-ID: <9RLqVMEBDHHgSW9aK0CJ51z7e8ef5BU9iTU7NRF4NjA=.e751cbeb-c3a5-4dc9-8504-514c966c3762@github.com>

On Mon, 27 Oct 2025 09:40:03 GMT, Xueming Shen  wrote:

>> src/java.base/share/classes/java/lang/StringLatin1.java line 217:
>> 
>>> 215:             if (c1 != c2) {
>>> 216:                 return c1 - c2;
>>> 217:             }
>> 
>> Compute difference only once.
>> Suggestion:
>> 
>>             if ((c1 - c2) != 0) {
>>                 return c1 - c2;
>>             }
>
> you meant go with
> 
>             if ((c1 - c2) != 0) {
> 	                return c1 - c2;
> 	        } ?

Yes, it might be an inconsequential difference but directly computes the difference and returns if not-equal.

>> src/java.base/share/classes/java/lang/StringUTF16.java line 605:
>> 
>>> 603:         int k1 = off, k2 = ooff, fk1 = 0, fk2 = 0;
>>> 604:         while ((k1 < last || folded1 != null && fk1 < folded1.length) &&
>>> 605:                (k2 < olast || folded2 != null && fk2 < folded2.length)) {
>> 
>> Use ArraySupport.mismatch to quickly scan past identical sequences.  (byte index will need to be converted to char index).
>
> seems like we are only using it for case-aware comparison in existing string comparison. just wonder do we really want to apply this for the case insensitive comparision?
> 
>     static int compareTo(byte[] value, byte[] other, int len1, int len2) {
>         int lim = Math.min(len1, len2);
>         int k = ArraysSupport.mismatch(value, other, lim);
>         return (k < 0) ? len1 - len2 : getChar(value, k) - getChar(other, k);
>     }

I expect most strings will be predominated by normal (not folded) strings, the use of mismatch can rapidly skip over identical strings to find the start of bytes/characters that need to be checked for folding.
I would think it would help speed up the case-sensitive comparisons too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2471124837
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2471118690

From bpb at openjdk.org  Tue Oct 28 21:48:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 28 Oct 2025 21:48:38 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v9]
In-Reply-To: 
References: 
Message-ID: 

> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355342: Resize buffer passed to GetFinalPathNameByHandleW if needed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27324/files
  - new: https://git.openjdk.org/jdk/pull/27324/files/e4cad2b1..3820a269

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=07-08

  Stats: 32 lines in 2 files changed: 14 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/27324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27324/head:pull/27324

PR: https://git.openjdk.org/jdk/pull/27324

From liach at openjdk.org  Tue Oct 28 22:30:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 Oct 2025 22:30:54 GMT
Subject: RFR: 4517644: Core reflection setter type conversion spec bugs
Message-ID: 

### Current Status
In core reflection, there are a few holes with the documentation on the type conversions performed on the different setters. They generally follow this process:

1. The Object-valued setters checks the destination type. If that type is primitive, unbox the object.
2. Perform identity or (primitive/reference, depending on destination type) widening conversions.

For each step, they can fail with IllegalArgumentException, which has been the long standing behavior.

Note that this process is more restrictive than the JLS 5.2 assignment context, which allows boxing conversions, while the primitive reflective setters consistently reject them.

### Problems
There are some problems with current specs:
1. No mention that boxing is never done for primitive-typed setters
2. Array.set missing description for the final identity or widening conversion (reference or primitive) and the associated IAE condition
3. Field.set misses the identity or widening in IAE clause (but mentioned in main body)
4. Field primitive setters incorrectly claim they are equivalent to `set(instance, wrapper)` which is wrong due to lack of boxing conversion
5. Field primitive setters refer to nonsense "unwrapping conversion"

### Solutions
1. Make sure the unbox -> identity/widen process and the IAE conditoins are present in both Field and Array.set
2. Add that boxing is absent for all primitive setters
3. Fix the Field primitive setters' "unwrapping conversion" to be "identity or primitive widening conversion" as in Array primitive setters
4. Qualify the Field primitive setters assertion with "if this field is of a primitive type" to make it correct

-------------

Commit messages:
 - 4517644: (reflect spec) Array.set documentation hole for array/value ref type mismatch

Changes: https://git.openjdk.org/jdk/pull/28029/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28029&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-4517644
  Stats: 76 lines in 2 files changed: 20 ins; 0 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/28029.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28029/head:pull/28029

PR: https://git.openjdk.org/jdk/pull/28029

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 duke at openjdk.org  Wed Oct 29 00:29:16 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Wed, 29 Oct 2025 00:29:16 GMT
Subject: RFR: 8370822: Improve performance for MemorySegment::fill
Message-ID: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>

The manual byte-replication expression replaced with the multiplicative expansion trick - a more compact and efficient equivalent.

-------------

Commit messages:
 - 8370822: Improve performance for MemorySegment::fill

Changes: https://git.openjdk.org/jdk/pull/28031/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28031&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370822
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28031/head:pull/28031

PR: https://git.openjdk.org/jdk/pull/28031

From swen at openjdk.org  Wed Oct 29 01:31:25 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 29 Oct 2025 01:31:25 GMT
Subject: Integrated: 8368172: Make java.time.format.DateTimePrintContext
 immutable
In-Reply-To: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com>
References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com>
Message-ID: 

On Sat, 23 Aug 2025 11:27:55 GMT, Shaojin Wen  wrote:

> I propose to make j.t.f.DateTimePrintContext immutable.
> 
> Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method.
> 
> Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization.

This pull request has now been integrated.

Changeset: a588c120
Author:    Shaojin Wen 
URL:       https://git.openjdk.org/jdk/commit/a588c120fc2ec9d5c59c43cda7f247e0a84981ff
Stats:     88 lines in 3 files changed: 9 ins; 32 del; 47 mod

8368172: Make java.time.format.DateTimePrintContext immutable

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/26913

From jpai at openjdk.org  Wed Oct 29 01:36:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Oct 2025 01:36:13 GMT
Subject: RFR: 8370775: ModulePatcher$JarResourceFinder.getByteBuffer() does
 not close the InputStream after reading the bytes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 10:17:38 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this code which closes the `InputStream` upon usage in `ModulePatcher$JarResourceFinder.getByteBuffer()`?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8370775, this is a minor clean up to this part of the code.
>> 
>> tier testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's suggestion - rename "is" to "in"

Thank you Alan and Francesco for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28014#issuecomment-3459281317

From jpai at openjdk.org  Wed Oct 29 01:36:14 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Oct 2025 01:36:14 GMT
Subject: Integrated: 8370775: ModulePatcher$JarResourceFinder.getByteBuffer()
 does not close the InputStream after reading the bytes
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 09:59:58 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this code which closes the `InputStream` upon usage in `ModulePatcher$JarResourceFinder.getByteBuffer()`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8370775, this is a minor clean up to this part of the code.
> 
> tier testing is currently in progress with this change.

This pull request has now been integrated.

Changeset: 76995067
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/769950674e4258e73d040ddeab042125870b55b1
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8370775: ModulePatcher$JarResourceFinder.getByteBuffer() does not close the InputStream after reading the bytes

Reviewed-by: alanb, fandreuzzi

-------------

PR: https://git.openjdk.org/jdk/pull/28014

From almatvee at openjdk.org  Wed Oct 29 01:39:40 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 29 Oct 2025 01:39:40 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist of
 embedded runtime
Message-ID: 

- Added JDK specific keys/values to Info.plist of embedded runtime.
- Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
- Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.

-------------

Commit messages:
 - 8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime [v2]
 - Merge remote-tracking branch 'upstream/master' into JDK-8363980
 - Merge remote-tracking branch 'upstream/master' into JDK-8363980
 - Merge remote-tracking branch 'upstream/master' into JDK-8363980
 - 8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime

Changes: https://git.openjdk.org/jdk/pull/28033/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28033&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363980
  Stats: 34 lines in 3 files changed: 26 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28033/head:pull/28033

PR: https://git.openjdk.org/jdk/pull/28033

From almatvee at openjdk.org  Wed Oct 29 01:42:01 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 29 Oct 2025 01:42:01 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
Message-ID: <7IQdSWdngykfcgl133i6e7rNA4N4hLiyRzhcF4RCuhE=.09fdfb4d-70ed-452c-951b-cf217778865e@github.com>

On Wed, 29 Oct 2025 01:32:50 GMT, Alexander Matveev  wrote:

> - Added JDK specific keys/values to Info.plist of embedded runtime.
> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.

@alexeysemenyukoracle Please review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3459292153

From fyang at openjdk.org  Wed Oct 29 01:48:08 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 29 Oct 2025 01:48:08 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v9]
In-Reply-To: 
References: 
 
 
Message-ID: <77E6HxJSWjDdGYLpk_R2W72ad6fJnI952ul_daWCvsM=.bf30b1de-6f62-4889-861a-33b96942aca8@github.com>

On Tue, 28 Oct 2025 19:34:08 GMT, Patricio Chilano Mateo  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment in anchor_mark_set_pd
>
> Thanks for the review Coleen!

Just FYI: I am witnessing build issues after applying this on JDK HEAD. So we might want to merge with latest master. @pchilano

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3459300121

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 sherman at openjdk.org  Wed Oct 29 02:03:14 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 29 Oct 2025 02:03:14 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v6]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
 
 
Message-ID: 

On Tue, 28 Oct 2025 20:15:26 GMT, Xueming Shen  wrote:

>> With the following changes
>> 
>> - Use int[] / code point storage instead of char[] / char for folding data.
>> - Add a fast path for Latin-1 vs. Latin-1 comparisons.
>> - Speed up the UTF-16 path as well.
>> 
>> The only remaining ?slow? path is Latin-1 vs. UTF-16 for now.
>> Would appreciate some eagle eyes on the new fast-path implementation.  The tests suggest it?s working as expected :-)
>> 
>> **StringCompareToFoldCase.latin1UTF16          avgt   15  23.959 ? 2.357  ns/op
>> StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.455 ? 0.104  ns/op
>> StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  32.782 ? 0.962  ns/op
>> StringCompareToFoldCase.latin1UTF16FC        avgt   15  32.581 ? 0.725  ns/op**
>> 
>> 
>> Benchmark                                    Mode  Cnt   Score   Error  Units
>> StringCompareToFoldCase.asciiLower           avgt   15  17.983 ? 0.208  ns/op
>> StringCompareToFoldCase.asciiLowerEQ         avgt   15   9.986 ? 0.254  ns/op
>> StringCompareToFoldCase.asciiLowerEQFC       avgt   15  10.781 ? 0.161  ns/op
>> StringCompareToFoldCase.asciiLowerFC         avgt   15  10.274 ? 0.136  ns/op
>> StringCompareToFoldCase.asciiUpperLower      avgt   15  12.465 ? 0.409  ns/op
>> StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  10.961 ? 0.407  ns/op
>> StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   9.157 ? 0.166  ns/op
>> StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   9.228 ? 0.254  ns/op
>> StringCompareToFoldCase.asciiWithDFFC        avgt   15  57.603 ? 1.540  ns/op
>> StringCompareToFoldCase.greekLower           avgt   15  39.593 ? 0.128  ns/op
>> StringCompareToFoldCase.greekLowerEQ         avgt   15  39.249 ? 0.032  ns/op
>> StringCompareToFoldCase.greekLowerEQFC       avgt   15  13.993 ? 0.346  ns/op
>> StringCompareToFoldCase.greekLowerFC         avgt   15  14.030 ? 0.454  ns/op
>> StringCompareToFoldCase.greekUpperLower      avgt   15   7.137 ? 0.130  ns/op
>> StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.496 ? 0.104  ns/op
>> StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   6.203 ? 0.316  ns/op
>> StringCompareToFoldCase.greekUpperLowerFC    avgt   15   6.235 ? 0.256  ns/op
>> StringCompareToFoldCase.latin1UTF16          avgt   15  23.959 ? 2.357  ns/op
>> StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.455 ? 0.104  ns/op
>> StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  32.782 ? 0.962  ns/op
>> StringCompareToFoldCase.latin1UTF16FC        avgt   15  32.581 ? 0.725  ns/op
>> StringCompare...
>
> Experimenting with Arrays.mismatch at the beginning of the array iteration as 
> 
> 
>         int k = ArraysSupport.mismatch(value, other, lim);
>         if (k < 0)
>             return len - olen;
>         for (; k < lim; k++) {
>             ....
>         }
> 
> 
> The benchmark results suggest that it does help 'dramatically' when the compared strings share with the same prefix.  For example those "UpperLower" test cases (which shares the same upper cases text prefix. However it is also relatively expensive, with a 20%-ish overhead when the strings do not share the same string text but are case-insensitively equals.  I would suggest let's leave it out for now?
> 
> ### With Arrays.mismatch
> 
> 
> Benchmark                                    Mode  Cnt   Score   Error  Units
> StringCompareToFoldCase.asciiLower           avgt   15  15.044 ? 0.751  ns/op
> StringCompareToFoldCase.asciiLowerEQ         avgt   15  10.033 ? 0.366  ns/op
> StringCompareToFoldCase.asciiLowerEQFC       avgt   15  12.094 ? 0.288  ns/op
> StringCompareToFoldCase.asciiLowerFC         avgt   15  12.513 ? 0.290  ns/op
> StringCompareToFoldCase.asciiUpperLower      avgt   15  11.716 ? 0.471  ns/op
> StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  11.120 ? 0.458  ns/op
> StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   7.544 ? 0.103  ns/op
> StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   7.384 ? 0.167  ns/op
> StringCompareToFoldCase.asciiWithDFFC        avgt   15  54.949 ? 1.260  ns/op
> StringCompareToFoldCase.greekLower           avgt   15  39.492 ? 0.124  ns/op
> StringCompareToFoldCase.greekLowerEQ         avgt   15  39.266 ? 0.071  ns/op
> StringCompareToFoldCase.greekLowerEQFC       avgt   15  28.049 ? 0.292  ns/op
> StringCompareToFoldCase.greekLowerFC         avgt   15  28.272 ? 0.115  ns/op
> StringCompareToFoldCase.greekUpperLower      avgt   15   7.103 ? 0.052  ns/op
> StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.439 ? 0.079  ns/op
> StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   2.716 ? 0.138  ns/op
> StringCompareToFoldCase.greekUpperLowerFC    avgt   15   2.628 ? 0.051  ns/op
> StringCompareToFoldCase.latin1UTF16          avgt   15  23.147 ? 0.094  ns/op
> StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.626 ? 0.081  ns/op
> StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  38.453 ? 0.697  ns/op
> StringCompareToFoldCase.latin1UTF16FC        avgt   15  38.464 ? 0.441  ns/op
> StringCompareToFoldCase.supLower             avgt   15  54.443 ? 0.162  ns/op
> StringCompareToFoldCase....

### Long:  packing  1:M-count + 1-3 folding codepoints

https://cr.openjdk.org/~sherman/casefolding_long/

The performance is slightly better, but not as good as I would have expected. The access to codepoint from the long looks a little clumsy,  but the logic looks smooth. need more work. opinion?


Benchmark                                    Mode  Cnt   Score   Error  Units
StringCompareToFoldCase.asciiLower           avgt   15  15.487 ? 0.298  ns/op
StringCompareToFoldCase.asciiLowerEQ         avgt   15  10.005 ? 0.368  ns/op
StringCompareToFoldCase.asciiLowerEQFC       avgt   15  10.755 ? 0.160  ns/op
StringCompareToFoldCase.asciiLowerFC         avgt   15  10.349 ? 0.155  ns/op
StringCompareToFoldCase.asciiUpperLower      avgt   15  12.188 ? 0.278  ns/op
StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  10.901 ? 0.551  ns/op
StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   9.218 ? 0.165  ns/op
StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   9.335 ? 0.404  ns/op
StringCompareToFoldCase.asciiWithDFFC        avgt   15  37.010 ? 0.518  ns/op
StringCompareToFoldCase.greekLower           avgt   15  39.572 ? 0.098  ns/op
StringCompareToFoldCase.greekLowerEQ         avgt   15  39.317 ? 0.104  ns/op
StringCompareToFoldCase.greekLowerEQFC       avgt   15  20.428 ? 0.243  ns/op
StringCompareToFoldCase.greekLowerFC         avgt   15  19.623 ? 0.141  ns/op
StringCompareToFoldCase.greekUpperLower      avgt   15   7.105 ? 0.048  ns/op
StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.462 ? 0.092  ns/op
StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   6.518 ? 0.128  ns/op
StringCompareToFoldCase.greekUpperLowerFC    avgt   15   6.593 ? 0.240  ns/op
StringCompareToFoldCase.latin1UTF16          avgt   15  23.130 ? 0.152  ns/op
StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.606 ? 0.089  ns/op
StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  29.574 ? 0.348  ns/op
StringCompareToFoldCase.latin1UTF16FC        avgt   15  29.691 ? 0.445  ns/op
StringCompareToFoldCase.supLower             avgt   15  55.027 ? 0.676  ns/op
StringCompareToFoldCase.supLowerEQ           avgt   15  55.784 ? 0.368  ns/op
StringCompareToFoldCase.supLowerEQFC         avgt   15  24.984 ? 0.157  ns/op
StringCompareToFoldCase.supLowerFC           avgt   15  24.865 ? 0.139  ns/op
StringCompareToFoldCase.supUpperLower        avgt   15  14.538 ? 0.144  ns/op
StringCompareToFoldCase.supUpperLowerEQ      avgt   15  14.728 ? 0.206  ns/op
StringCompareToFoldCase.supUpperLowerEQFC    avgt   15   9.932 ? 0.121  ns/op
StringCompareToFoldCase.supUpperLowerFC      avgt   15   9.870 ? 0.119  ns/op

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2471532292

From asemenyuk at openjdk.org  Wed Oct 29 02:32:03 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 29 Oct 2025 02:32:03 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 01:32:50 GMT, Alexander Matveev  wrote:

> - Added JDK specific keys/values to Info.plist of embedded runtime.
> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java line 363:

> 361:         final var app = env.app();
> 362: 
> 363:         // We should use full runtime info plist for standalone runtime and for

I guess the comment explains why jpackage should use the same info plist template for a runtime if it has the "bin" subdirectory. But what is the "full" runtime?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28033#discussion_r2471563801

From iklam at openjdk.org  Wed Oct 29 02:53:09 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 29 Oct 2025 02:53:09 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 18:51:40 GMT, Ioi Lam  wrote:

>> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments about @AOTSafeClassInitializer in SharedSecrets.java

Thanks everyone for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27880#issuecomment-3459415761

From liach at openjdk.org  Wed Oct 29 03:23:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Oct 2025 03:23:04 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 18:51:40 GMT, Ioi Lam  wrote:

>> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments about @AOTSafeClassInitializer in SharedSecrets.java

The updated comments look very clear. Thanks!

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27880#pullrequestreview-3391539750

From iklam at openjdk.org  Wed Oct 29 03:26:16 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 29 Oct 2025 03:26:16 GMT
Subject: Integrated: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam  wrote:

> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.

This pull request has now been integrated.

Changeset: 0687f120
Author:    Ioi Lam 
URL:       https://git.openjdk.org/jdk/commit/0687f120cc324f35fe43d811b6beb4184fd854ec
Stats:     260 lines in 10 files changed: 224 ins; 35 del; 1 mod

8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets

Reviewed-by: liach, heidinga

-------------

PR: https://git.openjdk.org/jdk/pull/27880

From asemenyuk at openjdk.org  Wed Oct 29 03:33:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 29 Oct 2025 03:33:02 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 01:32:50 GMT, Alexander Matveev  wrote:

> - Added JDK specific keys/values to Info.plist of embedded runtime.
> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.

How do we test the defaults? We need a new test that will verify that if the runtime has a "bin" subdirectory, the runtime plist file has "standalone runtime"-specific properties and vice versa.
The test should be used with the followign runtimes:
 - A runtime with "bin" subdirectory created by jpackage.
 - A runtime without "bin" subdirectory created by jpackage.
 - A runtime with "bin" subdirectory passed to jpackage through `--runtime-image`.
 - A runtime without "bin" subdirectory passed to jpackage through `--runtime-image`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3459481839

From asemenyuk at openjdk.org  Wed Oct 29 03:39:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 29 Oct 2025 03:39:02 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 01:32:50 GMT, Alexander Matveev  wrote:

> - Added JDK specific keys/values to Info.plist of embedded runtime.
> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 319:

> 317:                 // always something in application image.
> 318:                 fakeRuntimeDir.resolve("bin").toFile().mkdir();
> 319:                 createBulkFile.accept(fakeRuntimeDir.resolve(Path.of("bin", "bulk")));

This change makes the above `fakeRuntimeDir.resolve("bin").toFile().mkdir();` redundant. Overall, the whole

if (TKit.isLinux()) {
    // Need to make the code in rpm spec happy as it assumes there is
    // always something in application image.
    fakeRuntimeDir.resolve("bin").toFile().mkdir();
}

construction is redundant and can be replaced with:

if (includeBin) {
    createBulkFile.accept(fakeRuntimeDir.resolve(Path.of("bin", "bulk")));
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28033#discussion_r2471636936

From asemenyuk at openjdk.org  Wed Oct 29 03:45:07 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 29 Oct 2025 03:45:07 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 01:32:50 GMT, Alexander Matveev  wrote:

> - Added JDK specific keys/values to Info.plist of embedded runtime.
> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.

test/jdk/tools/jpackage/macosx/CustomInfoPListTest.java line 189:

> 187:                 return defaultVerifier;
> 188:             } else {
> 189:                 boolean includeBin = customPLists.contains(CustomPListType.EMBEDDED_RUNTIME_WITH_BIN);

`customPLists.contains(CustomPListType.EMBEDDED_RUNTIME_WITH_BIN)` puts restrictions on what test cases can be executed with the external runtime that has the "bin" subdirectory.

This should be a separate property of TestConfig class:

public record TestConfig(Set customPLists, boolean runtimeWithBinDir)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28033#discussion_r2471643208

From darcy at openjdk.org  Wed Oct 29 04:08:05 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Oct 2025 04:08:05 GMT
Subject: RFR: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 11:03:00 GMT, Raffaello Giulietti  wrote:

>> Yet another step in modernizing `FloatingDecimal`s floating-point parsing.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
> 
>  - Merge branch 'master' into 8366017
>  - Added test for all float->String->float roundtrips.
>  - Merge branch 'master' into 8366017
>  - Added tests to exercise fast paths.
>  - Fix a rare bug.
>  - Merge branch 'master' into 8366017
>  - More complete benchmarks.
>  - JMH benchmarks.
>  - Adapted tests to more restricted access.
>  - Merge branch 'master' into 8366017
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/96259936...c3485864

src/java.base/share/classes/jdk/internal/math/FDBigInteger.java line 55:

> 53:         Object[] caches = archivedCaches;
> 54:         if (caches == null) {
> 55:             long[] long5pow = {

Would it be worthwhile to make these arrays `@Stable`?

In the future, might be a candidate for StableConstant/LazyValue functionality.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26990#discussion_r2471667444

From asemenyuk at openjdk.org  Wed Oct 29 04:10:03 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 29 Oct 2025 04:10:03 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 01:32:50 GMT, Alexander Matveev  wrote:

> Updated CustomInfoPListTest to test Info.plist with bin folder.

Why? jpackage picks the same file from the resource directory regardless of whether the "bin" subdirectory is present in the runtime. The "bin" subdirectory in the runtime only affects the default plist resource that jpackage uses.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3459533619

From darcy at openjdk.org  Wed Oct 29 04:21:04 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Oct 2025 04:21:04 GMT
Subject: RFR: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 11:03:00 GMT, Raffaello Giulietti  wrote:

>> Yet another step in modernizing `FloatingDecimal`s floating-point parsing.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
> 
>  - Merge branch 'master' into 8366017
>  - Added test for all float->String->float roundtrips.
>  - Merge branch 'master' into 8366017
>  - Added tests to exercise fast paths.
>  - Fix a rare bug.
>  - Merge branch 'master' into 8366017
>  - More complete benchmarks.
>  - JMH benchmarks.
>  - Adapted tests to more restricted access.
>  - Merge branch 'master' into 8366017
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/96259936...c3485864

Marked as reviewed by darcy (Reviewer).

test/jdk/java/lang/Double/ParseDouble.java line 765:

> 763:     private static void testFastPaths() {
> 764:         /* Exercises the fast paths in jdk.internal.math.FloatingDecimal. */
> 765:         check("1", 1.0);

Something to consider: specify the double values in hex literals -- this would exercise entirely different code paths than the decimal ones.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26990#pullrequestreview-3391609408
PR Review Comment: https://git.openjdk.org/jdk/pull/26990#discussion_r2471679731

From darcy at openjdk.org  Wed Oct 29 04:21:06 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Oct 2025 04:21:06 GMT
Subject: RFR: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 29 Oct 2025 04:05:03 GMT, Joe Darcy  wrote:

> Would it be worthwhile to make these arrays `@Stable`?
> 
> In the future, might be a candidate for StableConstant/LazyValue functionality.

PS If each array is read only once, then perhaps the other data structures would be better initialized in a loop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26990#discussion_r2471678511

From iklam at openjdk.org  Wed Oct 29 04:35:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 29 Oct 2025 04:35:41 GMT
Subject: RFR: 8370797: Test
 runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java failed on macos
 26
Message-ID: 

The test expects output like this


CompressedClassSpaceBaseAddress=0x0000000b00000000 given, but reserving class space failed.


But the actual output is:


CompressedClassSpaceBaseAddress=0x0000000d00000000 given with shift 6, cannot be used to encode class pointers

-------------

Commit messages:
 - 8370797: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java failed on macos 26

Changes: https://git.openjdk.org/jdk/pull/28035/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28035&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370797
  Stats: 27 lines in 2 files changed: 25 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28035/head:pull/28035

PR: https://git.openjdk.org/jdk/pull/28035

From dholmes at openjdk.org  Wed Oct 29 05:56:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Oct 2025 05:56:07 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v6]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 24 Oct 2025 14:06:03 GMT, Coleen Phillimore  wrote:

>> Yes, but don?t really see the benefit. It?s replacing a null string for `precond` in a crash.
>
> These null strings make me wish we had an assert with no strings if one isn't provided.  I suppose the "precond" string isn't much better. I don't like null strings - it seems like you want to say why you're asserting this condition or what it means, ie take the opportunity to provide a bit more documentation.  Like here you could say that monitorenter is only preempted when the top frame is interpreted or runtime (which is coming from the compiler right?), which I suppose is redundant with the condition.  I suppose nothing is better than "sanity" or "should be".  I retract my suggestion to use precond though.  Others might believe it's better but I'm agnostic.

So is it a compiled frame otherwise? Reporting the unexpected frame type might be useful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2471812478

From dholmes at openjdk.org  Wed Oct 29 06:27:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Oct 2025 06:27:11 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v10]
In-Reply-To: 
References: 
 
Message-ID: <8lMiLlH9mRrGr7vGnywhk1tuTnaM8PanfOI20v5KYGU=.b428de44-95e5-459c-92f0-55a51b9ec910@github.com>

On Tue, 28 Oct 2025 19:37:34 GMT, Patricio Chilano Mateo  wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add const to references

A few additional comments/suggestions, but overall this looks good (to the extent I understand the details). Thanks.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2735:

> 2733:   HandleMarkCleaner hm(current);  // Cleanup all handles (including so._conth) before returning to Java.
> 2734:   ContinuationWrapper::SafepointOp so(current, _cont);
> 2735:   AnchorMark am(current, top);  // Set the anchor so that the stack is walkable.

Shouldn't you delete the `clear_anchor` at line 2739 below?

src/hotspot/share/runtime/javaCalls.cpp line 61:

> 59:   assert(!thread->owns_locks(), "must release all locks when leaving VM");
> 60:   guarantee(thread->can_call_java(), "cannot make java calls from the native compiler");
> 61:   assert(!thread->preempting(), "");

I'm not sure why this is checked here, and there is no error message to tell me. If we did get here with `preempting` set what would that mean?

src/hotspot/share/runtime/thread.cpp line 578:

> 576: 
> 577: bool Thread::TrySpinAcquire(volatile int * adr) {
> 578:   return AtomicAccess::cmpxchg(adr, 0, 1) == 0;

How is this a try-spin-acquire operation ??? I don't think we need this, we can just inline the `cmpxchg` where needed.

src/hotspot/share/utilities/exceptions.cpp line 350:

> 348:     // the exception is propagated we might make an upcall to
> 349:     // Java to initialize the object with the cause of exception.
> 350:     NoPreemptMark npm(thread);

Could you explain the control flow in more detail here please. I'm unclear both how we get here and exactly what the affect of the NoPreemptMark is.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3391793337
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2471824170
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2471827558
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2471843917
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2471852020

From dholmes at openjdk.org  Wed Oct 29 06:27:13 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Oct 2025 06:27:13 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: <8Oq4qcIh0vAMYwzAXVPZJwbx7Zx7b6nMMCN9gqFFNkE=.ea219d84-de39-4d64-8117-d919e41c4eeb@github.com>

On Fri, 24 Oct 2025 14:19:44 GMT, Coleen Phillimore  wrote:

>> src/hotspot/share/runtime/synchronizer.hpp line 230:
>> 
>>> 228:   bool    _skip_exit;
>>> 229:  public:
>>> 230:   ObjectLocker(Handle obj, TRAPS);
>> 
>> I wonder if we should declare `PREEMPTABLE_TRAPS` as an indicator that the only exception expected to come out of a call is the preempted-exception?
>
> Not sure if I like that idea because then we might have to change other callers along the way for this new convention and everybody's already confused by TRAPS so then they'd be confused by a new TRAPS too.

I don't think we would have to. There are a handful of methods that now declare TRAPS but the only exception they should ever encounter is the PreemptException. It would be easier to understand the code if this was evident in their use of TRAPS. Also note it is purely documentation - the definition of `PREEMPTABLE_TRAPS` is exactly the same as `TRAPS`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2471840756

From dholmes at openjdk.org  Wed Oct 29 06:33:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Oct 2025 06:33:02 GMT
Subject: RFR: 8370393: Cleanup handling of ancient Windows versions from
 GetJavaProperties java_props_md
In-Reply-To: 
References: 
 
Message-ID: <9XiDFi-Hic2nsVQmBO9Xj0xEfsQOpHbIkUkJc9rOIAc=.027457b7-1f58-4dc7-b420-a0209f9d9c5f@github.com>

On Tue, 28 Oct 2025 15:09:17 GMT, Matthias Baesken  wrote:

> I noticed that we handle some pre Windows 8 versions here too https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L1957
> 
> Should I remove/adjust this too in this PR (and change the PR/JBS issue title)?

I don't think I would worry about removing the old version reporting code in hotspot - it is harmless.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28022#issuecomment-3460040995

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 stuefe at openjdk.org  Wed Oct 29 07:04:06 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 29 Oct 2025 07:04:06 GMT
Subject: RFR: 8370797: Test
 runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java failed on macos
 26
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 04:28:59 GMT, Ioi Lam  wrote:

> The test expects output like this
> 
> 
> CompressedClassSpaceBaseAddress=0x0000000b00000000 given, but reserving class space failed.
> 
> 
> But the actual output is:
> 
> 
> CompressedClassSpaceBaseAddress=0x0000000d00000000 given with shift 6, cannot be used to encode class pointers

Ok. Thanks for fixing.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28035#pullrequestreview-3391930386

From sherman at openjdk.org  Wed Oct 29 07:37:06 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 29 Oct 2025 07:37:06 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v4]
In-Reply-To: <_5e7Ota89HOgtcpsy4umlfF1EL1f3Xiyt2lmG1gN_DM=.6a3718d0-4cb3-49d6-82ca-16d6ad7bf8bc@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
 <_5e7Ota89HOgtcpsy4umlfF1EL1f3Xiyt2lmG1gN_DM=.6a3718d0-4cb3-49d6-82ca-16d6ad7bf8bc@github.com>
Message-ID: 

On Wed, 22 Oct 2025 20:40:32 GMT, Roger Riggs  wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test case update
>
> src/java.base/share/classes/java/lang/StringLatin1.java line 70:
> 
>> 68:         return value[index] & 0xff;
>> 69:     }
>> 70: 
> 
> Seems to be unused and is identical to `getChar`

removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2471995749

From mbaesken at openjdk.org  Wed Oct 29 08:11:02 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 29 Oct 2025 08:11:02 GMT
Subject: RFR: 8370393: Cleanup handling of ancient Windows versions from
 GetJavaProperties java_props_md
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 15:05:14 GMT, Matthias Baesken  wrote:

> There are some ancient Windows versions still handled in GetJavaProperties :
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/windows/native/libjava/java_props_md.c#L456
> 
> We compile currently with Windows 8+ settings :
> 
> 
> # _WIN32_WINNT=0x0602 means access APIs for Windows 8 and above. See
> # https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170
> ALWAYS_DEFINES="-DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0602 \
> 
> 
> So everything older than Windows 8 could most likely be removed.

Okay thanks for the feedback so I keep the HS coding as it is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28022#issuecomment-3460286380

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 prappo at openjdk.org  Wed Oct 29 09:13:52 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Oct 2025 09:13:52 GMT
Subject: Integrated: 8368856: Add a method that performs saturating addition of
 a Duration to an Instant
In-Reply-To: 
References: 
Message-ID: 

On Mon, 29 Sep 2025 13:55:35 GMT, Pavel Rappo  wrote:

> We recently [discussed] the possibility of introducing saturating arithmetic for deadline computation. Consider this PR as a starting point. Once we agree on the implementation, I'll file a CSR.
> 
> I created a method in `Instant` to add `Duration`. One could argue that the proper way would be to go all the way and create a method in `Temporal` to add `TemporalAmount`. Or maybe even expand the functionality, and create an additional method in `Temporal` to subtract `TemporalAmount`.
> 
> My current thinking is that if we were to do that, there would be a lot of expensive, unused code. Saturating logic seems to be only useful for `Instant` and `Duration`.
> 
> Even if we decide to extend `Temporal` to add/subtract `TemporalAmount`, it could always be done later. From the perspective of `Instant`, `plus(TemporalAmount)` will be just an overload of `plus(Duration)`.
> 
> [discussed]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/151098.html

This pull request has now been integrated.

Changeset: 2758c6fd
Author:    Pavel Rappo 
URL:       https://git.openjdk.org/jdk/commit/2758c6fda2f774d98ef0c24535a7f7e9fc722379
Stats:     104 lines in 2 files changed: 104 ins; 0 del; 0 mod

8368856: Add a method that performs saturating addition of a Duration to an Instant

Reviewed-by: naoto, rriggs, scolebourne

-------------

PR: https://git.openjdk.org/jdk/pull/27549

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 jpai at openjdk.org  Wed Oct 29 09:52:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Oct 2025 09:52:56 GMT
Subject: RFR: 4397513: Misleading "interface method" in InvocationHandler
 specification
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 17:49:40 GMT, Chen Liang  wrote:

> Update occurrences of the not-exactly-correct "interface method" to "invoked method" because 3 Object methods are proxied too. In addition, update the description about the declaring class of the method to be more accurate so that it doesn't clash with the "duplicate method" section in Proxy.

src/java.base/share/classes/java/lang/reflect/InvocationHandler.java line 59:

> 57:      * the method invoked on the proxy instance; the declaring
> 58:      * class of the {@code Method} object may be a proxy interface,
> 59:      * one of their superinterfaces, or the {@code Object} class

Hello Chen, would it be better to word that latter part of the sentence as:

> the declaring class of the {@code Method} will either be one of the interfaces implemented by the proxy instance, or one of their super interfaces, or the {@code Object} class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28024#discussion_r2472350430

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 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 cushon at openjdk.org  Wed Oct 29 10:58:02 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 29 Oct 2025 10:58:02 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known
 lengths
Message-ID: 

This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.

This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest


    byte[] bytes = new byte[length];
    MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
    return new String(bytes, charset);


However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.

-------------

Commit messages:
 - 8369564: Provide a MemorySegment API to read strings with known lengths

Changes: https://git.openjdk.org/jdk/pull/28043/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369564
  Stats: 152 lines in 4 files changed: 136 ins; 14 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From rgiulietti at openjdk.org  Wed Oct 29 11:06:48 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 29 Oct 2025 11:06:48 GMT
Subject: RFR: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 29 Oct 2025 04:16:37 GMT, Joe Darcy  wrote:

>> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
>> 
>>  - Merge branch 'master' into 8366017
>>  - Added test for all float->String->float roundtrips.
>>  - Merge branch 'master' into 8366017
>>  - Added tests to exercise fast paths.
>>  - Fix a rare bug.
>>  - Merge branch 'master' into 8366017
>>  - More complete benchmarks.
>>  - JMH benchmarks.
>>  - Adapted tests to more restricted access.
>>  - Merge branch 'master' into 8366017
>>  - ... and 26 more: https://git.openjdk.org/jdk/compare/96259936...c3485864
>
> test/jdk/java/lang/Double/ParseDouble.java line 765:
> 
>> 763:     private static void testFastPaths() {
>> 764:         /* Exercises the fast paths in jdk.internal.math.FloatingDecimal. */
>> 765:         check("1", 1.0);
> 
> Something to consider: specify the double values in hex literals -- this would exercise entirely different code paths than the decimal ones.

Good point, I fully agree.
Updating the test to use hexadecimals...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26990#discussion_r2472575652

From duke at openjdk.org  Wed Oct 29 11:43:49 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 29 Oct 2025 11:43:49 GMT
Subject: RFR: 8367603: Optimize exact division in BigDecimal [v23]
In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
Message-ID: 

> A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator.

fabioromano1 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 28 additional commits since the last revision:

 - Merge branch 'openjdk:master' into big-decimal-exact-divide
 - Simplification
 - Update DivideTests.java
 - Added tests for extreme scale cases
 - Code simplification
 - Avoid incorrect results when the preferred scale exceeds int range
 - Review's changes
 - Minor change
 - Code simplification
 - Avoid overflow of result's scale
 - ... and 18 more: https://git.openjdk.org/jdk/compare/468387eb...57968657

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27271/files
  - new: https://git.openjdk.org/jdk/pull/27271/files/ccd9791a..57968657

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=21-22

  Stats: 219330 lines in 2925 files changed: 167752 ins; 33366 del; 18212 mod
  Patch: https://git.openjdk.org/jdk/pull/27271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27271/head:pull/27271

PR: https://git.openjdk.org/jdk/pull/27271

From duke at openjdk.org  Wed Oct 29 11:51:59 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 29 Oct 2025 11:51:59 GMT
Subject: RFR: 8367603: Optimize exact division in BigDecimal [v24]
In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
Message-ID: 

> A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27271/files
  - new: https://git.openjdk.org/jdk/pull/27271/files/57968657..cf2a309e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=22-23

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27271/head:pull/27271

PR: https://git.openjdk.org/jdk/pull/27271

From duke at openjdk.org  Wed Oct 29 11:52:01 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 29 Oct 2025 11:52:01 GMT
Subject: RFR: 8367603: Optimize exact division in BigDecimal [v24]
In-Reply-To: 
References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
 
 
Message-ID: <0zUQlypv2Mno6YgOv2DXfRgaPtCrz_Lu9diNMsgrI1I=.ffa6a6d2-e171-493a-8593-8011a7ada5cf@github.com>

On Mon, 27 Oct 2025 19:50:46 GMT, Joe Darcy  wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback
>
> src/java.base/share/classes/java/math/BigDecimal.java line 1794:
> 
>> 1792:         if (this.signum() == 0) // 0/y
>> 1793:             return zeroValueOf(preferredScale);
>> 1794:         else {
> 
> The old algorithm has relatively few paths through it for different arguments.
> 
> Do the existing test cases provide adequate coverage of the new set of code paths?

I think they do, @rgiulietti do you think the test coverage is adequate?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27271#discussion_r2472693270

From alanb at openjdk.org  Wed Oct 29 12:05:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Oct 2025 12:05:30 GMT
Subject: RFR: 4517644: Core reflection setter type conversion spec bugs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 22:23:59 GMT, Chen Liang  wrote:

> ### Current Status
> In core reflection, there are a few holes with the documentation on the type conversions performed on the different setters. They generally follow this process:
> 
> 1. The Object-valued setters checks the destination type. If that type is primitive, unbox the object.
> 2. Perform identity or (primitive/reference, depending on destination type) widening conversions.
> 
> For each step, they can fail with IllegalArgumentException, which has been the long standing behavior.
> 
> Note that this process is more restrictive than the JLS 5.2 assignment context, which allows boxing conversions, while the primitive reflective setters consistently reject them.
> 
> ### Problems
> There are some problems with current specs:
> 1. No mention that boxing is never done for primitive-typed setters
> 2. Array.set missing description for the final identity or widening conversion (reference or primitive) and the associated IAE condition
> 3. Field.set misses the identity or widening in IAE clause (but mentioned in main body)
> 4. Field primitive setters incorrectly claim they are equivalent to `set(instance, wrapper)` which is wrong due to lack of boxing conversion
> 5. Field primitive setters refer to nonsense "unwrapping conversion"
> 
> ### Solutions
> 1. Make sure the unbox -> identity/widen process and the IAE conditoins are present in both Field and Array.set
> 2. Add that boxing is absent for all primitive setters
> 3. Fix the Field primitive setters' "unwrapping conversion" to be "identity or primitive widening conversion" as in Array primitive setters
> 4. Qualify the Field primitive setters assertion with "if this field is of a primitive type" to make it correct

The class description allows for widening but specifies IAE if a narrowing conversion is needed. Should we expand this sentence? I'm also wondering about identity conversions in description of each method as I don't know if this will be understand by reader should links.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28029#issuecomment-3461163146

From alanb at openjdk.org  Wed Oct 29 12:10:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Oct 2025 12:10:28 GMT
Subject: RFR: 4397513: Misleading "interface method" in InvocationHandler
 specification
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 17:49:40 GMT, Chen Liang  wrote:

> Update occurrences of the not-exactly-correct "interface method" to "invoked method" because 3 Object methods are proxied too. In addition, update the description about the declaring class of the method to be more accurate so that it doesn't clash with the "duplicate method" section in Proxy.

I think this wording looks okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28024#pullrequestreview-3392989849

From rgiulietti at openjdk.org  Wed Oct 29 13:34:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 29 Oct 2025 13:34:51 GMT
Subject: RFR: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal [v7]
In-Reply-To: 
References: 
Message-ID: 

> Yet another step in modernizing `FloatingDecimal`s floating-point parsing.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Replace decimal with hexadecimal floating-point literals in test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26990/files
  - new: https://git.openjdk.org/jdk/pull/26990/files/c3485864..07e08aca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26990&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26990&range=05-06

  Stats: 23 lines in 1 file changed: 0 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/26990.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26990/head:pull/26990

PR: https://git.openjdk.org/jdk/pull/26990

From jlahoda at openjdk.org  Wed Oct 29 13:51:31 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 29 Oct 2025 13:51:31 GMT
Subject: RFR: 8359145: Implement JEP 530: Primitive Types in Patterns,
 instanceof, and switch (Fourth Preview) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 12:46:30 GMT, Aggelos Biboudis  wrote:

>> PR for Primitive Types in Patterns, instanceof, and switch (Fourth Preview).
>> 
>> spec: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis 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:
> 
>   8359145: JEP 530: Implement Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

I think the direction is good, there are some comments inline.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5099:

> 5097:         }
> 5098:     }
> 5099:     // where

Nit:
Suggestion:

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4743:

> 4741:                     boolean dominated = false;
> 4742: 
> 4743:                     if (unconditionalCaseLabel == testCaseLabel) unconditionalFound = true;

I think the code here is correct, but it is very hard to read (to me, at least). I wonder if there's a chance to try to tweak the code so that it is more readable.

At least: do `{}` around `unconditionalFound`, and move the `dominatedCandidate` into the `if (!currentType.hasTag(ERROR) && !testType.hasTag(ERROR)) {`. I suspect it might be possible to replace `dominatedCandidate` with `continue` in `if (currentType.constValue() instanceof Number) {` (would need to `if (allowPrimitivePatterns && unconditionalFound && unconditionalCaseLabel != label) {` check upfront, so not sure if that would improve things).

test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactInAssignability.java line 93:

> 91:     }
> 92:     void assertOriginalAssignmentNarrowingAndUnconditionality() {
> 93:         // byte b =  vs ExactConversionsSupport::isIntToByteExact

If I understand it correctly, the updated and original isAssignable should give the same results, right? I think it would be better to have one invocation, like `assertOriginaAndUpdatedAssignable`, that would check that for the given input, both methods return the same value, and the expected value. Having to lists of cases is likely to lead to omissions/mistakes, I suspect.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27637#pullrequestreview-3393466239
PR Review Comment: https://git.openjdk.org/jdk/pull/27637#discussion_r2473119289
PR Review Comment: https://git.openjdk.org/jdk/pull/27637#discussion_r2473182215
PR Review Comment: https://git.openjdk.org/jdk/pull/27637#discussion_r2473117111

From rgiulietti at openjdk.org  Wed Oct 29 14:01:39 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 29 Oct 2025 14:01:39 GMT
Subject: RFR: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal [v8]
In-Reply-To: 
References: 
Message-ID: 

> Yet another step in modernizing `FloatingDecimal`s floating-point parsing.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Make arrays stable and remove synchronisation.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26990/files
  - new: https://git.openjdk.org/jdk/pull/26990/files/07e08aca..81b3c642

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26990&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26990&range=06-07

  Stats: 66 lines in 1 file changed: 7 ins; 39 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/26990.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26990/head:pull/26990

PR: https://git.openjdk.org/jdk/pull/26990

From liach at openjdk.org  Wed Oct 29 14:28:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Oct 2025 14:28:33 GMT
Subject: RFR: 4517644: Core reflection setter type conversion spec bugs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 22:23:59 GMT, Chen Liang  wrote:

> ### Current Status
> In core reflection, there are a few holes with the documentation on the type conversions performed on the different setters. They generally follow this process:
> 
> 1. The Object-valued setters checks the destination type. If that type is primitive, unbox the object.
> 2. Perform identity or (primitive/reference, depending on destination type) widening conversions.
> 
> For each step, they can fail with IllegalArgumentException, which has been the long standing behavior.
> 
> Note that this process is more restrictive than the JLS 5.2 assignment context, which allows boxing conversions, while the primitive reflective setters consistently reject them.
> 
> ### Problems
> There are some problems with current specs:
> 1. No mention that boxing is never done for primitive-typed setters
> 2. Array.set missing description for the final identity or widening conversion (reference or primitive) and the associated IAE condition
> 3. Field.set misses the identity or widening in IAE clause (but mentioned in main body)
> 4. Field primitive setters incorrectly claim they are equivalent to `set(instance, wrapper)` which is wrong due to lack of boxing conversion
> 5. Field primitive setters refer to nonsense "unwrapping conversion"
> 
> ### Solutions
> 1. Make sure the unbox -> identity/widen process and the IAE conditoins are present in both Field and Array.set
> 2. Add that boxing is absent for all primitive setters
> 3. Fix the Field primitive setters' "unwrapping conversion" to be "identity or primitive widening conversion" as in Array primitive setters
> 4. Qualify the Field primitive setters assertion with "if this field is of a primitive type" to make it correct

I think that paragraph most likely applies to the primitive accessors, because Object `set` are already performing necessary casts as narrowing conversions, and Object `get` never narrows its result. I should qualify this paragraph.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28029#issuecomment-3461852729

From liach at openjdk.org  Wed Oct 29 14:31:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Oct 2025 14:31:58 GMT
Subject: RFR: 4397513: Misleading "interface method" in InvocationHandler
 specification
In-Reply-To: 
References: 
 
Message-ID: <0tJNg_4QtYc9aLHhMqmls3UTcgYE3GN3SO4v7FDhoko=.55ccac9d-7eb4-460f-ab3b-d2ae6105d591@github.com>

On Wed, 29 Oct 2025 09:50:06 GMT, Jaikiran Pai  wrote:

>> Update occurrences of the not-exactly-correct "interface method" to "invoked method" because 3 Object methods are proxied too. In addition, update the description about the declaring class of the method to be more accurate so that it doesn't clash with the "duplicate method" section in Proxy.
>
> src/java.base/share/classes/java/lang/reflect/InvocationHandler.java line 59:
> 
>> 57:      * the method invoked on the proxy instance; the declaring
>> 58:      * class of the {@code Method} object may be a proxy interface,
>> 59:      * one of their superinterfaces, or the {@code Object} class
> 
> Hello Chen, would it be better to word that latter part of the sentence as:
> 
>> the declaring class of the {@code Method} will either be one of the interfaces implemented by the proxy instance, or one of their super interfaces, or the {@code Object} class.

Hi Jai, the term "proxy interface" is defined in java.lang.reflect.Proxy, together with "proxy instance":

> A proxy class is a class created at runtime that implements a specified
> list of interfaces, known as proxy interfaces. A proxy instance
> is an instance of a proxy class.

So I believe the term "proxy interface" makes sense when you have a "proxy instance" in the context.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28024#discussion_r2473455829

From asemenyuk at openjdk.org  Wed Oct 29 14:45:32 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 29 Oct 2025 14:45:32 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
Message-ID: <-aY_Vo5sinHQHtqKjdV_7KS_6aRRNykC_wKei-scf_I=.76ae21ef-9bfd-4075-823f-d0fa0f4ee5da@github.com>

On Wed, 29 Oct 2025 01:32:50 GMT, Alexander Matveev  wrote:

> - Added JDK specific keys/values to Info.plist of embedded runtime.
> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java line 369:

> 367:                 Files.isDirectory(env.resolvedLayout().runtimeDirectory().resolve("bin")) ||
> 368:                 app.isRuntime();
> 369: 

The `writeRuntimeInfoPlist()` action is executed for the `MacBuildApplicationTaskID.RUNTIME_INFO_PLIST` and `MacBuildApplicationTaskID.COPY_RUNTIME_INFO_PLIST` tasks. `MacBuildApplicationTaskID.RUNTIME_INFO_PLIST` doesn't have dependencies. This means it can be executed before the runtime files are available in the output app image. Currently, this is not a problem because jpackage executes tasks synchronously, but eventually it will run them asynchronously, and the `Files.isDirectory(...)` test will fail.

The plist template should be selected at the configuration phase, not the bundling phase. However, this will require knowing/guessing if jlink will create native commands in the "bin" directory from its command line. It is straightforward if it boils down to testing whether it has the "--strip-native-commands" option. This is what we do when we test if jlink options are correct for the Apple App Store, right? [Test for "--strip-native-commands" in DeployParams.java](https://github.com/openjdk/jdk/blob/2c07214d7c075da5dd4a4e872aef29f58cef2bae/src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java#L277)

I'd suggest adding `boolean jdk.jpackage.internal.model.RuntimeBuilder.withNativeCommands()` method. Then  the code will be:

final var useRuntimeInfoPlist = app.isRuntime() || app.runtimeBuilder().orElseThrow().withNativeCommands();


Alternatively, you may add the `BuildApplicationTaskID.RUNTIME` task as a dependency for the `MacBuildApplicationTaskID.RUNTIME_INFO_PLIST` task. However, this is a less preferable solution.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28033#pullrequestreview-3393972142
PR Review Comment: https://git.openjdk.org/jdk/pull/28033#discussion_r2473538432

From liach at openjdk.org  Wed Oct 29 14:49:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Oct 2025 14:49:57 GMT
Subject: RFR: 4517644: Core reflection setter type conversion spec bugs
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> ### Current Status
> In core reflection, there are a few holes with the documentation on the type conversions performed on the different setters. They generally follow this process:
> 
> 1. The Object-valued setters checks the destination type. If that type is primitive, unbox the object.
> 2. Perform identity or (primitive/reference, depending on destination type) widening conversions.
> 
> For each step, they can fail with IllegalArgumentException, which has been the long standing behavior.
> 
> Note that this process is more restrictive than the JLS 5.2 assignment context, which allows boxing conversions, while the primitive reflective setters consistently reject them.
> 
> ### Problems
> There are some problems with current specs:
> 1. No mention that boxing is never done for primitive-typed setters
> 2. Array.set missing description for the final identity or widening conversion (reference or primitive) and the associated IAE condition
> 3. Class specification of field mentions widening/narrowing conversion rules that is not sensible for get/set Object accessors
> 4. Field.set misses the identity or widening in IAE clause (but mentioned in main body)
> 5. Field primitive setters incorrectly claim they are equivalent to set(instance, wrapper) which is wrong due to lack of boxing conversion
> 6. Field primitive setters refer to nonsense "unwrapping conversion"
> 
> ### Solutions
> 1. Make sure the unbox -> identity/widen process and the IAE conditions are present in both Field and Array.set
> 2. Add that boxing is absent for all primitive setters
> 3. Update Field class spec to mention the narrowing/widening conversion limits are for primitive accessors only
> 4. Fix the Field primitive setters' "unwrapping conversion" to be "identity or primitive widening conversion" as in Array primitive setters
> 5. Qualify the Field primitive setters assertion with "if this field is of a primitive type" to make it correct

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  the narrowing conversion restriction is primitive-only

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28029/files
  - new: https://git.openjdk.org/jdk/pull/28029/files/9f925617..5559e613

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28029&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28029&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28029.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28029/head:pull/28029

PR: https://git.openjdk.org/jdk/pull/28029

From liach at openjdk.org  Wed Oct 29 14:49:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Oct 2025 14:49:59 GMT
Subject: RFR: 4517644: Core reflection setter type conversion spec bugs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 22:23:59 GMT, Chen Liang  wrote:

> ### Current Status
> In core reflection, there are a few holes with the documentation on the type conversions performed on the different setters. They generally follow this process:
> 
> 1. The Object-valued setters checks the destination type. If that type is primitive, unbox the object.
> 2. Perform identity or (primitive/reference, depending on destination type) widening conversions.
> 
> For each step, they can fail with IllegalArgumentException, which has been the long standing behavior.
> 
> Note that this process is more restrictive than the JLS 5.2 assignment context, which allows boxing conversions, while the primitive reflective setters consistently reject them.
> 
> ### Problems
> There are some problems with current specs:
> 1. No mention that boxing is never done for primitive-typed setters
> 2. Array.set missing description for the final identity or widening conversion (reference or primitive) and the associated IAE condition
> 3. Class specification of field mentions widening/narrowing conversion rules that is not sensible for get/set Object accessors
> 4. Field.set misses the identity or widening in IAE clause (but mentioned in main body)
> 5. Field primitive setters incorrectly claim they are equivalent to set(instance, wrapper) which is wrong due to lack of boxing conversion
> 6. Field primitive setters refer to nonsense "unwrapping conversion"
> 
> ### Solutions
> 1. Make sure the unbox -> identity/widen process and the IAE conditions are present in both Field and Array.set
> 2. Add that boxing is absent for all primitive setters
> 3. Update Field class spec to mention the narrowing/widening conversion limits are for primitive accessors only
> 4. Fix the Field primitive setters' "unwrapping conversion" to be "identity or primitive widening conversion" as in Array primitive setters
> 5. Qualify the Field primitive setters assertion with "if this field is of a primitive type" to make it correct

I have pushed a commit correcting the class description paragraph in question to apply to primitive get/set only, and listed it in the problem and solutions sections on this PR and the CSR. Please review again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28029#issuecomment-3461979232

From jpai at openjdk.org  Wed Oct 29 14:56:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Oct 2025 14:56:53 GMT
Subject: RFR: 4397513: Misleading "interface method" in InvocationHandler
 specification
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 17:49:40 GMT, Chen Liang  wrote:

> Update occurrences of the not-exactly-correct "interface method" to "invoked method" because 3 Object methods are proxied too. In addition, update the description about the declaring class of the method to be more accurate so that it doesn't clash with the "duplicate method" section in Proxy.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28024#pullrequestreview-3394055086

From jpai at openjdk.org  Wed Oct 29 14:56:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Oct 2025 14:56:56 GMT
Subject: RFR: 4397513: Misleading "interface method" in InvocationHandler
 specification
In-Reply-To: <0tJNg_4QtYc9aLHhMqmls3UTcgYE3GN3SO4v7FDhoko=.55ccac9d-7eb4-460f-ab3b-d2ae6105d591@github.com>
References: 
 
 <0tJNg_4QtYc9aLHhMqmls3UTcgYE3GN3SO4v7FDhoko=.55ccac9d-7eb4-460f-ab3b-d2ae6105d591@github.com>
Message-ID: 

On Wed, 29 Oct 2025 14:28:41 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/reflect/InvocationHandler.java line 59:
>> 
>>> 57:      * the method invoked on the proxy instance; the declaring
>>> 58:      * class of the {@code Method} object may be a proxy interface,
>>> 59:      * one of their superinterfaces, or the {@code Object} class
>> 
>> Hello Chen, would it be better to word that latter part of the sentence as:
>> 
>>> the declaring class of the {@code Method} will either be one of the interfaces implemented by the proxy instance, or one of their super interfaces, or the {@code Object} class.
>
> Hi Jai, the term "proxy interface" is defined in java.lang.reflect.Proxy, together with "proxy instance":
> 
>> A proxy class is a class created at runtime that implements a specified
>> list of interfaces, known as proxy interfaces. A proxy instance
>> is an instance of a proxy class.
> 
> So I believe the term "proxy interface" makes sense when you have a "proxy instance" in the context.

Thank you for quoting that text - you are right, that term is already specified, so the changes you have here looks good to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28024#discussion_r2473606063

From alanb at openjdk.org  Wed Oct 29 15:18:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Oct 2025 15:18:56 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 21:48:38 GMT, Brian Burkhalter  wrote:

>> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355342: Resize buffer passed to GetFinalPathNameByHandleW if needed

src/java.base/windows/native/libjava/canonicalize_md.c line 200:

> 198:    have been converted to native form already, via JVM_NativePath().  This is
> 199:    necessary because _fullpath() rejects duplicate separator characters on
> 200:    Win95, though it accepts them on NT. */

What would you think about replacing this function description while it is fresh in our heads?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27324#discussion_r2473740438

From alanb at openjdk.org  Wed Oct 29 15:22:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Oct 2025 15:22:53 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 21:48:38 GMT, Brian Burkhalter  wrote:

>> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355342: Resize buffer passed to GetFinalPathNameByHandleW if needed

It's requires a lot of back and forth and several iterations but I think you've got this to a good place.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27324#pullrequestreview-3394249301

From jvernee at openjdk.org  Wed Oct 29 15:27:20 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 29 Oct 2025 15:27:20 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
Message-ID: 

See the JBS issue for a problem description.

This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.

For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
3. Any other Java code that runs as part of the linking process.

For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.

The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).

Testing: tier 1-4

-------------

Commit messages:
 - Make JVMTI test reentrant
 - Remove jdk.jfr vm symbol again
 - Use _throwing_unsafe_access_error flag to bail out of stack walk
 - Clarify comment
 - Merge branch 'master' into NewStackWalk
 - Whitelist jdk.jfr as well
 - Simplify BM
 - Add assert
 - Add reproducer
 - Polish
 - ... and 3 more: https://git.openjdk.org/jdk/compare/a0e0b2d3...fb01850d

Changes: https://git.openjdk.org/jdk/pull/27919/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27919&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370344
  Stats: 552 lines in 10 files changed: 534 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27919/head:pull/27919

PR: https://git.openjdk.org/jdk/pull/27919

From rgiulietti at openjdk.org  Wed Oct 29 15:29:00 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 29 Oct 2025 15:29:00 GMT
Subject: RFR: 8367603: Optimize exact division in BigDecimal [v24]
In-Reply-To: <0zUQlypv2Mno6YgOv2DXfRgaPtCrz_Lu9diNMsgrI1I=.ffa6a6d2-e171-493a-8593-8011a7ada5cf@github.com>
References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
 
 
 <0zUQlypv2Mno6YgOv2DXfRgaPtCrz_Lu9diNMsgrI1I=.ffa6a6d2-e171-493a-8593-8011a7ada5cf@github.com>
Message-ID: 

On Wed, 29 Oct 2025 11:48:04 GMT, fabioromano1  wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 1794:
>> 
>>> 1792:         if (this.signum() == 0) // 0/y
>>> 1793:             return zeroValueOf(preferredScale);
>>> 1794:         else {
>> 
>> The old algorithm has relatively few paths through it for different arguments.
>> 
>> Do the existing test cases provide adequate coverage of the new set of code paths?
>
> I think they do, @rgiulietti do you think the test coverage is adequate?

I'll have a look tomorrow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27271#discussion_r2473799850

From bpb at openjdk.org  Wed Oct 29 15:35:22 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Oct 2025 15:35:22 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v9]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 29 Oct 2025 15:16:20 GMT, Alan Bateman  wrote:

> [...] replacing this function description [...]

Will do. I also noticed the reference to legacy Windows versions, and it would be well timed given #28022.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27324#discussion_r2473834182

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 jvernee at openjdk.org  Wed Oct 29 15:43:25 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 29 Oct 2025 15:43:25 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 10:50:53 GMT, Liam Miller-Cushon  wrote:

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.

Some preliminary comments. I didn't look at the tests yet.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1338:

> 1336:      *                access operation will occur
> 1337:      * @param length  byte length to be used for string conversion (not including any
> 1338:      *                null termination)

I think 'to be used for string conversion' is a bit too vague (used _how_?). I think a more descriptive text could be something like 'length in bytes of the string to read' (matching also the pattern of the existing 'offset in bytes').

Also, what happens if:
- The length _does_ include a null terminator
- The length is not a multiple of the byte size of a character in the given charset.

On that last note, I wonder if this shouldn't be the length in bytes, but the length in characters. Then we can compute the byte length from the charset. That will make it impossible to pass a length that is not a multiple of the character size.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1349:

> 1347:      *         
      
> 1348:      *             
    • {@code B} is the size, in bytes, of the string encoded using the
> 1349:      *             provided charset (e.g. {@code str.getBytes(charset).length});
      • 

Isn't `B` equal to the `length` argument?

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1351:

> 1349:      *             provided charset (e.g. {@code str.getBytes(charset).length});
> 1350:      *             
    • {@code N} is the size (in bytes) of the terminator char according
> 1351:      *             to the provided charset. For instance, this is 1 for

Why is the terminator char important? The segment doesn't necessarily need to have a terminator char, right? I don't see this invariant being checked in the code either.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1363:

> 1361:      */
> 1362:     String getString(long offset, int length, Charset charset);
> 1363: 

I'd suggest putting the `length` parameter at the end, so that this becomes a telescoping overload of the length-less variant.

src/java.base/share/classes/jdk/internal/foreign/StringSupport.java line 66:

> 64:             case SINGLE_BYTE -> readByte(segment, offset, len, charset);
> 65:             case DOUBLE_BYTE -> readShort(segment, offset, len, charset);
> 66:             case QUAD_BYTE -> readInt(segment, offset, len, charset);

These 3 methods appear to be identical

-------------

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3394314370
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2473855397
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2473837599
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2473832085
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2473823655
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2473819485

From liach at openjdk.org  Wed Oct 29 16:34:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Oct 2025 16:34:28 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
In-Reply-To: 
References: 
Message-ID: <8sVi2i2XR1YXZpno5BSdfiP9MSBiFTxqAHmooOiDcJc=.0b14807a-188d-4fe8-b802-8ad1ba10233e@github.com>

On Tue, 21 Oct 2025 16:00:49 GMT, Jorn Vernee  wrote:

> See the JBS issue for a problem description.
> 
> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
> 
> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
> 3. Any other Java code that runs as part of the linking process.
> 
> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
> 
> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
> 
> Testing: tier 1-4

src/hotspot/share/prims/scopedMemoryAccess.cpp line 81:

> 79:     if (is_scoped) {
> 80:       assert(!would_have_bailed, "would have missed scoped method on release build");
> 81:       func(stream);

Why do we remove the short-circuiting here? For example, if we have is_accessing_session set to true already, why can't we short circuit?

test/jdk/java/foreign/sharedclosejfr/TestSharedCloseJFR.java line 30:

> 28:  * @requires vm.flavor != "zero"
> 29:  * @requires vm.debug
> 30:  * @requires vm.hasJFR

You can use & to require multiple conditions at once in one directive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2474193541
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2474079765

From cushon at openjdk.org  Wed Oct 29 16:37:34 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 29 Oct 2025 16:37:34 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Consolidate duplicate code in read methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/937a8681..cd6db90b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=00-01

  Stats: 70 lines in 2 files changed: 3 ins; 57 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From cushon at openjdk.org  Wed Oct 29 16:37:36 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 29 Oct 2025 16:37:36 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 15:29:34 GMT, Jorn Vernee  wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Consolidate duplicate code in read methods
>
> src/java.base/share/classes/jdk/internal/foreign/StringSupport.java line 66:
> 
>> 64:             case SINGLE_BYTE -> readByte(segment, offset, len, charset);
>> 65:             case DOUBLE_BYTE -> readShort(segment, offset, len, charset);
>> 66:             case QUAD_BYTE -> readInt(segment, offset, len, charset);
> 
> These 3 methods appear to be identical

Thanks, I refactored to do something more similar to the original PR to avoid the duplication here and with the existing read methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2474204354

From cushon at openjdk.org  Wed Oct 29 16:40:15 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 29 Oct 2025 16:40:15 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v2]
In-Reply-To: 
References: 
 
Message-ID: <_gORgVPPc2dmXVkRgjww36Z_6B80xoFP8MSDab7scZQ=.2ea4b41e-63bc-46d8-9608-a59602a66876@github.com>

On Wed, 29 Oct 2025 15:35:41 GMT, Jorn Vernee  wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Consolidate duplicate code in read methods
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1338:
> 
>> 1336:      *                access operation will occur
>> 1337:      * @param length  byte length to be used for string conversion (not including any
>> 1338:      *                null termination)
> 
> I think 'to be used for string conversion' is a bit too vague (used _how_?). I think a more descriptive text could be something like 'length in bytes of the string to read' (matching also the pattern of the existing 'offset in bytes').
> 
> Also, what happens if:
> - The length _does_ include a null terminator
> - The length is not a multiple of the byte size of a character in the given charset.
> 
> On that last note, I wonder if this shouldn't be the length in bytes, but the length in characters. Then we can compute the byte length from the charset. That will make it impossible to pass a length that is not a multiple of the character size.

Thanks for taking a look, I wanted to respond briefly to this part and will review the rest of the comments later:

> I wonder if this shouldn't be the length in bytes, but the length in characters. Then we can compute the byte length from the charset

Part of the motivation here is to support efficiently reading binary formats where I think it's more common to record the length of string data in bytes, than in 16-bit code units in the UTF-16 encoding of the line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2474212568

From bpb at openjdk.org  Wed Oct 29 16:47:00 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Oct 2025 16:47:00 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v10]
In-Reply-To: 
References: 
Message-ID: <-W8HvnEg10aJZDAL4bIsGdIukQuGw8626_-WldHC5EA=.92599c5e-de3e-401b-ac9c-7f20b76be8f2@github.com>

> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355342: Attempt to improve the description of wcanonicalize()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27324/files
  - new: https://git.openjdk.org/jdk/pull/27324/files/3820a269..e52cfb98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=08-09

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27324/head:pull/27324

PR: https://git.openjdk.org/jdk/pull/27324

From bpb at openjdk.org  Wed Oct 29 16:47:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Oct 2025 16:47:03 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v9]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 29 Oct 2025 15:32:08 GMT, Brian Burkhalter  wrote:

>> src/java.base/windows/native/libjava/canonicalize_md.c line 200:
>> 
>>> 198:    have been converted to native form already, via JVM_NativePath().  This is
>>> 199:    necessary because _fullpath() rejects duplicate separator characters on
>>> 200:    Win95, though it accepts them on NT. */
>> 
>> What would you think about replacing this function description while it is fresh in our heads?
>
>> [...] replacing this function description [...]
> 
> Will do. I also noticed the reference to legacy Windows versions, and it would be well timed given #28022.

Changed in e52cfb9.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27324#discussion_r2474224925

From alanb at openjdk.org  Wed Oct 29 16:51:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Oct 2025 16:51:09 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v9]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 29 Oct 2025 16:42:24 GMT, Brian Burkhalter  wrote:

>>> [...] replacing this function description [...]
>> 
>> Will do. I also noticed the reference to legacy Windows versions, and it would be well timed given #28022.
>
> Changed in e52cfb9.

It still references JVM_NativePath but the java.io hasn't used that in many years. So maybe we change that too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27324#discussion_r2474235906

From bpb at openjdk.org  Wed Oct 29 16:51:09 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Oct 2025 16:51:09 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v9]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 29 Oct 2025 16:46:18 GMT, Alan Bateman  wrote:

>> Changed in e52cfb9.
>
> It still references JVM_NativePath but the java.io hasn't used that in many years. So maybe we change that too.

Missed that; will fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27324#discussion_r2474241928

From bpb at openjdk.org  Wed Oct 29 17:07:19 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Oct 2025 17:07:19 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v11]
In-Reply-To: 
References: 
Message-ID: <555t3E1XBteckdnvkKb44wt88IJhfWAhN7Bi5aUIMBI=.7f4c99a5-3594-4b0c-9f8e-984ca43c9b6e@github.com>

> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355342: Remove vestigial reference from the description of wcanonicalize()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27324/files
  - new: https://git.openjdk.org/jdk/pull/27324/files/e52cfb98..4c58055f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=09-10

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27324/head:pull/27324

PR: https://git.openjdk.org/jdk/pull/27324

From bpb at openjdk.org  Wed Oct 29 17:09:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Oct 2025 17:09:55 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v9]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Wed, 29 Oct 2025 16:48:40 GMT, Brian Burkhalter  wrote:

>> It still references JVM_NativePath but the java.io hasn't used that in many years. So maybe we change that too.
>
> Missed that; will fix.

Updated in 4c58055.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27324#discussion_r2474290432

From alanb at openjdk.org  Wed Oct 29 17:16:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Oct 2025 17:16:38 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v11]
In-Reply-To: <555t3E1XBteckdnvkKb44wt88IJhfWAhN7Bi5aUIMBI=.7f4c99a5-3594-4b0c-9f8e-984ca43c9b6e@github.com>
References: 
 <555t3E1XBteckdnvkKb44wt88IJhfWAhN7Bi5aUIMBI=.7f4c99a5-3594-4b0c-9f8e-984ca43c9b6e@github.com>
Message-ID: 

On Wed, 29 Oct 2025 17:07:19 GMT, Brian Burkhalter  wrote:

>> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355342: Remove vestigial reference from the description of wcanonicalize()

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27324#pullrequestreview-3394907037

From mukulg at apache.org  Wed Oct 29 17:29:44 2025
From: mukulg at apache.org (Mukul Gandhi)
Date: Wed, 29 Oct 2025 22:59:44 +0530
Subject: Xalan's xslt 3.0 implementation updates
In-Reply-To: 
References: 
 <9ec8413d-aac9-4fd1-b623-3c993cec7519@oracle.com>
 
 
 
 
Message-ID: 

Hello Alan,
    As per your suggestions within mail below, Xalan has modified on
its repos, the code of JDK 1.8 class PatternSyntaxException.

With these modifications, Xalan's XSLT 3.0 code is now compiling fine
with JDK 25 with version 1.8 byte code compatibility.

On Thu, Oct 23, 2025 at 10:14?PM Alan Bateman  wrote:
> JDK 6 to JDK 8, it was been a warning at compile time to use JDK
> internal APIs. This changed to be a compile-time error in JDK 9, and for
> code compiled to older releases, an error at run-time since JDK 16.
>
> In the case of sun.security.action.GetPropertyAction then this was for
> the security manager case that is gone since JDK 24. So now needed now.
> There was a never a good reason to use this sun.* class directly as it
> just used AccessController.doPrivileged to invoke System.getProperty. So
> should be easy to replace the usage.


-- 
Regards,
Mukul Gandhi

From jvernee at openjdk.org  Wed Oct 29 17:35:33 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 29 Oct 2025 17:35:33 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> See the JBS issue for a problem description.
> 
> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
> 
> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
> 3. Any other Java code that runs as part of the linking process.
> 
> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
> 
> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
> 
> Testing: tier 1-4

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Short-circuit after finding our session

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27919/files
  - new: https://git.openjdk.org/jdk/pull/27919/files/fb01850d..041f6d2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27919&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27919&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27919/head:pull/27919

PR: https://git.openjdk.org/jdk/pull/27919

From jvernee at openjdk.org  Wed Oct 29 17:35:37 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 29 Oct 2025 17:35:37 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v2]
In-Reply-To: <8sVi2i2XR1YXZpno5BSdfiP9MSBiFTxqAHmooOiDcJc=.0b14807a-188d-4fe8-b802-8ad1ba10233e@github.com>
References: 
 <8sVi2i2XR1YXZpno5BSdfiP9MSBiFTxqAHmooOiDcJc=.0b14807a-188d-4fe8-b802-8ad1ba10233e@github.com>
Message-ID: 

On Wed, 29 Oct 2025 16:30:56 GMT, Chen Liang  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Short-circuit after finding our session
>
> src/hotspot/share/prims/scopedMemoryAccess.cpp line 81:
> 
>> 79:     if (is_scoped) {
>> 80:       assert(!would_have_bailed, "would have missed scoped method on release build");
>> 81:       func(stream);
> 
> Why do we remove the short-circuiting here? For example, if we have is_accessing_session set to true already, why can't we short circuit?

You're right. We can short circuit if we've already found our session. That will help cases where we have an agent loaded.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2474354136

From jvernee at openjdk.org  Wed Oct 29 17:42:38 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 29 Oct 2025 17:42:38 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v2]
In-Reply-To: <_gORgVPPc2dmXVkRgjww36Z_6B80xoFP8MSDab7scZQ=.2ea4b41e-63bc-46d8-9608-a59602a66876@github.com>
References: 
 
 <_gORgVPPc2dmXVkRgjww36Z_6B80xoFP8MSDab7scZQ=.2ea4b41e-63bc-46d8-9608-a59602a66876@github.com>
Message-ID: 

On Wed, 29 Oct 2025 16:37:55 GMT, Liam Miller-Cushon  wrote:

>> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1338:
>> 
>>> 1336:      *                access operation will occur
>>> 1337:      * @param length  byte length to be used for string conversion (not including any
>>> 1338:      *                null termination)
>> 
>> I think 'to be used for string conversion' is a bit too vague (used _how_?). I think a more descriptive text could be something like 'length in bytes of the string to read' (matching also the pattern of the existing 'offset in bytes').
>> 
>> Also, what happens if:
>> - The length _does_ include a null terminator
>> - The length is not a multiple of the byte size of a character in the given charset.
>> 
>> On that last note, I wonder if this shouldn't be the length in bytes, but the length in characters. Then we can compute the byte length from the charset. That will make it impossible to pass a length that is not a multiple of the character size.
>
> Thanks for taking a look, I wanted to respond briefly to this part and will review the rest of the comments later:
> 
>> I wonder if this shouldn't be the length in bytes, but the length in characters. Then we can compute the byte length from the charset
> 
> Part of the motivation here is to support efficiently reading binary formats where I think it's more common to record the length of string data in bytes, than in 16-bit code units in the UTF-16 encoding of the line.

Discussed this with the team as well. For cases of native interop it seems more likely that you'd have e.g. an array of `wchar_t` on the native side, and you are tracking the length of that array, not the byte size.

A user can easily convert between one or the other length representation by multiplying/dividing by the right scalar, but if the length is specified in bytes, the API has an extra error case we need to check and specify.

Either way, we felt that it would be a good idea if you could send an email to `panama-dev` in which you describe your exact use case, before getting further into the code review. That would give others a chance to respond with their use cases as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2474373352

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 jvernee at openjdk.org  Wed Oct 29 17:58:40 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 29 Oct 2025 17:58:40 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> See the JBS issue for a problem description.
> 
> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
> 
> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
> 3. Any other Java code that runs as part of the linking process.
> 
> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
> 
> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
> 
> Testing: tier 1-4

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Remove requires vm.debug

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27919/files
  - new: https://git.openjdk.org/jdk/pull/27919/files/041f6d2f..c1950051

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27919&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27919&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27919/head:pull/27919

PR: https://git.openjdk.org/jdk/pull/27919

From jvernee at openjdk.org  Wed Oct 29 17:58:42 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 29 Oct 2025 17:58:42 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v3]
In-Reply-To: <8sVi2i2XR1YXZpno5BSdfiP9MSBiFTxqAHmooOiDcJc=.0b14807a-188d-4fe8-b802-8ad1ba10233e@github.com>
References: 
 <8sVi2i2XR1YXZpno5BSdfiP9MSBiFTxqAHmooOiDcJc=.0b14807a-188d-4fe8-b802-8ad1ba10233e@github.com>
Message-ID: 

On Wed, 29 Oct 2025 16:08:49 GMT, Chen Liang  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove requires vm.debug
>
> test/jdk/java/foreign/sharedclosejfr/TestSharedCloseJFR.java line 30:
> 
>> 28:  * @requires vm.flavor != "zero"
>> 29:  * @requires vm.debug
>> 30:  * @requires vm.hasJFR
> 
> You can use & to require multiple conditions at once in one directive.

I prefer the readability of the separate requires tags. The `vm.debug` requirement can be removed though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2474403743

From cushon at openjdk.org  Wed Oct 29 18:27:42 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 29 Oct 2025 18:27:42 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v2]
In-Reply-To: 
References: 
 
 <_gORgVPPc2dmXVkRgjww36Z_6B80xoFP8MSDab7scZQ=.2ea4b41e-63bc-46d8-9608-a59602a66876@github.com>
 
Message-ID: 

On Wed, 29 Oct 2025 17:40:14 GMT, Jorn Vernee  wrote:

> A user can easily convert between one or the other length representation by multiplying/dividing by the right scalar

That is true of e.g. UTF-16 but not of UTF-8, since the encoding is variable width and doing the conversion from bytes to characters is more expensive there.

> Either way, we felt that it would be a good idea if you could send an email to panama-dev in which you describe your exact use case, before getting further into the code review. That would give others a chance to respond with their use cases as well.

Sounds good, thanks, I can start a thread discussing the use-case here at a higher level.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2474577641

From pchilanomate at openjdk.org  Wed Oct 29 20:25:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 29 Oct 2025 20:25:11 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v11]
In-Reply-To: 
References: 
Message-ID: 

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - More fixes from David's comments
 - Merge branch 'master' into JDK-8369238
 - add const to references
 - Improve comment in anchor_mark_set_pd
 - More comments from Coleen
 - rename _monitor to _init_lock
 - Extra comments from Coleen
 - define methods in resolve_from_cache with TRAPS and use CHECK_AND_CLEAR_PREEMPTED
 - PPC support
 - Remove extra debugging param
 - ... and 7 more: https://git.openjdk.org/jdk/compare/28f2591b...c7d6f5c5

-------------

Changes: https://git.openjdk.org/jdk/pull/27802/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=10
  Stats: 2179 lines in 98 files changed: 1753 ins; 120 del; 306 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

PR: https://git.openjdk.org/jdk/pull/27802

From pchilanomate at openjdk.org  Wed Oct 29 20:38:19 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 29 Oct 2025 20:38:19 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v6]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 29 Oct 2025 05:53:34 GMT, David Holmes  wrote:

>> These null strings make me wish we had an assert with no strings if one isn't provided.  I suppose the "precond" string isn't much better. I don't like null strings - it seems like you want to say why you're asserting this condition or what it means, ie take the opportunity to provide a bit more documentation.  Like here you could say that monitorenter is only preempted when the top frame is interpreted or runtime (which is coming from the compiler right?), which I suppose is redundant with the condition.  I suppose nothing is better than "sanity" or "should be".  I retract my suggestion to use precond though.  Others might believe it's better but I'm agnostic.
>
> So is it a compiled frame otherwise? Reporting the unexpected frame type might be useful.

I added a check for compiled or native. If we want to check all possibilities we could add a method in frame class to return the name of the frame type.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2475342971

From pchilanomate at openjdk.org  Wed Oct 29 20:38:22 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 29 Oct 2025 20:38:22 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v10]
In-Reply-To: <8lMiLlH9mRrGr7vGnywhk1tuTnaM8PanfOI20v5KYGU=.b428de44-95e5-459c-92f0-55a51b9ec910@github.com>
References: 
 
 <8lMiLlH9mRrGr7vGnywhk1tuTnaM8PanfOI20v5KYGU=.b428de44-95e5-459c-92f0-55a51b9ec910@github.com>
Message-ID: <37qXDxeUoKrmQSBxgOnJrvoxgjR6eMai0HNqY1ysYdE=.e3bf3e8e-3ae4-4baf-8681-3c0edc2a7e73@github.com>

On Wed, 29 Oct 2025 06:00:40 GMT, David Holmes  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add const to references
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2735:
> 
>> 2733:   HandleMarkCleaner hm(current);  // Cleanup all handles (including so._conth) before returning to Java.
>> 2734:   ContinuationWrapper::SafepointOp so(current, _cont);
>> 2735:   AnchorMark am(current, top);  // Set the anchor so that the stack is walkable.
> 
> Shouldn't you delete the `clear_anchor` at line 2739 below?

Yes, good catch. Removed.

> src/hotspot/share/runtime/thread.cpp line 578:
> 
>> 576: 
>> 577: bool Thread::TrySpinAcquire(volatile int * adr) {
>> 578:   return AtomicAccess::cmpxchg(adr, 0, 1) == 0;
> 
> How is this a try-spin-acquire operation ??? I don't think we need this, we can just inline the `cmpxchg` where needed.

Right, not sure why I used that class. I replaced it with the atomic operations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2475345821
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2475349441

From pchilanomate at openjdk.org  Wed Oct 29 20:38:24 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 29 Oct 2025 20:38:24 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: <8Oq4qcIh0vAMYwzAXVPZJwbx7Zx7b6nMMCN9gqFFNkE=.ea219d84-de39-4d64-8117-d919e41c4eeb@github.com>
References: 
 
 
 
 <8Oq4qcIh0vAMYwzAXVPZJwbx7Zx7b6nMMCN9gqFFNkE=.ea219d84-de39-4d64-8117-d919e41c4eeb@github.com>
Message-ID: 

On Wed, 29 Oct 2025 06:11:56 GMT, David Holmes  wrote:

>> Not sure if I like that idea because then we might have to change other callers along the way for this new convention and everybody's already confused by TRAPS so then they'd be confused by a new TRAPS too.
>
> I don't think we would have to. There are a handful of methods that now declare TRAPS but the only exception they should ever encounter is the PreemptException. It would be easier to understand the code if this was evident in their use of TRAPS. Also note it is purely documentation - the definition of `PREEMPTABLE_TRAPS` is exactly the same as `TRAPS`

If we want to avoid confusion with other users of `ObjectLocker` maybe we can leave it as it is and subclass it with a preemptable version? https://github.com/pchilano/jdk/compare/JDK-8369238...pchilano:jdk:PreemptableObjectLocker (this version could also use `PREEMPTABLE_TRAPS`)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2475339482

From pchilanomate at openjdk.org  Wed Oct 29 20:43:09 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 29 Oct 2025 20:43:09 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v10]
In-Reply-To: <8lMiLlH9mRrGr7vGnywhk1tuTnaM8PanfOI20v5KYGU=.b428de44-95e5-459c-92f0-55a51b9ec910@github.com>
References: 
 
 <8lMiLlH9mRrGr7vGnywhk1tuTnaM8PanfOI20v5KYGU=.b428de44-95e5-459c-92f0-55a51b9ec910@github.com>
Message-ID: 

On Wed, 29 Oct 2025 06:19:07 GMT, David Holmes  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add const to references
>
> src/hotspot/share/utilities/exceptions.cpp line 350:
> 
>> 348:     // the exception is propagated we might make an upcall to
>> 349:     // Java to initialize the object with the cause of exception.
>> 350:     NoPreemptMark npm(thread);
> 
> Could you explain the control flow in more detail here please. I'm unclear both how we get here and exactly what the affect of the NoPreemptMark is.

We can get here from a preemptable path if initialization of the klass failed: https://github.com/pchilano/jdk/blob/c7d6f5c5220a93653dea37488d238a76e2ad627d/src/hotspot/share/oops/instanceKlass.cpp#L1292
Also from here at linking step: https://github.com/pchilano/jdk/blob/c7d6f5c5220a93653dea37488d238a76e2ad627d/src/hotspot/share/oops/instanceKlass.cpp#L970.
The klass of the exception might need to be initialized, so without this `NoPreemptMark` the thread could be preempted while trying to initialize it. The problem is that this method is called here https://github.com/pchilano/jdk/blob/c7d6f5c5220a93653dea37488d238a76e2ad627d/src/hotspot/share/utilities/exceptions.cpp#L372, which will continue executing and possibly make an upcall to Java. We could potentially change these methods to identify a `PreemptedException` and use the `CHECK` macros to return, but I think it is simpler to disable preemption for these cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2475371881

From rriggs at openjdk.org  Wed Oct 29 20:44:01 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Oct 2025 20:44:01 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v6]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
 
 
 
Message-ID: 

On Wed, 29 Oct 2025 02:00:16 GMT, Xueming Shen  wrote:

>> Experimenting with Arrays.mismatch at the beginning of the array iteration as 
>> 
>> 
>>         int k = ArraysSupport.mismatch(value, other, lim);
>>         if (k < 0)
>>             return len - olen;
>>         for (; k < lim; k++) {
>>             ....
>>         }
>> 
>> 
>> The benchmark results suggest that it does help 'dramatically' when the compared strings share with the same prefix.  For example those "UpperLower" test cases (which shares the same upper cases text prefix. However it is also relatively expensive, with a 20%-ish overhead when the strings do not share the same string text but are case-insensitively equals.  I would suggest let's leave it out for now?
>> 
>> ### With Arrays.mismatch
>> 
>> 
>> Benchmark                                    Mode  Cnt   Score   Error  Units
>> StringCompareToFoldCase.asciiLower           avgt   15  15.044 ? 0.751  ns/op
>> StringCompareToFoldCase.asciiLowerEQ         avgt   15  10.033 ? 0.366  ns/op
>> StringCompareToFoldCase.asciiLowerEQFC       avgt   15  12.094 ? 0.288  ns/op
>> StringCompareToFoldCase.asciiLowerFC         avgt   15  12.513 ? 0.290  ns/op
>> StringCompareToFoldCase.asciiUpperLower      avgt   15  11.716 ? 0.471  ns/op
>> StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  11.120 ? 0.458  ns/op
>> StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   7.544 ? 0.103  ns/op
>> StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   7.384 ? 0.167  ns/op
>> StringCompareToFoldCase.asciiWithDFFC        avgt   15  54.949 ? 1.260  ns/op
>> StringCompareToFoldCase.greekLower           avgt   15  39.492 ? 0.124  ns/op
>> StringCompareToFoldCase.greekLowerEQ         avgt   15  39.266 ? 0.071  ns/op
>> StringCompareToFoldCase.greekLowerEQFC       avgt   15  28.049 ? 0.292  ns/op
>> StringCompareToFoldCase.greekLowerFC         avgt   15  28.272 ? 0.115  ns/op
>> StringCompareToFoldCase.greekUpperLower      avgt   15   7.103 ? 0.052  ns/op
>> StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.439 ? 0.079  ns/op
>> StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   2.716 ? 0.138  ns/op
>> StringCompareToFoldCase.greekUpperLowerFC    avgt   15   2.628 ? 0.051  ns/op
>> StringCompareToFoldCase.latin1UTF16          avgt   15  23.147 ? 0.094  ns/op
>> StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.626 ? 0.081  ns/op
>> StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  38.453 ? 0.697  ns/op
>> StringCompareToFoldCase.latin1UTF16FC        avgt   15  38.464 ? 0.441  ns/op
>> StringCompareToFoldCase....
>
> ### Long:  packing  1:M-count + 1-3 folding codepoints
> 
> https://cr.openjdk.org/~sherman/casefolding_long/
> 
> The performance is slightly better, but not as good as I would have expected. The access to codepoint from the long looks a little clumsy,  but the logic looks smooth. need more work. opinion?
> 
> 
> Benchmark                                    Mode  Cnt   Score   Error  Units
> StringCompareToFoldCase.asciiLower           avgt   15  15.487 ? 0.298  ns/op
> StringCompareToFoldCase.asciiLowerEQ         avgt   15  10.005 ? 0.368  ns/op
> StringCompareToFoldCase.asciiLowerEQFC       avgt   15  10.755 ? 0.160  ns/op
> StringCompareToFoldCase.asciiLowerFC         avgt   15  10.349 ? 0.155  ns/op
> StringCompareToFoldCase.asciiUpperLower      avgt   15  12.188 ? 0.278  ns/op
> StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  10.901 ? 0.551  ns/op
> StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   9.218 ? 0.165  ns/op
> StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   9.335 ? 0.404  ns/op
> StringCompareToFoldCase.asciiWithDFFC        avgt   15  37.010 ? 0.518  ns/op
> StringCompareToFoldCase.greekLower           avgt   15  39.572 ? 0.098  ns/op
> StringCompareToFoldCase.greekLowerEQ         avgt   15  39.317 ? 0.104  ns/op
> StringCompareToFoldCase.greekLowerEQFC       avgt   15  20.428 ? 0.243  ns/op
> StringCompareToFoldCase.greekLowerFC         avgt   15  19.623 ? 0.141  ns/op
> StringCompareToFoldCase.greekUpperLower      avgt   15   7.105 ? 0.048  ns/op
> StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.462 ? 0.092  ns/op
> StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   6.518 ? 0.128  ns/op
> StringCompareToFoldCase.greekUpperLowerFC    avgt   15   6.593 ? 0.240  ns/op
> StringCompareToFoldCase.latin1UTF16          avgt   15  23.130 ? 0.152  ns/op
> StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.606 ? 0.089  ns/op
> StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  29.574 ? 0.348  ns/op
> StringCompareToFoldCase.latin1UTF16FC        avgt   15  29.691 ? 0.445  ns/op
> StringCompareToFoldCase.supLower             avgt   15  55.027 ? 0.676  ns/op
> StringCompareToFoldCase.supLowerEQ           avgt   15  55.784 ? 0.368  ns/op
> StringCompareToFoldCase.supLowerEQFC         avgt   15  24.984 ? 0.157  ns/op
> StringCompareToFoldCase.supLowerFC           avgt   15  24.865 ? 0.139  ns/op
> StringCompareToFoldCase.supUpperLower        avgt   15  14.538 ? 0.144  ns/op
> StringCompareToFoldCase.supUpperLowerEQ      avgt   15  14.728 ? 0.206  ns/op
> StringCompareT...

> Experimenting with Arrays.mismatch at the beginning of the array iteration as
> ...
> The benchmark results suggest that it does help 'dramatically' when the compared strings share with the same prefix. For example those "UpperLower" test cases (which shares the same upper cases text prefix. However it is also relatively expensive, with a 20%-ish overhead when the strings do not share the same string text but are case-insensitively equals. I would suggest let's leave it out for now?

> ```
Ok to leave it out for now.  In similar contexts where System.arraycopy or Arrays.mismatch has some overhead I've suggested doing a simple check (like `size < 8`) to avoid the overhead when the strings/byte arrays are short.
Thanks for checking.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2475377160

From pchilanomate at openjdk.org  Wed Oct 29 20:46:02 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 29 Oct 2025 20:46:02 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v10]
In-Reply-To: <8lMiLlH9mRrGr7vGnywhk1tuTnaM8PanfOI20v5KYGU=.b428de44-95e5-459c-92f0-55a51b9ec910@github.com>
References: 
 
 <8lMiLlH9mRrGr7vGnywhk1tuTnaM8PanfOI20v5KYGU=.b428de44-95e5-459c-92f0-55a51b9ec910@github.com>
Message-ID: 

On Wed, 29 Oct 2025 06:02:57 GMT, David Holmes  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add const to references
>
> src/hotspot/share/runtime/javaCalls.cpp line 61:
> 
>> 59:   assert(!thread->owns_locks(), "must release all locks when leaving VM");
>> 60:   guarantee(thread->can_call_java(), "cannot make java calls from the native compiler");
>> 61:   assert(!thread->preempting(), "");
> 
> I'm not sure why this is checked here, and there is no error message to tell me. If we did get here with `preempting` set what would that mean?

This is a safety check since a thread marked as preempted should not be making upcalls to Java. It should be bailing out from methods and returning to the VM entry point. I found we could get here from the exception path (from your other comment below) when there was no `NoPreemptMark` there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2475389912

From pchilanomate at openjdk.org  Wed Oct 29 20:51:26 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 29 Oct 2025 20:51:26 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v9]
In-Reply-To: 
References: 
 
 
Message-ID: <_xAmFl3Kbf_weqAcF-cabI0-iIO4mHeaBcFdBwOSvSY=.36e530f9-5bd5-4073-a3ff-b9a2d969eef0@github.com>

On Tue, 28 Oct 2025 19:34:08 GMT, Patricio Chilano Mateo  wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment in anchor_mark_set_pd
>
> Thanks for the review Coleen!

> Just FYI: I am witnessing build issues after applying this on JDK HEAD. So we might want to merge with latest master. @pchilano
>
Thanks, merged with latest master.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3463940663

From acobbs at openjdk.org  Wed Oct 29 20:54:19 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 29 Oct 2025 20:54:19 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <81JqWQPRbafWl22IItWNL52faigZS1l31SXsD9Zq1EE=.b6d84001-edd9-443a-8ca7-555a81ae6af0@github.com>
References: 
 <81JqWQPRbafWl22IItWNL52faigZS1l31SXsD9Zq1EE=.b6d84001-edd9-443a-8ca7-555a81ae6af0@github.com>
Message-ID: <4Vtxklt1aGLbaZHO8bzuV1ZgR5YCmzvvQB1kdxxZvHw=.1ce1039c-d4df-4bd6-be04-c3c359b3de09@github.com>

On Tue, 16 Sep 2025 13:32:15 GMT, Erik Joelsson  wrote:

>> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
>> 
>> Summary of code changes:
>> 
>> * Add new warning and associated lint category `"suppression"`
>> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
>> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
>> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
>> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
>> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
>> 
>> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category
>
>> /label remove kulla
> 
> I have removed kulla-dev from the bot configuration so the stuck label is now benign.

@erikj79, @magicus - Would you mind updating your review since the recent changes that addressed merge conflicts?

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3463955731

From darcy at openjdk.org  Wed Oct 29 20:59:45 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 Oct 2025 20:59:45 GMT
Subject: RFR: 8366017: Extend the set of inputs handled by fast paths in
 FloatingDecimal [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 14:01:39 GMT, Raffaello Giulietti  wrote:

>> Yet another step in modernizing `FloatingDecimal`s floating-point parsing.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make arrays stable and remove synchronisation.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26990#pullrequestreview-3396208323

From rriggs at openjdk.org  Wed Oct 29 21:09:33 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Oct 2025 21:09:33 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v6]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
 
 
 
 
Message-ID: <8vnnaDLbpvjdSdANjw2p_i_xvu7X8mqkNexoDPSyzE4=.c274163d-1b2e-4b9a-a6c0-e22e5aacd3cd@github.com>

On Wed, 29 Oct 2025 20:41:06 GMT, Roger Riggs  wrote:

>> ### Long:  packing  1:M-count + 1-3 folding codepoints
>> 
>> https://cr.openjdk.org/~sherman/casefolding_long/
>> 
>> The performance is slightly better, but not as good as I would have expected. The access to codepoint from the long looks a little clumsy,  but the logic looks smooth. need more work. opinion?
>> 
>> 
>> Benchmark                                    Mode  Cnt   Score   Error  Units
>> StringCompareToFoldCase.asciiLower           avgt   15  15.487 ? 0.298  ns/op
>> StringCompareToFoldCase.asciiLowerEQ         avgt   15  10.005 ? 0.368  ns/op
>> StringCompareToFoldCase.asciiLowerEQFC       avgt   15  10.755 ? 0.160  ns/op
>> StringCompareToFoldCase.asciiLowerFC         avgt   15  10.349 ? 0.155  ns/op
>> StringCompareToFoldCase.asciiUpperLower      avgt   15  12.188 ? 0.278  ns/op
>> StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  10.901 ? 0.551  ns/op
>> StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   9.218 ? 0.165  ns/op
>> StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   9.335 ? 0.404  ns/op
>> StringCompareToFoldCase.asciiWithDFFC        avgt   15  37.010 ? 0.518  ns/op
>> StringCompareToFoldCase.greekLower           avgt   15  39.572 ? 0.098  ns/op
>> StringCompareToFoldCase.greekLowerEQ         avgt   15  39.317 ? 0.104  ns/op
>> StringCompareToFoldCase.greekLowerEQFC       avgt   15  20.428 ? 0.243  ns/op
>> StringCompareToFoldCase.greekLowerFC         avgt   15  19.623 ? 0.141  ns/op
>> StringCompareToFoldCase.greekUpperLower      avgt   15   7.105 ? 0.048  ns/op
>> StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.462 ? 0.092  ns/op
>> StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   6.518 ? 0.128  ns/op
>> StringCompareToFoldCase.greekUpperLowerFC    avgt   15   6.593 ? 0.240  ns/op
>> StringCompareToFoldCase.latin1UTF16          avgt   15  23.130 ? 0.152  ns/op
>> StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.606 ? 0.089  ns/op
>> StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  29.574 ? 0.348  ns/op
>> StringCompareToFoldCase.latin1UTF16FC        avgt   15  29.691 ? 0.445  ns/op
>> StringCompareToFoldCase.supLower             avgt   15  55.027 ? 0.676  ns/op
>> StringCompareToFoldCase.supLowerEQ           avgt   15  55.784 ? 0.368  ns/op
>> StringCompareToFoldCase.supLowerEQFC         avgt   15  24.984 ? 0.157  ns/op
>> StringCompareToFoldCase.supLowerFC           avgt   15  24.865 ? 0.139  ns/op
>> StringCompareToFoldCase.supUpperLower        avgt   15  14.538 ? 0.144  ns/op
>> StringCompareToFoldCas...
>
>> Experimenting with Arrays.mismatch at the beginning of the array iteration as
>> ...
>> The benchmark results suggest that it does help 'dramatically' when the compared strings share with the same prefix. For example those "UpperLower" test cases (which shares the same upper cases text prefix. However it is also relatively expensive, with a 20%-ish overhead when the strings do not share the same string text but are case-insensitively equals. I would suggest let's leave it out for now?
> 
>> ```
> Ok to leave it out for now.  In similar contexts where System.arraycopy or Arrays.mismatch has some overhead I've suggested doing a simple check (like `size < 8`) to avoid the overhead when the strings/byte arrays are short.
> Thanks for checking.

> The performance is slightly better, but not as good as I would have expected. The access to codepoint from the long looks a little clumsy, but the logic looks smooth. need more work. opinion?
It does look cleaner without the array indexing in the loops.
Can the counting of characters (fcnt1,fcnt2) be eliminated by encoding 3 20-bit characters into the long and then checking `f1 != 0` to indicate there are more characters.  Its a bit of an odd mix of 16-bit characters vs a single 20-bit char. Are there any 20-bit chars from or to folded replacements in the folding mappings?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2475481372

From erikj at openjdk.org  Wed Oct 29 21:10:33 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 29 Oct 2025 21:10:33 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v4]
In-Reply-To: 
References: 
 
Message-ID: <3TYbuRwZvS0UJxfI1fFZN4HXZwbsX6fHFbkgndH6cNU=.adcd31f8-12c8-4087-be78-b679f6f9e275@github.com>

On Wed, 22 Oct 2025 15:21:43 GMT, Archie Cobbs  wrote:

>> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
>> 
>> Summary of code changes:
>> 
>> * Add new warning and associated lint category `"suppression"`
>> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
>> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
>> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
>> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
>> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
>> 
>> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 133 commits:
> 
>  - Merge branch 'master' into JDK-8344159 to fix conflict.
>  - Merge branch 'master' into JDK-8344159 to fix conflict.
>  - Merge branch 'master' into JDK-8344159 to fix conflicts.
>  - Add clarifying comment.
>  - Merge branch 'master' into JDK-8344159
>  - Change inner class name to avoid shadowing superclass name.
>  - Add a couple of code clarification comments.
>  - Refactor test to avoid requiring changes to TestRunner.
>  - Remove unnecessary -Xlint:-suppression flags.
>  - Minor cleanups.
>  - ... and 123 more: https://git.openjdk.org/jdk/compare/a1be2979...f2b75547

Build changes still look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25167#pullrequestreview-3396264627

From jvernee at openjdk.org  Wed Oct 29 22:49:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 29 Oct 2025 22:49:01 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v2]
In-Reply-To: 
References: 
 
 <_gORgVPPc2dmXVkRgjww36Z_6B80xoFP8MSDab7scZQ=.2ea4b41e-63bc-46d8-9608-a59602a66876@github.com>
 
 
Message-ID: <4AH-S5IP_abXOC121l0tB0oZWkXp8l4SmsN2w1sGlu0=.ad194b1f-ce60-4e16-b905-8ec8ce5dfb77@github.com>

On Wed, 29 Oct 2025 18:24:56 GMT, Liam Miller-Cushon  wrote:

> > A user can easily convert between one or the other length representation by multiplying/dividing by the right scalar
> 
> That is true of e.g. UTF-16 but not of UTF-8, since the encoding is variable width and doing the conversion from bytes to characters is more expensive there.

Sorry, I don't mean 'character' but 'unit', or whatever it's called (I don't think 'code point' is the right word either). For instance, when reading a UTF-8 string, the unit would be one byte, for UTF-16 it would be two, for UTF-32 four. So a user would just need to divide by the unit size, at least that's the idea.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2475835009

From skuksenko at openjdk.org  Wed Oct 29 22:58:28 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Wed, 29 Oct 2025 22:58:28 GMT
Subject: RFR: 8370150: Add StrictMath microbenchmarks to cover FDLIBM
 algorithms [v3]
In-Reply-To: <-zFdpTE0II7muIj0FtbT62bOtCWDDxJgQiOt65ehpZM=.37ddba8f-bb12-471c-8134-1e72c25f2fc2@github.com>
References: <-zFdpTE0II7muIj0FtbT62bOtCWDDxJgQiOt65ehpZM=.37ddba8f-bb12-471c-8134-1e72c25f2fc2@github.com>
Message-ID: 

> Add StrictMath microbenchmarks to cover FDLIBM algorithms
> 
> The methods that require fdlibm semantics are sin, cos, tan, asin, acos, atan, exp, log, log10, cbrt, atan2, pow, sinh, cosh, tanh, hypot, expm1, and log1p.

Sergey Kuksenko has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8370150' of github.com:kuksenko/jdk into JDK-8370150
 - update after review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27881/files
  - new: https://git.openjdk.org/jdk/pull/27881/files/3ad3f541..e577c78c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27881&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27881&range=01-02

  Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27881/head:pull/27881

PR: https://git.openjdk.org/jdk/pull/27881

From skuksenko at openjdk.org  Wed Oct 29 22:58:31 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Wed, 29 Oct 2025 22:58:31 GMT
Subject: RFR: 8370150: Add StrictMath microbenchmarks to cover FDLIBM
 algorithms [v2]
In-Reply-To: 
References: <-zFdpTE0II7muIj0FtbT62bOtCWDDxJgQiOt65ehpZM=.37ddba8f-bb12-471c-8134-1e72c25f2fc2@github.com>
 <5CjWG5Fl98CgY2kHSsl3Zt_Rq3kMX5K_5tYp99F7x8s=.f3039e96-b4ad-4943-a475-139e0060a514@github.com>
 
Message-ID: 

On Mon, 20 Oct 2025 14:46:42 GMT, Raffaello Giulietti  wrote:

>> Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update StrictMathExtraBench.java
>>   
>>   Fix copyright format
>
> test/micro/org/openjdk/bench/java/lang/StrictMathExtraBench.java line 51:
> 
>> 49:             this.min = min;
>> 50:             this.max = max;
>> 51:             this.signed = signed;
> 
> This field is never read.
> I guess you want to change the `setup()` method to use this field rather than rely on `nextBoolean()`?

resolved

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27881#discussion_r2475862303

From fandreuzzi at openjdk.org  Wed Oct 29 23:24:01 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 29 Oct 2025 23:24:01 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication [v2]
In-Reply-To: 
References: 
Message-ID: 

> In this PR I introduce two new JFR events:
> - `jdk.StringDeduplicationStatistics`
> - `jdk.StringDeduplicationTimes`
> 
> The events are emitted every time a deduplication cycle happens, and they contain information about that cycle only.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  one event

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28015/files
  - new: https://git.openjdk.org/jdk/pull/28015/files/1cb7d996..bff0fd30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=00-01

  Stats: 61 lines in 8 files changed: 8 ins; 52 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28015.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28015/head:pull/28015

PR: https://git.openjdk.org/jdk/pull/28015

From fandreuzzi at openjdk.org  Wed Oct 29 23:31:25 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 29 Oct 2025 23:31:25 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication [v3]
In-Reply-To: 
References: 
Message-ID: 

> In this PR I introduce two new JFR events:
> - `jdk.StringDeduplicationStatistics`
> - `jdk.StringDeduplicationTimes`
> 
> The events are emitted every time a deduplication cycle happens, and they contain information about that cycle only.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:

 - disable
 - revert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28015/files
  - new: https://git.openjdk.org/jdk/pull/28015/files/bff0fd30..c3c9a8db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28015.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28015/head:pull/28015

PR: https://git.openjdk.org/jdk/pull/28015

From fandreuzzi at openjdk.org  Wed Oct 29 23:37:02 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 29 Oct 2025 23:37:02 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 29 Oct 2025 12:57:43 GMT, Erik Gahlin  wrote:

> I think one event is sufficient. It?s easier to configure, easier to program against and will have less overhead.

Sounds good, I made the change in the latest commits.

> We want events to be enabled by default, and they must work even in pathological cases, such as an application calling String::intern() in a loop. If you believe we can get 10 000 events per minute in such cases, it might be better to fix JDK-8315238 first, or disable the event and enable it only in profile.jfc, then re-enable it in default.jfc once JDK-8315238 has been fixed.

Sure, I disabled the new event in `default.jfc`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3465092462

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 duke at openjdk.org  Thu Oct 30 02:00:07 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Thu, 30 Oct 2025 02:00:07 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v24]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Oct 2025 18:42:32 GMT, Roger Riggs  wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add \@implNote to recommend overriding close and calling `super.close()`.

src/java.base/share/classes/java/lang/snippet-files/ProcessExamples.java line 31:

> 29: public class ProcessExamples {
> 30:     // @start region=example
> 31:     void example() {

Should there be another version of this that is involved with interruption set at top of method? That example would forever freeze which shows there is a problem with the example.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2476178801

From sherman at openjdk.org  Thu Oct 30 02:59:45 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Thu, 30 Oct 2025 02:59:45 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7]
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
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
> 
> See CSR https://bugs.openjd...

Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:

  update to use value long for folding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27628/files
  - new: https://git.openjdk.org/jdk/pull/27628/files/74b4d83e..c21de111

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=05-06

  Stats: 166 lines in 5 files changed: 56 ins; 28 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/27628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27628/head:pull/27628

PR: https://git.openjdk.org/jdk/pull/27628

From sherman at openjdk.org  Thu Oct 30 03:03:08 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Thu, 30 Oct 2025 03:03:08 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7]
In-Reply-To: <8vnnaDLbpvjdSdANjw2p_i_xvu7X8mqkNexoDPSyzE4=.c274163d-1b2e-4b9a-a6c0-e22e5aacd3cd@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
 
 
 
 
 <8vnnaDLbpvjdSdANjw2p_i_xvu7X8mqkNexoDPSyzE4=.c274163d-1b2e-4b9a-a6c0-e22e5aacd3cd@github.com>
Message-ID: 

On Wed, 29 Oct 2025 21:07:03 GMT, Roger Riggs  wrote:

>>> Experimenting with Arrays.mismatch at the beginning of the array iteration as
>>> ...
>>> The benchmark results suggest that it does help 'dramatically' when the compared strings share with the same prefix. For example those "UpperLower" test cases (which shares the same upper cases text prefix. However it is also relatively expensive, with a 20%-ish overhead when the strings do not share the same string text but are case-insensitively equals. I would suggest let's leave it out for now?
>> 
>>> ```
>> Ok to leave it out for now.  In similar contexts where System.arraycopy or Arrays.mismatch has some overhead I've suggested doing a simple check (like `size < 8`) to avoid the overhead when the strings/byte arrays are short.
>> Thanks for checking.
>
>> The performance is slightly better, but not as good as I would have expected. The access to codepoint from the long looks a little clumsy, but the logic looks smooth. need more work. opinion?
> It does look cleaner without the array indexing in the loops.
> Can the counting of characters (fcnt1,fcnt2) be eliminated by encoding 3 20-bit characters into the long and then checking `f1 != 0` to indicate there are more characters.  Its a bit of an odd mix of 16-bit characters vs a single 20-bit char. Are there any 20-bit chars from or to folded replacements in the folding mappings?

Good idea.   After removing the fcnt the implementation looks much cleaner and more straightforward. The1:m folding implementation is also faster.  Maybe this is good enough to. go :-) 

The latest numbers


Benchmark                                    Mode  Cnt   Score   Error  Units
StringCompareToFoldCase.asciiLower           avgt   15  15.874 ? 1.276  ns/op
StringCompareToFoldCase.asciiLowerEQ         avgt   15   9.915 ? 0.242  ns/op
StringCompareToFoldCase.asciiLowerEQFC       avgt   15  10.751 ? 0.219  ns/op
StringCompareToFoldCase.asciiLowerFC         avgt   15  10.277 ? 0.126  ns/op
StringCompareToFoldCase.asciiUpperLower      avgt   15  12.121 ? 0.699  ns/op
StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  10.836 ? 0.746  ns/op
StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   9.091 ? 0.273  ns/op
StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   9.207 ? 0.255  ns/op
StringCompareToFoldCase.asciiWithDFFC        avgt   15  38.322 ? 0.975  ns/op
StringCompareToFoldCase.greekLower           avgt   15  39.746 ? 0.127  ns/op
StringCompareToFoldCase.greekLowerEQ         avgt   15  39.303 ? 0.063  ns/op
StringCompareToFoldCase.greekLowerEQFC       avgt   15  20.470 ? 0.329  ns/op
StringCompareToFoldCase.greekLowerFC         avgt   15  19.734 ? 0.295  ns/op
StringCompareToFoldCase.greekUpperLower      avgt   15   7.084 ? 0.085  ns/op
StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.472 ? 0.115  ns/op
StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   6.608 ? 0.248  ns/op
StringCompareToFoldCase.greekUpperLowerFC    avgt   15   6.573 ? 0.189  ns/op
StringCompareToFoldCase.latin1UTF16          avgt   15  24.407 ? 2.157  ns/op
StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.632 ? 0.131  ns/op
StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  29.564 ? 0.655  ns/op
StringCompareToFoldCase.latin1UTF16FC        avgt   15  29.273 ? 0.324  ns/op
StringCompareToFoldCase.supLower             avgt   15  54.145 ? 0.075  ns/op
StringCompareToFoldCase.supLowerEQ           avgt   15  55.545 ? 0.042  ns/op
StringCompareToFoldCase.supLowerEQFC         avgt   15  24.788 ? 0.180  ns/op
StringCompareToFoldCase.supLowerFC           avgt   15  24.515 ? 0.025  ns/op
StringCompareToFoldCase.supUpperLower        avgt   15  14.437 ? 0.127  ns/op
StringCompareToFoldCase.supUpperLowerEQ      avgt   15  15.253 ? 0.728  ns/op
StringCompareToFoldCase.supUpperLowerEQFC    avgt   15   9.820 ? 0.104  ns/op
StringCompareToFoldCase.supUpperLowerFC      avgt   15   9.776 ? 0.127  ns/op
Finished running test 'micro:org.openjdk.bench.java.lang.StringCompareToFoldCase'

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2476267966

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 dholmes at openjdk.org  Thu Oct 30 03:50:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Oct 2025 03:50:02 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 17:58:40 GMT, Jorn Vernee  wrote:

>> See the JBS issue for a problem description.
>> 
>> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
>> 
>> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
>> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
>> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
>> 3. Any other Java code that runs as part of the linking process.
>> 
>> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
>> 
>> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove requires vm.debug

Functional changes seem fine to me - this seems a reasonable approach to take.

Tests seem okay (one nit) but I'm not that familiar with testing in this area.

Thanks.

PS. I will be likely be on vacation before this finalizes.

test/jdk/java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java line 65:

> 63:             Process process = ProcessTools.startProcess("fork", pb, null, null, 1L, TimeUnit.MINUTES);
> 64:             OutputAnalyzer output = new OutputAnalyzer(process);
> 65:             assertEquals(0, output.getExitValue());

Suggestion:

            output.shouldHaveExitValue(0);

That way we get the diagnostic summary printed on failure.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27919#pullrequestreview-3397321596
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2476317588

From egahlin at openjdk.org  Thu Oct 30 06:06:03 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 30 Oct 2025 06:06:03 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Wed, 29 Oct 2025 23:34:40 GMT, Francesco Andreuzzi  wrote:

> Sure, I disabled the new event in `default.jfc`.

Best would be to have it enabled, but if you believe we could get a very high number of events, it must be disabled or emitted at a lower frequency.

Typically, statistical events are emitted as periodic events, so users can set the period, e.g. 10 s, but that would require synchronization, which could also create issues.

> `false`

The control parameter must be in sync with the element value.
**gc-enabled-normal** is the default mode, which means it will be true. 

**gc-enabled-high**, **gc-enabled-detailed** and **gc-enabled-all** are false by default. It would be good if you could provide some ballpark figures on the number of events in a worst-case scenario, so we can determine what GC level is appropriate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3466243974

From dholmes at openjdk.org  Thu Oct 30 06:21:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Oct 2025 06:21:08 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v10]
In-Reply-To: 
References: 
 
 <8lMiLlH9mRrGr7vGnywhk1tuTnaM8PanfOI20v5KYGU=.b428de44-95e5-459c-92f0-55a51b9ec910@github.com>
 
Message-ID: 

On Wed, 29 Oct 2025 20:43:24 GMT, Patricio Chilano Mateo  wrote:

>> src/hotspot/share/runtime/javaCalls.cpp line 61:
>> 
>>> 59:   assert(!thread->owns_locks(), "must release all locks when leaving VM");
>>> 60:   guarantee(thread->can_call_java(), "cannot make java calls from the native compiler");
>>> 61:   assert(!thread->preempting(), "");
>> 
>> I'm not sure why this is checked here, and there is no error message to tell me. If we did get here with `preempting` set what would that mean?
>
> This is a safety check since a thread marked as preempted should not be making upcalls to Java. It should be bailing out from methods and returning to the VM entry point. I found we could get here from the exception path (from your other comment below) when there was no `NoPreemptMark` there.

Okay then how about `"Unexpected Java upcall whilst processing preemption"` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2476538796

From dholmes at openjdk.org  Thu Oct 30 06:26:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Oct 2025 06:26:06 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: 
References: 
 
 
 
 <8Oq4qcIh0vAMYwzAXVPZJwbx7Zx7b6nMMCN9gqFFNkE=.ea219d84-de39-4d64-8117-d919e41c4eeb@github.com>
 
Message-ID: 

On Wed, 29 Oct 2025 20:34:24 GMT, Patricio Chilano Mateo  wrote:

>> I don't think we would have to. There are a handful of methods that now declare TRAPS but the only exception they should ever encounter is the PreemptException. It would be easier to understand the code if this was evident in their use of TRAPS. Also note it is purely documentation - the definition of `PREEMPTABLE_TRAPS` is exactly the same as `TRAPS`
>
> If we want to avoid confusion with other users of `ObjectLocker` maybe we can leave it as it is and subclass it with a preemptable version? https://github.com/pchilano/jdk/compare/JDK-8369238...pchilano:jdk:PreemptableObjectLocker (this version could also use `PREEMPTABLE_TRAPS`)

Never mind - I thought there were a few functions that had TRAPS added just for the preempt case but now I don't see them. Thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2476548285

From dholmes at openjdk.org  Thu Oct 30 06:30:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Oct 2025 06:30:09 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 20:25:11 GMT, Patricio Chilano Mateo  wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - More fixes from David's comments
>  - Merge branch 'master' into JDK-8369238
>  - add const to references
>  - Improve comment in anchor_mark_set_pd
>  - More comments from Coleen
>  - rename _monitor to _init_lock
>  - Extra comments from Coleen
>  - define methods in resolve_from_cache with TRAPS and use CHECK_AND_CLEAR_PREEMPTED
>  - PPC support
>  - Remove extra debugging param
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/28f2591b...c7d6f5c5

Thanks for explanations and updates.

Nominal approval but obviously you need additional approvers for this one.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3397609556
Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3397614596

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 duke at openjdk.org  Thu Oct 30 07:33:20 2025
From: duke at openjdk.org (duke)
Date: Thu, 30 Oct 2025 07:33:20 GMT
Subject: Withdrawn: 8366439: test/jdk/java/util/zip/ZipFile/ZipSourceCache.java
 fails with AssertionFailedError: expected: <6> but was: <5>
In-Reply-To: 
References: 
Message-ID: 

On Fri, 29 Aug 2025 14:33:03 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this test-only change which addresses a failure in `test/jdk/java/util/zip/ZipFile/ZipSourceCache.java` test?
> 
> As noted in the description of https://bugs.openjdk.org/browse/JDK-8366439, this test fails if the underlying file system's timestamp granularity doesn't allow for the last modified timestamp to increase when the test's ZIP file is updated with newer content.
> 
> The change in this PR updates the test to first check that the last modified timestamp has increased on the ZIP file that was updated, before running the rest of the test assertions. The test continues to pass in our CI with this change.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/27005

From rrich at openjdk.org  Thu Oct 30 07:37:13 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 30 Oct 2025 07:37:13 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v10]
In-Reply-To: 
References: 
 
 <8lMiLlH9mRrGr7vGnywhk1tuTnaM8PanfOI20v5KYGU=.b428de44-95e5-459c-92f0-55a51b9ec910@github.com>
 
Message-ID: 

On Wed, 29 Oct 2025 20:40:14 GMT, Patricio Chilano Mateo  wrote:

>> src/hotspot/share/utilities/exceptions.cpp line 350:
>> 
>>> 348:     // the exception is propagated we might make an upcall to
>>> 349:     // Java to initialize the object with the cause of exception.
>>> 350:     NoPreemptMark npm(thread);
>> 
>> Could you explain the control flow in more detail here please. I'm unclear both how we get here and exactly what the affect of the NoPreemptMark is.
>
> We can get here from a preemptable path if initialization of the klass failed: https://github.com/pchilano/jdk/blob/c7d6f5c5220a93653dea37488d238a76e2ad627d/src/hotspot/share/oops/instanceKlass.cpp#L1292
> Also from here at linking step: https://github.com/pchilano/jdk/blob/c7d6f5c5220a93653dea37488d238a76e2ad627d/src/hotspot/share/oops/instanceKlass.cpp#L970.
> The klass of the exception might need to be initialized, so without this `NoPreemptMark` the thread could be preempted while trying to initialize it. The problem is that this method is called here https://github.com/pchilano/jdk/blob/c7d6f5c5220a93653dea37488d238a76e2ad627d/src/hotspot/share/utilities/exceptions.cpp#L372, which will continue executing and possibly make an upcall to Java. We could potentially change these methods to identify a `PreemptedException` and use the `CHECK` macros to return, but I think it is simpler to disable preemption for these cases.

I'm a correct that at line 348 "the *exception* is propagated we might make an upcall to" you are referring to an `PreemptedException`? You could change the comment to distinguish this one with the exception being created better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2476701445

From duke at openjdk.org  Thu Oct 30 09:10:07 2025
From: duke at openjdk.org (duke)
Date: Thu, 30 Oct 2025 09:10:07 GMT
Subject: Withdrawn: 8361207: Build native Windows ARM64 MSI packages
In-Reply-To: 
References: 
Message-ID: 

On Wed, 2 Jul 2025 11:15:00 GMT, Armin Schrenk  wrote:

> Add support for native ARM64 Windows MSI pacakges to jpackage.
> 
> For some reasoning and more info, check out the ticket on JBS: https://bugs.openjdk.org/browse/JDK-8361207.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/26093

From abimpoudis at openjdk.org  Thu Oct 30 10:08:55 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 30 Oct 2025 10:08:55 GMT
Subject: RFR: 8359145: Implement JEP 530: Primitive Types in Patterns,
 instanceof, and switch (Fourth Preview) [v3]
In-Reply-To: 
References: 
Message-ID: 

> PR for Primitive Types in Patterns, instanceof, and switch (Fourth Preview).
> 
> spec: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8359145
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
 - Address review
 - 8359145: JEP 530: Implement Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27637/files
  - new: https://git.openjdk.org/jdk/pull/27637/files/f1448e1b..8a17c55a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27637&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27637&range=01-02

  Stats: 36486 lines in 973 files changed: 21635 ins; 9436 del; 5415 mod
  Patch: https://git.openjdk.org/jdk/pull/27637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27637/head:pull/27637

PR: https://git.openjdk.org/jdk/pull/27637

From kfarrell at openjdk.org  Thu Oct 30 10:30:05 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 30 Oct 2025 10:30:05 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v23]
In-Reply-To: 
References: 
Message-ID: 

> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
> 
> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
> 
> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
> 
> 
> - random-byte-only - 99.8%
> - higher-precision - 3.5%
> - counter-based - 0%
> 
> 
> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
> 
> - random-byte-only   143.487 ? 10.932  ns/op
> - higher-precision      149.651 ?  8.438 ns/op
> - counter-based         245.036 ?  2.943  ns/op
> 
> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  update api note

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25303/files
  - new: https://git.openjdk.org/jdk/pull/25303/files/1be228fc..27613619

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=21-22

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303

PR: https://git.openjdk.org/jdk/pull/25303

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 prappo at openjdk.org  Thu Oct 30 12:05:46 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 30 Oct 2025 12:05:46 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v24]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Oct 2025 18:42:32 GMT, Roger Riggs  wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add \@implNote to recommend overriding close and calling `super.close()`.

Looks good.

src/java.base/share/classes/java/lang/Process.java line 121:

> 119:  * or readers, or they have been closed. The Process {@linkplain Process#close close} method closes
> 120:  * all the streams and terminates the process to release the resources. Using try-with-resources to
> 121:  * {@linkplain ProcessBuilder#start()} the process can ensure the process

This link looks weird in the generated documentation:

Using try-with-resources to ProcessBuilder.start() the process can ensure the process is terminated when the try-with-resources block exits.

I suggest fixing the text to just "start" and optionally removing the link as that method is already linked to from this same doc comment:
  

Suggestion:

 * {@linkplain ProcessBuilder#start() start} the process can ensure the process


Related: while it's not part of this PR, consider removing `{@code}` around closed on L130. There's no such method as "closed", and I think readers understand what plain "closed" refers to. Alternatively, you could use this

    {@linkplain #close() closed}

src/java.base/share/classes/java/lang/Process.java line 180:

> 178: 
> 179:     /**
> 180:      * Close all reader and writer streams and wait for the process to terminate.

Suggestion:

     * Closes all reader and writer streams and waits for the process to terminate.

src/java.base/share/classes/java/lang/Process.java line 194:

> 192:      * Closing an already closed stream usually has no effect but is specific to the stream.
> 193:      * If an {@code IOException} occurs when closing a stream it is thrown
> 194:      * after the process has terminated. {@linkplain Exception}s

Suggestion:

     * after the process has terminated. Exceptions

src/java.base/share/classes/java/lang/Process.java line 218:

> 216:      * The {@code errorReader} and {@code errorStream} from the process are closed.
> 217:      * This method {@linkplain #waitFor() waits for the process} to terminate.
> 218:      * If {@linkplain #waitFor() waitFor()} is {@linkplain Thread#interrupt() interrupted}

Suggestion:

     * If {@link #waitFor() waitFor()} is {@linkplain Thread#interrupt() interrupted}


or better still


Suggestion:

     * If wait is {@linkplain Thread#interrupt() interrupted}

-------------

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26649#pullrequestreview-3399134720
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2477745802
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2477762020
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2477816911
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2477789248

From prappo at openjdk.org  Thu Oct 30 12:12:35 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 30 Oct 2025 12:12:35 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v24]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Oct 2025 18:42:32 GMT, Roger Riggs  wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add \@implNote to recommend overriding close and calling `super.close()`.

src/java.base/share/classes/java/lang/Process.java line 188:

> 186:      * are lost, they are discarded or ignored.
> 187:      * 
      
> 188:      * If the process exit value of the process is of interest, then the caller must

Suggestion:

     * If the process exit value is of interest, then the caller must

src/java.base/share/classes/java/lang/Process.java line 203:

> 201:      * this method continues to wait for the process to terminate.
> 202:      * The interrupted status is re-asserted before this method returns and
> 203:      * any {@code IOExceptions} are thrown.

Suggestion:

     * The interrupted status is re-asserted before this method returns or
     * an {@code IOException} is thrown.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2477861213
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2477867129

From abimpoudis at openjdk.org  Thu Oct 30 12:50:14 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 30 Oct 2025 12:50:14 GMT
Subject: RFR: 8359145: Implement JEP 530: Primitive Types in Patterns,
 instanceof, and switch (Fourth Preview) [v4]
In-Reply-To: 
References: 
Message-ID: 

> PR for Primitive Types in Patterns, instanceof, and switch (Fourth Preview).
> 
> spec: https://cr.openjdk.org/~abimpoudis/instanceof/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix regression in Check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27637/files
  - new: https://git.openjdk.org/jdk/pull/27637/files/8a17c55a..abe53647

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27637&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27637&range=02-03

  Stats: 14 lines in 1 file changed: 4 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27637/head:pull/27637

PR: https://git.openjdk.org/jdk/pull/27637

From rriggs at openjdk.org  Thu Oct 30 14:18:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Oct 2025 14:18:40 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v21]
In-Reply-To: 
References: 
 <9R7seCgprkFm6IGTN-FqFCXHCHHru3phbCjMB0MG8Dw=.68cee43e-110d-4aab-8855-8dcbec39511b@github.com>
 
Message-ID: 

On Sun, 26 Oct 2025 14:46:54 GMT, Alan Bateman  wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update name
>
> src/java.base/share/classes/java/util/UUID.java line 40:
> 
>> 38:  * A UUID represents a 128-bit value.
>> 39:  *
>> 40:  * 
       There exist different variants of these global identifiers.  The methods
> 
> As follow-up (not this PR), we might consider re-visiting the switch from UUID in the first sentence/paragraph to "global identifiers" in the second paragraph. We seem to missing an "also known" to allow this switch.

Created https://bugs.openjdk.org/browse/JDK-8370910

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2478286645

From rriggs at openjdk.org  Thu Oct 30 14:35:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Oct 2025 14:35:54 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v23]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 10:30:05 GMT, Kieran Farrell  wrote:

>> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
>> 
>> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>> 
>> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
>> 
>> 
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>> 
>> 
>> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
>> 
>> - random-byte-only   143.487 ? 10.932  ns/op
>> - higher-precision      149.651 ?  8.438 ns/op
>> - counter-based         245.036 ?  2.943  ns/op
>> 
>> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update api note

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25303#pullrequestreview-3399964678

From dfuchs at openjdk.org  Thu Oct 30 15:11:10 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 30 Oct 2025 15:11:10 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v24]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Oct 2025 18:42:32 GMT, Roger Riggs  wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add \@implNote to recommend overriding close and calling `super.close()`.

Minor nit formatting suggestions. Otherwise the specification and implementation of the `close()` method look reasonable to me.

src/java.base/share/classes/java/lang/Process.java line 199:

> 197:      * 
      
> 198:      * After the streams are closed this method {@linkplain #waitFor() waits for} the
> 199:      * process to terminate. If interrupted while {@linkplain #waitFor waiting} for termination

Suggestion:

     * process to terminate. If interrupted while {@linkplain #waitFor() waiting} for termination

src/java.base/share/classes/java/lang/Process.java line 218:

> 216:      * The {@code errorReader} and {@code errorStream} from the process are closed.
> 217:      * This method {@linkplain #waitFor() waits for the process} to terminate.
> 218:      * If {@linkplain #waitFor() waitFor()} is {@linkplain Thread#interrupt() interrupted}

Suggestion:

     * If {@link #waitFor() waitFor()} is {@linkplain Thread#interrupt() interrupted}

-------------

PR Review: https://git.openjdk.org/jdk/pull/26649#pullrequestreview-3400131750
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2478469017
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2478477773

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 pchilanomate at openjdk.org  Thu Oct 30 15:54:18 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 30 Oct 2025 15:54:18 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: 
References: 
Message-ID: 

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Improve comment and assert msg

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27802/files
  - new: https://git.openjdk.org/jdk/pull/27802/files/c7d6f5c5..ffcd92a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=10-11

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

PR: https://git.openjdk.org/jdk/pull/27802

From pchilanomate at openjdk.org  Thu Oct 30 15:54:21 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 30 Oct 2025 15:54:21 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 20:25:11 GMT, Patricio Chilano Mateo  wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - More fixes from David's comments
>  - Merge branch 'master' into JDK-8369238
>  - add const to references
>  - Improve comment in anchor_mark_set_pd
>  - More comments from Coleen
>  - rename _monitor to _init_lock
>  - Extra comments from Coleen
>  - define methods in resolve_from_cache with TRAPS and use CHECK_AND_CLEAR_PREEMPTED
>  - PPC support
>  - Remove extra debugging param
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/28f2591b...c7d6f5c5

Thanks for the review David!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3468707728

From pchilanomate at openjdk.org  Thu Oct 30 15:54:22 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 30 Oct 2025 15:54:22 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v10]
In-Reply-To: 
References: 
 
 <8lMiLlH9mRrGr7vGnywhk1tuTnaM8PanfOI20v5KYGU=.b428de44-95e5-459c-92f0-55a51b9ec910@github.com>
 
 
Message-ID: 

On Thu, 30 Oct 2025 06:18:29 GMT, David Holmes  wrote:

>> This is a safety check since a thread marked as preempted should not be making upcalls to Java. It should be bailing out from methods and returning to the VM entry point. I found we could get here from the exception path (from your other comment below) when there was no `NoPreemptMark` there.
>
> Okay then how about `"Unexpected Java upcall whilst processing preemption"` ?

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2478633316

From pchilanomate at openjdk.org  Thu Oct 30 15:54:22 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 30 Oct 2025 15:54:22 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v10]
In-Reply-To: 
References: 
 
 <8lMiLlH9mRrGr7vGnywhk1tuTnaM8PanfOI20v5KYGU=.b428de44-95e5-459c-92f0-55a51b9ec910@github.com>
 
 
Message-ID: <6QZNGgZgFS5TcRwwRZB0VSZpA-574sJqqbmAJVTo-bU=.ca3f8ef5-f1bf-49c4-99f1-dee3f5651d1d@github.com>

On Thu, 30 Oct 2025 07:34:52 GMT, Richard Reingruber  wrote:

>> We can get here from a preemptable path if initialization of the klass failed: https://github.com/pchilano/jdk/blob/c7d6f5c5220a93653dea37488d238a76e2ad627d/src/hotspot/share/oops/instanceKlass.cpp#L1292
>> Also from here at linking step: https://github.com/pchilano/jdk/blob/c7d6f5c5220a93653dea37488d238a76e2ad627d/src/hotspot/share/oops/instanceKlass.cpp#L970.
>> The klass of the exception might need to be initialized, so without this `NoPreemptMark` the thread could be preempted while trying to initialize it. The problem is that this method is called here https://github.com/pchilano/jdk/blob/c7d6f5c5220a93653dea37488d238a76e2ad627d/src/hotspot/share/utilities/exceptions.cpp#L372, which will continue executing and possibly make an upcall to Java. We could potentially change these methods to identify a `PreemptedException` and use the `CHECK` macros to return, but I think it is simpler to disable preemption for these cases.
>
> I'm a correct that at line 348 "the *exception* is propagated we might make an upcall to" you are referring to an `PreemptedException`? You could change the comment to distinguish this one with the exception being created better.

Yes, I updated the comment to make the distinction clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2478637299

From jvernee at openjdk.org  Thu Oct 30 16:15:10 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 30 Oct 2025 16:15:10 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> See the JBS issue for a problem description.
> 
> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
> 
> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
> 3. Any other Java code that runs as part of the linking process.
> 
> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
> 
> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
> 
> Testing: tier 1-4

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  David review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27919/files
  - new: https://git.openjdk.org/jdk/pull/27919/files/c1950051..76c1ad1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27919&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27919&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27919/head:pull/27919

PR: https://git.openjdk.org/jdk/pull/27919

From jvernee at openjdk.org  Thu Oct 30 16:15:12 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 30 Oct 2025 16:15:12 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 17:58:40 GMT, Jorn Vernee  wrote:

>> See the JBS issue for a problem description.
>> 
>> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
>> 
>> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
>> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
>> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
>> 3. Any other Java code that runs as part of the linking process.
>> 
>> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
>> 
>> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove requires vm.debug

Thanks for the review comments so far. I've addressed them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27919#issuecomment-3468811262

From asemenyuk at openjdk.org  Thu Oct 30 16:29:14 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 16:29:14 GMT
Subject: RFR: 8370956: ShortcutHintTest test fails when executed locally on
 Linux
Message-ID: 

Don't verify icons when the test package is uninstalled.

-------------

Commit messages:
 - LinuxHelper: fix a regression from JDK-8370100

Changes: https://git.openjdk.org/jdk/pull/28064/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28064&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370956
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28064/head:pull/28064

PR: https://git.openjdk.org/jdk/pull/28064

From asemenyuk at openjdk.org  Thu Oct 30 16:29:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 16:29:15 GMT
Subject: RFR: 8370956: ShortcutHintTest test fails when executed locally on
 Linux
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 16:20:27 GMT, Alexey Semenyuk  wrote:

> Don't verify icons when the test package is uninstalled.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28064#issuecomment-3468889108

From abimpoudis at openjdk.org  Thu Oct 30 16:45:51 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 30 Oct 2025 16:45:51 GMT
Subject: RFR: 8359145: Implement JEP 530: Primitive Types in Patterns,
 instanceof, and switch (Fourth Preview) [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 29 Oct 2025 13:48:04 GMT, Jan Lahoda  wrote:

>> Aggelos Biboudis 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:
>> 
>>   8359145: JEP 530: Implement Primitive Types in Patterns, instanceof, and switch (Fourth Preview)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4743:
> 
>> 4741:                     boolean dominated = false;
>> 4742: 
>> 4743:                     if (unconditionalCaseLabel == testCaseLabel) unconditionalFound = true;
> 
> I think the code here is correct, but it is very hard to read (to me, at least). I wonder if there's a chance to try to tweak the code so that it is more readable.
> 
> At least: do `{}` around `unconditionalFound`, and move the `dominatedCandidate` into the `if (!currentType.hasTag(ERROR) && !testType.hasTag(ERROR)) {`. I suspect it might be possible to replace `dominatedCandidate` with `continue` in `if (currentType.constValue() instanceof Number) {` (would need to `if (allowPrimitivePatterns && unconditionalFound && unconditionalCaseLabel != label) {` check upfront, so not sure if that would improve things).

I simplified the code (abstained from using `continue`). Do you still think it is necessary?

> test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactInAssignability.java line 93:
> 
>> 91:     }
>> 92:     void assertOriginalAssignmentNarrowingAndUnconditionality() {
>> 93:         // byte b =  vs ExactConversionsSupport::isIntToByteExact
> 
> If I understand it correctly, the updated and original isAssignable should give the same results, right? I think it would be better to have one invocation, like `assertOriginaAndUpdatedAssignable`, that would check that for the given input, both methods return the same value, and the expected value. Having to lists of cases is likely to lead to omissions/mistakes, I suspect.

Addressed!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27637#discussion_r2478811104
PR Review Comment: https://git.openjdk.org/jdk/pull/27637#discussion_r2478812442

From abimpoudis at openjdk.org  Thu Oct 30 16:45:55 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 30 Oct 2025 16:45:55 GMT
Subject: RFR: 8359145: Implement JEP 530: Primitive Types in Patterns,
 instanceof, and switch (Fourth Preview) [v4]
In-Reply-To: 
References: 
 
Message-ID: <_qw7Y4M5qZJn9-oIES_aUWMH0B3A-37Jzhd4qQgncto=.4fd227da-3352-42df-b2ad-10b6dde44597@github.com>

On Thu, 30 Oct 2025 12:50:14 GMT, Aggelos Biboudis  wrote:

>> PR for Primitive Types in Patterns, instanceof, and switch (Fourth Preview).
>> 
>> spec: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix regression in Check

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4752:

> 4750:                         if (types.isUnconditionallyExactCombined(currentType, testType) &&
> 4751:                                 label instanceof JCConstantCaseLabel) {
> 4752:                             dominated = !(testCaseLabel instanceof JCConstantCaseLabel) &&

Note that I turned `|=` into `=` @lahodaj

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27637#discussion_r2478807035

From liach at openjdk.org  Thu Oct 30 16:54:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Oct 2025 16:54:40 GMT
Subject: RFR: 4397513: Misleading "interface method" in InvocationHandler
 specification
In-Reply-To: 
References: 
Message-ID: <-_lssxgITl6kZMYEPa-C5ICGchZ1BPM7ZFB75rs3Ysc=.90ed3d40-25bb-4b4f-98b8-52c649351175@github.com>

On Tue, 28 Oct 2025 17:49:40 GMT, Chen Liang  wrote:

> Update occurrences of the not-exactly-correct "interface method" to "invoked method" because 3 Object methods are proxied too. In addition, update the description about the declaring class of the method to be more accurate so that it doesn't clash with the "duplicate method" section in Proxy.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28024#issuecomment-3469016290

From liach at openjdk.org  Thu Oct 30 16:54:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Oct 2025 16:54:41 GMT
Subject: Integrated: 4397513: Misleading "interface method" in
 InvocationHandler specification
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 17:49:40 GMT, Chen Liang  wrote:

> Update occurrences of the not-exactly-correct "interface method" to "invoked method" because 3 Object methods are proxied too. In addition, update the description about the declaring class of the method to be more accurate so that it doesn't clash with the "duplicate method" section in Proxy.

This pull request has now been integrated.

Changeset: a2196e20
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/a2196e20608a1acd12c84ecfb8522bf1666545f4
Stats:     11 lines in 1 file changed: 0 ins; 1 del; 10 mod

4397513: Misleading "interface method" in InvocationHandler specification

Reviewed-by: alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/28024

From asemenyuk at openjdk.org  Thu Oct 30 17:07:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 17:07:15 GMT
Subject: RFR: 8370963: Errors in jpackage jtreg test descriptions
Message-ID: 

Fix jpackage jtreg test descriptions. No functional impact

-------------

Commit messages:
 - Cleanup jtreg descriptions
 - Fix jtreg descriptions

Changes: https://git.openjdk.org/jdk/pull/28067/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28067&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370963
  Stats: 29 lines in 13 files changed: 5 ins; 24 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28067/head:pull/28067

PR: https://git.openjdk.org/jdk/pull/28067

From fweimer at redhat.com  Thu Oct 30 17:10:17 2025
From: fweimer at redhat.com (Florian Weimer)
Date: Thu, 30 Oct 2025 18:10:17 +0100
Subject: InputStream/OutputStream concurrency guarantees
In-Reply-To: <5848207d-a5f7-48c8-81c8-826de122af48@oracle.com> (Viktor Klang's
 message of "Tue, 28 Oct 2025 14:12:09 +0100")
References: 
 
 
 
 <5848207d-a5f7-48c8-81c8-826de122af48@oracle.com>
Message-ID: 

* Viktor Klang:

> Also, since there aren't any consistency effects in place, it is not
> deterministic which changes made by the writer would be seen by the
> reader/copier.

Sure, but if a defensive copy were made, at least the output would be
internally consistent.  This would be similar to what various
byte[]-accepting String methods already do.

But it seems to me that the consensus seems to be that
InputStream/OutputStream do not need to do this, and (for example)
FileInputStream and FileOutputStream could be changed in ways that make
multiple byte array reads and writes observable through race conditions.

Thanks,
Florian


From asemenyuk at openjdk.org  Thu Oct 30 17:13:43 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 17:13:43 GMT
Subject: RFR: 8370963: Errors in jpackage jtreg test descriptions
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 16:58:58 GMT, Alexey Semenyuk  wrote:

> Fix jpackage jtreg test descriptions. No functional impact

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28067#issuecomment-3469098496

From viktor.klang at oracle.com  Thu Oct 30 17:25:48 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 30 Oct 2025 18:25:48 +0100
Subject: [External] : Re: InputStream/OutputStream concurrency guarantees
In-Reply-To: 
References: 
 
 
 
 <5848207d-a5f7-48c8-81c8-826de122af48@oracle.com>
 
Message-ID: 

The creation of said signatures was most likely to reduce copying of 
buffers so copying the buffer would likely be going against the design. 
Presumably the party which passes the array to the read/write is in 
control of said array, so if one wants to defensively copy it before 
passing it to the read/write it is definitely possible to do so on a 
case-by-case basis.

One important difference to something like String is that String is 
immutable, so being able to create a mutable String would subvert the 
guarantees of the type?the same is not the case for 
InputStream/OutputStream.

On 2025-10-30 18:10, Florian Weimer wrote:
> * Viktor Klang:
>
>> Also, since there aren't any consistency effects in place, it is not
>> deterministic which changes made by the writer would be seen by the
>> reader/copier.
> Sure, but if a defensive copy were made, at least the output would be
> internally consistent.  This would be similar to what various
> byte[]-accepting String methods already do.
>
> But it seems to me that the consensus seems to be that
> InputStream/OutputStream do not need to do this, and (for example)
> FileInputStream and FileOutputStream could be changed in ways that make
> multiple byte array reads and writes observable through race conditions.
>
> Thanks,
> Florian
>
-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle


From pavel.rappo at gmail.com  Thu Oct 30 17:30:15 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Thu, 30 Oct 2025 17:30:15 +0000
Subject: InputStream/OutputStream concurrency guarantees
In-Reply-To: 
References: 
 
 
 
 <5848207d-a5f7-48c8-81c8-826de122af48@oracle.com>
 
Message-ID: 

Replies inline.

On Thu, Oct 30, 2025 at 5:10?PM Florian Weimer  wrote:
>
> * Viktor Klang:
>
> > Also, since there aren't any consistency effects in place, it is not
> > deterministic which changes made by the writer would be seen by the
> > reader/copier.
>
> Sure, but if a defensive copy were made, at least the output would be
> internally consistent.  This would be similar to what various
> byte[]-accepting String methods already do.

Even with a private copy, there's no guarantee that the array will
remain unchanged while you are copying it. What is guaranteed is that
_after_ you have made that copy, no external code will be able to
change it.

You should protect your arrays from unintended modifications, but I'm
unaware of any good way to catch such modifications.

> 

> FileInputStream and FileOutputStream could be changed in ways that make
> multiple byte array reads and writes observable through race conditions.

Could you clarify this by providing an example? What do you mean by
"FileInputStream and FileOutputStream could be changed"?

-Pavel

From archie.cobbs at gmail.com  Thu Oct 30 17:36:40 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 30 Oct 2025 12:36:40 -0500
Subject: InputStream/OutputStream concurrency guarantees
In-Reply-To: 
References: 
 
 
 
 <5848207d-a5f7-48c8-81c8-826de122af48@oracle.com>
 
Message-ID: 

On Thu, Oct 30, 2025 at 12:11?PM Florian Weimer  wrote:

> > Also, since there aren't any consistency effects in place, it is not
> > deterministic which changes made by the writer would be seen by the
> > reader/copier.
>
> Sure, but if a defensive copy were made, at least the output would be
> internally consistent.


I think this is still missing the bigger picture. I.e., what is "internally
consistent" supposed to mean? As Pavel said:

the array may be changed while it's being copied, which is no different
> from it being changed while it is being written from.


>From a "consistency" point of view, I think the array behaves essentially
as a bunch of unrelated 8-bit quantities, all of which are subject
to change, in any order. Even if the adversarial writers were writing in
some order, the OutputStream method won't necessarily observe those writes
in that same order (actually I am not 100% certain, but I'm pretty sure
the memory model doesn't guarantee that). So it doesn't matter if
OutputStream happens to read the array from 0 to N - that doesn't really
impose any "order" so to speak.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alanb at openjdk.org  Thu Oct 30 17:45:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Oct 2025 17:45:59 GMT
Subject: RFR: 4517644: Core reflection setter type conversion spec bugs
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 14:49:57 GMT, Chen Liang  wrote:

>> ### Current Status
>> In core reflection, there are a few holes with the documentation on the type conversions performed on the different setters. They generally follow this process:
>> 
>> 1. The Object-valued setters checks the destination type. If that type is primitive, unbox the object.
>> 2. Perform identity or (primitive/reference, depending on destination type) widening conversions.
>> 
>> For each step, they can fail with IllegalArgumentException, which has been the long standing behavior.
>> 
>> Note that this process is more restrictive than the JLS 5.2 assignment context, which allows boxing conversions, while the primitive reflective setters consistently reject them.
>> 
>> ### Problems
>> There are some problems with current specs:
>> 1. No mention that boxing is never done for primitive-typed setters
>> 2. Array.set missing description for the final identity or widening conversion (reference or primitive) and the associated IAE condition
>> 3. Class specification of field mentions widening/narrowing conversion rules that is not sensible for get/set Object accessors
>> 4. Field.set misses the identity or widening in IAE clause (but mentioned in main body)
>> 5. Field primitive setters incorrectly claim they are equivalent to set(instance, wrapper) which is wrong due to lack of boxing conversion
>> 6. Field primitive setters refer to nonsense "unwrapping conversion"
>> 
>> ### Solutions
>> 1. Make sure the unbox -> identity/widen process and the IAE conditions are present in both Field and Array.set
>> 2. Add that boxing is absent for all primitive setters
>> 3. Update Field class spec to mention the narrowing/widening conversion limits are for primitive accessors only
>> 4. Fix the Field primitive setters' "unwrapping conversion" to be "identity or primitive widening conversion" as in Array primitive setters
>> 5. Qualify the Field primitive setters assertion with "if this field is of a primitive type" to make it correct
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   the narrowing conversion restriction is primitive-only

Thanks for the update, I think it looks good.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28029#pullrequestreview-3400872398

From rriggs at openjdk.org  Thu Oct 30 17:59:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Oct 2025 17:59:42 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
 
 
 
 
 <8vnnaDLbpvjdSdANjw2p_i_xvu7X8mqkNexoDPSyzE4=.c274163d-1b2e-4b9a-a6c0-e22e5aacd3cd@github.com>
 
Message-ID: 

On Thu, 30 Oct 2025 03:00:47 GMT, Xueming Shen  wrote:

>>> The performance is slightly better, but not as good as I would have expected. The access to codepoint from the long looks a little clumsy, but the logic looks smooth. need more work. opinion?
>> It does look cleaner without the array indexing in the loops.
>> Can the counting of characters (fcnt1,fcnt2) be eliminated by encoding 3 20-bit characters into the long and then checking `f1 != 0` to indicate there are more characters.  Its a bit of an odd mix of 16-bit characters vs a single 20-bit char. Are there any 20-bit chars from or to folded replacements in the folding mappings?
>
> Good idea.   After removing the fcnt the implementation looks much cleaner and more straightforward. The1:m folding implementation is also faster.  Maybe this is good enough to. go :-) 
> 
> The latest numbers
> 
> 
> Benchmark                                    Mode  Cnt   Score   Error  Units
> StringCompareToFoldCase.asciiLower           avgt   15  15.874 ? 1.276  ns/op
> StringCompareToFoldCase.asciiLowerEQ         avgt   15   9.915 ? 0.242  ns/op
> StringCompareToFoldCase.asciiLowerEQFC       avgt   15  10.751 ? 0.219  ns/op
> StringCompareToFoldCase.asciiLowerFC         avgt   15  10.277 ? 0.126  ns/op
> StringCompareToFoldCase.asciiUpperLower      avgt   15  12.121 ? 0.699  ns/op
> StringCompareToFoldCase.asciiUpperLowerEQ    avgt   15  10.836 ? 0.746  ns/op
> StringCompareToFoldCase.asciiUpperLowerEQFC  avgt   15   9.091 ? 0.273  ns/op
> StringCompareToFoldCase.asciiUpperLowerFC    avgt   15   9.207 ? 0.255  ns/op
> StringCompareToFoldCase.asciiWithDFFC        avgt   15  38.322 ? 0.975  ns/op
> StringCompareToFoldCase.greekLower           avgt   15  39.746 ? 0.127  ns/op
> StringCompareToFoldCase.greekLowerEQ         avgt   15  39.303 ? 0.063  ns/op
> StringCompareToFoldCase.greekLowerEQFC       avgt   15  20.470 ? 0.329  ns/op
> StringCompareToFoldCase.greekLowerFC         avgt   15  19.734 ? 0.295  ns/op
> StringCompareToFoldCase.greekUpperLower      avgt   15   7.084 ? 0.085  ns/op
> StringCompareToFoldCase.greekUpperLowerEQ    avgt   15   7.472 ? 0.115  ns/op
> StringCompareToFoldCase.greekUpperLowerEQFC  avgt   15   6.608 ? 0.248  ns/op
> StringCompareToFoldCase.greekUpperLowerFC    avgt   15   6.573 ? 0.189  ns/op
> StringCompareToFoldCase.latin1UTF16          avgt   15  24.407 ? 2.157  ns/op
> StringCompareToFoldCase.latin1UTF16EQ        avgt   15  22.632 ? 0.131  ns/op
> StringCompareToFoldCase.latin1UTF16EQFC      avgt   15  29.564 ? 0.655  ns/op
> StringCompareToFoldCase.latin1UTF16FC        avgt   15  29.273 ? 0.324  ns/op
> StringCompareToFoldCase.supLower             avgt   15  54.145 ? 0.075  ns/op
> StringCompareToFoldCase.supLowerEQ           avgt   15  55.545 ? 0.042  ns/op
> StringCompareToFoldCase.supLowerEQFC         avgt   15  24.788 ? 0.180  ns/op
> StringCompareToFoldCase.supLowerFC           avgt   15  24.515 ? 0.025  ns/op
> StringCompareToFoldCase.supUpperLower        avgt   15  14.437 ? 0.127  ns/op
> StringCompareToFoldCase.supUpperLowerEQ      avgt   15  15.253 ? 0.728  ns/op
> StringCompareToFoldCase.supUpperLowerEQFC    avgt   15   9.820 ? 0.104  ns/op
> StringCompareToFoldCase.supUpp...

Looking pretty good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2479020631

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

From asemenyuk at openjdk.org  Thu Oct 30 19:12:08 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 19:12:08 GMT
Subject: RFR: 8370969: --launcher-as-service option is ignored when used with
 --app-image option
Message-ID: 

- Fix jpackage to handle correctly the `--launcher-as-service` cli option when bundling a native bundle from the predefined app image.
 - Rework `LauncherAsServiceVerifier` to make it work with `JPackageCommand` and `PackageTest`. This allows using it in tests when jpackage creates a native bundle from the predefined app image (`--app-image` option).
 - Add relevant test cases to `ServiceTest`. The new test cases cover "launcher-as-service" feature for additional launchers.
 - Fix `MacHelper.getPackageId()` to make it work when bundling a native bundle from the predefined app image.

Supplementary changes:
 - Get rid of "thows IOException" from all method signatures in `CfgTest` and `TKit.traceFileContents()`. 
 - Format `TKit.createTextFile()` and `TKit.createPropertiesFile()`.
 - Add `JPackageCommand.mainLauncherName()`. It returns the same value as `JPackageCommand.name()`, but will fail if called in case or runtime bundling. Replace `JPackageCommand.name()` with `JPackageCommand.mainLauncherName()` where appropriate.
 - Add the `PropertyFinder` class, which provides a declarative way to calculate the value of a property that may be sourced from one or a few cli options, a property in an additionl launcher property file, and a value in the app image file (.jpackage.xml).

-------------

Commit messages:
 - CfgFile, TKit: get rid of "throws IOException"; TKit: reformat createTextFile() and createPropertiesFile()
 - FromParams: fix a bug that "--launcher-as-service" doesn't have any effect on the main launcher when used with the "--app-image" option.
 - MacHelper: use PropertyFinder to get the value of the package ID
 - ConfigFilesStasher: use LauncherAsServiceVerifier.launcherAsService()
 - ServiceTest, LauncherAsServiceVerifier: improve test coverage
 - Introduce PropertyFinder to calculate value of properties defined by jpackage command line options, additional launcher property files, and .jpackage.xml file fom the predefeined app image in a uniform way
 - JPackageCommand: add mainLauncherName(), launcherNames(); change signature of addLauncherNames(); MacSignVerify: follow-up for addLauncherNames() change; WinShortcutVerifier, LauncherShortcut, LinuxHelper: use JPackageCommand.mainLauncherName(), JPackageCommand.addLauncherNames()
 - AdditionalLauncher: add removeProperty()

Changes: https://git.openjdk.org/jdk/pull/28071/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28071&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370969
  Stats: 632 lines in 14 files changed: 480 ins; 42 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/28071.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28071/head:pull/28071

PR: https://git.openjdk.org/jdk/pull/28071

From prappo at openjdk.org  Thu Oct 30 19:37:38 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 30 Oct 2025 19:37:38 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v24]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Oct 2025 18:42:32 GMT, Roger Riggs  wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add \@implNote to recommend overriding close and calling `super.close()`.

Roger, I'm thinking about that example in `close()`. It would be a ready-to-run program, if not for the method name: `example`. Since the text already says that it's an example, we could rename the method to `main` without loss of information.

This way the example could be pasted into a file and run, thanks to JEP 512: Compact Source Files and Instance Main Methods. Note, I used `var` for the reader and writer to get rid of imports from `java.io`, but it's not essential as a decent IDE would insert them on paste.


void main() {
    try (Process p = new ProcessBuilder("cat").start();
         var writer = p.outputWriter();
         var reader = p.inputReader()) {
        writer.write(haiku);
        writer.close();
        // Read all lines and print each
        reader.readAllLines()
                .forEach(System.out::println);
        var status = p.waitFor();
        if (status != 0) {
            throw new RuntimeException("unexpected process status: " + status);
        }
    } catch (Exception e) {
        System.out.println("Process failed: " + e);
    }
}

String haiku = """
        Oh, the sunrise glow;
        Paddling with the river flow;
        Chilling still, go slow.
        """;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26649#issuecomment-3469753255

From almatvee at openjdk.org  Thu Oct 30 19:48:38 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 Oct 2025 19:48:38 GMT
Subject: RFR: 8370956: ShortcutHintTest test fails when executed locally on
 Linux
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 16:20:27 GMT, Alexey Semenyuk  wrote:

> Don't verify icons when the test package is uninstalled.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28064#pullrequestreview-3401361950

From almatvee at openjdk.org  Thu Oct 30 20:04:32 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 Oct 2025 20:04:32 GMT
Subject: RFR: 8370963: Errors in jpackage jtreg test descriptions
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 16:58:58 GMT, Alexey Semenyuk  wrote:

> Fix jpackage jtreg test descriptions. No functional impact

test/jdk/tools/jpackage/windows/WinLongVersionTest.java line 74:

> 72:  * @library /test/jdk/tools/jpackage/helpers
> 73:  * @key jpackagePlatformPackage
> 74:  * @requires (jpackage.test.SQETest != null)

Do you know if SQE actually was testing this test? Duplicated annotation is different only in `jpackage.test.SQETest`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28067#discussion_r2479357790

From liach at openjdk.org  Thu Oct 30 20:21:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Oct 2025 20:21:39 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 16:15:10 GMT, Jorn Vernee  wrote:

>> See the JBS issue for a problem description.
>> 
>> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
>> 
>> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
>> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
>> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
>> 3. Any other Java code that runs as part of the linking process.
>> 
>> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
>> 
>> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David review comment

This approach and test look good, but note I am not professional. Let's use a valid bug number for the tests.

test/jdk/java/foreign/sharedclosejfr/TestSharedCloseJFR.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8351032

Suggestion:

 * @bug 8370344

test/jdk/java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8351032

Suggestion:

 * @bug 8370344

-------------

PR Review: https://git.openjdk.org/jdk/pull/27919#pullrequestreview-3401475908
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2479404865
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2479405318

From rriggs at openjdk.org  Thu Oct 30 20:38:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Oct 2025 20:38:17 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v25]
In-Reply-To: 
References: 
Message-ID: 

> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
> 
> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
> 
> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Replaced the test mechanism to force stream closes to throw exceptions.
  The previous mechanism was subject to race conditions and was complicated and fragile.
  The new mechanism interposes a stream implementation that closes the underlying stream and then throws a well known exception.
  It is much less sensitive to platform and race conditions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26649/files
  - new: https://git.openjdk.org/jdk/pull/26649/files/c2072f7d..a1bcf5ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=23-24

  Stats: 118 lines in 1 file changed: 25 ins; 48 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/26649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26649/head:pull/26649

PR: https://git.openjdk.org/jdk/pull/26649

From rriggs at openjdk.org  Thu Oct 30 21:10:28 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Oct 2025 21:10:28 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v24]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Oct 2025 19:34:52 GMT, Pavel Rappo  wrote:

> Roger, I'm thinking about that example in `close()`. It would be a ready-to-run program, if not for the method name: `example`. Since the text already says that it's an example, we could rename the method to `main` without loss of information.

Good idea, thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26649#issuecomment-3470241779

From almatvee at openjdk.org  Thu Oct 30 21:13:26 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 Oct 2025 21:13:26 GMT
Subject: RFR: 8370963: Errors in jpackage jtreg test descriptions
In-Reply-To: 
References: 
Message-ID: <9PHlMgrAYFPl64I9ijjAFYT2Vw2yDSp8jc5Ofz-mEAk=.5b371049-4632-462a-b299-c7b0333c0e17@github.com>

On Thu, 30 Oct 2025 16:58:58 GMT, Alexey Semenyuk  wrote:

> Fix jpackage jtreg test descriptions. No functional impact

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28067#pullrequestreview-3401667206

From asemenyuk at openjdk.org  Thu Oct 30 21:13:30 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 21:13:30 GMT
Subject: RFR: 8370963: Errors in jpackage jtreg test descriptions
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 20:01:27 GMT, Alexander Matveev  wrote:

>> Fix jpackage jtreg test descriptions. No functional impact
>
> test/jdk/tools/jpackage/windows/WinLongVersionTest.java line 74:
> 
>> 72:  * @library /test/jdk/tools/jpackage/helpers
>> 73:  * @key jpackagePlatformPackage
>> 74:  * @requires (jpackage.test.SQETest != null)
> 
> Do you know if SQE actually was testing this test? Duplicated annotation is different only in `jpackage.test.SQETest`.

No, they didn't. I checked the test spec, it doesn't reference this test. That is why I deleted this

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28067#discussion_r2479529032

From rriggs at openjdk.org  Thu Oct 30 21:17:23 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Oct 2025 21:17:23 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v24]
In-Reply-To: 
References: 
 
 
Message-ID: <7BJ6CVagwPkQKsUMykjuJ-LPffQre6oAHqPZPXckrjY=.5cc76c9d-8abd-4e49-9374-d1065080521e@github.com>

On Thu, 30 Oct 2025 01:57:06 GMT, Jason Mehrens  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add \@implNote to recommend overriding close and calling `super.close()`.
>
> src/java.base/share/classes/java/lang/snippet-files/ProcessExamples.java line 31:
> 
>> 29: public class ProcessExamples {
>> 30:     // @start region=example
>> 31:     void example() {
> 
> Should there be another version of this that is involved with interruption set at top of method? That example would forever freeze which shows there is a problem with the example.

I don't see a hang in this example, it writes 3 lines to the child and flushes and closes the output stream.
`cat` will see end of file and exit.
Almost all processes started will exit when they've done what they are supposed to.
A more defensive example would give the impression that every use of a process should follow the same pattern.
It adds a lot of boilerplate to schedule an interrupt and then cancel when the process exits.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2479546092

From asemenyuk at openjdk.org  Thu Oct 30 21:17:24 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 21:17:24 GMT
Subject: Integrated: 8370956: ShortcutHintTest test fails when executed locally
 on Linux
In-Reply-To: 
References: 
Message-ID: <9CaVZSzaDKkBCIJYKKce7ktrt1r_Vkix5Xao9ao74uk=.7f973eba-a75e-4cc0-a0e8-b2823a882bb9@github.com>

On Thu, 30 Oct 2025 16:20:27 GMT, Alexey Semenyuk  wrote:

> Don't verify icons when the test package is uninstalled.

This pull request has now been integrated.

Changeset: a5f3a6f2
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/a5f3a6f21b68fe9b97cb1aa22f54173b192fbd10
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8370956: ShortcutHintTest test fails when executed locally on Linux

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28064

From asemenyuk at openjdk.org  Thu Oct 30 21:17:25 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 21:17:25 GMT
Subject: Integrated: 8370963: Errors in jpackage jtreg test descriptions
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 16:58:58 GMT, Alexey Semenyuk  wrote:

> Fix jpackage jtreg test descriptions. No functional impact

This pull request has now been integrated.

Changeset: e293166e
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/e293166e440df75f650ee280c300c085cd141d30
Stats:     29 lines in 13 files changed: 5 ins; 24 del; 0 mod

8370963: Errors in jpackage jtreg test descriptions

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28067

From fweimer at redhat.com  Thu Oct 30 21:39:46 2025
From: fweimer at redhat.com (Florian Weimer)
Date: Thu, 30 Oct 2025 22:39:46 +0100
Subject: InputStream/OutputStream concurrency guarantees
In-Reply-To: 
 (Archie Cobbs's message of "Thu, 30 Oct 2025 12:36:40 -0500")
References: 
 
 
 
 <5848207d-a5f7-48c8-81c8-826de122af48@oracle.com>
 
 
Message-ID: 

* Archie Cobbs:

> I think this is still missing the bigger picture. I.e., what is
> "internally consistent" supposed to mean? As Pavel said:
>
>> the array may be changed while it's being copied, which is no
>> different from it being changed while it is being written from.
>
> From a "consistency" point of view, I think the array behaves
> essentially as a bunch of unrelated 8-bit quantities, all of which are
> subject to change, in any order. Even if the adversarial writers were
> writing in some order, the OutputStream method won't necessarily
> observe those writes in that same order (actually I am not 100%
> certain, but I'm pretty sure the memory model doesn't guarantee
> that). So it doesn't matter if OutputStream happens to read the array
> from 0 to N - that doesn't really impose any "order" so to speak.

Okay, maybe I should write down why I'm asking these questions.

I'm trying to image in a way to get rid of the double buffering in
FileInputStream/FileOutputStream: have the kernel access the heap
directly, instead of a copy.  The na?ve approach with critical byte
array operations doesn't work because it won't meet pause time
expectations.  On the other hand, it seems perfectly safe to let the
kernel read or write the array during the GC marking phase because the
two kinds of accesses do not interfere at all.  Evacuation while a
FileInputStream is reading is more tricky because it's in principle
observable: the evacuated object would have to be copied over again once
the read comes out of the kernel.

However, the real challenge is to get out of the kernel when it is time
to make the old object available for reuse (which may happen pretty
quickly with in-place compaction used by some GCs).  I believe it is
possible to achieve this by sending a signal that is already handled by
the JVM.  There is an inherent race condition there because the required
behavior differs somewhat depending on whether the system call has not
yet started, has started, but was interrupted by the signal, has
concluded, and has concluded and the thread previously doing I/O is now
stuck at the safepoint.  It is possible to tell these cases apart if the
JVM does a direct system call (not through libc) from a machine code
sequence with a known layout, and the signal handler examines the
program counter.  (A single system call helper could handle all system
calls, if the system call number is an additional parameter.)  This is
how POSIX thread cancellation is nowadays implemented in musl and glibc,
as it's the only way to figure out if it is safe to act on the
cancellation.

(All of this is of course very Linux-specific.)

Thanks,
Florian


From almatvee at openjdk.org  Thu Oct 30 22:31:01 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 Oct 2025 22:31:01 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 02:29:24 GMT, Alexey Semenyuk  wrote:

>> - Added JDK specific keys/values to Info.plist of embedded runtime.
>> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
>> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java line 363:
> 
>> 361:         final var app = env.app();
>> 362: 
>> 363:         // We should use full runtime info plist for standalone runtime and for
> 
> I guess the comment explains why jpackage should use the same info plist template for a runtime if it has the "bin" subdirectory. But what is the "full" runtime?

"full" runtime info plist -> refers to info plist from standalone runtime. I will re-write it to:

   // We should use info plist from standalone runtime for embedded runtime
   // if embedded runtime contains "bin" folder, so embedded runtime
   // can act as standalone runtime. Standalone runtime always uses same
   // info plist which has "JavaVM" dictionary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28033#discussion_r2479674193

From asemenyuk at openjdk.org  Thu Oct 30 22:37:38 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 22:37:38 GMT
Subject: RFR: 8370965: Remove SigningPackageFromTwoStepAppImageTest test
Message-ID: 

Remove redundant SigningPackageFromTwoStepAppImageTest test.

-------------

Commit messages:
 - empty
 - SigningPackageFromTwoStepAppImageTest: remove

Changes: https://git.openjdk.org/jdk/pull/28068/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28068&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370965
  Stats: 195 lines in 1 file changed: 0 ins; 195 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28068.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28068/head:pull/28068

PR: https://git.openjdk.org/jdk/pull/28068

From asemenyuk at openjdk.org  Thu Oct 30 22:37:38 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 22:37:38 GMT
Subject: RFR: 8370965: Remove SigningPackageFromTwoStepAppImageTest test
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 17:09:40 GMT, Alexey Semenyuk  wrote:

> Remove redundant SigningPackageFromTwoStepAppImageTest test.

@sashamatveev PTAL

Quote from the description of the https://github.com/openjdk/jdk/pull/10316 PR:

> Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed.

I believe the right way to test that jpackage writes correct data in the .jpackage.xml file in the two-step signing scenario is to add a relevant check to the SigningAppImageTwoStepsTest test. But it still doesn't have this check. Instead, the correctness of .jpackage.xml in the predefined app image is (was) indirectly tested in SigningPackageFromTwoStepAppImageTest test.

Even more reasons to remove SigningPackageFromTwoStepAppImageTest as it was hiding a gap in test coverage in the SigningAppImageTwoStepsTest test :)

UPD: We test the value of the "mac-signed" property in ,jpackage.xml file in [JPackageCommand.assertAppImageFile()](https://github.com/openjdk/jdk/blob/a5f3a6f21b68fe9b97cb1aa22f54173b192fbd10/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java#L1217) function. No need to update SigningAppImageTwoStepsTest test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28068#issuecomment-3469100761
PR Comment: https://git.openjdk.org/jdk/pull/28068#issuecomment-3470359163

From almatvee at openjdk.org  Thu Oct 30 22:37:06 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 Oct 2025 22:37:06 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 03:36:19 GMT, Alexey Semenyuk  wrote:

>> - Added JDK specific keys/values to Info.plist of embedded runtime.
>> - Modified `setFakeRuntime()` not to include `bin` folder. By default it was always included, but generated embedded runtime by default does not have `bin` folder. As a result `CustomInfoPListTest` failed.
>> - Updated  `CustomInfoPListTest` to test Info.plist with `bin` folder.
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 319:
> 
>> 317:                 // always something in application image.
>> 318:                 fakeRuntimeDir.resolve("bin").toFile().mkdir();
>> 319:                 createBulkFile.accept(fakeRuntimeDir.resolve(Path.of("bin", "bulk")));
> 
> This change makes the above `fakeRuntimeDir.resolve("bin").toFile().mkdir();` redundant. Overall, the whole
> 
> if (TKit.isLinux()) {
>     // Need to make the code in rpm spec happy as it assumes there is
>     // always something in application image.
>     fakeRuntimeDir.resolve("bin").toFile().mkdir();
> }
> 
> construction is redundant and can be replaced with:
> 
> if (includeBin) {
>     createBulkFile.accept(fakeRuntimeDir.resolve(Path.of("bin", "bulk")));
> }

We still need to add file to "bin" for Linux. I will change it to:

            // Need to make the code in rpm spec happy as it assumes there is
            // always something in application image.
            includeBin |= TKit.isLinux();

            if (includeBin) {
                createBulkFile.accept(fakeRuntimeDir.resolve(Path.of("bin", "bulk")));
            }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28033#discussion_r2479681605

From almatvee at openjdk.org  Thu Oct 30 22:37:39 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 Oct 2025 22:37:39 GMT
Subject: RFR: 8370965: Remove SigningPackageFromTwoStepAppImageTest test
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 17:11:19 GMT, Alexey Semenyuk  wrote:

>> Remove redundant SigningPackageFromTwoStepAppImageTest test.
>
> @sashamatveev PTAL

@alexeysemenyukoracle Removed test was added as part of https://github.com/openjdk/jdk/pull/10316. Can you double check that tests we have will catch https://bugs.openjdk.org/browse/JDK-8293462.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28068#issuecomment-3469903182

From asemenyuk at openjdk.org  Thu Oct 30 22:37:39 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 22:37:39 GMT
Subject: RFR: 8370965: Remove SigningPackageFromTwoStepAppImageTest test
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 20:03:21 GMT, Alexander Matveev  wrote:

> You need to fix "The pull request body must not be empty."

The empty commit didn't help. I guess jcheck doesn't allow PRs that only delete files.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28068#issuecomment-3470385681

From almatvee at openjdk.org  Thu Oct 30 22:37:39 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 Oct 2025 22:37:39 GMT
Subject: RFR: 8370965: Remove SigningPackageFromTwoStepAppImageTest test
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Oct 2025 21:44:59 GMT, Alexey Semenyuk  wrote:

> The empty commit didn't help. I guess jcheck doesn't allow PRs that only delete files.

I think it wants description in PR. Like "SigningPackageFromTwoStepAppImageTest was removed."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28068#issuecomment-3470465439

From almatvee at openjdk.org  Thu Oct 30 22:37:39 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 Oct 2025 22:37:39 GMT
Subject: RFR: 8370965: Remove SigningPackageFromTwoStepAppImageTest test
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 17:09:40 GMT, Alexey Semenyuk  wrote:

> Remove redundant SigningPackageFromTwoStepAppImageTest test.

You need to fix "The pull request body must not be empty."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28068#issuecomment-3469877103

From prappo at openjdk.org  Thu Oct 30 22:39:24 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 30 Oct 2025 22:39:24 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v24]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 30 Oct 2025 21:07:28 GMT, Roger Riggs  wrote:

> > Roger, I'm thinking about that example in `close()`. It would be a ready-to-run program, if not for the method name: `example`. Since the text already says that it's an example, we could rename the method to `main` without loss of information.
> 
> Good idea, thanks

Actually, I completely forgot that we don't even need to bother with `var`. [JEP 512] uses `import module java.base`, so `Reader` and `Writer` will be imported regardless. So, keep explicit types or use `var` -- your choice. 

The only thing that we'll need to do is change the snippet flavour. While __now__ it works as is, technically, there will no longer be the `ProcessExamples` class. From JEP 512:

> The Java compiler generates a class name when compiling a compact source file, but that name is implementation-specific and should not be relied upon in any source code -- not even source code in the compact source file itself.

So, we should use the `file` not `class` attribute, I think. See [JEP 413] for more info:

    {@snippet file=ProcessExamples.java region=example}

[JEP 512]: https://openjdk.org/jeps/512
[JEP 413]: https://openjdk.org/jeps/413

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26649#issuecomment-3470499640

From almatvee at openjdk.org  Thu Oct 30 22:45:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 Oct 2025 22:45:05 GMT
Subject: RFR: 8370965: Remove SigningPackageFromTwoStepAppImageTest test
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 17:09:40 GMT, Alexey Semenyuk  wrote:

> Remove redundant SigningPackageFromTwoStepAppImageTest test.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28068#pullrequestreview-3401901986

From naoto at openjdk.org  Thu Oct 30 22:46:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Oct 2025 22:46:09 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0
Message-ID: 

Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.

-------------

Commit messages:
 - v48 final
 - Merge branch 'master' into JDK-8354548-CLDR-48
 - Merge branch 'master' into JDK-8354548-CLDR-48
 - Merge branch 'master' into JDK-8354548-CLDR-48
 - Reverted Optional
 - release-48-beta3
 - Merge branch 'master' into JDK-8354548-CLDR-48
 - release-48-beta2
 - Merge branch 'master' into JDK-8354548-CLDR-48
 - 2025-09-30-1822z
 - ... and 42 more: https://git.openjdk.org/jdk/compare/cc9483b4...055336bd

Changes: https://git.openjdk.org/jdk/pull/28076/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28076&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354548
  Stats: 135768 lines in 385 files changed: 94267 ins; 15578 del; 25923 mod
  Patch: https://git.openjdk.org/jdk/pull/28076.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28076/head:pull/28076

PR: https://git.openjdk.org/jdk/pull/28076

From jvernee at openjdk.org  Thu Oct 30 22:47:41 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 30 Oct 2025 22:47:41 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> See the JBS issue for a problem description.
> 
> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
> 
> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
> 3. Any other Java code that runs as part of the linking process.
> 
> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
> 
> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
> 
> Testing: tier 1-4

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Update bug number in tests
  
  Co-authored-by: Chen Liang 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27919/files
  - new: https://git.openjdk.org/jdk/pull/27919/files/76c1ad1b..7a793468

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27919&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27919&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27919/head:pull/27919

PR: https://git.openjdk.org/jdk/pull/27919

From asemenyuk at openjdk.org  Thu Oct 30 22:49:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 22:49:10 GMT
Subject: Integrated: 8370965: Remove SigningPackageFromTwoStepAppImageTest test
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 17:09:40 GMT, Alexey Semenyuk  wrote:

> Remove redundant SigningPackageFromTwoStepAppImageTest test.

This pull request has now been integrated.

Changeset: a926c216
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/a926c216e0f56dfc4d129260f8bf028ade615756
Stats:     195 lines in 1 file changed: 0 ins; 195 del; 0 mod

8370965: Remove SigningPackageFromTwoStepAppImageTest test

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/28068

From asemenyuk at openjdk.org  Thu Oct 30 23:02:36 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 23:02:36 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Oct 2025 22:33:58 GMT, Alexander Matveev  wrote:

> We still need to add file to "bin" for Linux. I will change it to:

I simplified the body of the `setFakeRuntime()` function as follows:

        addPrerequisiteAction(cmd -> {
            Path fakeRuntimeDir = TKit.createTempDirectory("fake_runtime");

            TKit.trace(String.format("Init fake runtime in [%s] directory",
                    fakeRuntimeDir));

            if (TKit.isOSX()) {
                // Make MacAppImageBuilder happy
                createBulkFile.accept(fakeRuntimeDir.resolve(Path.of(
                        "lib/jli/libjli.dylib")));
            }

            // Make sure fake runtime takes some disk space.
            // Package bundles with 0KB size are unexpected and considered
            // an error by PackageTest.
            createBulkFile.accept(fakeRuntimeDir.resolve(Path.of("lib", "bulk")));

            cmd.setArgumentValue("--runtime-image", fakeRuntimeDir);
        });


And ran Windows and Linux tests that use it. All passed.

WinOSConditionTest:

[18:44:19.893] TRACE: assertStringListEquals(): Check jpackage didn't modify ${RUNTIME_IMAGE}=[C:\jpackage-tests\WinOSConditionTest\test\fake_runtime-0]
[18:44:19.893] TRACE: assertStringListEquals(1, #)
[18:44:19.894] TRACE: assertStringListEquals(2, lib#)
[18:44:19.894] TRACE: assertStringListEquals(3, lib\bulk#2025-10-30T22:44:17.6191874Z)
[18:44:19.894] TRACE: assertTrue(): Check [WinOSConditionTest\test\output\WinOSConditionTest-1.0.msi] path exists


AppAboutUrlTest.testDefaults (DEB):

[18:49:22.115] TRACE: assertStringListEquals(): Check jpackage didn't modify ${RUNTIME_IMAGE}=[/jpackage-tests/AppAboutUrlTest/testDefaults/fake_runtime]
[18:49:22.120] TRACE: assertStringListEquals(1, #)
[18:49:22.120] TRACE: assertStringListEquals(2, lib#)
[18:49:22.120] TRACE: assertStringListEquals(3, lib/bulk#2025-10-30T22:49:20.128409727Z)
[18:49:22.120] TRACE: assertTrue(): Check [AppAboutUrlTest/testDefaults/output/defaultsappabouturltest_1.0_amd64.deb] path exists


AppAboutUrlTest.testDefaults (RPM):

[18:56:37.897] TRACE: assertStringListEquals(): Check jpackage didn't modify ${RUNTIME_IMAGE}=[/jpackage-tests/AppAboutUrlTest/testDefaults/fake_runtime]
[18:56:37.898] TRACE: assertStringListEquals(1, #)
[18:56:37.898] TRACE: assertStringListEquals(2, lib#)
[18:56:37.898] TRACE: assertStringListEquals(3, lib/bulk#2025-10-30T22:56:37.204554597Z)
[18:56:37.898] TRACE: assertTrue(): Check [AppAboutUrlTest/testDefaults/output/defaultsappabouturltest-1.0-1.x86_64.rpm] path exists

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28033#discussion_r2479726131

From iklam at openjdk.org  Thu Oct 30 23:00:37 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 30 Oct 2025 23:00:37 GMT
Subject: RFR: 8370975: Test
 runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java can still fail
 on macos 26
Message-ID: 

In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines.

I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`.

I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case:


if (forceBase >= end) {
    throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test.");
}

-------------

Commit messages:
 - Removed sanity test
 - Fix with sanity test

Changes: https://git.openjdk.org/jdk/pull/28077/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28077&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370975
  Stats: 13 lines in 2 files changed: 9 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28077.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28077/head:pull/28077

PR: https://git.openjdk.org/jdk/pull/28077

From asemenyuk at openjdk.org  Thu Oct 30 23:07:04 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 23:07:04 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 30 Oct 2025 22:59:42 GMT, Alexey Semenyuk  wrote:

>> We still need to add file to "bin" for Linux. I will change it to:
>> 
>>             // Need to make the code in rpm spec happy as it assumes there is
>>             // always something in application image.
>>             includeBin |= TKit.isLinux();
>> 
>>             if (includeBin) {
>>                 createBulkFile.accept(fakeRuntimeDir.resolve(Path.of("bin", "bulk")));
>>             }
>
>> We still need to add file to "bin" for Linux. I will change it to:
> 
> I simplified the body of the `setFakeRuntime()` function as follows:
> 
>         addPrerequisiteAction(cmd -> {
>             Path fakeRuntimeDir = TKit.createTempDirectory("fake_runtime");
> 
>             TKit.trace(String.format("Init fake runtime in [%s] directory",
>                     fakeRuntimeDir));
> 
>             if (TKit.isOSX()) {
>                 // Make MacAppImageBuilder happy
>                 createBulkFile.accept(fakeRuntimeDir.resolve(Path.of(
>                         "lib/jli/libjli.dylib")));
>             }
> 
>             // Make sure fake runtime takes some disk space.
>             // Package bundles with 0KB size are unexpected and considered
>             // an error by PackageTest.
>             createBulkFile.accept(fakeRuntimeDir.resolve(Path.of("lib", "bulk")));
> 
>             cmd.setArgumentValue("--runtime-image", fakeRuntimeDir);
>         });
> 
> 
> And ran Windows and Linux tests that use it. All passed.
> 
> WinOSConditionTest:
> 
> [18:44:19.893] TRACE: assertStringListEquals(): Check jpackage didn't modify ${RUNTIME_IMAGE}=[C:\jpackage-tests\WinOSConditionTest\test\fake_runtime-0]
> [18:44:19.893] TRACE: assertStringListEquals(1, #)
> [18:44:19.894] TRACE: assertStringListEquals(2, lib#)
> [18:44:19.894] TRACE: assertStringListEquals(3, lib\bulk#2025-10-30T22:44:17.6191874Z)
> [18:44:19.894] TRACE: assertTrue(): Check [WinOSConditionTest\test\output\WinOSConditionTest-1.0.msi] path exists
> 
> 
> AppAboutUrlTest.testDefaults (DEB):
> 
> [18:49:22.115] TRACE: assertStringListEquals(): Check jpackage didn't modify ${RUNTIME_IMAGE}=[/jpackage-tests/AppAboutUrlTest/testDefaults/fake_runtime]
> [18:49:22.120] TRACE: assertStringListEquals(1, #)
> [18:49:22.120] TRACE: assertStringListEquals(2, lib#)
> [18:49:22.120] TRACE: assertStringListEquals(3, lib/bulk#2025-10-30T22:49:20.128409727Z)
> [18:49:22.120] TRACE: assertTrue(): Check [AppAboutUrlTest/testDefaults/output/defaultsappabouturltest_1.0_amd64.deb] path exists
> 
> 
> AppAboutUrlTest.testDefaults (RPM):
> 
> [18:56:37.897] TRACE: assertStringListEquals(): Check jpackage didn't modify ${RUNTIME_IMAGE}=[/jpackage-tests/AppAboutUrlTest/testDefaults/fake_runtime]
> [18:56:37.898] TRACE: assertStringListEquals(1, #)
> [18:56:37.898] TRACE: assertStringListEquals(2, lib#)
> [18:56:37.898] TRACE: assertStringListEquals(3, lib/bulk#2025-10-30T22:56:37.204554597Z)
> [18:56:37.898] TRACE: assertTrue(): Check [AppAboutUrlTest/testDefaults/output/defaultsappabouturltest-1.0-1.x86_64.rpm] path e...

The diff:

diff --git a/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java b/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
index fcd940e725e..73af859b6ac 100644
--- a/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
+++ b/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
@@ -307,24 +307,16 @@ public JPackageCommand setFakeRuntime() {
             TKit.trace(String.format("Init fake runtime in [%s] directory",
                     fakeRuntimeDir));

-            Files.createDirectories(fakeRuntimeDir);
-
-            if (TKit.isLinux()) {
-                // Need to make the code in rpm spec happy as it assumes there is
-                // always something in application image.
-                fakeRuntimeDir.resolve("bin").toFile().mkdir();
-            }
-
             if (TKit.isOSX()) {
                 // Make MacAppImageBuilder happy
                 createBulkFile.accept(fakeRuntimeDir.resolve(Path.of(
                         "lib/jli/libjli.dylib")));
             }

-            // Mak sure fake runtime takes some disk space.
+            // Make sure fake runtime takes some disk space.
             // Package bundles with 0KB size are unexpected and considered
             // an error by PackageTest.
-            createBulkFile.accept(fakeRuntimeDir.resolve(Path.of("bin", "bulk")));
+            createBulkFile.accept(fakeRuntimeDir.resolve(Path.of("lib", "bulk")));

             cmd.setArgumentValue("--runtime-image", fakeRuntimeDir);
         });

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28033#discussion_r2479736389

From naoto at openjdk.org  Thu Oct 30 23:13:02 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Oct 2025 23:13:02 GMT
Subject: RFR: 8354548: Update CLDR to Version 48.0 [v2]
In-Reply-To: 
References: 
Message-ID: <9VpoTyAJ3oQwtSpHO6sCVwaWA_Jx3B91DS2oxOTTTcI=.afc95ec9-c937-44e8-9a0c-9b087dd3c4ff@github.com>

> Upgrading the CLDR to version 48.0. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  .md files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28076/files
  - new: https://git.openjdk.org/jdk/pull/28076/files/055336bd..38f86493

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28076&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28076&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28076.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28076/head:pull/28076

PR: https://git.openjdk.org/jdk/pull/28076

From asemenyuk at openjdk.org  Thu Oct 30 23:21:03 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 Oct 2025 23:21:03 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Oct 2025 22:28:29 GMT, Alexander Matveev  wrote:

> so embedded runtime can act as standalone runtime

This can imply many things. I suggest more specific wording:

_If the embedded runtime contains executable(s) in the "bin" subdirectory, we should use the standalone runtime info plist template. Otherwise, the user may be unable to run the "java" or other executables in the "bin" subdirectory of the embedded runtime._

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28033#discussion_r2479760317

From almatvee at openjdk.org  Thu Oct 30 23:30:00 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 Oct 2025 23:30:00 GMT
Subject: RFR: 8363980: [macos] Add JDK specific keys/values to Info.plist
 of embedded runtime
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 04:07:14 GMT, Alexey Semenyuk  wrote:

> Why? jpackage picks the same file from the resource directory regardless of whether the "bin" subdirectory is present in the runtime. The "bin" subdirectory in the runtime only affects the default plist resource that jpackage uses.

Not sure. I agree we should not mix testing this fix with `CustomInfoPListTest`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28033#issuecomment-3470698014

From bpb at openjdk.org  Thu Oct 30 23:47:16 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 30 Oct 2025 23:47:16 GMT
Subject: RFR: 8367943: PipedOutputStream write(0, 0) successful after close()
Message-ID: 

Update the specification of `java.io.PipedOutputStream.write(byte[],int,int)` to match longstanding behavior. Add a verification to an existing test.

-------------

Commit messages:
 - 8367943: PipedOutputStream write(0, 0) successful after close()

Changes: https://git.openjdk.org/jdk/pull/28078/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28078&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367943
  Stats: 19 lines in 2 files changed: 8 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28078.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28078/head:pull/28078

PR: https://git.openjdk.org/jdk/pull/28078

From liach at openjdk.org  Fri Oct 31 00:06:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Oct 2025 00:06:34 GMT
Subject: RFR: 8370976: Review the behavioral changes of core reflection
 descriptor parsing migration
Message-ID: 

There were a few other holes in the recent migration of BytecodeDescriptor, most notably:

1. BytecodeDescriptor is missing checks for `.`, `[` characters, leading, trailing, consecutive `/`, or empty name.
2. EnclosingMethod is only validated by hotspot to carry either field or method type. We still need to check for field types

I have written up the behavioral changes in the CSR. In addition, I have added a few more tests to ensure the failure case behaviors of the migrated use sites.

-------------

Commit messages:
 - Desc parse migration problems

Changes: https://git.openjdk.org/jdk/pull/28079/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28079&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370976
  Stats: 152 lines in 7 files changed: 115 ins; 15 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/28079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28079/head:pull/28079

PR: https://git.openjdk.org/jdk/pull/28079

From liach at openjdk.org  Fri Oct 31 00:16:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Oct 2025 00:16:02 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 22:47:41 GMT, Jorn Vernee  wrote:

>> See the JBS issue for a problem description.
>> 
>> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
>> 
>> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
>> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
>> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
>> 3. Any other Java code that runs as part of the linking process.
>> 
>> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
>> 
>> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update bug number in tests
>   
>   Co-authored-by: Chen Liang 

Lgtm, thanks! @mcimadamore might want to check too.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27919#pullrequestreview-3402130962

From archie.cobbs at gmail.com  Fri Oct 31 02:33:18 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 30 Oct 2025 21:33:18 -0500
Subject: InputStream/OutputStream concurrency guarantees
In-Reply-To: 
References: 
 
 
 
 <5848207d-a5f7-48c8-81c8-826de122af48@oracle.com>
 
 
 
Message-ID: 

On Thu, Oct 30, 2025 at 4:39?PM Florian Weimer  wrote:

> I'm trying to image in a way to get rid of the double buffering in
> FileInputStream/FileOutputStream: have the kernel access the heap
> directly, instead of a copy.


Wasn't that one of the goals of the NIO Channel API and direct ByteBuffers?

You've probably already considered that approach - if so I'm curious why it
doesn't work.

Also there is the new Foreign Function & Memory AP (JEP 454) which might
help.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From smarks at openjdk.org  Fri Oct 31 04:29:08 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 31 Oct 2025 04:29:08 GMT
Subject: RFR: 8368178: Add specialization of SequencedCollection methods to
 standard list factories [v5]
In-Reply-To: 
References: 
 
Message-ID: <_YhRQ8OUyQ_E6HJQ9SCofn3VvTVcf0iNcVZ0tI4pxfw=.216c2681-6374-40f7-bf95-0c68b1ecc563@github.com>

On Sat, 27 Sep 2025 05:51:00 GMT, Tagir F. Valeev  wrote:

>> Please review this small change. If you have more ideas which classes may miss specializations of SequencedCollection methods, I can add them to this PR as well.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move EmptyListTest, SingletonListTest cases to MOAT.java

Marked as reviewed by smarks (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27406#pullrequestreview-3402553530

From smarks at openjdk.org  Fri Oct 31 04:29:09 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 31 Oct 2025 04:29:09 GMT
Subject: RFR: 8368178: Add specialization of SequencedCollection methods to
 standard list factories [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 24 Oct 2025 13:40:49 GMT, Tagir F. Valeev  wrote:

>> OK, List12::getFirst and List12::getLast seem fine.
>> 
>> But yeah... AbstractImmutableList::reversed and List12::reversed are indeed debatable. I wrestled over this for a while. I don't think they're incorrect, but I'm also having trouble convincing myself they're cases worth optimizing. There are also weird tradeoffs.
>> 
>> With no override, calling reversed() on a List12 returns a ReverseOrderListView(orig) and reversed() on that returns orig again. But with the override, calling reversed() gives a new List12, and calling reversed() on that gives another new List12. Nothing here is really terrible, but it's also not clear to me this is an improvement.
>> 
>> With AbstractImmutableList I got kind of tangled up in analyzing where this would be used. It seems to me the optimization would take effect for the zero-size nulls-disallowed case, the zero-size nulls-allowed case, and the size-one nulls-allowed case. (The size-one nulls-disallowed case is covered by List12, unless we don't add the override there....) I don't think this is incorrect for any case, but I'm also having a hard time seeing the improvement. It might save the allocation of a small object, or it might save an indirection. And ... that's about it?
>> 
>> The reversed() overrides hardly seem worthwhile. Maybe don't include them.
>> 
>> Regarding the tests, is it necessary to add new test files for EmptyList and SingletonList? Maybe it's possible to add cases to test/jdk/java/util/Collection/MOAT.java. I'm also a bit surprised to see a new provider added to the ListFactories test. But I haven't looked too closely. If it's necessary, then of course we should include it.
>
> @stuart-marks a gentle ping: could you please review after the latest changes? Thank you in advance!

Hi @amaembo thanks for making the updates as I requested. They look good. I ran the changes through our internal testing system and the results are good too. Also, thanks for your patience!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27406#issuecomment-3471296861

From stuart.marks at oracle.com  Fri Oct 31 05:00:37 2025
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 30 Oct 2025 22:00:37 -0700
Subject: [External] : Re: Potential Thread-Safety Bug in XMLEntityManager
In-Reply-To: 
References: 
 <52c0a976-827f-426e-a849-b85a1dfe8dfe@oracle.com>
 
Message-ID: 

Hi yes, thanks for mentioning this.

In the context of API specifications, "immutable" often means that from the point of 
view of the public API, the state of the object cannot be observed to mutate. And 
yes it usually implies thread safety. Of course that's possible to achieve if none 
of the object's fields are mutated, but it's possible for such an object to have 
mutable fields. (String and BigInteger are examples of this.)

Unfortunately the CatalogImpl object is mutated to hold temporary state that's used 
during the resolution process. This temporary state doesn't really belong in the 
object itself, so it seems likely that a fix would involve refactoring this 
temporary state out of the Catalog itself into an object owned by some resolver 
object (or similar).

We'll take another look at the docs here to see if other updates are necessary.

s'marks

On 10/22/25 11:26 AM, Elliot Barlas wrote:
> Thanks, Stuart.
>
> Regarding specification, I noticed that the?javax.xml.catalog package summary[1] 
> indicates that "A Catalog object is immutable." Immutable typically indicates that 
> internal state cannot be changed and it implies thread-safety. It might be worth 
> clarifying the javadocs.
>
> [1] 
> https://docs.oracle.com/en/java/javase/25/docs/api/java.xml/javax/xml/catalog/package-summary.html
>
> On Tue, Oct 21, 2025 at 8:51?PM Stuart Marks  wrote:
>
>     Hi Elliot,
>
>     Yes, this is indeed a bug. It seems that most of the XML and JAXP APIs aren't
>     thread-safe and so must be used in a thread-confined manner. (Hm, I can't seem to
>     find anything in the specifications about this... another thing to look at.) Most
>     JAXP objects are constructed on demand. However, as you point out they end up
>     using
>     a shared CatalogImpl instance that represents the built-in JDK catalog. Since
>     catalog resolution mutates this object, it's a thread-safety issue.
>
>     I've filed
>
>     https://bugs.openjdk.org/browse/JDK-8370379
>
>     to cover this issue. Thanks for reporting it!
>
>     s'marks
>
>     On 10/14/25 3:07 PM, Elliot Barlas wrote:
>     > Hello core-libs-dev!
>     >
>     > There appears to be a thread-safety bug in
>     > com.sun.org.apache.xerces.internal.impl.XMLEntityManager related to the
>     > introduction of the following field[1] in the following commit[2].
>     >
>     > [1] CatalogResolver fDefCR // the default JDK Catalog Resolver
>     >
>     > [2]
>     https://github.com/openjdk/jdk/commit/93bdc2a6db91a95d6ee52ec92080e586c694dad5
>     
>     >
>     > Multiple threads executing the following sample code use the same underlying
>     > javax.xml.catalog.CatalogImpl obtained from
>     > JdkXmlConfig.getInstance().getJdkCatalog(). CatalogImpl is not thread safe. The
>     > resolveEntity method mutates the underlying JDK catalog[3].
>     >
>     > [3]
>     >
>     https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java#L279
>     
>     >
>     > XMLEntityManager entityManager = new XMLEntityManager();
>     > XMLResourceIdentifier resourceIdentifier = new XMLResourceIdentifierImpl(
>     > ? ? ? ? "http://example.com/dtd/sample.dtd
>     ",
>     > ? ? ? ? "sample.dtd",
>     > ? ? ? ? "http://example.com/base/
>     ",
>     > ? ? ? ? "http://example.com/base/sample.dtd
>     ");
>     > entityManager.resolveEntity(resourceIdentifier);
>     >
>     > Prior to the commit above, this code did not access a shared JDK CatalogImpl.
>     >
>     > -Elliot Barlas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tvaleev at openjdk.org  Fri Oct 31 05:37:12 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Fri, 31 Oct 2025 05:37:12 GMT
Subject: RFR: 8368178: Add specialization of SequencedCollection methods to
 standard list factories [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 31 Oct 2025 04:25:46 GMT, Stuart Marks  wrote:

>> @stuart-marks a gentle ping: could you please review after the latest changes? Thank you in advance!
>
> Hi @amaembo thanks for making the updates as I requested. They look good. I ran the changes through our internal testing system and the results are good too. Also, thanks for your patience!

@stuart-marks thank you for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27406#issuecomment-3471405738

From tvaleev at openjdk.org  Fri Oct 31 05:37:13 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Fri, 31 Oct 2025 05:37:13 GMT
Subject: Integrated: 8368178: Add specialization of SequencedCollection methods
 to standard list factories
In-Reply-To: 
References: 
Message-ID: <58SsX-zJTyd-ajHoeJmA6NMji_mYW1XvieHprMketYw=.3bc2baae-0c0a-4dda-836f-4b0d58c925e5@github.com>

On Sat, 20 Sep 2025 19:29:11 GMT, Tagir F. Valeev  wrote:

> Please review this small change. If you have more ideas which classes may miss specializations of SequencedCollection methods, I can add them to this PR as well.

This pull request has now been integrated.

Changeset: c6cc7a7b
Author:    Tagir F. Valeev 
URL:       https://git.openjdk.org/jdk/commit/c6cc7a7b2a45a892c4a5a7a24e1fdbc5f9325f4a
Stats:     71 lines in 5 files changed: 68 ins; 0 del; 3 mod

8368178: Add specialization of SequencedCollection methods to standard list factories

Reviewed-by: smarks

-------------

PR: https://git.openjdk.org/jdk/pull/27406

From stefank at openjdk.org  Fri Oct 31 07:21:01 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 31 Oct 2025 07:21:01 GMT
Subject: RFR: 8370975: Test
 runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java can still fail
 on macos 26
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 22:53:59 GMT, Ioi Lam  wrote:

> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines.
> 
> I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`.
> 
> I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case:
> 
> 
> if (forceBase >= end) {
>     throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test.");
> }

I'm skeptical to adding MULTILINE to all users of these regex functions. And with that said, something is fishy here. Why do you need to match over multiple lines? I see that the bug report makes it look like you have multiple lines, but the linked output from the test doesn't have them. Could you give a more comprehensive explanation what this solves?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3471601865

From stefank at openjdk.org  Fri Oct 31 07:36:05 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 31 Oct 2025 07:36:05 GMT
Subject: RFR: 8370975: Test
 runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java can still fail
 on macos 26
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 22:53:59 GMT, Ioi Lam  wrote:

> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines.
> 
> I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`.
> 
> I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case:
> 
> 
> if (forceBase >= end) {
>     throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test.");
> }

I now see that this is the way the OutputAnalyzer deals with all the other regex functions, so ignore my skepticism.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3471636863

From stefank at openjdk.org  Fri Oct 31 07:47:13 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 31 Oct 2025 07:47:13 GMT
Subject: RFR: 8370975: Test
 runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java can still fail
 on macos 26
In-Reply-To: 
References: 
Message-ID: <_bWgF8fr2vxQtytAarIQALhZS23ibbR5vVRH5kjNjyY=.98184bf6-621a-4fbf-9378-23950a962071@github.com>

On Thu, 30 Oct 2025 22:53:59 GMT, Ioi Lam  wrote:

> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines.
> 
> I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`.
> 
> I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case:
> 
> 
> if (forceBase >= end) {
>     throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test.");
> }

Changes requested by stefank (Reviewer).

test/lib/jdk/test/lib/process/OutputAnalyzer.java line 359:

> 357:     private boolean matchesHelper(String s, Pattern pattern) {
> 358:         return s != null && pattern.matcher(s).find();
> 359:     }

This function is named `matchesX` so why is it using `Matcher::find` instead of `Matcher::matches`? That seems confusing.

test/lib/jdk/test/lib/process/OutputAnalyzer.java line 364:

> 362:         Pattern pattern = Pattern.compile(regexp, Pattern.MULTILINE);
> 363:         return matchesHelper(stdout, pattern) || matchesHelper(stderr, pattern);
> 364:     }

I'd like to suggest that you don't hard-code `stdout` and `stderr` here and use something like this (with updated name as suggested above):
Suggestion:

    private boolean findIn(String regexp, String... strings) {
        Pattern pattern = Pattern.compile(regexp, Pattern.MULTILINE);
        for (String string : strings) {
            if (pattern.matcher(string).find()) {
                return true;
            }
        }

        return false;
    }


and then the code you have that looks like this:

return matchesHelper(getStdout(), null, regexp);

can get rid of the `null`:

return findIn(regexp, getStdout());

-------------

PR Review: https://git.openjdk.org/jdk/pull/28077#pullrequestreview-3402888668
PR Review Comment: https://git.openjdk.org/jdk/pull/28077#discussion_r2480391654
PR Review Comment: https://git.openjdk.org/jdk/pull/28077#discussion_r2480406005

From stefank at openjdk.org  Fri Oct 31 07:47:14 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 31 Oct 2025 07:47:14 GMT
Subject: RFR: 8370975: Test
 runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java can still fail
 on macos 26
In-Reply-To: <_bWgF8fr2vxQtytAarIQALhZS23ibbR5vVRH5kjNjyY=.98184bf6-621a-4fbf-9378-23950a962071@github.com>
References: 
 <_bWgF8fr2vxQtytAarIQALhZS23ibbR5vVRH5kjNjyY=.98184bf6-621a-4fbf-9378-23950a962071@github.com>
Message-ID: 

On Fri, 31 Oct 2025 07:35:18 GMT, Stefan Karlsson  wrote:

>> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines.
>> 
>> I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`.
>> 
>> I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case:
>> 
>> 
>> if (forceBase >= end) {
>>     throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test.");
>> }
>
> test/lib/jdk/test/lib/process/OutputAnalyzer.java line 359:
> 
>> 357:     private boolean matchesHelper(String s, Pattern pattern) {
>> 358:         return s != null && pattern.matcher(s).find();
>> 359:     }
> 
> This function is named `matchesX` so why is it using `Matcher::find` instead of `Matcher::matches`? That seems confusing.

If it truly is `find` you need, then I think you need to fix the names.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28077#discussion_r2480398463

From stefank at openjdk.org  Fri Oct 31 08:41:28 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 31 Oct 2025 08:41:28 GMT
Subject: RFR: 8370975: Test
 runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java can still fail
 on macos 26
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 22:53:59 GMT, Ioi Lam  wrote:

> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines.
> 
> I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`.
> 
> I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case:
> 
> 
> if (forceBase >= end) {
>     throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test.");
> }

I took a closer look at this and I think the crucial part is that we are using `find` and not the change to use `MULTILINE`. `MULTILINE` seems to only be needed if you want to use `^` and `$` in your regex.

I added some temporary test to OutputAnalyzerTest to show this:

    public static boolean findIn(String regex, String... strings) {
        Pattern pattern = Pattern.compile(regex, Pattern.MULTILINE);
        for (String string : strings) {
            if (pattern.matcher(string).find()) {
                return true;
            }
        }

        return false;
    }

    private static void testFindIn() {
        String stdout = "some stdout";
        String stderr = "A little dog\nThe small cat\nA small horse";
        
        check(findIn("little", stdout, stderr));
        
        // Does not work with matches() `.` doesn't matche newlines
        check(findIn(".*A little dog.*", stdout, stderr));
        check(findIn("A.*", stdout, stderr));
        check(findIn("T.*", stdout, stderr));
        check(findIn(".*cat", stdout, stderr));
        check(findIn(".*horse", stdout, stderr));
        check(!findIn("frog", stdout, stderr));
        
        // Does not require multi-line
        check(findIn("dog\nThe", stdout, stderr));

        // Requires MULTILINE
        check(findIn("^The small cat", stdout, stderr));
        check(findIn("The small cat$", stdout, stderr));
        check(findIn("^The small cat$", stdout, stderr));
    }

    private static void check(boolean b) {
        if (!b) {
            throw new RuntimeException("Check failed");
        }
    }


Now play around with changing the `find` to `matches` and/or removing `MULTILINE`.

So, I would prefer to see the following:
1) Fix the title to indicate that your updating the OutputAnalyzer
2) Fix the summary that states that MULTILINE is needed to match over newlines
3) Introduce the new "find" function (or rename matches)
4) Add tests
5) Preferably, use one RFE for the above enhancements and Bug for the test failure

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3471893950

From clanger at openjdk.org  Fri Oct 31 09:15:06 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 31 Oct 2025 09:15:06 GMT
Subject: RFR: 8370393: Cleanup handling of ancient Windows versions from
 GetJavaProperties java_props_md
In-Reply-To: 
References: 
Message-ID: <0rEalGPAtYOLRSbBp4EtjIrxI4I2LlZd4zi7CzpPvvk=.66afebe7-4961-4bc1-84e9-38a73b6f1ec3@github.com>

On Tue, 28 Oct 2025 15:05:14 GMT, Matthias Baesken  wrote:

> There are some ancient Windows versions still handled in GetJavaProperties :
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/windows/native/libjava/java_props_md.c#L456
> 
> We compile currently with Windows 8+ settings :
> 
> 
> # _WIN32_WINNT=0x0602 means access APIs for Windows 8 and above. See
> # https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170
> ALWAYS_DEFINES="-DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0602 \
> 
> 
> So everything older than Windows 8 could most likely be removed.

I guess this is ok now. But somebody from the platform libraries team should approve this as well.

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28022#pullrequestreview-3403200748

From pminborg at openjdk.org  Fri Oct 31 09:22:01 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 31 Oct 2025 09:22:01 GMT
Subject: RFR: 8370822: Improve performance for MemorySegment::fill
In-Reply-To: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
References: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
Message-ID: 

On Wed, 29 Oct 2025 00:01:57 GMT, Igor Rudenko  wrote:

> The manual byte-replication expression replaced with the multiplicative expansion trick - a more compact and efficient equivalent.

I ran some benchmarks and was unable to see any significant performance improvements. I ran on Linux (a64/x64), macOS a64, and Windows x64. Can you provide benchmarks that support this is a performance improvement?


| Benchmark | Linux aarch64 | Linux x64 | MacOSX aarch64 | ?Windows x64 |
| --- | --- | --- | --- | --- |
| openjdk.bench.java.lang.foreign.SegmentBulkFill.nativeSegmentFillJava-ELEM_SIZE:2 | -0.05% | -4.60% | -0.12% | -0.22% |
| openjdk.bench.java.lang.foreign.SegmentBulkFill.nativeSegmentFillJava-ELEM_SIZE:3 | -0.01% | -0.17% | -1.18% | 0.04% |
| openjdk.bench.java.lang.foreign.SegmentBulkFill.nativeSegmentFillJava-ELEM_SIZE:4 | -0.01% | 0.00% | -0.01% | 0.28% |
| openjdk.bench.java.lang.foreign.SegmentBulkFill.nativeSegmentFillJava-ELEM_SIZE:5 | 0.35% | -0.00% | 0.04% | 0.18% |
| openjdk.bench.java.lang.foreign.SegmentBulkFill.nativeSegmentFillJava-ELEM_SIZE:512 | -0.17% | -0.84% | 1.57% | -0.05% |
| openjdk.bench.java.lang.foreign.SegmentBulkFill.nativeSegmentFillJava-ELEM_SIZE:6 | 0.00% | 0.02% | -0.01% | 0.36% |
| openjdk.bench.java.lang.foreign.SegmentBulkFill.nativeSegmentFillJava-ELEM_SIZE:64 | -0.03% | -0.75% | -5.88% | -2.61% |
| openjdk.bench.java.lang.foreign.SegmentBulkFill.nativeSegmentFillJava-ELEM_SIZE:7 | -0.11% | -0.25% | -0.02% | 0.16% |
| openjdk.bench.java.lang.foreign.SegmentBulkFill.nativeSegmentFillJava-ELEM_SIZE:8 | -0.01% | -0.20% | -0.07% | ?0.15% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28031#issuecomment-3472046372

From cushon at openjdk.org  Fri Oct 31 10:10:07 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 31 Oct 2025 10:10:07 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Update length to code units instead of bytes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/cd6db90b..43a719eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=01-02

  Stats: 44 lines in 5 files changed: 8 ins; 9 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/28043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043

PR: https://git.openjdk.org/jdk/pull/28043

From cushon at openjdk.org  Fri Oct 31 10:10:10 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 31 Oct 2025 10:10:10 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 15:32:40 GMT, Jorn Vernee  wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update length to code units instead of bytes
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1349:
> 
>> 1347:      *         
        
>> 1348:      *             
      • {@code B} is the size, in bytes, of the string encoded using the
>> 1349:      *             provided charset (e.g. {@code str.getBytes(charset).length});
        • 
> 
> Isn't `B` equal to the `length` argument?

Thanks, yes, I reworked this part

> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1351:
> 
>> 1349:      *             provided charset (e.g. {@code str.getBytes(charset).length});
>> 1350:      *             
      • {@code N} is the size (in bytes) of the terminator char according
>> 1351:      *             to the provided charset. For instance, this is 1 for
> 
> Why is the terminator char important? The segment doesn't necessarily need to have a terminator char, right? I don't see this invariant being checked in the code either.

Thanks, it is not, I think this was left over from javadoc adapted from another overload

> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1363:
> 
>> 1361:      */
>> 1362:     String getString(long offset, int length, Charset charset);
>> 1363: 
> 
> I'd suggest putting the `length` parameter at the end, so that this becomes a telescoping overload of the length-less variant.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2480856010
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2480854556
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2480852695

From rgiulietti at openjdk.org  Fri Oct 31 13:35:05 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 31 Oct 2025 13:35:05 GMT
Subject: RFR: 8370150: Add StrictMath microbenchmarks to cover FDLIBM
 algorithms [v3]
In-Reply-To: 
References: <-zFdpTE0II7muIj0FtbT62bOtCWDDxJgQiOt65ehpZM=.37ddba8f-bb12-471c-8134-1e72c25f2fc2@github.com>
 
Message-ID: 

On Wed, 29 Oct 2025 22:58:28 GMT, Sergey Kuksenko  wrote:

>> Add StrictMath microbenchmarks to cover FDLIBM algorithms
>> 
>> The methods that require fdlibm semantics are sin, cos, tan, asin, acos, atan, exp, log, log10, cbrt, atan2, pow, sinh, cosh, tanh, hypot, expm1, and log1p.
>
> Sergey Kuksenko has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8370150' of github.com:kuksenko/jdk into JDK-8370150
>  - update after review

Marked as reviewed by rgiulietti (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27881#pullrequestreview-3404299747

From rriggs at openjdk.org  Fri Oct 31 14:00:08 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 31 Oct 2025 14:00:08 GMT
Subject: RFR: 8370393: Cleanup handling of ancient Windows versions from
 GetJavaProperties java_props_md
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 15:05:14 GMT, Matthias Baesken  wrote:

> There are some ancient Windows versions still handled in GetJavaProperties :
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/windows/native/libjava/java_props_md.c#L456
> 
> We compile currently with Windows 8+ settings :
> 
> 
> # _WIN32_WINNT=0x0602 means access APIs for Windows 8 and above. See
> # https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170
> ALWAYS_DEFINES="-DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0602 \
> 
> 
> So everything older than Windows 8 could most likely be removed.

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28022#pullrequestreview-3404430500

From skuksenko at openjdk.org  Fri Oct 31 14:04:34 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Fri, 31 Oct 2025 14:04:34 GMT
Subject: Integrated: 8370150: Add StrictMath microbenchmarks to cover FDLIBM
 algorithms
In-Reply-To: <-zFdpTE0II7muIj0FtbT62bOtCWDDxJgQiOt65ehpZM=.37ddba8f-bb12-471c-8134-1e72c25f2fc2@github.com>
References: <-zFdpTE0II7muIj0FtbT62bOtCWDDxJgQiOt65ehpZM=.37ddba8f-bb12-471c-8134-1e72c25f2fc2@github.com>
Message-ID: <8ACQ8h2j3UOoRGWLtB05qMFNVvvl9V3AWskxz8cfxc8=.568f4eb6-e3cd-41ce-8cde-70324e4790ac@github.com>

On Fri, 17 Oct 2025 22:37:47 GMT, Sergey Kuksenko  wrote:

> Add StrictMath microbenchmarks to cover FDLIBM algorithms
> 
> The methods that require fdlibm semantics are sin, cos, tan, asin, acos, atan, exp, log, log10, cbrt, atan2, pow, sinh, cosh, tanh, hypot, expm1, and log1p.

This pull request has now been integrated.

Changeset: 2158719a
Author:    Sergey Kuksenko 
URL:       https://git.openjdk.org/jdk/commit/2158719aab5f3ab652225113b5205070e9241995
Stats:     674 lines in 1 file changed: 674 ins; 0 del; 0 mod

8370150: Add StrictMath microbenchmarks to cover FDLIBM algorithms

Reviewed-by: rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/27881

From mbaesken at openjdk.org  Fri Oct 31 14:14:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 31 Oct 2025 14:14:17 GMT
Subject: RFR: 8370393: Cleanup handling of ancient Windows versions from
 GetJavaProperties java_props_md
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 15:05:14 GMT, Matthias Baesken  wrote:

> There are some ancient Windows versions still handled in GetJavaProperties :
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/windows/native/libjava/java_props_md.c#L456
> 
> We compile currently with Windows 8+ settings :
> 
> 
> # _WIN32_WINNT=0x0602 means access APIs for Windows 8 and above. See
> # https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170
> ALWAYS_DEFINES="-DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0602 \
> 
> 
> So everything older than Windows 8 could most likely be removed.

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28022#issuecomment-3473262842

From mbaesken at openjdk.org  Fri Oct 31 14:14:18 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 31 Oct 2025 14:14:18 GMT
Subject: Integrated: 8370393: Cleanup handling of ancient Windows versions from
 GetJavaProperties java_props_md
In-Reply-To: 
References: 
Message-ID: <3K6KGj04lF5t4XsNFHp-EOME0e1d4MOo8mAEiUGQ39M=.75bf6eb9-d6a7-4971-84b6-d6638226573d@github.com>

On Tue, 28 Oct 2025 15:05:14 GMT, Matthias Baesken  wrote:

> There are some ancient Windows versions still handled in GetJavaProperties :
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/windows/native/libjava/java_props_md.c#L456
> 
> We compile currently with Windows 8+ settings :
> 
> 
> # _WIN32_WINNT=0x0602 means access APIs for Windows 8 and above. See
> # https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170
> ALWAYS_DEFINES="-DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0602 \
> 
> 
> So everything older than Windows 8 could most likely be removed.

This pull request has now been integrated.

Changeset: 16dafc00
Author:    Matthias Baesken 
URL:       https://git.openjdk.org/jdk/commit/16dafc00eca8acb0fdabf2f373bb5f84bd293086
Stats:     54 lines in 1 file changed: 0 ins; 53 del; 1 mod

8370393: Cleanup handling of ancient Windows versions from GetJavaProperties java_props_md

Reviewed-by: clanger, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/28022

From rriggs at openjdk.org  Fri Oct 31 14:19:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 31 Oct 2025 14:19:04 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close()
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Oct 2025 23:41:07 GMT, Brian Burkhalter  wrote:

> Update the specification of `java.io.PipedOutputStream.write(byte[],int,int)` to match longstanding behavior. Add a verification to an existing test.

src/java.base/share/classes/java/io/PipedOutputStream.java line 141:

> 139:      * @throws  IOException if the pipe is  broken,
> 140:      *          {@link #connect(java.io.PipedInputStream) unconnected},
> 141:      *          closed and {@code len} is positive,

Though "positive" is correct, fewer people will be puzzled if you say `len is greater than zero`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28078#discussion_r2481583992

From duke at openjdk.org  Fri Oct 31 14:20:02 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Fri, 31 Oct 2025 14:20:02 GMT
Subject: RFR: 8370822: Improve performance for MemorySegment::fill
In-Reply-To: 
References: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
 
Message-ID: <2A-ofcjn4kSgKunle_MB2pR-2s3lH4TrAF9z9kWznUc=.17efcc4f-f9c1-4bca-a5d2-1ee0f199fb8b@github.com>

On Fri, 31 Oct 2025 09:15:18 GMT, Per Minborg  wrote:

> I ran some benchmarks and was unable to see any significant performance improvements. I ran on Linux (a64/x64), macOS a64, and Windows x64. Can you provide benchmarks that support this is a performance improvement?

Hello Per-Ake,

I explored the corresponding code using JITWatch. My analysis shows that the patch reduces the number of instructions (in both bytecode and JIT-compiled assembly). However, as your benchmarks demonstrate, this does not lead to measurable overall performance improvement, the differences fall within normal noise.

So, the idea for the patch may be clarity and maintainability, as it simplifies and shortens the code.

Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28031#issuecomment-3473299353

From rriggs at openjdk.org  Fri Oct 31 14:32:24 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 31 Oct 2025 14:32:24 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v26]
In-Reply-To: 
References: 
Message-ID: <4y_Uc6Qjvh_VmJwj8V3Q_0RiNvJUyFEXk8l_5mg-2Cw=.bbf52699-28aa-4cd0-8fd8-a5a9bc6fd601@github.com>

> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
> 
> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
> 
> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.

Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:

 - Correct reference to ProcessExamples.java to use the `file` tag.
 - Miscellaneous javadoc improvements suggested by reviewers.
   Updated the example program to be a standalone program as might be run
   as a compact source file main program.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26649/files
  - new: https://git.openjdk.org/jdk/pull/26649/files/a1bcf5ac..58176c88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=24-25

  Stats: 18 lines in 2 files changed: 0 ins; 3 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26649/head:pull/26649

PR: https://git.openjdk.org/jdk/pull/26649

From prappo at openjdk.org  Fri Oct 31 14:45:29 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 31 Oct 2025 14:45:29 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v26]
In-Reply-To: <4y_Uc6Qjvh_VmJwj8V3Q_0RiNvJUyFEXk8l_5mg-2Cw=.bbf52699-28aa-4cd0-8fd8-a5a9bc6fd601@github.com>
References: 
 <4y_Uc6Qjvh_VmJwj8V3Q_0RiNvJUyFEXk8l_5mg-2Cw=.bbf52699-28aa-4cd0-8fd8-a5a9bc6fd601@github.com>
Message-ID: 

On Fri, 31 Oct 2025 14:32:24 GMT, Roger Riggs  wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Correct reference to ProcessExamples.java to use the `file` tag.
>  - Miscellaneous javadoc improvements suggested by reviewers.
>    Updated the example program to be a standalone program as might be run
>    as a compact source file main program.

Looks really good. Below nits are just that -- nits, and are optional. Thanks for your perseverance.

src/java.base/share/classes/java/lang/Process.java line 130:

> 128:  * Processes that have terminated or been terminated are monitored and their resources released.
> 129:  *
> 130:  * 
        Streams should be closed when they are no longer needed, to avoid delaying

Since there's no way to link to `Reader.close`, `Writer.close`, `InputStream.close` and `OutputStream.close` at the same time, consider linking to some of those from `@see` tags.

src/java.base/share/classes/java/lang/snippet-files/ProcessExamples.java line 36:

> 34:             // Read all lines and print each
> 35:             reader.readAllLines()
> 36:                     .forEach(IO::println);

Using `IO` instead of `System.out` in this particular case is an extra touch; I like it!

-------------

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26649#pullrequestreview-3404603961
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2481654961
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2481645906

From pminborg at openjdk.org  Fri Oct 31 15:09:26 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 31 Oct 2025 15:09:26 GMT
Subject: RFR: 8370822: Improve performance for MemorySegment::fill
In-Reply-To: <2A-ofcjn4kSgKunle_MB2pR-2s3lH4TrAF9z9kWznUc=.17efcc4f-f9c1-4bca-a5d2-1ee0f199fb8b@github.com>
References: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
 
 <2A-ofcjn4kSgKunle_MB2pR-2s3lH4TrAF9z9kWznUc=.17efcc4f-f9c1-4bca-a5d2-1ee0f199fb8b@github.com>
Message-ID: 

On Fri, 31 Oct 2025 14:17:29 GMT, Igor Rudenko  wrote:

> Hello Per-Ake,
> 
> I explored the corresponding code using JITWatch. My analysis shows that the patch reduces the number of instructions (in both bytecode and JIT-compiled assembly). However, as your benchmarks demonstrate, this does not lead to measurable overall performance improvement, the differences fall within normal noise.
> 
> So, the idea for the patch may be clarity and maintainability, as it simplifies and shortens the code.
> 
> Thanks.

Interesting observation. I think reducing bytecode is also important. Are you able to share some JIT-compiled assembly before/after?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28031#issuecomment-3473498832

From archie.cobbs at gmail.com  Fri Oct 31 15:26:56 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 31 Oct 2025 10:26:56 -0500
Subject: [External] : Re: Potential Thread-Safety Bug in XMLEntityManager
In-Reply-To: 
References: 
 <52c0a976-827f-426e-a849-b85a1dfe8dfe@oracle.com>
 
 
Message-ID: 

On Fri, Oct 31, 2025 at 12:01?AM Stuart Marks 
wrote:

> Unfortunately the CatalogImpl object is mutated to hold temporary state
> that's used during the resolution process. This temporary state doesn't
> really belong in the object itself, so it seems likely that a fix would
> involve refactoring this temporary state out of the Catalog itself into an
> object owned by some resolver object (or similar).
>
This reminds me of a similar situation with the XML DOM classes like
org.w3c.dom.Element: instances are not thread safe even if the threads are
only accessing them read-only. This was surprising to me to discover at the
time.

Be careful out there! :)

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pavel.rappo at gmail.com  Fri Oct 31 15:38:31 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Fri, 31 Oct 2025 15:38:31 +0000
Subject: [External] : Re: Potential Thread-Safety Bug in XMLEntityManager
In-Reply-To: 
References: 
 <52c0a976-827f-426e-a849-b85a1dfe8dfe@oracle.com>
 
 
 
Message-ID: 

On Fri, Oct 31, 2025 at 3:27?PM Archie Cobbs  wrote:
> 
> Be careful out there! :)

A very Halloween-y thing to say!

-Pavel

From duke at openjdk.org  Fri Oct 31 16:13:35 2025
From: duke at openjdk.org (Igor Rudenko)
Date: Fri, 31 Oct 2025 16:13:35 GMT
Subject: RFR: 8370822: Improve performance for MemorySegment::fill
In-Reply-To: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
References: <9BpPIGSWx8o0alx0Y2UVFa6m_BeHKKw3GAs-mdZbYG4=.6c6bfe52-b6e8-42e3-bc51-b499c22e6e48@github.com>
Message-ID: <5vKlNQaNHB4KEQpjt1eWqRtSEcWOA_nyBmMSSdwFjss=.e4b9b1ba-870d-4785-8b5a-41fc8b216906@github.com>

On Wed, 29 Oct 2025 00:01:57 GMT, Igor Rudenko  wrote:

> The manual byte-replication expression replaced with the multiplicative expansion trick - a more compact and efficient equivalent.

Here is syntactic example 

Before
before

After
after

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28031#issuecomment-3473794663

From bpb at openjdk.org  Fri Oct 31 16:27:58 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 31 Oct 2025 16:27:58 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close() [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Oct 2025 14:16:47 GMT, Roger Riggs  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8367943: positive -> greater than zero
>
> src/java.base/share/classes/java/io/PipedOutputStream.java line 141:
> 
>> 139:      * @throws  IOException if the pipe is  broken,
>> 140:      *          {@link #connect(java.io.PipedInputStream) unconnected},
>> 141:      *          closed and {@code len} is positive,
> 
> Though "positive" is correct, fewer people will be puzzled if you say `len is greater than zero`.

So changed in commit [06f0a11](https://github.com/openjdk/jdk/pull/28078/commits/06f0a11a41ecc9a7d27f742218f03f153bb3c58b).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28078#discussion_r2482001473

From bpb at openjdk.org  Fri Oct 31 16:27:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 31 Oct 2025 16:27:57 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close() [v2]
In-Reply-To: 
References: 
Message-ID: 

> Update the specification of `java.io.PipedOutputStream.write(byte[],int,int)` to match longstanding behavior. Add a verification to an existing test.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8367943: positive -> greater than zero

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28078/files
  - new: https://git.openjdk.org/jdk/pull/28078/files/655d0e6e..06f0a11a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28078&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28078&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28078.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28078/head:pull/28078

PR: https://git.openjdk.org/jdk/pull/28078

From darcy at openjdk.org  Fri Oct 31 16:33:03 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 Oct 2025 16:33:03 GMT
Subject: RFR: 8370983: Add methods for primitive operators to support
 method handles
In-Reply-To: 
References: 
Message-ID: <3HS1abS6C2U8_ozRfP7ZjwTH7_r7FPzspu1VLC17qgs=.3f5d577b-1e73-451c-bc40-fe6999bfdb36@github.com>

On Fri, 31 Oct 2025 04:55:31 GMT, Joe Darcy  wrote:

> Initial draft of a partial set of methods wrapping primitive operators to get feedback on the class providing this functionality.

If this work goes forward, analagous methods for the long and double types would be added.

For testing, for each method, I was thinking to compare the operation of the method as a method reference to a lambda with the intended functionality over a set of inputs. This would help guard against any typos in constructing the simple methods. For example, a set of int values like {Integer.MAX_VALUE, -3, -1, 0, 1, 2, 10, Integer.MAX_VALUE} would be able to discriminate between {+, -, *, /}, etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28081#issuecomment-3471342812

From darcy at openjdk.org  Fri Oct 31 16:33:02 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 Oct 2025 16:33:02 GMT
Subject: RFR: 8370983: Add methods for primitive operators to support method
 handles
Message-ID: 

Initial draft of a partial set of methods wrapping primitive operators to get feedback on the class providing this functionality.

-------------

Commit messages:
 - Appease jcheck.
 - JDK-8370983: Add methods for primiative operators to support method handles

Changes: https://git.openjdk.org/jdk/pull/28081/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28081&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370983
  Stats: 699 lines in 1 file changed: 699 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28081/head:pull/28081

PR: https://git.openjdk.org/jdk/pull/28081

From rriggs at openjdk.org  Fri Oct 31 16:35:22 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 31 Oct 2025 16:35:22 GMT
Subject: RFR: 8367943: PipedOutputStream write(0,
 0) successful after close() [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Oct 2025 16:27:57 GMT, Brian Burkhalter  wrote:

>> Update the specification of `java.io.PipedOutputStream.write(byte[],int,int)` to match longstanding behavior. Add a verification to an existing test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367943: positive -> greater than zero

looks good.
(Needs a CSR I think)

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28078#pullrequestreview-3405113343

From bpb at openjdk.org  Fri Oct 31 16:37:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 31 Oct 2025 16:37:07 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v12]
In-Reply-To: 
References: 
Message-ID: 

> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355342: Fix call to wcanonicalize in JDK_Canonicalize; clean up code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27324/files
  - new: https://git.openjdk.org/jdk/pull/27324/files/4c58055f..624f2c80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=10-11

  Stats: 38 lines in 3 files changed: 5 ins; 28 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27324/head:pull/27324

PR: https://git.openjdk.org/jdk/pull/27324

From hgreule at openjdk.org  Fri Oct 31 16:45:17 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Fri, 31 Oct 2025 16:45:17 GMT
Subject: RFR: 8370983: Add methods for primitive operators to support
 method handles
In-Reply-To: 
References: 
Message-ID: <91jUJqz_ebfc_x_1FQBpaJKCmIjN9dl2rAKiU2qofjQ=.a041015f-68b6-465c-b480-23c1214d8e98@github.com>

On Fri, 31 Oct 2025 04:55:31 GMT, Joe Darcy  wrote:

> Initial draft of a partial set of methods wrapping primitive operators to get feedback on the class providing this functionality.

I definitely like to see easier ways to construct method handles for specific operators, mainly the mathematical ones.

Some you've currently included are already present in `MethodHandles`, e.g., `arrayElementGetter` and `arrayElementSetter` for the array store and load bytecodes. `throwException` exists as well. You could also argue that `zero(void.class)` can be used as a nop.

The increment and decrement bytecodes are also somewhat weird, because you can't really observe them this way.

The conversion opcodes (x2y) can also be represented using `identity(x)` + `asType((x)y)`, but more explicit representation of that might be interesting.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28081#issuecomment-3473950733

From swen at openjdk.org  Fri Oct 31 16:55:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 31 Oct 2025 16:55:43 GMT
Subject: RFR: 8370983: Add methods for primitive operators to support
 method handles
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Oct 2025 04:55:31 GMT, Joe Darcy  wrote:

> Initial draft of a partial set of methods wrapping primitive operators to get feedback on the class providing this functionality.

src/java.base/share/classes/java/lang/invoke/Operators.java line 73:

> 71:      *
> 72:      * @implSpec
> 73:      * This method wraps the {@code <} operator on {@code int} augments.

Suggestion:

     * This method wraps the {@code <} operator on {@code int} arguments.

typo

src/java.base/share/classes/java/lang/invoke/Operators.java line 219:

> 217:      * @param subtrahend the second operand
> 218:      */
> 219:     public static int substract(int minuend, int subtrahend) {return minuend - subtrahend;}

Suggestion:

    public static int subtract(int minuend, int subtrahend) {return minuend - subtrahend;}

src/java.base/share/classes/java/lang/invoke/Operators.java line 231:

> 229:      * @param a the operand
> 230:      */
> 231:     public static int increment(int a) {return a++;}

Suggestion:

    public static int increment(int a) {return ++a;}

src/java.base/share/classes/java/lang/invoke/Operators.java line 241:

> 239:      * @param a the operand
> 240:      */
> 241:     public static int decrement(int a) {return a--;}

Suggestion:

    public static int decrement(int a) {return --a;}

src/java.base/share/classes/java/lang/invoke/Operators.java line 698:

> 696:      * This method corresponds to the {@code nop} JVM instruction.
> 697:      */
> 698:     public void nop() {return;}

Suggestion:

    public static void nop() {return;}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28081#discussion_r2482094079
PR Review Comment: https://git.openjdk.org/jdk/pull/28081#discussion_r2482099634
PR Review Comment: https://git.openjdk.org/jdk/pull/28081#discussion_r2482091037
PR Review Comment: https://git.openjdk.org/jdk/pull/28081#discussion_r2482091703
PR Review Comment: https://git.openjdk.org/jdk/pull/28081#discussion_r2482101678

From alanb at openjdk.org  Fri Oct 31 18:19:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Oct 2025 18:19:07 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Oct 2025 16:37:07 GMT, Brian Burkhalter  wrote:

>> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355342: Fix call to wcanonicalize in JDK_Canonicalize; clean up code

src/java.base/windows/native/libjava/WinNTFileSystem_md.c line 62:

> 60: /* -- Path operations -- */
> 61: 
> 62: extern WCHAR* wcanonicalize(const WCHAR *path, WCHAR *out, int len);

The first parameter here is `const WCHAR*` but `WCHAR*` in canoncailize_md.c, can you check that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27324#discussion_r2482310239

From rriggs at openjdk.org  Fri Oct 31 18:33:19 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 31 Oct 2025 18:33:19 GMT
Subject: RFR: 8364361: [process] java.lang.Process should implement
 Closeable [v26]
In-Reply-To: <4y_Uc6Qjvh_VmJwj8V3Q_0RiNvJUyFEXk8l_5mg-2Cw=.bbf52699-28aa-4cd0-8fd8-a5a9bc6fd601@github.com>
References: 
 <4y_Uc6Qjvh_VmJwj8V3Q_0RiNvJUyFEXk8l_5mg-2Cw=.bbf52699-28aa-4cd0-8fd8-a5a9bc6fd601@github.com>
Message-ID: 

On Fri, 31 Oct 2025 14:32:24 GMT, Roger Riggs  wrote:

>> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated.
>> 
>> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources.
>> 
>> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated.
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Correct reference to ProcessExamples.java to use the `file` tag.
>  - Miscellaneous javadoc improvements suggested by reviewers.
>    Updated the example program to be a standalone program as might be run
>    as a compact source file main program.

The javadoc and implementation and CSR have stabilized.  Will integrate in a day or so.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26649#issuecomment-3474357578

From bpb at openjdk.org  Fri Oct 31 18:38:40 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 31 Oct 2025 18:38:40 GMT
Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on
 network drives to UNC format [v13]
In-Reply-To: 
References: 
Message-ID: 

> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355342: Clean up "const" usages

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27324/files
  - new: https://git.openjdk.org/jdk/pull/27324/files/624f2c80..14f91a36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=11-12

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27324/head:pull/27324

PR: https://git.openjdk.org/jdk/pull/27324

From asemenyuk at openjdk.org  Fri Oct 31 19:04:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 31 Oct 2025 19:04:55 GMT
Subject: RFR: 8371076: jpackage will wrongly overwrite the plist file in the
 embedded runtime when executed with the "--app-image" option
Message-ID: 

- Fix MacPackagingPipeline.
- Fix AppImageSigner: this is the follow-up for MacPackagingPipeline fix. Without fixing AppImageSigner AppImagePackageTest.testEmpty test fails. It happened that the test passed because jpackage wrongly created the plist file for the embedded runtime in the case of the predefined app image. The test passed because of the bug in jpackage fixed in this PR.
- Add test cases for predefined app image packaging to the CustomInfoPListTest test. They had been failing before MacPackagingPipeline was fixed.

Supplementary changes:
 - Get rid of duplicated `createInputRuntimeImage()` and `createRuntimeBundle()` functions.
 - Improve `MacHelper.writeFaPListFragment()` to work with a predefined app image.
 - Add optional tracing to the packaging pipeline (turned off by default, must edit static fields to enable in custom builds).
 - PListReader: add find methods that return an Optional instead of throwing an exception when the requested key is not found; update unit tests.

-------------

Commit messages:
 - MacPackagingPipeline: fix the issue with writing info plist file for the embedded runtime when bundling predefined app image; AppImageSigner: should not attempt to sign embedded runtime bundle if it is not valid (missing). AppImagePackageTest.testEmpty test fails unless AppImageSigner is fixed.
 - CustomInfoPListTest: better test coverage; shorten test case names
 - RuntimePackageTest, SigningRuntimeImagePackageTest: use JPackageCommand.createInputRuntimeImage() and MacHelper.createRuntimeBundle()
 - MacHelper: add createRuntimeBundle(); make writeFaPListFragment() work with a predefined app image.
 - PackagingPipeline: add debug capabilities
 - JPackageCommand: fix setDefaultAppName(); remove redundant "throws IOException" from createInputRuntimeImage()
 - XmlUtils: rename mergeXmls() into concatXml(); WixLauncherAsService: follow-up change.
 - PListReader: add find methods that return an Optional instead of throwing an exception when the requested key is not found; add toXmlConsumer(); update unit tests.

Changes: https://git.openjdk.org/jdk/pull/28089/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28089&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371076
  Stats: 519 lines in 12 files changed: 274 ins; 118 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/28089.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28089/head:pull/28089

PR: https://git.openjdk.org/jdk/pull/28089

From asemenyuk at openjdk.org  Fri Oct 31 19:16:21 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 31 Oct 2025 19:16:21 GMT
Subject: RFR: 8371076: jpackage will wrongly overwrite the plist file in
 the embedded runtime when executed with the "--app-image" option
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Oct 2025 16:51:45 GMT, Alexey Semenyuk  wrote:

> - Fix MacPackagingPipeline.
> - Fix AppImageSigner: this is the follow-up for MacPackagingPipeline fix. Without fixing AppImageSigner AppImagePackageTest.testEmpty test fails. It happened that the test passed because jpackage wrongly created the plist file for the embedded runtime in the case of the predefined app image. The test passed because of the bug in jpackage fixed in this PR.
> - Add test cases for predefined app image packaging to the CustomInfoPListTest test. They had been failing before MacPackagingPipeline was fixed.
> 
> Supplementary changes:
>  - Get rid of duplicated `createInputRuntimeImage()` and `createRuntimeBundle()` functions.
>  - Improve `MacHelper.writeFaPListFragment()` to work with a predefined app image.
>  - Add optional tracing to the packaging pipeline (turned off by default, must edit static fields to enable in custom builds).
>  - PListReader: add find methods that return an Optional instead of throwing an exception when the requested key is not found; update unit tests.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28089#issuecomment-3474567168

From darcy at openjdk.org  Fri Oct 31 20:59:40 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 Oct 2025 20:59:40 GMT
Subject: RFR: 8370983: Add methods for primitive operators to support
 method handles [v2]
In-Reply-To: 
References: 
Message-ID: 

> Initial draft of a partial set of methods wrapping primitive operators to get feedback on the class providing this functionality.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback, fix typos, etc.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28081/files
  - new: https://git.openjdk.org/jdk/pull/28081/files/f4c58d81..ed7abf69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28081&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28081&range=00-01

  Stats: 95 lines in 1 file changed: 3 ins; 0 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/28081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28081/head:pull/28081

PR: https://git.openjdk.org/jdk/pull/28081

From darcy at openjdk.org  Fri Oct 31 20:59:40 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 Oct 2025 20:59:40 GMT
Subject: RFR: 8370983: Add methods for primitive operators to support
 method handles
In-Reply-To: <91jUJqz_ebfc_x_1FQBpaJKCmIjN9dl2rAKiU2qofjQ=.a041015f-68b6-465c-b480-23c1214d8e98@github.com>
References: 
 <91jUJqz_ebfc_x_1FQBpaJKCmIjN9dl2rAKiU2qofjQ=.a041015f-68b6-465c-b480-23c1214d8e98@github.com>
Message-ID: 

On Fri, 31 Oct 2025 16:42:37 GMT, Hannes Greule  wrote:

> I definitely like to see easier ways to construct method handles for specific operators, mainly the mathematical ones.
> 
> Some you've currently included are already present in `MethodHandles`, e.g., `arrayElementGetter` and `arrayElementSetter` for the array store and load bytecodes. `throwException` exists as well. You could also argue that `zero(void.class)` can be used as a nop.
> 
> The increment and decrement bytecodes are also somewhat weird, because you can't really observe them this way.
> 
> The conversion opcodes (x2y) can also be represented using `identity(x)` + `asType((x)y)`, but more explicit representation of that might be interesting.

Hmm. I do expect a few iterations on this PR before the set of operations/methods converges. I've added links to related elements in `MethodHandles` thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28081#issuecomment-3474878695

From asemenyuk at openjdk.org  Fri Oct 31 21:55:27 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 31 Oct 2025 21:55:27 GMT
Subject: RFR: 8371076: jpackage will wrongly overwrite the plist file in
 the embedded runtime when executed with the "--app-image" option [v2]
In-Reply-To: 
References: 
Message-ID: 

> - Fix MacPackagingPipeline.
> - Fix AppImageSigner: this is the follow-up for MacPackagingPipeline fix. Without fixing AppImageSigner AppImagePackageTest.testEmpty test fails. It happened that the test passed because jpackage wrongly created the plist file for the embedded runtime in the case of the predefined app image. The test passed because of the bug in jpackage fixed in this PR.
> - Add test cases for predefined app image packaging to the CustomInfoPListTest test. They had been failing before MacPackagingPipeline was fixed.
> 
> Supplementary changes:
>  - Get rid of duplicated `createInputRuntimeImage()` and `createRuntimeBundle()` functions.
>  - Improve `MacHelper.writeFaPListFragment()` to work with a predefined app image.
>  - Add optional tracing to the packaging pipeline (turned off by default, must edit static fields to enable in custom builds).
>  - PListReader: add find methods that return an Optional instead of throwing an exception when the requested key is not found; update unit tests.

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - CustomInfoPListTest: use Slot class
 - Add Slot utility class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28089/files
  - new: https://git.openjdk.org/jdk/pull/28089/files/746a2220..494adc56

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28089&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28089&range=00-01

  Stats: 59 lines in 2 files changed: 47 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/28089.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28089/head:pull/28089

PR: https://git.openjdk.org/jdk/pull/28089

From liach at openjdk.org  Fri Oct 31 22:18:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Oct 2025 22:18:02 GMT
Subject: RFR: 8370983: Add methods for primitive operators to support
 method handles [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Oct 2025 20:59:40 GMT, Joe Darcy  wrote:

>> Initial draft of a partial set of methods wrapping primitive operators to get feedback on the class providing this functionality.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback, fix typos, etc.

I strongly oppose adding operators corresponding to individual instructions. They are not the best primitive operations, and using them as methods in method handles may suffer the same problem as Objects::equals performance drop due to lack of dedicated separate profile due to shared bytecode.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28081#issuecomment-3475053182

From alexey.semenyuk at oracle.com  Mon Oct 27 20:05:44 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 27 Oct 2025 16:05:44 -0400
Subject: [External] : Re: [jpackage] Windows 11 25H2 ignores the
 win-menu-group option
In-Reply-To: 
References: 
 <9c931768-299e-4fa6-9b18-0cf3ee4ff4fe@oracle.com>
 
 
 
Message-ID: 

Hi Davide,

I'm not 100% sure, but the category can be assigned only for apps in the 
app store.

- Alexey

On 10/27/2025 3:30 PM, Davide Perini wrote:
>
> Hi Alexey,
> |--win-menu-group| works as you described.
>
> I thought that option could be used to place my app in the right 
> Windows category.
>
>
>
>
>
> Is there a way to tell |jpackage| to put my app in the /Entertainment/ 
> category?
> Possibly by using a |.wxs| file?
>
>
>
> Il 27/10/2025 18:19, Alexey Semenyuk ha scritto:
>> Hi Davide,
>>
>> --win-menu-group option controls a subdirectory in Windows Start Menu 
>> directory where to install links to application launchers.
>>
>> In case of system-wide installation, the full path to the directory 
>> with application launchers is:
>> %ProgramData%\Microsoft\Windows\Start Menu\Programs\
>>
>> In case of per-user installation the full path to the directory with 
>> application launchers is:
>> %AppData%\Microsoft\Windows\Start Menu\Programs\
>>
>> Say, the value of --win-menu-group is "Entertainment", then in the 
>> standard Windows installation, the directories will be:
>> C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Entertainment
>> C:\Users\\AppData\Roaming\Microsoft\Windows\Start 
>> Menu\Programs\Entertainment
>>
>> There are automated tests to verify that jpackage behaves as 
>> described above. They are part of the JDK build. I also ran manual 
>> testing and it works as expected.
>>
>> - Alexey
>>
>> On 10/23/2025 11:07 AM, Davide Perini wrote:
>>>
>>> Hi Alexey,
>>>
>>> thanks for the answer.
>>>
>>> I'm using the latest from
>>> Temurin (25.0.0+36-LTS)
>>>
>>> I have tried the latest 25 from Zulu and same problem.
>>>
>>> Thanks
>>> Davide
>>>
>>> On 2025-10-23 13:56, Alexey Semenyuk wrote:
>>>
>>>> Hi?Davide,
>>>>
>>>> It?looks?like?a?jpackage?issue.?What?version?of?jpackage?do?you?use?
>>>>
>>>> -?Alexey
>>>>
>>>> On?10/23/2025?6:23?AM,?Davide?Perini?wrote:
>>>>> Hi?there,
>>>>> I'm?using?Jpackage?with?a?command?like?this:
>>>>>
>>>>> jpackage?-i?target?--type?exe?--resource-dir?build_tools/wix?\
>>>>> --main-class?org.dpsoftware.JavaFXStarter?\
>>>>> --main-jar?FireflyLuciferin-jar-with-dependencies.jar?\
>>>>> --icon?data/img/java_fast_screen_capture_logo.ico?\
>>>>> --win-menu?\
>>>>> --win-menu-group?Entertainment?\
>>>>> --win-shortcut?\
>>>>> --win-shortcut-prompt?\
>>>>> --win-dir-chooser?\
>>>>> --win-upgrade-uuid?myid?\
>>>>> --copyright?"Davide?Perini"?\
>>>>> --name?"Firefly?Luciferin"?\
>>>>> --vendor?DPsoftware?\
>>>>> --app-version?"2.0.0"?\
>>>>> --java-options "-XX:+UseZGC -XX:+UseStringDeduplication -Xms64m 
>>>>> -Xmx1024m \
>>>>> --add-modules=jdk.incubator.vector 
>>>>> --enable-native-access=org.dpsoftware \
>>>>> --enable-native-access=ALL-UNNAMED?--enable-native-access=com.sun.jna?\
>>>>> --enable-native-access=javafx.graphics 
>>>>> --enable-native-access=javafx.web \
>>>>> --enable-native-access=com.fazecast.jSerialComm"
>>>>>
>>>>>
>>>>> My?main.wxs?file?can?be?found?here:
>>>>> https://github.com/sblantipodi/build_tools/blob/4f99c29440d27f3ff800d2cf2698f80433bce64c/wix/main.wxs 
>>>>>  
>>>>> It?s the default one generated by jpackage, with a small 
>>>>> modification that adds a checkbox to launch the app after 
>>>>> installation.
>>>>>
>>>>> As?you?can?see,?the?--win-menu-group?is?set?to?"Entertainment",
>>>>> but on Windows 11 25H2, my app still appears under the "Other" 
>>>>> category in the Start menu.
>>>>>
>>>>> Is?this?a?jpackage?issue?
>>>>>
>>>>> Thanks
>>>>> Davide
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JDvHldAql1alTY01.png
Type: image/png
Size: 904703 bytes
Desc: not available
URL: 

From eddy at imap.linux.ibm.com  Mon Oct 27 07:18:11 2025
From: eddy at imap.linux.ibm.com (eddy)
Date: Mon, 27 Oct 2025 07:18:11 +0000
Subject: state of openjdk-zlib on s390x
Message-ID: 

Hello,

# TLDR

zlib (and zlib-ng) on s390x use hardware compression. This
hardware compression implementation has currently some problems when
used by openjdk.



# current situation

- openjdk uses zlib(or zlib-ng) for most(all?) its data compression.
   This includes also jar file creation.
- s390x has deflate implemented on hardware level(called dfltcc). This
   implementation is up to 10x faster(empirical value) compared to the
   standard software algorithm.
- The dfltcc implementation has some drawbacks vs the software
   implementation:
	- dfltcc will ALWAYS write to the output buffer, indifferent
of 	  the flushing parameter passed to deflate()
	- dfltcc does not generate reproducible output. This means
	  that it will always generate valid deflate data streams
	  that uncompress(inflate) to the same input. But the
compressed data may look different between two calls with
	  the same input data, because the hardware compressor depends
	  also on hardware variables that not visible to the external
	  api user.




# the problem

due to the differences of the hardware implementation, some tests in
the openjdk JREG tests fail(tracked here[1][2])

- java/util/zip/CloseInflaterDeflaterTest.java
     fails due to dfltcc's flushing behaviour. The test should check if
     the openjdk wrapper around the jni and native library will
     successfully detect writes to closed output streams. This was
     created because there where bugs with and race conditions in the
     write/close/flush.

- tools/jlink/JLinkReproducibleTest.java:
- tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java:
     This tests fail due to two calls to dfltcc will not generate the
     same compressed data for the same input data. I want to
     emphasize that RFC 1950 and 1951 do not guarantee the same output
     for two deflate/zlib data streams if feed the same input data.


# proposed solutions
## flushing problem

IMHO the CloseInflaterDeflaterTest.java test relays on zlib behavior
where zlib explicitly has the freedom to change its behavior[3][1].
As a quick and dirty solution i would propose to backport the
disablement[4] of this test to openjdk-17 21 and 24.

I read and traced through the test, and for me it looks like the
behavior of the openjdk and jni wrappers will be the same regardless of
the underlying zlib. Therefor it seems ok to assume that: "If its okay
on x86 it will be ok on s390x"

However I think that this test might need a redesign. It relies on
flushing behavior of zlib the the library explicitly stated can change.



## reproducible compression

I don't know how much openjdk relies on reproducible data compression.
I assume it is preferable if its possible to create the same .jar twice
and get the same binary data. The zlib dfltcc implementation could be
controlled via an env variable to disable the hardware compression[5].
Also usually dftcc will only be used for certain compression levels and
this can also be changed via env variables[6].

Unfortunately this env variables are evaluated at library load and can
not be adjusted during runtime.

Moreover ubuntu setzt the default LEVEL_MASK to 0x7e[7]. This means
that the compression level is also not a reliabl method in order to
force zlib to use software instead of hardware compression.

Also zlib-ng lacks this env variables. Here the use of dfltcc cannot be
influenced at all.

This all leads me to the conclusion that there has to be a decision if
and how openjdk on s390x will be able to generate reproducible jars.
For the time being I suppose to also disable this tests and backport
the disablements down till openjdk-17.



# Finally

I hope i did not overwhelm you all with this email. As I don't have a
bugs.openjdk.org account, I thought the mailing list is the best place
to discuss this mater.

cheers Eddy



[1] https://bugs.launchpad.net/ubuntu/+source/openjdk-21/+bug/2109016
[2] https://bugs.openjdk.org/browse/JDK-8339216
[3] https://github.com/madler/zlib/blob/develop/zlib.h#L286-L288
[4]
https://github.com/openjdk/jdk/commit/537447f8816129dad9a1edd21bd30f3edf69ea60
[5]
https://github.com/iii-i/zlib/blob/dfltcc/contrib/s390/dfltcc.c#L705-L706
[6]
https://github.com/iii-i/zlib/blob/dfltcc/contrib/s390/dfltcc.c#L714-L715
[7] https://git.launchpad.net/ubuntu/+source/zlib/tree/debian/rules#n53