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: <xTQVqBrhrTpxqGO0VbN5XYPc5ed0PYWS3lKkf9f9HNM=.30ae1614-537c-471d-8e2b-91f0b4effc00@github.com>
References: <xTQVqBrhrTpxqGO0VbN5XYPc5ed0PYWS3lKkf9f9HNM=.30ae1614-537c-471d-8e2b-91f0b4effc00@github.com>
Message-ID: <BkAKepDi7wSlHkXG4V2S-hNjEAfRVR-syWd1KoVBo4I=.3ef74c9b-bf9e-4364-98bf-8ddc06966d38@github.com>

On Mon, 29 Sep 2025 08:52:04 GMT, SendaoYan <syan at openjdk.org> 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: <xTQVqBrhrTpxqGO0VbN5XYPc5ed0PYWS3lKkf9f9HNM=.30ae1614-537c-471d-8e2b-91f0b4effc00@github.com>
References: <xTQVqBrhrTpxqGO0VbN5XYPc5ed0PYWS3lKkf9f9HNM=.30ae1614-537c-471d-8e2b-91f0b4effc00@github.com>
Message-ID: <qNw3x2_wYhfldGlS_8K0e1IDSvwvB4o2VgLayCrObRg=.d0554b57-1bd0-4090-bc4e-8f39eb78fa2e@github.com>

On Mon, 29 Sep 2025 08:52:04 GMT, SendaoYan <syan at openjdk.org> 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 <syan at openjdk.org>
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 <alanb at openjdk.org>
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: <n7QPvfFPnkuErdTijO_LXo40jkXfPcBTj7aA9t8Ulng=.2b29e37c-82f4-4fbe-864f-ba9e94931dfa@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <n7QPvfFPnkuErdTijO_LXo40jkXfPcBTj7aA9t8Ulng=.2b29e37c-82f4-4fbe-864f-ba9e94931dfa@github.com>
Message-ID: <3hUJWM9fAKkjWpNnZDRtMgEXZWpP-DyVMTrk1EK0wRQ=.a5ad5755-a0d5-4e15-9d97-d978cb803adc@github.com>

On Tue, 30 Sep 2025 19:28:15 GMT, Roger Riggs <rriggs at openjdk.org> 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: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>

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: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
References: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
Message-ID: <LgqkHfZ179vaiOrUMR-F6uTklLG00YrCFBcDQU8iQUs=.f2968c15-aabc-46c6-96e9-b2ca2b04c131@github.com>

On Wed, 1 Oct 2025 04:29:56 GMT, Joe Darcy <darcy at openjdk.org> 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: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
References: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
Message-ID: <CXQBLlYt2Ur3WsZdfezKcUFuOfdllMGDRKkDOaM9wzI=.d984243d-52e5-4ee2-90e9-342c96ef92de@github.com>

On Wed, 1 Oct 2025 04:29:56 GMT, Joe Darcy <darcy at openjdk.org> 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: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
References: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
Message-ID: <ZpkrbKIueSiCkagrLgiDIM9lQ8v25cBaV89ntGR8hiU=.9247200f-3361-410d-b887-e8dc101c5802@github.com>

On Wed, 1 Oct 2025 04:29:56 GMT, Joe Darcy <darcy at openjdk.org> 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: <XLScJW2bF1SqJ57jGi_0lasslXEaQN2LWukDzWbfwqg=.3a924f83-89ab-4a19-bdd7-7ee5a598a686@github.com>
References: <PjC2_W6FCwj1IhMOjyYiJTwOywQr1yhmPWHPbz3v-EY=.3547aa18-f4c9-4c11-bf7e-ca2ea8c7ab76@github.com>
 <XLScJW2bF1SqJ57jGi_0lasslXEaQN2LWukDzWbfwqg=.3a924f83-89ab-4a19-bdd7-7ee5a598a686@github.com>
Message-ID: <-X-9fSlE_DaHOrrXgzhPR4MzpUdBbhGE7Cwf5wclJCY=.1ff98822-dfee-4552-8712-78086b079dc5@github.com>

On Tue, 30 Sep 2025 23:42:13 GMT, Chen Liang <liach at openjdk.org> 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: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
References: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
Message-ID: <F-A5cXBGC46tczQpPg2rCe5IlzHHt5hUyDhKnS9pWXk=.814c555c-d482-4c3d-84f1-7d5f942b4606@github.com>

On Mon, 15 Sep 2025 05:43:43 GMT, Chen Liang <liach at openjdk.org> 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: <iJHUgdQGkaZgpZ63GJwUkoLNIrSFtt2uFRqCHdN7wrQulQvSkQU7zov2Pml_YfMhw4h6-3rUDX0YN1EW6pyMB1hTPB6Zb-GNLhO4l2XyR-8=@proton.me>

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<Void>().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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251001/52c761c0/attachment-0001.htm>

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: <iJHUgdQGkaZgpZ63GJwUkoLNIrSFtt2uFRqCHdN7wrQulQvSkQU7zov2Pml_YfMhw4h6-3rUDX0YN1EW6pyMB1hTPB6Zb-GNLhO4l2XyR-8=@proton.me>
References: <iJHUgdQGkaZgpZ63GJwUkoLNIrSFtt2uFRqCHdN7wrQulQvSkQU7zov2Pml_YfMhw4h6-3rUDX0YN1EW6pyMB1hTPB6Zb-GNLhO4l2XyR-8=@proton.me>
Message-ID: <CAChcVukJimnFjp7f4E4hWW2DU8Wuc-bfiOvLGqBycSsOV8vqHw@mail.gmail.com>

This belongs to the net-dev mailing list, which I CC'ed.

On Wed, Oct 1, 2025 at 10:56?AM Micha? G. <michal.gn at proton.me> 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<Void>().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: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
References: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
Message-ID: <yEI8aapg8zu3-YcWYAYMLjnflCX-urTt460Vr-vWe2g=.d1273ce7-3eac-4b87-99ee-b6942d3f2084@github.com>

On Wed, 1 Oct 2025 04:29:56 GMT, Joe Darcy <darcy at openjdk.org> 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: <KEsCiYpSzNv3Ppit9SWjcy2R8nQZXwSjLFETAW359Zc=.c6dd98de-02b4-4b90-aabb-f5e512b19276@github.com>
 <8hPfwxOf_dDz25bT4yIdq323qfxF92YxxKbGoNX1t-Y=.dad7c2f0-48fa-4c16-a324-21ed23885f11@github.com>
Message-ID: <eBgW20iDyG9t-gA-FSZ6Hc-7tAL8GMuVr4V736Ggdzk=.083a3a2b-a65b-4576-896a-424fbb262cfc@github.com>

On Tue, 30 Sep 2025 23:06:39 GMT, Pavel Rappo <prappo at openjdk.org> 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: <evZpwBdKcOIjXylDSu-Aj5mAdReZLuwpZA4SgsmnXKk=.b0836b35-2c6d-428f-95b1-be73e1158216@github.com>

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: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
References: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
Message-ID: <dCvyk5x8_j5JAbItOw85f2RpDxgCZOQGdT7O7h5KNUY=.505a3941-f29a-4699-959b-9bd841eec24c@github.com>

On Mon, 15 Sep 2025 05:43:43 GMT, Chen Liang <liach at openjdk.org> 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: <n7QPvfFPnkuErdTijO_LXo40jkXfPcBTj7aA9t8Ulng=.2b29e37c-82f4-4fbe-864f-ba9e94931dfa@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <n7QPvfFPnkuErdTijO_LXo40jkXfPcBTj7aA9t8Ulng=.2b29e37c-82f4-4fbe-864f-ba9e94931dfa@github.com>
Message-ID: <tO9wyC_jHfn9LsoXT45EySRVTWrmUYUnZRsa8KZWuK0=.2378e056-0827-4de5-a171-1b9626c53ae4@github.com>

On Tue, 30 Sep 2025 19:28:15 GMT, Roger Riggs <rriggs at openjdk.org> 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: <tO9wyC_jHfn9LsoXT45EySRVTWrmUYUnZRsa8KZWuK0=.2378e056-0827-4de5-a171-1b9626c53ae4@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <n7QPvfFPnkuErdTijO_LXo40jkXfPcBTj7aA9t8Ulng=.2b29e37c-82f4-4fbe-864f-ba9e94931dfa@github.com>
 <tO9wyC_jHfn9LsoXT45EySRVTWrmUYUnZRsa8KZWuK0=.2378e056-0827-4de5-a171-1b9626c53ae4@github.com>
Message-ID: <CcO0bK0S63x3OnB-FEXftGwGXQfyr9Hg2F2WbOhuEiw=.51408d70-da83-42ad-a461-d0df411145bd@github.com>

On Wed, 1 Oct 2025 12:21:58 GMT, Jason Mehrens <duke at openjdk.org> 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: <FUfjh1AXkoMpe8rirgU9FbjJhEBxvex67qtMrtEyKkk=.81f97df4-55f9-4cad-9d86-8b1ad9bc2cf4@github.com>
References: <FUfjh1AXkoMpe8rirgU9FbjJhEBxvex67qtMrtEyKkk=.81f97df4-55f9-4cad-9d86-8b1ad9bc2cf4@github.com>
Message-ID: <N9diWjgfhOGmEpM_lBQspP4HdHTgWESbvWSeR8u9tP4=.27d1b329-7fbc-4af6-894d-ef29192d735c@github.com>

> 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 <Justin.lu at oracle.com>
 - 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: <Yhu9BwS4foiq2w4p0KR1PSwef34MjJo4-g8bLgB93iE=.70dda87b-3d23-489e-8598-eaf1423055bd@github.com>
References: <FUfjh1AXkoMpe8rirgU9FbjJhEBxvex67qtMrtEyKkk=.81f97df4-55f9-4cad-9d86-8b1ad9bc2cf4@github.com>
 <jJevw92eras9mrwRNU60SvfzxQbKRXBlkqeSMllfdIw=.eb7986c0-fcee-4f61-bd77-ba1fd8e74cbf@github.com>
 <Yhu9BwS4foiq2w4p0KR1PSwef34MjJo4-g8bLgB93iE=.70dda87b-3d23-489e-8598-eaf1423055bd@github.com>
Message-ID: <eLoalG7dEdFiRYumHyL7iRmUndfUVEbzxFPWvaYNyIQ=.de3ed2d1-8aa1-4ee8-8ee4-b359552032e9@github.com>

On Wed, 17 Sep 2025 16:28:06 GMT, Roger Riggs <rriggs at openjdk.org> 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: <m2IjoxvRCO--PlZP-f6CfeOvuvIolBOocLlmtHJlAWo=.817e10ef-6255-4aea-a3b6-4bfeb5f01fd8@github.com>
References: <Tmp62cMK0TPVavha-TmNL9TN-H8b8bAcemtZYD8xuBM=.8db45d0a-ec70-4bb9-875b-5d59536a7a1e@github.com>
 <m2IjoxvRCO--PlZP-f6CfeOvuvIolBOocLlmtHJlAWo=.817e10ef-6255-4aea-a3b6-4bfeb5f01fd8@github.com>
Message-ID: <f3ciW5usvaMK4fGftCf5FqMGOAEsBcjfpRUJcYfdlfw=.793814d7-ce2a-42f1-a264-fd50b28dc8d2@github.com>

On Tue, 30 Sep 2025 23:21:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The DateTimeFormatterBuilder::FIELD_MAP previously used a Map<Character, TemporalField> 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
>> <img width="2018" height="1016" alt="image" src="https://github.com/user-attachments/assets/57d4c513-55c7-472e-95a8-9f7a4b47662d" />
>
> 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: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
Message-ID: <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>

> 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: <kCR8a_Su7gfjqmdjNFOn_9UmgeGSgBfJ7vtX5zyMBug=.25335d05-e67c-41d9-b5cd-6d16f84f210f@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <kCR8a_Su7gfjqmdjNFOn_9UmgeGSgBfJ7vtX5zyMBug=.25335d05-e67c-41d9-b5cd-6d16f84f210f@github.com>
Message-ID: <TlJjhErtgSvR-K1FOz4P1N2MtUsU4E-BlBLs1qcY3hA=.362e8d50-dc4e-400c-a434-c9e27bd403ea@github.com>

On Tue, 30 Sep 2025 13:32:24 GMT, Martin Doerr <mdoerr at openjdk.org> 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: <AWHRLHnr8XKdHE_IIUgSaVT1LQDc_zyNWDobFFC8eU8=.a29b86a8-3b19-4644-9b9a-db127c54e4d5@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <AWHRLHnr8XKdHE_IIUgSaVT1LQDc_zyNWDobFFC8eU8=.a29b86a8-3b19-4644-9b9a-db127c54e4d5@github.com>
Message-ID: <nHGpswdjvwytY1Sqpdj2q_gzZgIej_PJ4mRpCe47UDs=.f133d44b-6946-428c-a407-0ab68a86629d@github.com>

On Tue, 30 Sep 2025 15:51:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> 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: <N9diWjgfhOGmEpM_lBQspP4HdHTgWESbvWSeR8u9tP4=.27d1b329-7fbc-4af6-894d-ef29192d735c@github.com>
References: <FUfjh1AXkoMpe8rirgU9FbjJhEBxvex67qtMrtEyKkk=.81f97df4-55f9-4cad-9d86-8b1ad9bc2cf4@github.com>
 <N9diWjgfhOGmEpM_lBQspP4HdHTgWESbvWSeR8u9tP4=.27d1b329-7fbc-4af6-894d-ef29192d735c@github.com>
Message-ID: <caMHGBwgDrcqNO9q6i8T0JHClwwhSPImkrRDEY-ip7I=.61fe9e7a-5477-4b17-aaab-9817e7143722@github.com>

On Wed, 1 Oct 2025 13:26:52 GMT, Pavel Rappo <prappo at openjdk.org> 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 <Justin.lu at oracle.com>
>  - 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: <gPLWXCadQzq8dYfEe9AR-dpl8rDTMKYAQmMrwfO6f9o=.8bcd7370-4832-42f9-af42-3f7cf538bbd0@github.com>
References: <pXf8-xw4yhb4gRzNDS4GdcQ8uVF80kA0iLZpqUYKot4=.0cdf9034-43ac-4e66-8349-bfb8157db2fd@github.com>
 <gPLWXCadQzq8dYfEe9AR-dpl8rDTMKYAQmMrwfO6f9o=.8bcd7370-4832-42f9-af42-3f7cf538bbd0@github.com>
Message-ID: <3wmTc01gqlZgKbHbolEjymrkTN0ONFgmSLlfTjHvKfI=.9c3b4fcd-79b0-4702-8dd0-a8c7b8257bf7@github.com>

On Thu, 28 Aug 2025 15:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <U26BubDrKfAsBpEEZb_q9udsU5_IhZjPBcZSIMzxbeY=.709687ee-40b1-4c32-883e-20aba2bca325@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
 <U26BubDrKfAsBpEEZb_q9udsU5_IhZjPBcZSIMzxbeY=.709687ee-40b1-4c32-883e-20aba2bca325@github.com>
Message-ID: <FGvD0ybOROd2Nnb-0ZrZcsDNDDj0NJtFlqtYWkcnhwc=.c4d2b4de-327d-423f-9ef6-2247a0787447@github.com>

On Wed, 1 Oct 2025 14:01:57 GMT, Martin Doerr <mdoerr at openjdk.org> 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: <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
Message-ID: <U26BubDrKfAsBpEEZb_q9udsU5_IhZjPBcZSIMzxbeY=.709687ee-40b1-4c32-883e-20aba2bca325@github.com>

On Wed, 1 Oct 2025 13:35:52 GMT, Fredrik Bredberg <fbredberg at openjdk.org> 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: <U26BubDrKfAsBpEEZb_q9udsU5_IhZjPBcZSIMzxbeY=.709687ee-40b1-4c32-883e-20aba2bca325@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
 <U26BubDrKfAsBpEEZb_q9udsU5_IhZjPBcZSIMzxbeY=.709687ee-40b1-4c32-883e-20aba2bca325@github.com>
Message-ID: <2HZuTvrbG5DED7c-r-MBu-itrFiIzJiy4B2WCjXxdiw=.cb10434a-3390-4c48-b27f-ad0ac7e6092f@github.com>

On Wed, 1 Oct 2025 14:01:57 GMT, Martin Doerr <mdoerr at openjdk.org> 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: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
References: <KvwOQGklXhQCvZzM7Zprm4QrtGd0BGrVV-9BYsTL1do=.48ab0bcb-d93c-4b89-8860-beddc33ddfef@github.com>
Message-ID: <LWU6F2M9hQ2Wv0Cbp_1--9p28aIF7uB04imxN6MCVIc=.ca0cca1c-a929-4335-bec9-402ee580a0a3@github.com>

On Mon, 15 Sep 2025 05:43:43 GMT, Chen Liang <liach at openjdk.org> 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: <gPLWXCadQzq8dYfEe9AR-dpl8rDTMKYAQmMrwfO6f9o=.8bcd7370-4832-42f9-af42-3f7cf538bbd0@github.com>
References: <pXf8-xw4yhb4gRzNDS4GdcQ8uVF80kA0iLZpqUYKot4=.0cdf9034-43ac-4e66-8349-bfb8157db2fd@github.com>
 <gPLWXCadQzq8dYfEe9AR-dpl8rDTMKYAQmMrwfO6f9o=.8bcd7370-4832-42f9-af42-3f7cf538bbd0@github.com>
Message-ID: <fVNxDl4pW4K6CYnr_wS1BoPZ3LFL9jMY28eXvt_cFDs=.fdeb0a3c-9388-4b6c-86e0-56c5a0763bd1@github.com>

On Thu, 28 Aug 2025 15:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <m2IjoxvRCO--PlZP-f6CfeOvuvIolBOocLlmtHJlAWo=.817e10ef-6255-4aea-a3b6-4bfeb5f01fd8@github.com>
References: <Tmp62cMK0TPVavha-TmNL9TN-H8b8bAcemtZYD8xuBM=.8db45d0a-ec70-4bb9-875b-5d59536a7a1e@github.com>
 <m2IjoxvRCO--PlZP-f6CfeOvuvIolBOocLlmtHJlAWo=.817e10ef-6255-4aea-a3b6-4bfeb5f01fd8@github.com>
Message-ID: <03DIrJA3CcONrHoKW1eji6ri8XydMjwxuaDb8Eu8ix4=.a95d8913-2c41-4d02-b53e-63d761fd5966@github.com>

On Tue, 30 Sep 2025 23:21:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The DateTimeFormatterBuilder::FIELD_MAP previously used a Map<Character, TemporalField> 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
>> <img width="2018" height="1016" alt="image" src="https://github.com/user-attachments/assets/57d4c513-55c7-472e-95a8-9f7a4b47662d" />
>
> 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: <N9diWjgfhOGmEpM_lBQspP4HdHTgWESbvWSeR8u9tP4=.27d1b329-7fbc-4af6-894d-ef29192d735c@github.com>
References: <FUfjh1AXkoMpe8rirgU9FbjJhEBxvex67qtMrtEyKkk=.81f97df4-55f9-4cad-9d86-8b1ad9bc2cf4@github.com>
 <N9diWjgfhOGmEpM_lBQspP4HdHTgWESbvWSeR8u9tP4=.27d1b329-7fbc-4af6-894d-ef29192d735c@github.com>
Message-ID: <Kk7WV3qtcYYws-SLUYO6gSINT2ehNmiKpIuE_WSeyCQ=.396f2103-413a-466b-829e-b8b97fb9b2a3@github.com>

On Wed, 1 Oct 2025 13:26:52 GMT, Pavel Rappo <prappo at openjdk.org> 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 <Justin.lu at oracle.com>
>  - 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: <N9diWjgfhOGmEpM_lBQspP4HdHTgWESbvWSeR8u9tP4=.27d1b329-7fbc-4af6-894d-ef29192d735c@github.com>
References: <FUfjh1AXkoMpe8rirgU9FbjJhEBxvex67qtMrtEyKkk=.81f97df4-55f9-4cad-9d86-8b1ad9bc2cf4@github.com>
 <N9diWjgfhOGmEpM_lBQspP4HdHTgWESbvWSeR8u9tP4=.27d1b329-7fbc-4af6-894d-ef29192d735c@github.com>
Message-ID: <lYTYEWW81k3eYjKNAycoImftGvzh1QcfOZ3T-ldtuF8=.4d39cf36-db19-4ef5-9135-2026c73eac7e@github.com>

On Wed, 1 Oct 2025 13:26:52 GMT, Pavel Rappo <prappo at openjdk.org> 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 <Justin.lu at oracle.com>
>  - 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: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
References: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
Message-ID: <W2pKOOQP-tCDxisFC6C3MYUuoq92ZUMmW6hvsyHsx9w=.7720432c-ab3e-47f4-8b6f-4fed3b3bf544@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/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: <CXQBLlYt2Ur3WsZdfezKcUFuOfdllMGDRKkDOaM9wzI=.d984243d-52e5-4ee2-90e9-342c96ef92de@github.com>
References: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
 <CXQBLlYt2Ur3WsZdfezKcUFuOfdllMGDRKkDOaM9wzI=.d984243d-52e5-4ee2-90e9-342c96ef92de@github.com>
Message-ID: <ArmZBme5NXKAJV-IhsNC9fh6gJwzDwXcPmTyaEeHShA=.1da597d4-5a82-4d59-b26f-7ea5134127af@github.com>

On Wed, 1 Oct 2025 06:43:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> 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: <FUfjh1AXkoMpe8rirgU9FbjJhEBxvex67qtMrtEyKkk=.81f97df4-55f9-4cad-9d86-8b1ad9bc2cf4@github.com>
References: <FUfjh1AXkoMpe8rirgU9FbjJhEBxvex67qtMrtEyKkk=.81f97df4-55f9-4cad-9d86-8b1ad9bc2cf4@github.com>
Message-ID: <mBrD2BTLMWZI6ZUWFEWYsHy2hjdpnB3OoQ5ZlyblKrQ=.866d65ba-867a-4a3b-b463-fe7945c4bf2c@github.com>

On Mon, 15 Sep 2025 15:17:29 GMT, Pavel Rappo <prappo at openjdk.org> 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 <prappo at openjdk.org>
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: <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
Message-ID: <xVyb8ebr75-EzPC2-3XwG2xDfZiT5Z8MB6eQFNI6MMg=.1df36ad6-bc31-4263-af05-d69e30fcb38b@github.com>

On Wed, 1 Oct 2025 13:35:52 GMT, Fredrik Bredberg <fbredberg at openjdk.org> 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: <CAA55TJo8mLrdkbmcS3+Y9f8iDNuG-6kj0u6y_oeLoDe8V9wVHQ@mail.gmail.com>
References: <CAA55TJo8mLrdkbmcS3+Y9f8iDNuG-6kj0u6y_oeLoDe8V9wVHQ@mail.gmail.com>
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: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <zpsaCrgZQIHZY-HAlSFxruwk13dsLxEYhgl2Aj7zTdE=.4da22ba3-8893-44ed-b61c-2f689b1e47f7@github.com>

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

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
Message-ID: <Grf-fFPwvcYVO4_MABpdig4qiUDev-S70DstaYkSifI=.1f09c8a9-1531-4dcd-bc00-ee25759a9da4@github.com>

> 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: <W2pKOOQP-tCDxisFC6C3MYUuoq92ZUMmW6hvsyHsx9w=.7720432c-ab3e-47f4-8b6f-4fed3b3bf544@github.com>
References: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
 <W2pKOOQP-tCDxisFC6C3MYUuoq92ZUMmW6hvsyHsx9w=.7720432c-ab3e-47f4-8b6f-4fed3b3bf544@github.com>
Message-ID: <-7H4fKLBHM_RZ5E3Po9dGcpT9Kw50zCcrYMDzFFMpcA=.bc661f6d-6c55-471a-b724-0c93d19dbcb9@github.com>

On Wed, 1 Oct 2025 16:06:45 GMT, Joe Darcy <darcy at openjdk.org> 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: <CcO0bK0S63x3OnB-FEXftGwGXQfyr9Hg2F2WbOhuEiw=.51408d70-da83-42ad-a461-d0df411145bd@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <n7QPvfFPnkuErdTijO_LXo40jkXfPcBTj7aA9t8Ulng=.2b29e37c-82f4-4fbe-864f-ba9e94931dfa@github.com>
 <tO9wyC_jHfn9LsoXT45EySRVTWrmUYUnZRsa8KZWuK0=.2378e056-0827-4de5-a171-1b9626c53ae4@github.com>
 <CcO0bK0S63x3OnB-FEXftGwGXQfyr9Hg2F2WbOhuEiw=.51408d70-da83-42ad-a461-d0df411145bd@github.com>
Message-ID: <WWSSiYCEJ--_NbLLHmEdr4HibZQGJrr0_xHQCC2xW1I=.21210b22-efe5-4481-a304-0999d579783f@github.com>

On Wed, 1 Oct 2025 13:00:41 GMT, Roger Riggs <rriggs at openjdk.org> 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: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
References: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
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: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
 <W2pKOOQP-tCDxisFC6C3MYUuoq92ZUMmW6hvsyHsx9w=.7720432c-ab3e-47f4-8b6f-4fed3b3bf544@github.com>
 <-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 <rgiulietti at openjdk.org> 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: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
Message-ID: <uBFPt2NvmStCwl3OGr8wo6jjeus2qFMeIlPwQkjg8ng=.3bf30b68-dda1-4f3b-b65b-c7420fabfca5@github.com>

> 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: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
Message-ID: <Ngl6t12T9fEXSTaLnXTjZzKn5Eo2F_IxIAnDwbXZ2tE=.ba3502a3-4c58-48d8-9cbb-bf3253438498@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 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: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
 <51-xEz43o2zWyWoagMw74aG1hbVdwwVOtEESDJ_Fn4Q=.52d9039b-d11c-4667-84f5-bda9dc4bf9c0@github.com>
Message-ID: <IuWcX9PCRGMBPosjQIX-yuLnhRThgC09bZq64pQsM2w=.7f1e759f-15c8-4d43-bc96-dc4fbecde405@github.com>

On Wed, 1 Oct 2025 17:22:17 GMT, Joe Darcy <darcy at openjdk.org> 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: <Vm_yFiCQk4pjVlXReRnrclI5lhdGc7tlg84diOXSZUU=.52b123b5-5d64-4a13-b4c9-a2cd032986a7@github.com>
References: <Vm_yFiCQk4pjVlXReRnrclI5lhdGc7tlg84diOXSZUU=.52b123b5-5d64-4a13-b4c9-a2cd032986a7@github.com>
Message-ID: <7QqLWmbtCXGPM5tYbAacAJekA1DCZ7Mx7L8zJXp6alc=.383938b5-9fe8-479e-a0da-67c95d2c7d02@github.com>

On Mon, 29 Sep 2025 21:38:28 GMT, Justin Lu <jlu at openjdk.org> 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 <jlu at openjdk.org>
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: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
 <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 <darcy at openjdk.org> 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: <TBC_-bS0wveSnqaD7o2rlRCMe_gfBMJDaHTeO6tPJ8s=.751b9545-3c0b-4600-8976-df931df8c1ee@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
 <TBC_-bS0wveSnqaD7o2rlRCMe_gfBMJDaHTeO6tPJ8s=.751b9545-3c0b-4600-8976-df931df8c1ee@github.com>
Message-ID: <5jy7TESrdbKHEh9oS_BZHjUh-mvL5lhoMlihE1XCXIY=.98295122-bc66-4b80-810d-47cbf3197fc3@github.com>

On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao <wxiao at openjdk.org> 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: <Zc3mAHEIAfH7fD_eSM2JDlTnVno0fik95BPmwngIRx4=.e7c86cfe-8220-4567-8009-08cd2145b6b7@github.com>
References: <SubXPqTRupG2aOTz8jB7oTZGSR1v37tpR9IaJ5VcUwo=.b4a80951-8e48-4b6e-a888-0ce5402f986f@github.com>
 <Zc3mAHEIAfH7fD_eSM2JDlTnVno0fik95BPmwngIRx4=.e7c86cfe-8220-4567-8009-08cd2145b6b7@github.com>
Message-ID: <8wMk52nQ4lhHxDHN3xVJwnW5QVzFC8iJ9xmw3h37XEY=.80cd7146-26b1-428f-b21d-1626749c3884@github.com>

On Tue, 30 Sep 2025 18:42:59 GMT, Johannes Graham <jgraham at openjdk.org> 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 <raffaello.giulietti at oracle.com>

@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: <KEsCiYpSzNv3Ppit9SWjcy2R8nQZXwSjLFETAW359Zc=.c6dd98de-02b4-4b90-aabb-f5e512b19276@github.com>
References: <KEsCiYpSzNv3Ppit9SWjcy2R8nQZXwSjLFETAW359Zc=.c6dd98de-02b4-4b90-aabb-f5e512b19276@github.com>
Message-ID: <IeB9Avm7OPCIYJZ9ETfrhuXQ5OAM6_SDYKFtcmfc_04=.43ffb898-88c2-4469-b698-2ec24269d555@github.com>

> 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: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
 <51-xEz43o2zWyWoagMw74aG1hbVdwwVOtEESDJ_Fn4Q=.52d9039b-d11c-4667-84f5-bda9dc4bf9c0@github.com>
 <_9cWhFYDxgq2lb_TPCsyiuQDHha-Gf9jLQKBaBIohJ4=.d0d97447-e64b-458f-ac00-baf557cadf26@github.com>
Message-ID: <A-Zi0IKAfEkJXuwMbtwV_kJs64wcvJ2Vd2uBmiV5dkI=.6cd409f0-c9c0-460f-ac48-d46973b29555@github.com>

On Wed, 1 Oct 2025 18:30:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> 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: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
References: <xc_l19ppsqtT47Ni1A5gTkzvSgl-Lq-0oqsiOOEKdf0=.a7fdc225-91e6-44e6-8899-b6cb1d247413@github.com>
Message-ID: <XwctS8RW1rJyPn_LlXd9lrjk4zdPrcgHnMoLvTeyAsc=.71610246-70d8-4f64-b917-9b68491acc70@github.com>

On Wed, 1 Oct 2025 04:29:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> A few more small cleanups to Float16 and its tests.

This pull request has now been integrated.

Changeset: ef724f40
Author:    Joe Darcy <darcy at openjdk.org>
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: <SubXPqTRupG2aOTz8jB7oTZGSR1v37tpR9IaJ5VcUwo=.b4a80951-8e48-4b6e-a888-0ce5402f986f@github.com>
References: <SubXPqTRupG2aOTz8jB7oTZGSR1v37tpR9IaJ5VcUwo=.b4a80951-8e48-4b6e-a888-0ce5402f986f@github.com>
Message-ID: <wr_Gz3Nl6ZvWAhZjQ7HAVUV-InCGE4GQF6tIGrXsPT0=.b62a915e-6c8a-4326-befd-57f7e740b788@github.com>

On Tue, 30 Sep 2025 15:35:03 GMT, Johannes Graham <jgraham at openjdk.org> 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 <jgraham at openjdk.org>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
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: <KEsCiYpSzNv3Ppit9SWjcy2R8nQZXwSjLFETAW359Zc=.c6dd98de-02b4-4b90-aabb-f5e512b19276@github.com>
References: <KEsCiYpSzNv3Ppit9SWjcy2R8nQZXwSjLFETAW359Zc=.c6dd98de-02b4-4b90-aabb-f5e512b19276@github.com>
Message-ID: <eY5diSdDeVaClwre2tPI-DpIBs-jihD5G08Yq2manTk=.5451cc3e-336f-492f-ba44-b7cecb9af032@github.com>

> 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: <eMqKgtG2CaTi2MowybPYR4l_S8Vot2agt-FrGD0ubKk=.c44d0ab0-89bc-4068-a823-4e0c73d7d439@github.com>
References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com>
 <eMqKgtG2CaTi2MowybPYR4l_S8Vot2agt-FrGD0ubKk=.c44d0ab0-89bc-4068-a823-4e0c73d7d439@github.com>
Message-ID: <T6ETEKnVZmdzDSrwhD_0QJDQr7ZIXjOTC3hqpX6T-Hs=.179c6c4d-e38a-45f0-b296-0a1d344e9604@github.com>

On Fri, 26 Sep 2025 04:04:40 GMT, Shaojin Wen <swen at openjdk.org> 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: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>

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: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
References: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
Message-ID: <Pxmwx5PtTmGGdlHLKlfVpfUNtZAAMpiQUM17EeE_NGU=.d5abf7af-d950-4153-be9b-bb65a2c577de@github.com>

On Wed, 1 Oct 2025 21:11:53 GMT, Justin Lu <jlu at openjdk.org> 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: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
References: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
Message-ID: <Vxqh4Dx-K3sxnxAH14UwT8H2d30k3o7Rkk6AF9Sz-Sk=.b3ca5f02-e65c-42a4-b969-2a96bfb8f49b@github.com>

> 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: <Pxmwx5PtTmGGdlHLKlfVpfUNtZAAMpiQUM17EeE_NGU=.d5abf7af-d950-4153-be9b-bb65a2c577de@github.com>
References: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
 <Pxmwx5PtTmGGdlHLKlfVpfUNtZAAMpiQUM17EeE_NGU=.d5abf7af-d950-4153-be9b-bb65a2c577de@github.com>
Message-ID: <0ERKiGbLdQe_k6CuJMiS877HpgA1gAQ1nyOwXEybFCo=.a6837f5f-c6ad-4f81-9196-0c5ea2cf858c@github.com>

On Wed, 1 Oct 2025 22:02:11 GMT, Naoto Sato <naoto at openjdk.org> 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: <Vxqh4Dx-K3sxnxAH14UwT8H2d30k3o7Rkk6AF9Sz-Sk=.b3ca5f02-e65c-42a4-b969-2a96bfb8f49b@github.com>
References: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
 <Vxqh4Dx-K3sxnxAH14UwT8H2d30k3o7Rkk6AF9Sz-Sk=.b3ca5f02-e65c-42a4-b969-2a96bfb8f49b@github.com>
Message-ID: <VouJm-HRgy4nYhiXSa0-x7e4BXLSQ__TOq4gCo8ygwg=.1c3df30a-524e-4084-bf24-fbc2ddace6fe@github.com>

On Wed, 1 Oct 2025 22:51:30 GMT, Justin Lu <jlu at openjdk.org> 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: <IpbzpzMGbO--yCORCLshyOq8QPyabhXlLvGAqllf5o0=.67ca514f-dc41-4926-8f3f-662b4c00d50d@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:

  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: <RjyF_DJ4j4gvwkut_U8a_UMH6YLIKHPv2NBMKyImAWQ=.2294d54f-a8fa-47cd-b275-b2c8fee197ed@github.com>
References: <RjyF_DJ4j4gvwkut_U8a_UMH6YLIKHPv2NBMKyImAWQ=.2294d54f-a8fa-47cd-b275-b2c8fee197ed@github.com>
Message-ID: <WAXQf1FEsZ3jfG--7a02YRUlhA_nhW-a5dB_SzS_xw4=.0b13f1ac-3a0d-441b-9194-a3f308b63416@github.com>

> - 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: <RjyF_DJ4j4gvwkut_U8a_UMH6YLIKHPv2NBMKyImAWQ=.2294d54f-a8fa-47cd-b275-b2c8fee197ed@github.com>
References: <RjyF_DJ4j4gvwkut_U8a_UMH6YLIKHPv2NBMKyImAWQ=.2294d54f-a8fa-47cd-b275-b2c8fee197ed@github.com>
Message-ID: <dYEnZu1B5Zq0YvbU7nlJ0HImDWNO1nh2m-OsEDP1Xao=.fb170bf8-8da7-453f-a759-4115a8aade68@github.com>

On Fri, 26 Sep 2025 02:54:32 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <nx0k_Ztbu0A3JxwOSUzwdytU3rZmBLMg6lYRmOQ1bOE=.6990c1e4-b4b4-4af2-8bff-7c60450bc12b@github.com>

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: <Ek4b4HPpiONBsl6MFHGYG0aYOUyzstegbkjNNrf9bBQ=.02004818-6848-4377-91e1-ac8db7cf3f69@github.com>
References: <Ek4b4HPpiONBsl6MFHGYG0aYOUyzstegbkjNNrf9bBQ=.02004818-6848-4377-91e1-ac8db7cf3f69@github.com>
Message-ID: <Ad_yTQ-lJEfUQxDvWWgJdd87kWp2CDEBsD_dRuyPWG4=.7687b03e-3f4c-4b6d-bf01-3a089f4bfc40@github.com>

> 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: <WWJzOE0HrykcWuNdn8uAfgxub1RtpyznSHjBnnzp8T0=.783d3a95-53f2-4a68-a469-1dd1d22dc03f@github.com>
 <8HZBxhhTi-z6Dj7grgPJy_zh1Ss2YFLQBJMuA6Rs8Jk=.f1c2a5a3-abc9-4430-980d-e318b8927f25@github.com>
Message-ID: <TMkvhFuj2KG3sJaExDSwiJ2QkeSd7vAbVII-VvSlXn8=.17775262-b578-4732-8432-f2c992429d0e@github.com>

On Wed, 27 Aug 2025 19:18:17 GMT, Chen Liang <liach at openjdk.org> 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: <m2IjoxvRCO--PlZP-f6CfeOvuvIolBOocLlmtHJlAWo=.817e10ef-6255-4aea-a3b6-4bfeb5f01fd8@github.com>
References: <Tmp62cMK0TPVavha-TmNL9TN-H8b8bAcemtZYD8xuBM=.8db45d0a-ec70-4bb9-875b-5d59536a7a1e@github.com>
 <m2IjoxvRCO--PlZP-f6CfeOvuvIolBOocLlmtHJlAWo=.817e10ef-6255-4aea-a3b6-4bfeb5f01fd8@github.com>
Message-ID: <zz-hC2yd_9TymN05L9TVoE_OEz-Ql8FrpVNKLzKvL7g=.9410fa55-f39d-4862-ace8-f79b0ffa23a2@github.com>

On Tue, 30 Sep 2025 23:21:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The DateTimeFormatterBuilder::FIELD_MAP previously used a Map<Character, TemporalField> 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
>> <img width="2018" height="1016" alt="image" src="https://github.com/user-attachments/assets/57d4c513-55c7-472e-95a8-9f7a4b47662d" />
>
> 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: <yVkjdjek4_PbOVXdqixZ5goxgunaYmpNyWdoT5ERM7U=.f380c56f-4834-4083-927c-ddf3a91f5883@github.com>
References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
 <z2uySdwAaNh--vFUSBWaJS9sG3Z_1hA-RzJSNsmRGSA=.1d5a92ca-f5b1-47d2-a00e-64f96dd7333c@github.com>
 <yVkjdjek4_PbOVXdqixZ5goxgunaYmpNyWdoT5ERM7U=.f380c56f-4834-4083-927c-ddf3a91f5883@github.com>
Message-ID: <I8-3AqQk_lp-9K8CFJl4NXG-LxQ-0kOmKUrEnL7ZzYs=.5fce7087-ed88-4257-985f-9289773fce46@github.com>

On Thu, 25 Sep 2025 17:37:34 GMT, fabioromano1 <duke at openjdk.org> 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: <fKRI_i9WJRWx-aj56XEQG_4GkXCSqN9NlooRD-p2Vr0=.5c3cc96f-434f-43cc-b052-c1cb448e84b0@github.com>
References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com>
 <fKRI_i9WJRWx-aj56XEQG_4GkXCSqN9NlooRD-p2Vr0=.5c3cc96f-434f-43cc-b052-c1cb448e84b0@github.com>
Message-ID: <-Ei1bFBHQvpeD3n7j8WuhV572oNW1b9X8FI488DMigI=.d1f9c421-b0f5-49e0-9ac5-97732ca82c4f@github.com>

On Mon, 29 Sep 2025 07:18:42 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <gMpgM_vzCr879wnmTmebhqWKa99YNVA63h_XkgdXhcE=.9b175f8a-3b97-4240-91e7-6850fe8d709d@github.com>
References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com>
 <gMpgM_vzCr879wnmTmebhqWKa99YNVA63h_XkgdXhcE=.9b175f8a-3b97-4240-91e7-6850fe8d709d@github.com>
Message-ID: <6GSnA_2G7jXB6-yfQlj6WdSaI17PMkjFdcwCTHUVaZM=.15fa382f-0ba1-43f7-9104-4629721b42a3@github.com>

On Mon, 29 Sep 2025 16:12:20 GMT, fabioromano1 <duke at openjdk.org> 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: <fKRI_i9WJRWx-aj56XEQG_4GkXCSqN9NlooRD-p2Vr0=.5c3cc96f-434f-43cc-b052-c1cb448e84b0@github.com>
References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com>
 <fKRI_i9WJRWx-aj56XEQG_4GkXCSqN9NlooRD-p2Vr0=.5c3cc96f-434f-43cc-b052-c1cb448e84b0@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 <xgong at openjdk.org> 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: <evZpwBdKcOIjXylDSu-Aj5mAdReZLuwpZA4SgsmnXKk=.b0836b35-2c6d-428f-95b1-be73e1158216@github.com>
References: <evZpwBdKcOIjXylDSu-Aj5mAdReZLuwpZA4SgsmnXKk=.b0836b35-2c6d-428f-95b1-be73e1158216@github.com>
Message-ID: <D-tDd-E0AyrNHMqoK21nDz_9wE1FeOnS8tZJr0e0eLk=.d0b63f9f-29b2-48be-a51e-acfff6c23f05@github.com>

On Wed, 1 Oct 2025 11:22:34 GMT, Darragh Clarke <dclarke at openjdk.org> 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: <AL89ZzP2BS7xG3dutYWe5YF9QR38bZGLRN8DcoMP42Y=.1a75b21a-e275-4254-8730-ee8cfd092e49@github.com>
References: <_RSrJDqgl9UDaKCwPK31uetZp7TEzY4VzkC00P7TKaQ=.fca60c93-cae5-43db-879a-0b63cd2e5d77@github.com>
 <AL89ZzP2BS7xG3dutYWe5YF9QR38bZGLRN8DcoMP42Y=.1a75b21a-e275-4254-8730-ee8cfd092e49@github.com>
Message-ID: <sN0C2xnkAQosLV7l9UmpI5GcA4Pe7oQ2rtqUf4slv8A=.52e92523-7207-4595-afb3-139f107af6d7@github.com>

On Fri, 26 Sep 2025 16:42:49 GMT, Chris Dennis <duke at openjdk.org> 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: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <Vw8wZcOqmkIFPJJXz9Yl_hNdtMd47x5If5-7-ivUS-Y=.b38400f5-2377-4377-b8e4-184b9265957a@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 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>
 <gMpgM_vzCr879wnmTmebhqWKa99YNVA63h_XkgdXhcE=.9b175f8a-3b97-4240-91e7-6850fe8d709d@github.com>
 <6GSnA_2G7jXB6-yfQlj6WdSaI17PMkjFdcwCTHUVaZM=.15fa382f-0ba1-43f7-9104-4629721b42a3@github.com>
Message-ID: <iGvEs5rtK6EULSydFHRB9CLZOMP35-Ldgr8nxwXH3IY=.78f0ccad-88e5-4322-93f7-aedc43fac9c9@github.com>

On Thu, 2 Oct 2025 10:12:01 GMT, fabioromano1 <duke at openjdk.org> 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: <uBFPt2NvmStCwl3OGr8wo6jjeus2qFMeIlPwQkjg8ng=.3bf30b68-dda1-4f3b-b65b-c7420fabfca5@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <uBFPt2NvmStCwl3OGr8wo6jjeus2qFMeIlPwQkjg8ng=.3bf30b68-dda1-4f3b-b65b-c7420fabfca5@github.com>
Message-ID: <QIhgo3shGtvqKhWJCCRam5dS6leeZ3G2xPJAfuE0nKE=.63f35d70-8d5a-45da-b48d-76b389e18c5e@github.com>

On Wed, 1 Oct 2025 17:22:39 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <uBFPt2NvmStCwl3OGr8wo6jjeus2qFMeIlPwQkjg8ng=.3bf30b68-dda1-4f3b-b65b-c7420fabfca5@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <uBFPt2NvmStCwl3OGr8wo6jjeus2qFMeIlPwQkjg8ng=.3bf30b68-dda1-4f3b-b65b-c7420fabfca5@github.com>
Message-ID: <QYSpfWJg79xhxSx2I8mq1N2VLBxzi-ToRCmLaffK3CQ=.31f2adb4-d674-4b05-9b68-04c82ce34041@github.com>

On Wed, 1 Oct 2025 17:22:39 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <pI0eJIHdSw72R3vuyOWeNuDZv796bVjCvaFFDag_m94=.fd65f249-5b40-408f-92e4-c85c4948fb42@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
 <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>
 <Te4rI_U8oqzoaZjU2qMlboFjiXhTIX6v7uzGitVMpew=.befd073a-561c-46f6-8d4c-6cc5a64872b0@github.com>
 <cnqT7g1JdcDC0IjD8h386mUWQPL9AgcQOW_Djrjz4l4=.06a5f9be-ad54-4466-936d-7a443560cd2b@github.com>
 <pI0eJIHdSw72R3vuyOWeNuDZv796bVjCvaFFDag_m94=.fd65f249-5b40-408f-92e4-c85c4948fb42@github.com>
Message-ID: <HMDr8G0o2N5E4sAZr328oSrzLmNeIUNW8ct5-VVYwSU=.e77bf9c5-727b-456a-b095-98e2306a62a2@github.com>

On Mon, 4 Aug 2025 13:46:36 GMT, Artur Barashev <abarashev at openjdk.org> 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: <AL89ZzP2BS7xG3dutYWe5YF9QR38bZGLRN8DcoMP42Y=.1a75b21a-e275-4254-8730-ee8cfd092e49@github.com>
References: <_RSrJDqgl9UDaKCwPK31uetZp7TEzY4VzkC00P7TKaQ=.fca60c93-cae5-43db-879a-0b63cd2e5d77@github.com>
 <AL89ZzP2BS7xG3dutYWe5YF9QR38bZGLRN8DcoMP42Y=.1a75b21a-e275-4254-8730-ee8cfd092e49@github.com>
Message-ID: <QRxtUqcTX0-SxeRAzogAdiNwb-o1kkeJxvtz7x6E6pc=.e5387ed4-6d94-4d1c-a936-da25a44df7f5@github.com>

On Fri, 26 Sep 2025 16:42:49 GMT, Chris Dennis <duke at openjdk.org> 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: <nCp4BiJIVaCS2lAT16EyYLnHNwid1NTBQWd6dKmZu-M=.5907534f-3457-4e99-ba2c-5ca914c33a34@github.com>

On Fri, 26 Sep 2025 16:21:35 GMT, Marc Chevalier <mchevalier at openjdk.org> 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: <evZpwBdKcOIjXylDSu-Aj5mAdReZLuwpZA4SgsmnXKk=.b0836b35-2c6d-428f-95b1-be73e1158216@github.com>
References: <evZpwBdKcOIjXylDSu-Aj5mAdReZLuwpZA4SgsmnXKk=.b0836b35-2c6d-428f-95b1-be73e1158216@github.com>
Message-ID: <duHCVb5e3A6jkXmetKiCekpOwGksciWeJyDwaEu9rtQ=.80f2c620-3e8a-4d07-a67d-b905c1e54819@github.com>

On Wed, 1 Oct 2025 11:22:34 GMT, Darragh Clarke <dclarke at openjdk.org> 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: <Ngl6t12T9fEXSTaLnXTjZzKn5Eo2F_IxIAnDwbXZ2tE=.ba3502a3-4c58-48d8-9cbb-bf3253438498@github.com>
References: <VU_pyNsP-dPWU0PG8IuoYQefPEryMgjjpf1P-NaA9HM=.66cfb2f3-11f2-48a8-8fd2-291c985df18d@github.com>
 <Ngl6t12T9fEXSTaLnXTjZzKn5Eo2F_IxIAnDwbXZ2tE=.ba3502a3-4c58-48d8-9cbb-bf3253438498@github.com>
Message-ID: <_Huph1orV4PKtvcCC32PVK13D4oxCazAp7FsypWD6lQ=.a8b931fb-4a55-4bf4-a8b4-fccfac865a0b@github.com>

On Wed, 1 Oct 2025 17:45:41 GMT, Roger Riggs <rriggs at openjdk.org> 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 <bkilambi at openjdk.org> 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: <i96JH5gLBF8dqLJoJl2fZTUdqKdQUoStdCv7ypn8lJU=.ffa74907-ff5b-4262-885a-27889786b544@github.com>

On Thu, 2 Oct 2025 03:08:32 GMT, Shaojin Wen <swen at openjdk.org> 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: <Tmp62cMK0TPVavha-TmNL9TN-H8b8bAcemtZYD8xuBM=.8db45d0a-ec70-4bb9-875b-5d59536a7a1e@github.com>
References: <Tmp62cMK0TPVavha-TmNL9TN-H8b8bAcemtZYD8xuBM=.8db45d0a-ec70-4bb9-875b-5d59536a7a1e@github.com>
Message-ID: <a-3b4wEOZf8aG5HunHFLWtLKaGOGSJElbun1YbVzDso=.a85b18de-64e4-4aaf-b77f-87ae0f2a5f49@github.com>

On Tue, 5 Aug 2025 01:42:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The DateTimeFormatterBuilder::FIELD_MAP previously used a Map<Character, TemporalField> 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
> <img width="2018" height="1016" alt="image" src="https://github.com/user-attachments/assets/57d4c513-55c7-472e-95a8-9f7a4b47662d" />

This pull request has now been integrated.

Changeset: 2c7f7380
Author:    Shaojin Wen <swen at openjdk.org>
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: <Q89FMcLl0Ud1vAfwa_qltsnb8Sg0Uw5AiQgKQY6cdkE=.41d2fc44-af81-4a75-9494-d62bb1bab30f@github.com>

On Thu, 2 Oct 2025 13:21:32 GMT, Marc Chevalier <mchevalier at openjdk.org> 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: <i96JH5gLBF8dqLJoJl2fZTUdqKdQUoStdCv7ypn8lJU=.ffa74907-ff5b-4262-885a-27889786b544@github.com>
References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com>
 <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com>
 <i96JH5gLBF8dqLJoJl2fZTUdqKdQUoStdCv7ypn8lJU=.ffa74907-ff5b-4262-885a-27889786b544@github.com>
Message-ID: <2vNtq03FnpQvKBx4QnRGZGyilEoIcgHRv_SoxPneE3U=.6e1c2c8f-8a89-482c-b2c6-8484ac6cd64b@github.com>

On Thu, 2 Oct 2025 13:24:25 GMT, Roger Riggs <rriggs at openjdk.org> 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: <HMDr8G0o2N5E4sAZr328oSrzLmNeIUNW8ct5-VVYwSU=.e77bf9c5-727b-456a-b095-98e2306a62a2@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
 <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>
 <Te4rI_U8oqzoaZjU2qMlboFjiXhTIX6v7uzGitVMpew=.befd073a-561c-46f6-8d4c-6cc5a64872b0@github.com>
 <cnqT7g1JdcDC0IjD8h386mUWQPL9AgcQOW_Djrjz4l4=.06a5f9be-ad54-4466-936d-7a443560cd2b@github.com>
 <pI0eJIHdSw72R3vuyOWeNuDZv796bVjCvaFFDag_m94=.fd65f249-5b40-408f-92e4-c85c4948fb42@github.com>
 <HMDr8G0o2N5E4sAZr328oSrzLmNeIUNW8ct5-VVYwSU=.e77bf9c5-727b-456a-b095-98e2306a62a2@github.com>
Message-ID: <yRn564YrhbIqkLxbIQu-sL3CsY78mrxNFwJqY-ISGNk=.a23fae24-6dc6-456a-a419-cd78e29fd8e6@github.com>

On Thu, 2 Oct 2025 11:29:12 GMT, Matthew Donovan <mdonovan at openjdk.org> 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: <vdKvjkidExuEdK_WZ-ledbDnM3pGRc4YpJiMT_9OHxo=.2da525da-b1a8-4659-81da-ed8a6d969427@github.com>

On Thu, 2 Oct 2025 03:08:32 GMT, Shaojin Wen <swen at openjdk.org> 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: <TBC_-bS0wveSnqaD7o2rlRCMe_gfBMJDaHTeO6tPJ8s=.751b9545-3c0b-4600-8976-df931df8c1ee@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
 <TBC_-bS0wveSnqaD7o2rlRCMe_gfBMJDaHTeO6tPJ8s=.751b9545-3c0b-4600-8976-df931df8c1ee@github.com>
Message-ID: <z96sMNXwnPPGZJYn-zXJdV3IWvGiB8Eli2-tpc13B4A=.0ba92a9c-066e-456b-ab88-d670d6ccb6bc@github.com>

On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao <wxiao at openjdk.org> 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: <d2jMeO5C4WaqV5Dc3B4uK811p4W3OEAD4Ei2eCmBgi4=.18db4564-0c0d-4dd9-baec-5d140c1fafc5@github.com>

On Thu, 2 Oct 2025 03:08:32 GMT, Shaojin Wen <swen at openjdk.org> 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: <nx0k_Ztbu0A3JxwOSUzwdytU3rZmBLMg6lYRmOQ1bOE=.6990c1e4-b4b4-4af2-8bff-7c60450bc12b@github.com>
References: <nx0k_Ztbu0A3JxwOSUzwdytU3rZmBLMg6lYRmOQ1bOE=.6990c1e4-b4b4-4af2-8bff-7c60450bc12b@github.com>
Message-ID: <qDgc_PNGitfNJUZdUgAOjLcnfYqr_CYnwEXMEZzt0dw=.9256c633-3ca8-4c11-9c00-fb06026aed97@github.com>

On Wed, 1 Oct 2025 22:31:42 GMT, Sergey Bylokhov <serb at openjdk.org> 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: <Vxqh4Dx-K3sxnxAH14UwT8H2d30k3o7Rkk6AF9Sz-Sk=.b3ca5f02-e65c-42a4-b969-2a96bfb8f49b@github.com>
References: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
 <Vxqh4Dx-K3sxnxAH14UwT8H2d30k3o7Rkk6AF9Sz-Sk=.b3ca5f02-e65c-42a4-b969-2a96bfb8f49b@github.com>
Message-ID: <DR69MXlA2RYW0WZcpjrkFO41pj9JG5uAZJX_iloFkOM=.647a66b0-a357-46d7-9866-af0dc6ed8bd6@github.com>

On Wed, 1 Oct 2025 22:51:30 GMT, Justin Lu <jlu at openjdk.org> 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: <rVC6-niGFQR7ZjTW-ErKCf6GNBrI1NZwYfYaRMuEzK4=.25e51b66-c369-4e4a-b616-a7fccc6323e0@github.com>

On Thu, 2 Oct 2025 03:08:32 GMT, Shaojin Wen <swen at openjdk.org> 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: <Ek4b4HPpiONBsl6MFHGYG0aYOUyzstegbkjNNrf9bBQ=.02004818-6848-4377-91e1-ac8db7cf3f69@github.com>
 <Jg0TGdv2bz0Dt5vD2zFGHvqSZygy68x9aXqITPN56oQ=.4e92edb0-1ead-4a0c-b4dc-7852bc39d9d6@github.com>
 <6sINPIjIQYrD8qnU5q_meoNELGlIYNLdQ1Va3lbXwSY=.4b5e4086-c4b0-4320-a27f-7d0c90b1a5dd@github.com>
Message-ID: <MGsTDuKG0DfD4a26R-tpzAy2-rt8axIxWPUPVcIkn6s=.f45ea45c-35b7-463f-b98e-ff4f4385cf82@github.com>

On Tue, 30 Sep 2025 06:28:18 GMT, Hannes Greule <hgreule at openjdk.org> 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: <adkkQyFUmbIi2nnI0WYZ9tyOF032SNqYWL4v8h0eti0=.65eedb8c-fbbc-44fd-92c2-b39073d36629@github.com>
References: <t15AeicU0KFhxQWVl1bOiXiUdOYsJ0ahNdfmLeI6vDI=.818b8f24-1494-4a4f-afed-2bf66c28688d@github.com>
 <adkkQyFUmbIi2nnI0WYZ9tyOF032SNqYWL4v8h0eti0=.65eedb8c-fbbc-44fd-92c2-b39073d36629@github.com>
Message-ID: <kZvzzItlLIlBKDFR_TWWJeo4-TJlknErGW46lxczCy0=.ba8e718c-81bd-4f58-abee-3ace5cf55367@github.com>

On Tue, 30 Sep 2025 20:00:09 GMT, Chen Liang <liach at openjdk.org> 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: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>

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: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
References: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
Message-ID: <Csuk4JZGVamA9S7JjE0PeqBaYpsRJ-L5k6Jc5lBJi2I=.ab4e2f1d-2383-4553-99a2-fa97af338994@github.com>

On Thu, 2 Oct 2025 15:39:51 GMT, Roger Riggs <rriggs at openjdk.org> 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: <DR69MXlA2RYW0WZcpjrkFO41pj9JG5uAZJX_iloFkOM=.647a66b0-a357-46d7-9866-af0dc6ed8bd6@github.com>
References: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
 <Vxqh4Dx-K3sxnxAH14UwT8H2d30k3o7Rkk6AF9Sz-Sk=.b3ca5f02-e65c-42a4-b969-2a96bfb8f49b@github.com>
 <DR69MXlA2RYW0WZcpjrkFO41pj9JG5uAZJX_iloFkOM=.647a66b0-a357-46d7-9866-af0dc6ed8bd6@github.com>
Message-ID: <qju_o-CV5SvjZ9GZPm6oU2rgiVymLCYxWfNGOi92fDM=.03564f63-a441-4c5b-abdc-c5e1c9713b0e@github.com>

On Thu, 2 Oct 2025 14:52:20 GMT, Roger Riggs <rriggs at openjdk.org> 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: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
References: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
Message-ID: <AJwExd1S3amjTfS8yaU6UZFSjGifPutTaYBr-Mg2b-k=.fc04b4d8-f4f3-4d31-9d8f-2c5ec387ce65@github.com>

> 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: <AJwExd1S3amjTfS8yaU6UZFSjGifPutTaYBr-Mg2b-k=.fc04b4d8-f4f3-4d31-9d8f-2c5ec387ce65@github.com>
References: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
 <AJwExd1S3amjTfS8yaU6UZFSjGifPutTaYBr-Mg2b-k=.fc04b4d8-f4f3-4d31-9d8f-2c5ec387ce65@github.com>
Message-ID: <hhzKTSMqDzP70GkFFxmf9jn8NYn0MNTpTnkFJVYuXMs=.fab84e21-6fac-4874-aae4-40229d18a419@github.com>

On Thu, 2 Oct 2025 16:14:45 GMT, Roger Riggs <rriggs at openjdk.org> 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: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
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: <hhzKTSMqDzP70GkFFxmf9jn8NYn0MNTpTnkFJVYuXMs=.fab84e21-6fac-4874-aae4-40229d18a419@github.com>
References: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
 <AJwExd1S3amjTfS8yaU6UZFSjGifPutTaYBr-Mg2b-k=.fc04b4d8-f4f3-4d31-9d8f-2c5ec387ce65@github.com>
 <hhzKTSMqDzP70GkFFxmf9jn8NYn0MNTpTnkFJVYuXMs=.fab84e21-6fac-4874-aae4-40229d18a419@github.com>
Message-ID: <WHV8D9QRxTZtuV5Uy4LncXg_Z6Xi0otsgQXog5oBgKM=.126c816e-3306-4f05-bfd5-0789ec5d5860@github.com>

On Thu, 2 Oct 2025 16:02:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> 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: <vpHfJiwCt65WNr6ouwXtjavIS0yn6YERHk6t2xZc1sk=.8f043373-7050-4c47-a889-c19cbe62c968@github.com>

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: <AJwExd1S3amjTfS8yaU6UZFSjGifPutTaYBr-Mg2b-k=.fc04b4d8-f4f3-4d31-9d8f-2c5ec387ce65@github.com>
References: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
 <AJwExd1S3amjTfS8yaU6UZFSjGifPutTaYBr-Mg2b-k=.fc04b4d8-f4f3-4d31-9d8f-2c5ec387ce65@github.com>
Message-ID: <irIlQBgW4UDBwYGiREyQ0n3rPbK6PWEVQNi6yyBixiw=.ca6f5328-1736-46e9-9d4e-13f2c0f77fad@github.com>

On Thu, 2 Oct 2025 16:17:32 GMT, Roger Riggs <rriggs at openjdk.org> 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: <vpHfJiwCt65WNr6ouwXtjavIS0yn6YERHk6t2xZc1sk=.8f043373-7050-4c47-a889-c19cbe62c968@github.com>
References: <vpHfJiwCt65WNr6ouwXtjavIS0yn6YERHk6t2xZc1sk=.8f043373-7050-4c47-a889-c19cbe62c968@github.com>
Message-ID: <uT_RDlJ7RmkXda87I_mYVZkslYiSeqX5OiqEC4ormcE=.e1eb8dea-e0cb-4fde-9e33-6447b5b6da89@github.com>

On Thu, 2 Oct 2025 16:22:56 GMT, Joe Darcy <darcy at openjdk.org> 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: <vpHfJiwCt65WNr6ouwXtjavIS0yn6YERHk6t2xZc1sk=.8f043373-7050-4c47-a889-c19cbe62c968@github.com>
References: <vpHfJiwCt65WNr6ouwXtjavIS0yn6YERHk6t2xZc1sk=.8f043373-7050-4c47-a889-c19cbe62c968@github.com>
Message-ID: <ufdnZqTKnhVLZD1YDYHUa2cym1zX6PmJLb7sQoGfoR4=.988a6aff-10e5-4e31-8903-f9dde3909365@github.com>

On Thu, 2 Oct 2025 16:22:56 GMT, Joe Darcy <darcy at openjdk.org> 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 <darcy at openjdk.org>
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: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
References: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
Message-ID: <sse-sbwwMkh_4JvEX31GcE-no415hlE_UNN_4yFrd9U=.c3a661d8-8eac-44d1-bad0-719bbbfd747d@github.com>

> 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: <qju_o-CV5SvjZ9GZPm6oU2rgiVymLCYxWfNGOi92fDM=.03564f63-a441-4c5b-abdc-c5e1c9713b0e@github.com>
References: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
 <Vxqh4Dx-K3sxnxAH14UwT8H2d30k3o7Rkk6AF9Sz-Sk=.b3ca5f02-e65c-42a4-b969-2a96bfb8f49b@github.com>
 <DR69MXlA2RYW0WZcpjrkFO41pj9JG5uAZJX_iloFkOM=.647a66b0-a357-46d7-9866-af0dc6ed8bd6@github.com>
 <qju_o-CV5SvjZ9GZPm6oU2rgiVymLCYxWfNGOi92fDM=.03564f63-a441-4c5b-abdc-c5e1c9713b0e@github.com>
Message-ID: <iB-2jXv2YT6xOvrVgTLDtkb9i-4_ZX2pcUQXUMRsqdM=.fad9113e-a3f8-4d32-9a47-ff875375f934@github.com>

On Thu, 2 Oct 2025 16:06:07 GMT, Naoto Sato <naoto at openjdk.org> 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: <AJwExd1S3amjTfS8yaU6UZFSjGifPutTaYBr-Mg2b-k=.fc04b4d8-f4f3-4d31-9d8f-2c5ec387ce65@github.com>
References: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
 <AJwExd1S3amjTfS8yaU6UZFSjGifPutTaYBr-Mg2b-k=.fc04b4d8-f4f3-4d31-9d8f-2c5ec387ce65@github.com>
Message-ID: <k9W3mWz-nlDw8o4oUq7uBh2n5vwW2Jpoz0w99MZjMHA=.304fd38e-b933-4d00-9b7f-37f1a25a48f0@github.com>

On Thu, 2 Oct 2025 16:17:32 GMT, Roger Riggs <rriggs at openjdk.org> 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: <Op-fmpm24yt9YrdnQ4mFKKuf2sGJDa5qii3tQDQiZPQ=.04918e80-dc2c-471a-bc1e-f4253dfaa6d9@github.com>
References: <SajkurwYpwnPA2of1eJk47j813Xm7otCmkk5fDXrKGs=.ca848b55-4134-48fa-9d24-11e81d1871c2@github.com>
 <Op-fmpm24yt9YrdnQ4mFKKuf2sGJDa5qii3tQDQiZPQ=.04918e80-dc2c-471a-bc1e-f4253dfaa6d9@github.com>
Message-ID: <otpxgRQj9DNU0Tjp6c3aGLT0xGONULEGiicmts1ewq0=.b2aa083a-9727-4289-96b8-6d458cc72461@github.com>

On Tue, 30 Sep 2025 13:26:54 GMT, Alan Bateman <alanb at openjdk.org> 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: <sse-sbwwMkh_4JvEX31GcE-no415hlE_UNN_4yFrd9U=.c3a661d8-8eac-44d1-bad0-719bbbfd747d@github.com>
References: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
 <sse-sbwwMkh_4JvEX31GcE-no415hlE_UNN_4yFrd9U=.c3a661d8-8eac-44d1-bad0-719bbbfd747d@github.com>
Message-ID: <FR5guD2ZhjVpLI1Cbh0_hqooqk9rfKSns9uEk-6ub5k=.7bd45aa9-7ad2-48a4-a75b-6793123f2445@github.com>

On Thu, 2 Oct 2025 16:58:41 GMT, Justin Lu <jlu at openjdk.org> 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: <SajkurwYpwnPA2of1eJk47j813Xm7otCmkk5fDXrKGs=.ca848b55-4134-48fa-9d24-11e81d1871c2@github.com>
References: <SajkurwYpwnPA2of1eJk47j813Xm7otCmkk5fDXrKGs=.ca848b55-4134-48fa-9d24-11e81d1871c2@github.com>
Message-ID: <ti4uwMA8dpSCLeP_P9FlGw3_OBQyUx6PTNSt1eKR7dY=.320a4cb4-98f9-4e40-bea9-3ee6b532aa5e@github.com>

> 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: <Op-fmpm24yt9YrdnQ4mFKKuf2sGJDa5qii3tQDQiZPQ=.04918e80-dc2c-471a-bc1e-f4253dfaa6d9@github.com>
References: <SajkurwYpwnPA2of1eJk47j813Xm7otCmkk5fDXrKGs=.ca848b55-4134-48fa-9d24-11e81d1871c2@github.com>
 <Op-fmpm24yt9YrdnQ4mFKKuf2sGJDa5qii3tQDQiZPQ=.04918e80-dc2c-471a-bc1e-f4253dfaa6d9@github.com>
Message-ID: <ovvJk5JdH8ITF9JgeaRAGMZ36J49CswGuYOihUSsiMY=.0e1ff162-219f-4682-9044-d7d97435ec6c@github.com>

On Tue, 30 Sep 2025 13:26:54 GMT, Alan Bateman <alanb at openjdk.org> 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: <y4T_mWSebkHr_bVAIWqRfRCK8gobIWTT_L70BLPhVQM=.63150ddc-99c3-4ae8-81c9-af2ccaecbe13@github.com>
References: <y4T_mWSebkHr_bVAIWqRfRCK8gobIWTT_L70BLPhVQM=.63150ddc-99c3-4ae8-81c9-af2ccaecbe13@github.com>
Message-ID: <6UL10SYr5G890rfretlI_p9x6bldmb5M962iEkmEnnk=.375cc226-b76a-4a89-9d6f-92b4946c623f@github.com>

On Tue, 23 Sep 2025 21:11:07 GMT, Joe Wang <joehw at openjdk.org> 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: <y4T_mWSebkHr_bVAIWqRfRCK8gobIWTT_L70BLPhVQM=.63150ddc-99c3-4ae8-81c9-af2ccaecbe13@github.com>
References: <y4T_mWSebkHr_bVAIWqRfRCK8gobIWTT_L70BLPhVQM=.63150ddc-99c3-4ae8-81c9-af2ccaecbe13@github.com>
Message-ID: <C6Cbfx0xlcboJ7Ws6mybRAB3RjlJ-xrK6RaLgHOf6Z8=.67d4cae0-1aab-4692-8256-422def94ee81@github.com>

On Tue, 23 Sep 2025 21:11:07 GMT, Joe Wang <joehw at openjdk.org> 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 <joehw at openjdk.org>
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: <AJwExd1S3amjTfS8yaU6UZFSjGifPutTaYBr-Mg2b-k=.fc04b4d8-f4f3-4d31-9d8f-2c5ec387ce65@github.com>
References: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
 <AJwExd1S3amjTfS8yaU6UZFSjGifPutTaYBr-Mg2b-k=.fc04b4d8-f4f3-4d31-9d8f-2c5ec387ce65@github.com>
Message-ID: <VpXMmSkKP8l1jDh8nfnlH8hH9PKB1f8rfSELXezKLI8=.baf98216-ee8c-4acc-8d6a-bd4c518e1a73@github.com>

On Thu, 2 Oct 2025 16:17:32 GMT, Roger Riggs <rriggs at openjdk.org> 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: <gIml69-bcFkT1V5ug3zT4fKrJBIv1lE8HDSZdas7Qgo=.a4e1f67b-086a-4f22-96aa-d5f4bd5a8a9d@github.com>
References: <TRqk-W4Y6V__UK59PvyxxHIVBKHmXlbTYhbnJxGC7PY=.8b79d76c-6346-4567-8d59-6d8f3e0fb1ac@github.com>
 <gIml69-bcFkT1V5ug3zT4fKrJBIv1lE8HDSZdas7Qgo=.a4e1f67b-086a-4f22-96aa-d5f4bd5a8a9d@github.com>
Message-ID: <zgGzMtVHoQwZbSoaBByC9ubn-sUIZ1STFvz8Kpo28jE=.32b171bc-6478-42ba-bc29-af2054f34ec5@github.com>

On Fri, 19 Sep 2025 20:44:54 GMT, Jatin Bhateja <jbhateja at openjdk.org> 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: <rVC6-niGFQR7ZjTW-ErKCf6GNBrI1NZwYfYaRMuEzK4=.25e51b66-c369-4e4a-b616-a7fccc6323e0@github.com>
References: <5xcmzM6BhoL-zhBZc_TrRSDCKBrOMqq8bRcmihc1zpU=.732bd228-f9ff-43f0-9771-56645dab6cd2@github.com>
 <-MQxYO6i5RCnBQ-1NTwm5GcwucQgqYXIRHlFvsxO17A=.a6846ed0-8cc5-4501-9b94-cafa62a4909e@github.com>
 <rVC6-niGFQR7ZjTW-ErKCf6GNBrI1NZwYfYaRMuEzK4=.25e51b66-c369-4e4a-b616-a7fccc6323e0@github.com>
Message-ID: <_6CJOczFmBqEl2qBXgJEYoj3jc9RxAfhN-ieR92zRAw=.0fc6f1e5-5653-4ca4-8db5-58a860002e04@github.com>

On Thu, 2 Oct 2025 15:11:05 GMT, Roger Riggs <rriggs at openjdk.org> 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: <h9eLdPF7ZpYGNw27p99jHmuEBrElfQFZqS6XZJcxgKU=.f2bb52ad-25da-48ca-8831-142bcac88987@github.com>
References: <h9eLdPF7ZpYGNw27p99jHmuEBrElfQFZqS6XZJcxgKU=.f2bb52ad-25da-48ca-8831-142bcac88987@github.com>
Message-ID: <aDmaWB-BPpo8GTJLMpjDISpAP8y2Z3CcSu3LDgjUAqo=.438edf0c-a434-49c7-873c-4771d2aa57f3@github.com>

> 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: <gIml69-bcFkT1V5ug3zT4fKrJBIv1lE8HDSZdas7Qgo=.a4e1f67b-086a-4f22-96aa-d5f4bd5a8a9d@github.com>
References: <TRqk-W4Y6V__UK59PvyxxHIVBKHmXlbTYhbnJxGC7PY=.8b79d76c-6346-4567-8d59-6d8f3e0fb1ac@github.com>
 <gIml69-bcFkT1V5ug3zT4fKrJBIv1lE8HDSZdas7Qgo=.a4e1f67b-086a-4f22-96aa-d5f4bd5a8a9d@github.com>
Message-ID: <hLWBpj28ovRVmVEFph-jMAclHf0Rt1jBSWTu4_0gvv8=.e24b37a6-6694-4f8f-8ae9-dc53507968fe@github.com>

On Fri, 19 Sep 2025 20:44:54 GMT, Jatin Bhateja <jbhateja at openjdk.org> 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<juint> 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: <AJwExd1S3amjTfS8yaU6UZFSjGifPutTaYBr-Mg2b-k=.fc04b4d8-f4f3-4d31-9d8f-2c5ec387ce65@github.com>
References: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
 <AJwExd1S3amjTfS8yaU6UZFSjGifPutTaYBr-Mg2b-k=.fc04b4d8-f4f3-4d31-9d8f-2c5ec387ce65@github.com>
Message-ID: <A7zOOHv8RypvKcy06bTkAjU5dMOjV671zd8Sl_qkmrU=.413e9c9d-4d11-4dc6-8bc8-d3636e5fc197@github.com>

On Thu, 2 Oct 2025 16:17:32 GMT, Roger Riggs <rriggs at openjdk.org> 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: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
References: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
Message-ID: <T-3t0TNLhyW5F8go5L_thKzcNeTzYBcOIyFYvBa4BTQ=.5b20856e-34b8-40f5-82a0-b29c365461ec@github.com>

> 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: <XLScJW2bF1SqJ57jGi_0lasslXEaQN2LWukDzWbfwqg=.3a924f83-89ab-4a19-bdd7-7ee5a598a686@github.com>
References: <PjC2_W6FCwj1IhMOjyYiJTwOywQr1yhmPWHPbz3v-EY=.3547aa18-f4c9-4c11-bf7e-ca2ea8c7ab76@github.com>
 <XLScJW2bF1SqJ57jGi_0lasslXEaQN2LWukDzWbfwqg=.3a924f83-89ab-4a19-bdd7-7ee5a598a686@github.com>
Message-ID: <P-RhE4TAVsMFwaTgNc0Q5lTjK0eTCWT3K-I1Smuus1o=.84af8880-6b33-413d-8249-e7a68331ba4a@github.com>

On Tue, 30 Sep 2025 23:42:13 GMT, Chen Liang <liach at openjdk.org> 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: <cfOyHraZ1JATK3on7Gda5nnWhrsDEy6udH95iD-UZKA=.892185ef-8cca-4fa4-9497-2851dc4cd34f@github.com>
References: <cfOyHraZ1JATK3on7Gda5nnWhrsDEy6udH95iD-UZKA=.892185ef-8cca-4fa4-9497-2851dc4cd34f@github.com>
Message-ID: <mCUADni_gUlA29vBc29QpFXZgS0P_pkxNw6UTQrYzSo=.92abbe76-effc-4a9e-8978-048acff441d0@github.com>

On Fri, 26 Sep 2025 22:13:00 GMT, Chen Liang <liach at openjdk.org> 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: <KBRcnxykgoG61A0RKEfU9_OlEf6lLywAeEFXhWXNvrA=.e520d437-11b7-498a-bd60-4c735f6c61f1@github.com>
References: <ARjI44UG551o1xr4FOT8ezBDuSnuH0svvgwNOVMuvZs=.050eb1e6-f771-4c23-8d37-84506bf889cf@github.com>
 <KBRcnxykgoG61A0RKEfU9_OlEf6lLywAeEFXhWXNvrA=.e520d437-11b7-498a-bd60-4c735f6c61f1@github.com>
Message-ID: <lPp0IyAl9Q7ExrFt_7qxgWi4xoK5mNppY7pN1gRORFc=.836af5bf-72cf-426b-b63f-0065440971c5@github.com>

On Mon, 29 Sep 2025 04:22:24 GMT, Johny Jose <duke at openjdk.org> 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: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
References: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
Message-ID: <HcQDG4_4ukoWMaxnKbYEsemsWFjCo6nxT0llWoEpoWs=.81b63298-383b-43ad-b7a7-4b53e6114728@github.com>

> 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: <WAXQf1FEsZ3jfG--7a02YRUlhA_nhW-a5dB_SzS_xw4=.0b13f1ac-3a0d-441b-9194-a3f308b63416@github.com>
References: <RjyF_DJ4j4gvwkut_U8a_UMH6YLIKHPv2NBMKyImAWQ=.2294d54f-a8fa-47cd-b275-b2c8fee197ed@github.com>
 <WAXQf1FEsZ3jfG--7a02YRUlhA_nhW-a5dB_SzS_xw4=.0b13f1ac-3a0d-441b-9194-a3f308b63416@github.com>
Message-ID: <E9tkhTXuNEn7gxJ-RDCNjHwKIad27A2sS4S6zIb_WpM=.8c4b37c6-b737-40f5-81ad-0adf673de5e6@github.com>

On Thu, 2 Oct 2025 02:26:33 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <HcQDG4_4ukoWMaxnKbYEsemsWFjCo6nxT0llWoEpoWs=.81b63298-383b-43ad-b7a7-4b53e6114728@github.com>
References: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
 <HcQDG4_4ukoWMaxnKbYEsemsWFjCo6nxT0llWoEpoWs=.81b63298-383b-43ad-b7a7-4b53e6114728@github.com>
Message-ID: <SWyDeDj1XzvxaJUQLf-8ROUa61vYxtbGVqf1rPhcDUo=.4113f034-2d60-4945-befe-f87d5f932bd0@github.com>

On Fri, 3 Oct 2025 14:51:39 GMT, Roger Riggs <rriggs at openjdk.org> 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: <sse-sbwwMkh_4JvEX31GcE-no415hlE_UNN_4yFrd9U=.c3a661d8-8eac-44d1-bad0-719bbbfd747d@github.com>
References: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
 <sse-sbwwMkh_4JvEX31GcE-no415hlE_UNN_4yFrd9U=.c3a661d8-8eac-44d1-bad0-719bbbfd747d@github.com>
Message-ID: <8vPRllD5nujUmTtZsCiC-AhlBVi1G_DCFuXVQT4biTo=.e39d8ddf-9ba5-4447-bfbb-c10c60c61b69@github.com>

On Thu, 2 Oct 2025 16:58:41 GMT, Justin Lu <jlu at openjdk.org> 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: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
References: <lEClwPdpgB7129UT2s9YDP93xj5BFRR9u2LHskVPuR4=.530b9c2f-226b-4c42-950c-f59b8972a0b1@github.com>
Message-ID: <2t4pwt6e4uOa9YOGmOoNeUmM0vmxrwSq5gatLH2lKMM=.eea1f7b4-504d-4891-95d9-05e8fca18eea@github.com>

On Wed, 1 Oct 2025 21:11:53 GMT, Justin Lu <jlu at openjdk.org> 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 <jlu at openjdk.org>
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: <rCRoWSb_UHuPPcts31uFu95deyNchRnoMmu11JFwHmc=.ac98e5e0-38ae-49ad-90ee-8e4d88f55539@github.com>

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: <cKd3ERLoTbs6DSPK203HD7eZvUe8io5OHh6ubp1OzOw=.6fe1c6b3-eee8-45b3-9de6-8d5ace2ccd88@github.com>
References: <cKd3ERLoTbs6DSPK203HD7eZvUe8io5OHh6ubp1OzOw=.6fe1c6b3-eee8-45b3-9de6-8d5ace2ccd88@github.com>
Message-ID: <VIAgVhOQob_U0Vf-8fA0q-D87pwa2UUi_PeXulB8ekg=.43f825c8-c9a9-4e7b-b90c-b199357cdb1a@github.com>

> 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: <cKd3ERLoTbs6DSPK203HD7eZvUe8io5OHh6ubp1OzOw=.6fe1c6b3-eee8-45b3-9de6-8d5ace2ccd88@github.com>
 <0wdfY8mtBcpaQQx0GmUu2iGyvqYRVQlpKZjVyo770fY=.8cd2fb63-b204-405d-bd4a-7150f7f688b0@github.com>
Message-ID: <PrixVmBhPbRi4mBJDU_QShJ4SjMHdgI4DnGr94AClxw=.edbdb6b1-ded1-4e7c-909d-d2a266dbacc8@github.com>

On Fri, 3 Oct 2025 05:33:41 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <liRifFe1zp9_FzQOuhfu1EpfD11mEpxkW8SEGSR0tm8=.1b39fe33-3f4c-470d-b633-590f64374d3a@github.com>
References: <cKd3ERLoTbs6DSPK203HD7eZvUe8io5OHh6ubp1OzOw=.6fe1c6b3-eee8-45b3-9de6-8d5ace2ccd88@github.com>
 <liRifFe1zp9_FzQOuhfu1EpfD11mEpxkW8SEGSR0tm8=.1b39fe33-3f4c-470d-b633-590f64374d3a@github.com>
Message-ID: <yMlysZ-f-3im5W1bucnwmJ9_H5q_DYHIR5CsBCNmPfs=.ce93f118-1a95-42ed-8dec-684ebc9fdf14@github.com>

On Fri, 3 Oct 2025 05:41:58 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <VIAgVhOQob_U0Vf-8fA0q-D87pwa2UUi_PeXulB8ekg=.43f825c8-c9a9-4e7b-b90c-b199357cdb1a@github.com>
References: <cKd3ERLoTbs6DSPK203HD7eZvUe8io5OHh6ubp1OzOw=.6fe1c6b3-eee8-45b3-9de6-8d5ace2ccd88@github.com>
 <VIAgVhOQob_U0Vf-8fA0q-D87pwa2UUi_PeXulB8ekg=.43f825c8-c9a9-4e7b-b90c-b199357cdb1a@github.com>
Message-ID: <YIFHsCtrhsqmLYAG2bVWOmOtSqXIbzdakGE2-0z9sdw=.2b525659-7b90-46b6-9b0f-415f2b4d763c@github.com>

On Fri, 3 Oct 2025 17:34:24 GMT, Mahendra Chhipa <mchhipa at openjdk.org> 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: <YIFHsCtrhsqmLYAG2bVWOmOtSqXIbzdakGE2-0z9sdw=.2b525659-7b90-46b6-9b0f-415f2b4d763c@github.com>
References: <cKd3ERLoTbs6DSPK203HD7eZvUe8io5OHh6ubp1OzOw=.6fe1c6b3-eee8-45b3-9de6-8d5ace2ccd88@github.com>
 <VIAgVhOQob_U0Vf-8fA0q-D87pwa2UUi_PeXulB8ekg=.43f825c8-c9a9-4e7b-b90c-b199357cdb1a@github.com>
 <YIFHsCtrhsqmLYAG2bVWOmOtSqXIbzdakGE2-0z9sdw=.2b525659-7b90-46b6-9b0f-415f2b4d763c@github.com>
Message-ID: <Aeyj9HgATCVf60_0dae9Ta2q514fLAN0He1DYFENSHM=.28ecdc34-62d3-4fc0-940e-508b41b9dc19@github.com>

On Fri, 3 Oct 2025 17:47:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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: <aDmaWB-BPpo8GTJLMpjDISpAP8y2Z3CcSu3LDgjUAqo=.438edf0c-a434-49c7-873c-4771d2aa57f3@github.com>
References: <h9eLdPF7ZpYGNw27p99jHmuEBrElfQFZqS6XZJcxgKU=.f2bb52ad-25da-48ca-8831-142bcac88987@github.com>
 <aDmaWB-BPpo8GTJLMpjDISpAP8y2Z3CcSu3LDgjUAqo=.438edf0c-a434-49c7-873c-4771d2aa57f3@github.com>
Message-ID: <o-8hP91xsY_DAXKUwlMASsfKFELbxesLyRcFfM-gtms=.ff587677-3212-4f30-ae9e-efdf6ea5a3b6@github.com>

On Fri, 3 Oct 2025 09:50:23 GMT, Pavel Rappo <prappo at openjdk.org> 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: <aDmaWB-BPpo8GTJLMpjDISpAP8y2Z3CcSu3LDgjUAqo=.438edf0c-a434-49c7-873c-4771d2aa57f3@github.com>
References: <h9eLdPF7ZpYGNw27p99jHmuEBrElfQFZqS6XZJcxgKU=.f2bb52ad-25da-48ca-8831-142bcac88987@github.com>
 <aDmaWB-BPpo8GTJLMpjDISpAP8y2Z3CcSu3LDgjUAqo=.438edf0c-a434-49c7-873c-4771d2aa57f3@github.com>
Message-ID: <gb4LQQ_O63ois_zUytSEp85rGGqYonMW5QnEvu29dyc=.c7313b9d-8572-4d7e-b9a7-43e32b872ac5@github.com>

On Fri, 3 Oct 2025 09:50:23 GMT, Pavel Rappo <prappo at openjdk.org> 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: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
References: <ExMPsCPJwjysFT7gz8oeuCXFW71-OmIgmGOnANbwI98=.58aad4df-f8d4-4185-b7a2-dc313cbefcd1@github.com>
Message-ID: <PpNHeV9t7h6i82Zoypd7-jugWJngM_wlCYD3khDs1l8=.83d69b12-5e94-443c-a3ea-870483ec2f27@github.com>

On Thu, 2 Oct 2025 15:39:51 GMT, Roger Riggs <rriggs at openjdk.org> 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 <rriggs at openjdk.org>
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: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@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<String> 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 <em>Unicode case folding</em>. Two strings are considered equal
     * by this method if their case-folded forms are identical.
     * <p>
     * Case folding is defined by the Unicode Standard in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * 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"}.
     * <p>
     * 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:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }</pre>
     *
     * @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 <em>Unicode case folding</em>.
     * 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
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}.
     * <p>
     * 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 <em>full</em> case folding, providing stable and
     * consistent results across all environments.
     * <p>
     * Note that this method does <em>not</em> 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 <em>full</em> case folding
     * as defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code compareToIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }</pre>
     *
     * @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<String> 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 extends Appendable> 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: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>
References: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>
Message-ID: <XmrPXxWubXK0V4sLHruFfklfLmOWQcfYo_65VZH7WZY=.c9abec92-cae1-4927-b74a-928b9ecd5807@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<String> 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: <XmrPXxWubXK0V4sLHruFfklfLmOWQcfYo_65VZH7WZY=.c9abec92-cae1-4927-b74a-928b9ecd5807@github.com>
References: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>
 <XmrPXxWubXK0V4sLHruFfklfLmOWQcfYo_65VZH7WZY=.c9abec92-cae1-4927-b74a-928b9ecd5807@github.com>
Message-ID: <QsU_oaagatZATmQKQDWE7gOvX7P-BFrwf8y5VV5Ccmw=.6785e1a0-c6bd-49eb-a808-ce5155c3d82e@github.com>

On Fri, 3 Oct 2025 19:41:20 GMT, Xueming Shen <sherman at openjdk.org> 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<String> 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: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>
References: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>
Message-ID: <j2PytCsaYuRiL0kiYcq0yxgMfJHH0NjNUGVm-3vIm-k=.f1add041-3639-4f59-ae67-a7a1570bd40f@github.com>

On Fri, 22 Aug 2025 03:50:03 GMT, Xueming Shen <sherman at openjdk.org> 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<String> 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<String> 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 <em>Unicode case folding</em>. Two strings are considered equal
     * by this method if their case-folded forms are identical.
     * <p>
     * Case folding is defined by the Unicode Standard in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * 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"}.
     * <p>
     * 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:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }</pre>
     *
     * @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 <em>Unicode case folding</em>.
     * 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
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}.
     * <p>
     * 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 <em>full</em> case folding, providing stable and
     * consistent results across all environments.
     * <p>
     * Note that this method does <em>not</em> 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 <em>full</em> case folding
     * as defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code compareToIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }</pre>
     *
     * @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<String> 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 extends Appendable> 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: <RjyF_DJ4j4gvwkut_U8a_UMH6YLIKHPv2NBMKyImAWQ=.2294d54f-a8fa-47cd-b275-b2c8fee197ed@github.com>
References: <RjyF_DJ4j4gvwkut_U8a_UMH6YLIKHPv2NBMKyImAWQ=.2294d54f-a8fa-47cd-b275-b2c8fee197ed@github.com>
Message-ID: <de7p3F_z9y179dyfwniHxOYFyUgjU_cPa0oP9-tma9I=.cc075fbb-3835-4822-ad83-8454eae8fe85@github.com>

> - 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: <E9tkhTXuNEn7gxJ-RDCNjHwKIad27A2sS4S6zIb_WpM=.8c4b37c6-b737-40f5-81ad-0adf673de5e6@github.com>
References: <RjyF_DJ4j4gvwkut_U8a_UMH6YLIKHPv2NBMKyImAWQ=.2294d54f-a8fa-47cd-b275-b2c8fee197ed@github.com>
 <WAXQf1FEsZ3jfG--7a02YRUlhA_nhW-a5dB_SzS_xw4=.0b13f1ac-3a0d-441b-9194-a3f308b63416@github.com>
 <E9tkhTXuNEn7gxJ-RDCNjHwKIad27A2sS4S6zIb_WpM=.8c4b37c6-b737-40f5-81ad-0adf673de5e6@github.com>
Message-ID: <HDkBa2ivY3XhXgGI0uOwkYs5-jLD2rUvdaRzXCjySQQ=.80a3af3c-65d0-4b3e-b906-67af40f8ffd1@github.com>

On Fri, 3 Oct 2025 14:57:21 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> 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: <RjyF_DJ4j4gvwkut_U8a_UMH6YLIKHPv2NBMKyImAWQ=.2294d54f-a8fa-47cd-b275-b2c8fee197ed@github.com>
References: <RjyF_DJ4j4gvwkut_U8a_UMH6YLIKHPv2NBMKyImAWQ=.2294d54f-a8fa-47cd-b275-b2c8fee197ed@github.com>
Message-ID: <Fm-3aNVl3Vl5sb6_wdBZeGMpst0KH3ofweUHF1Yx_UU=.2e54a3f7-14bf-4d4e-a7bf-29909e386dce@github.com>

> - 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: <nx0k_Ztbu0A3JxwOSUzwdytU3rZmBLMg6lYRmOQ1bOE=.6990c1e4-b4b4-4af2-8bff-7c60450bc12b@github.com>
References: <nx0k_Ztbu0A3JxwOSUzwdytU3rZmBLMg6lYRmOQ1bOE=.6990c1e4-b4b4-4af2-8bff-7c60450bc12b@github.com>
Message-ID: <GEf6MpXP8cxGY0FKZ8sMYWuE3HRh1SnW0TZqLkhcIJ0=.a3aa03b4-6f2e-4931-86e2-50b36f92f0a3@github.com>

> 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