From serb at openjdk.org  Thu Jan  1 04:24:24 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 1 Jan 2026 04:24:24 GMT
Subject: Withdrawn: 8374320: Update copyright year to 2025 for java.net.http in
 files where it was missed
In-Reply-To: <i1BM1nHJu2w611rqvMcufkN4_ommsmNTzqCAoH6ZoI0=.82c59e6f-53ac-47c9-8f00-aa6db1c0f93d@github.com>
References: <i1BM1nHJu2w611rqvMcufkN4_ommsmNTzqCAoH6ZoI0=.82c59e6f-53ac-47c9-8f00-aa6db1c0f93d@github.com>
Message-ID: <zYIlVtcK68eED3BdTEfHQQl4ow1lpsna9z9Ozp5zGwE=.a8399be1-3dc7-47df-9942-0887d23da6d8@github.com>

On Wed, 24 Dec 2025 02:05:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "java.net.http" files updated in 2025 has been bumped to 2025. All files are updated which touched the src/java.net.http and related files.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `
> git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

This pull request has been closed without being integrated.

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

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

From weijun at openjdk.org  Thu Jan  1 04:40:00 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Jan 2026 04:40:00 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <G1HpP1CVgjD-6dUfPU61Bj3FbScVg4pd_LZskbKdtvI=.dcbac94b-65aa-450d-8046-76e7a21b4664@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <G1HpP1CVgjD-6dUfPU61Bj3FbScVg4pd_LZskbKdtvI=.dcbac94b-65aa-450d-8046-76e7a21b4664@github.com>
Message-ID: <7sRIajvnH0fG2sLvkHlDnAAZYUKQr1S3A7_5gVEIvN0=.d2153bfd-0dd7-4e2a-86fc-aaafbf990476@github.com>

On Tue, 30 Dec 2025 22:37:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rewrite without jextract
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 152:
> 
>> 150:             int out = (int) getpwuid_r.invokeExact(
>> 151:                     tmpUid, resbuf, pwd_buf, GETPW_R_SIZE_MAX, pwd);
>> 152:             if (out != 0 || pwd.get(ValueLayout.ADDRESS, 0).equals(MemorySegment.NULL)) {
> 
> The additional `|| pwd.get(ValueLayout.ADDRESS, 0).equals(MemorySegment.NULL)` breaks AIX. The included test passes when we remove it and we get the correct username.
> @JoKern65, @varada1110: Do you know why `getpwuid_r` writes nullptr (or nothing) to `result` on a successful query?

First, thank you so much for the experiments.

Here, I think I follow the C checks in the old `Unix.c`:

    if (getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd) == 0 &&
            pwd != NULL) {

How did it run in AIX?

> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 155:
> 
>> 153:                 uid = tmpUid;
>> 154:                 gid = (int)getgid.invokeExact();
>> 155:                 username = null;
> 
> Setting it to `null` will cause `NullPointerException` in the `UnixPrincipal` constructor.

Hmm, maybe this has never happened before. If the username is really not available, we should not add a `UnixPrincipal`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2656083411
PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2656083377

From mdoerr at openjdk.org  Fri Jan  2 13:10:54 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jan 2026 13:10:54 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <7sRIajvnH0fG2sLvkHlDnAAZYUKQr1S3A7_5gVEIvN0=.d2153bfd-0dd7-4e2a-86fc-aaafbf990476@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <G1HpP1CVgjD-6dUfPU61Bj3FbScVg4pd_LZskbKdtvI=.dcbac94b-65aa-450d-8046-76e7a21b4664@github.com>
 <7sRIajvnH0fG2sLvkHlDnAAZYUKQr1S3A7_5gVEIvN0=.d2153bfd-0dd7-4e2a-86fc-aaafbf990476@github.com>
Message-ID: <fKVrINT5UQC4O_U2Z8N974A7tl1-HXbgRNjeMXnG9bY=.2632a586-1679-40c2-bd93-2350baf4c8b4@github.com>

On Thu, 1 Jan 2026 04:37:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 152:
>> 
>>> 150:             int out = (int) getpwuid_r.invokeExact(
>>> 151:                     tmpUid, resbuf, pwd_buf, GETPW_R_SIZE_MAX, pwd);
>>> 152:             if (out != 0 || pwd.get(ValueLayout.ADDRESS, 0).equals(MemorySegment.NULL)) {
>> 
>> The additional `|| pwd.get(ValueLayout.ADDRESS, 0).equals(MemorySegment.NULL)` breaks AIX. The included test passes when we remove it and we get the correct username.
>> @JoKern65, @varada1110: Do you know why `getpwuid_r` writes nullptr (or nothing) to `result` on a successful query?
>
> First, thank you so much for the experiments.
> 
> Here, I think I follow the C checks in the old `Unix.c`:
> 
>     if (getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd) == 0 &&
>             pwd != NULL) {
> 
> How did it run in AIX?

The old C code works on AIX. I haven't figured out what causes different behavior with the new code. Note that the new code works on linux on ppc64 (big and little endian).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657691333

From abarashev at openjdk.org  Fri Jan  2 13:31:14 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 2 Jan 2026 13:31:14 GMT
Subject: Integrated: 8374317: Change GCM IV size to 12 bytes when
 encrypting/decrypting TLS session ticket
In-Reply-To: <BTdxt19883hVhWz8PBz1fxrTizCPDuoONkVZ74Ztoek=.ec4b4294-be65-40da-afa3-b5ddd5612afc@github.com>
References: <BTdxt19883hVhWz8PBz1fxrTizCPDuoONkVZ74Ztoek=.ec4b4294-be65-40da-afa3-b5ddd5612afc@github.com>
Message-ID: <Dk8ERF0H-J5yeOnXoBOGr17_q5SgSjTnhZlkvPlwc-4=.ebb246ae-9ef9-4f9a-87f9-7157062449f2@github.com>

On Wed, 24 Dec 2025 00:40:05 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> 12 bytes is the recommended size for GCM per NIST SP 800-38D:
> 
> For IVs, it is recommended that implementations restrict support to the length of 96 bits, to
> promote interoperability, efficiency, and simplicity of design.`
> 
> Larger IV size requires an extra hashing step (GHASH). Currently we have it set to 16 bytes.

This pull request has now been integrated.

Changeset: 34395124
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34395124018c434b0bad534cb6f85452466fd404
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket

Reviewed-by: djelinski, mpowers, ascarpino

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

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

From mdoerr at openjdk.org  Fri Jan  2 13:37:57 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jan 2026 13:37:57 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
Message-ID: <PxesRloLikfstlNxnlwwr1ybe0kSra3mA63AHW_SCbE=.a2c363d0-1deb-4b59-b53f-53c0019ff081@github.com>

On Mon, 22 Dec 2025 14:47:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewrite without jextract

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 83:

> 81:     private static final ValueLayout.OfLong C_LONG
> 82:             = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long");
> 83: 

These functions are probably always fast and never block, right?
If so, we could use `Linker.Option.critical` to make the calls faster if performance is important.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657727804

From abarashev at openjdk.org  Fri Jan  2 13:47:33 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 2 Jan 2026 13:47:33 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints [v3]
In-Reply-To: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
Message-ID: <RB7705SFSJdZVj8JwAiLNvpyAT4zoVpljNPprt0D5Dg=.9b73ee93-938b-496f-987e-ccb7cb8028c3@github.com>

> NamedGroup.SupportedGroups.namedGroups values are not being filtered against algorithm constraints, unlike other SSLParameters returned by SSLConfiguration#getSSLParameters() call. Those are the values being displayed to the user with "java -XshowSettings:security:tls" command.
> 
> Also making changes to avoid needless default group names lookup while we are touching this file.

Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Update copyright year
 - Merge branch 'master' into JDK-8370885
 - Merge branch 'master' into JDK-8370885
   
   # Conflicts:
   #	src/java.base/share/classes/sun/security/ssl/NamedGroup.java
 - 8370885: Default namedGroups values are not being filtered against algorithm constraints

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

Changes: https://git.openjdk.org/jdk/pull/28397/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28397&range=02
  Stats: 224 lines in 2 files changed: 153 ins; 41 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/28397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28397/head:pull/28397

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

From weijun at openjdk.org  Fri Jan  2 13:48:53 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 13:48:53 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <fKVrINT5UQC4O_U2Z8N974A7tl1-HXbgRNjeMXnG9bY=.2632a586-1679-40c2-bd93-2350baf4c8b4@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <G1HpP1CVgjD-6dUfPU61Bj3FbScVg4pd_LZskbKdtvI=.dcbac94b-65aa-450d-8046-76e7a21b4664@github.com>
 <7sRIajvnH0fG2sLvkHlDnAAZYUKQr1S3A7_5gVEIvN0=.d2153bfd-0dd7-4e2a-86fc-aaafbf990476@github.com>
 <fKVrINT5UQC4O_U2Z8N974A7tl1-HXbgRNjeMXnG9bY=.2632a586-1679-40c2-bd93-2350baf4c8b4@github.com>
Message-ID: <xszXy9Y-chIP9MYeZ3jQmwDuyCaBwb6nNgdEdbOGjlk=.22fbf94d-df8f-413a-8fe3-5d844651ffa0@github.com>

On Fri, 2 Jan 2026 13:08:35 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> First, thank you so much for the experiments.
>> 
>> Here, I think I follow the C checks in the old `Unix.c`:
>> 
>>     if (getpwuid_r(getuid(), &resbuf, pwd_buf, sizeof(pwd_buf), &pwd) == 0 &&
>>             pwd != NULL) {
>> 
>> How did it run in AIX?
>
> The old C code works on AIX. I haven't figured out what causes different behavior with the new code. Note that the new code works on linux on ppc64 (big and little endian).

I tried on both macOS and Linux and `pwd.get(ValueLayout.ADDRESS, 0)` and `resbuf` ended up having the same address. This is consistent to what the doc requires. On the other hand, I tried to pass in a fake uid, the function returned 0 and `pwd` pointed to null. If I ignore the check, my test program crashed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657743731

From weijun at openjdk.org  Fri Jan  2 14:00:54 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 14:00:54 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <PxesRloLikfstlNxnlwwr1ybe0kSra3mA63AHW_SCbE=.a2c363d0-1deb-4b59-b53f-53c0019ff081@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <PxesRloLikfstlNxnlwwr1ybe0kSra3mA63AHW_SCbE=.a2c363d0-1deb-4b59-b53f-53c0019ff081@github.com>
Message-ID: <bD5X3dqYsWjc_3II_a_UaRk7vMGQClxBjS-wwwLrppo=.52298726-143d-49fe-8d96-4df58b22422d@github.com>

On Fri, 2 Jan 2026 13:34:57 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rewrite without jextract
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 83:
> 
>> 81:     private static final ValueLayout.OfLong C_LONG
>> 82:             = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long");
>> 83: 
> 
> These functions are probably always fast and never block, right?
> If so, we could use `Linker.Option.critical` to make the calls faster if performance is important.

Maybe not necessary, in JAAS one should not login again and again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657759208

From mdoerr at openjdk.org  Fri Jan  2 14:27:00 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jan 2026 14:27:00 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
Message-ID: <u5rtXHJBKZzgE5mWjYj2S5U8JYeUTh4s9zKvQtEIz4U=.fd9de106-094f-41ae-8b7c-95d222993598@github.com>

On Mon, 22 Dec 2025 14:47:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewrite without jextract

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 96:

> 94:             .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
> 95:                     FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
> 96:                             C_LONG, C_POINTER));

`C_LONG` looks wrong for 32 bit platforms (arm 32).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657805167

From abarashev at openjdk.org  Fri Jan  2 15:02:31 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 2 Jan 2026 15:02:31 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints [v4]
In-Reply-To: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
Message-ID: <SvUGi7_7e6pvwmVOec0MTv33yavtP2Ve3ixb7WanHnQ=.c3cfc626-657b-4076-ada1-3b5eae49418a@github.com>

> NamedGroup.SupportedGroups.namedGroups values are not being filtered against algorithm constraints, unlike other SSLParameters returned by SSLConfiguration#getSSLParameters() call. Those are the values being displayed to the user with "java -XshowSettings:security:tls" command.
> 
> Also making changes to avoid needless default group names lookup while we are touching this file.

Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8370885
   
   # Conflicts:
   #	src/java.base/share/classes/sun/security/ssl/NamedGroup.java
 - Update copyright year
 - Merge branch 'master' into JDK-8370885
 - Merge branch 'master' into JDK-8370885
   
   # Conflicts:
   #	src/java.base/share/classes/sun/security/ssl/NamedGroup.java
 - 8370885: Default namedGroups values are not being filtered against algorithm constraints

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

Changes: https://git.openjdk.org/jdk/pull/28397/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28397&range=03
  Stats: 224 lines in 2 files changed: 153 ins; 41 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/28397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28397/head:pull/28397

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

From weijun at openjdk.org  Fri Jan  2 15:28:20 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 15:28:20 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v3]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <Q2DtlfyzOc5GFTZMWsMowij3HdS-78iEoISKZBu6-SI=.7b94def9-f438-431d-8e35-1c7813caa284@github.com>

> Rewrite the native calls with FFM.

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

  error handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/8c0c7c0b..fa1a511c

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

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

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

From weijun at openjdk.org  Fri Jan  2 15:38:59 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 15:38:59 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <u5rtXHJBKZzgE5mWjYj2S5U8JYeUTh4s9zKvQtEIz4U=.fd9de106-094f-41ae-8b7c-95d222993598@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <u5rtXHJBKZzgE5mWjYj2S5U8JYeUTh4s9zKvQtEIz4U=.fd9de106-094f-41ae-8b7c-95d222993598@github.com>
Message-ID: <h1uRSpSClxalHlIBspl3Jgo9SFs8AHA7FaL3CGgUJds=.5ca2823d-38a5-4163-b745-f72ebeed0422@github.com>

On Fri, 2 Jan 2026 14:23:58 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rewrite without jextract
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 96:
> 
>> 94:             .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
>> 95:                     FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
>> 96:                             C_LONG, C_POINTER));
> 
> `C_LONG` looks wrong for 32 bit platforms (arm 32). Note that `size_t` is supported by `canonicalLayouts`.

Do you see 64 bit?
<img width="588" height="306" alt="Screenshot 2026-01-02 at 10 26 20" src="https://github.com/user-attachments/assets/82106d61-27f8-4871-a890-039971665e62" />
There is no arm32 here so I assume it will be the `FallbackLinker`. The size will be returned by a JNI function `ffi_sizeof_long()`. No idea how it could go wrong.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657919123

From mullan at openjdk.org  Fri Jan  2 15:40:21 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 2 Jan 2026 15:40:21 GMT
Subject: RFR: 8369282: Distrust TLS server certificates anchored by
 Chunghwa ePKI Root CA [v2]
In-Reply-To: <MvLEAe_wRx-W5ilMG3Jqy2iHi0gv6b8TWhmfoWhuGGw=.fb6823e1-6db5-4ffe-94c9-ad23bf3c720a@github.com>
References: <fTAmOVJi88B74grU7hUK5pPmpdDXdfSRiyqqYTvPscM=.53c29683-d76f-42b2-8299-39032b47c620@github.com>
 <MvLEAe_wRx-W5ilMG3Jqy2iHi0gv6b8TWhmfoWhuGGw=.fb6823e1-6db5-4ffe-94c9-ad23bf3c720a@github.com>
Message-ID: <bE4XXy-Ka6K40xv13BiOfURxI0roPYWFvX43HlqaFGs=.9b7e5e08-6f8a-406c-a6d1-96c4c2c56a01@github.com>

On Wed, 24 Dec 2025 19:35:48 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8369282](https://bugs.openjdk.org/browse/JDK-8369282)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Mikhail

src/java.base/share/classes/sun/security/validator/CADistrustPolicy.java line 89:

> 87: 
> 88:     /**
> 89:      * Distrust TLS Server certificates anchored by a Chunghwa ePKI root CA and

s/a Chunghwa ePKI root CA/the Chunghwa ePKI root CA/

src/java.base/share/classes/sun/security/validator/ChunghwaTLSPolicy.java line 46:

> 44:     private static final Debug debug = Debug.getInstance("certpath");
> 45: 
> 46:     // SHA-256 certificate fingerprints of distrusted root for TLS

s/fingerprints/fingerprint/

src/java.base/share/classes/sun/security/validator/ChunghwaTLSPolicy.java line 53:

> 51:             "C0A6F4DC63A24BFDCF54EF2A6A082A0A72DE35803E2FF5FF527AE5D87206DFD5";
> 52: 
> 53:     // Any TLS Server certificate that is anchored by one of the Chunghwa

s/one of the/the/

src/java.base/share/classes/sun/security/validator/ChunghwaTLSPolicy.java line 54:

> 52: 
> 53:     // Any TLS Server certificate that is anchored by one of the Chunghwa
> 54:     // roots above and is issued after this date will be distrusted.

s/roots/root/

test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/Chunghwa.java line 49:

> 47:     private static final String CERT_PATH = "chains" + File.separator + "chunghwa";
> 48: 
> 49:     // Each of the roots have a test certificate chain stored in a file

Only one root is distrusted, so change this comment to "The ePKI root has a test ..."

test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/Chunghwa.java line 63:

> 61:         String prop = Security.getProperty("jdk.certpath.disabledAlgorithms");
> 62:         String newProp = prop.replace(", SHA1 jdkCA & usage TLSServer", "");
> 63:         Security.setProperty("jdk.certpath.disabledAlgorithms", newProp);

These lines shouldn't be necessary, the test cert is signed with SHA256withRSA.

test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/chunghwa/chunghwaepkirootca-chain.pem line 1:

> 1: -----BEGIN CERTIFICATE-----

Can you add a header describing the main fields of the certificate similar to the camerfirma chain?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2657870076
PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2657894340
PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2657895688
PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2657896145
PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2657887853
PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2657890476
PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2657881716

From mdoerr at openjdk.org  Fri Jan  2 15:58:01 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jan 2026 15:58:01 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <h1uRSpSClxalHlIBspl3Jgo9SFs8AHA7FaL3CGgUJds=.5ca2823d-38a5-4163-b745-f72ebeed0422@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <u5rtXHJBKZzgE5mWjYj2S5U8JYeUTh4s9zKvQtEIz4U=.fd9de106-094f-41ae-8b7c-95d222993598@github.com>
 <h1uRSpSClxalHlIBspl3Jgo9SFs8AHA7FaL3CGgUJds=.5ca2823d-38a5-4163-b745-f72ebeed0422@github.com>
Message-ID: <u3rVZyt8nZiPD77vqe8bCerYiAlxKdBi2M5PHm5C_0k=.fb5dc64b-3151-421d-950b-77c93022dd5d@github.com>

On Fri, 2 Jan 2026 15:35:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 96:
>> 
>>> 94:             .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
>>> 95:                     FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
>>> 96:                             C_LONG, C_POINTER));
>> 
>> `C_LONG` looks wrong for 32 bit platforms (arm 32). Note that `size_t` is supported by `canonicalLayouts`.
>
> Do you see 64 bit?
> <img width="588" height="306" alt="Screenshot 2026-01-02 at 10 26 20" src="https://github.com/user-attachments/assets/82106d61-27f8-4871-a890-039971665e62" />
> There is no arm32 here so I assume it will be the `FallbackLinker`. The size will be returned by a JNI function `ffi_sizeof_long()`. No idea how it could go wrong.

Right, arm32 is using the `FallbackLinker`. `size_t` is mapped here: https://github.com/openjdk/jdk/blob/2daf12edd24e641d4d7706d582994c2b3fe95e87/src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java#L311
which takes it from here:
https://github.com/openjdk/jdk/blob/2daf12edd24e641d4d7706d582994c2b3fe95e87/src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FFIType.java#L59
@bulasevich: You may want to try on arm32.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657948890

From weijun at openjdk.org  Fri Jan  2 16:03:05 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 16:03:05 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <u3rVZyt8nZiPD77vqe8bCerYiAlxKdBi2M5PHm5C_0k=.fb5dc64b-3151-421d-950b-77c93022dd5d@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <u5rtXHJBKZzgE5mWjYj2S5U8JYeUTh4s9zKvQtEIz4U=.fd9de106-094f-41ae-8b7c-95d222993598@github.com>
 <h1uRSpSClxalHlIBspl3Jgo9SFs8AHA7FaL3CGgUJds=.5ca2823d-38a5-4163-b745-f72ebeed0422@github.com>
 <u3rVZyt8nZiPD77vqe8bCerYiAlxKdBi2M5PHm5C_0k=.fb5dc64b-3151-421d-950b-77c93022dd5d@github.com>
Message-ID: <hkuwAInnEU3ZSVOUy_212WDcV4QVV2M2Kcio4eop-PE=.fcad3185-e31c-44cb-96d4-e26ad2fc2b56@github.com>

On Fri, 2 Jan 2026 15:53:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Do you see 64 bit?
>> <img width="588" height="306" alt="Screenshot 2026-01-02 at 10 26 20" src="https://github.com/user-attachments/assets/82106d61-27f8-4871-a890-039971665e62" />
>> There is no arm32 here so I assume it will be the `FallbackLinker`. The size will be returned by a JNI function `ffi_sizeof_long()`. No idea how it could go wrong.
>
> Right, arm32 is using the `FallbackLinker`. `size_t` is mapped here: https://github.com/openjdk/jdk/blob/2daf12edd24e641d4d7706d582994c2b3fe95e87/src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java#L311
> which takes it from here:
> https://github.com/openjdk/jdk/blob/2daf12edd24e641d4d7706d582994c2b3fe95e87/src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FFIType.java#L59
> @bulasevich: You may want to try on arm32.

Ah, maybe I should use `canonicalLayouts().get("size_t")`? `jextract` didn't create that entry at the beginning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2657965365

From weijun at openjdk.org  Fri Jan  2 16:43:28 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 16:43:28 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v4]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <AoK2nYVNhfCQrJOHmnM0BlnPTXlvxbjD1XKKzU3wIY8=.9736f26f-8f47-43e6-a2e1-cae59e9c273f@github.com>

> Rewrite the native calls with FFM.

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

  use size_t

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/fa1a511c..05ab387c

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

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

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

From weijun at openjdk.org  Fri Jan  2 17:00:37 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Jan 2026 17:00:37 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>

> Rewrite the native calls with FFM.

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

  fail early on Windows, and more comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/05ab387c..578f1d2e

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

  Stats: 24 lines in 3 files changed: 14 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28931/head:pull/28931

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

From mdoerr at openjdk.org  Fri Jan  2 23:34:53 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jan 2026 23:34:53 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
Message-ID: <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>

On Fri, 2 Jan 2026 17:00:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fail early on Windows, and more comments

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 154:

> 152:         if (ss.getUsername() != null) {
> 153:             // When getpwuid_r fails, username will not be available.
> 154:             userPrincipal = new UnixPrincipal(ss.getUsername());

With this change, the test passes on AIX (though the `getpwuid_r` call does not work as expected).
@JoKern65, @varada1110: The `getpwuid_r` FFM call doesn't set the `result`. The strange thing is that it works when I call it through a C wrapper (same FFM call):

#include <pwd.h>

__attribute__((visibility("default"))) int call_getpwuid_r(int uid, struct passwd *pwd,
                                             char *buf, size_t buflen, struct passwd **result)
{
  return getpwuid_r(uid, pwd, buf, buflen, result);
}

Any idea?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2658544971

From duke at openjdk.org  Sat Jan  3 00:23:13 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Sat, 3 Jan 2026 00:23:13 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI and AVX512_VBMI2 [v2]
In-Reply-To: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
Message-ID: <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>

> This change allows use of the AVX512_VBMI/VMBI2 instruction set to further optimize decompression/parsing of polynomial coefficients for ML-KEM.  The speedup gained in the ML-KEM benchmarks for key generation is between 0.2 to 0.5%, encapsulation is  0.3 to 1.5%, and decapsulation is 0 to 0.9%.
> 
> Thank you to @sviswa7 and @ferakocz for their help in working through the early stages of this code with me.

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28815/files
  - new: https://git.openjdk.org/jdk/pull/28815/files/d2cadaf9..7cd8de53

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

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

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

From weijun at openjdk.org  Sat Jan  3 02:30:55 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 3 Jan 2026 02:30:55 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
Message-ID: <fkpcx_kqqMhSiQeiTHr2d-gDfhin4ONBMKXS7VRZzxE=.ef815873-6916-4c91-ae77-7789b725a1c8@github.com>

On Fri, 2 Jan 2026 23:31:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fail early on Windows, and more comments
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 154:
> 
>> 152:         if (ss.getUsername() != null) {
>> 153:             // When getpwuid_r fails, username will not be available.
>> 154:             userPrincipal = new UnixPrincipal(ss.getUsername());
> 
> With this change, the test passes on AIX (though the `getpwuid_r` call does not work as expected).
> @JoKern65, @varada1110: The `getpwuid_r` FFM call doesn't set the `result`. The strange thing is that it works when I call it through a C wrapper (same FFM call):
> 
> #include <pwd.h>
> 
> __attribute__((visibility("default"))) int call_getpwuid_r(int uid, struct passwd *pwd,
>                                              char *buf, size_t buflen, struct passwd **result)
> {
>   return getpwuid_r(uid, pwd, buf, buflen, result);
> }
> 
> Any idea?

I somehow think the `size_t buflen` in-between might be the reason. Are they put on the stack or into registers? Is there an alignment issue here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2658656686

From weijun at openjdk.org  Sat Jan  3 02:39:56 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 3 Jan 2026 02:39:56 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
Message-ID: <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>

On Fri, 2 Jan 2026 23:31:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fail early on Windows, and more comments
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 154:
> 
>> 152:         if (ss.getUsername() != null) {
>> 153:             // When getpwuid_r fails, username will not be available.
>> 154:             userPrincipal = new UnixPrincipal(ss.getUsername());
> 
> With this change, the test passes on AIX (though the `getpwuid_r` call does not work as expected).
> @JoKern65, @varada1110: The `getpwuid_r` FFM call doesn't set the `result`. The strange thing is that it works when I call it through a C wrapper (same FFM call):
> 
> #include <pwd.h>
> 
> __attribute__((visibility("default"))) int call_getpwuid_r(int uid, struct passwd *pwd,
>                                              char *buf, size_t buflen, struct passwd **result)
> {
>   return getpwuid_r(uid, pwd, buf, buflen, result);
> }
> 
> Any idea?

Have you tried `jextract` on AIX? Does the generated code have the same `FunctionDescriptor`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2658665306

From mpowers at openjdk.org  Sat Jan  3 02:48:43 2026
From: mpowers at openjdk.org (Mark Powers)
Date: Sat, 3 Jan 2026 02:48:43 GMT
Subject: RFR: 8369282: Distrust TLS server certificates anchored by
 Chunghwa ePKI Root CA [v3]
In-Reply-To: <fTAmOVJi88B74grU7hUK5pPmpdDXdfSRiyqqYTvPscM=.53c29683-d76f-42b2-8299-39032b47c620@github.com>
References: <fTAmOVJi88B74grU7hUK5pPmpdDXdfSRiyqqYTvPscM=.53c29683-d76f-42b2-8299-39032b47c620@github.com>
Message-ID: <TMtiIeeMYa4yrs0fNM1zqZj_FtVLCHRHCI3hzf9ZEOo=.8be15c07-ac92-4e39-ad19-f5233b3d4e2b@github.com>

> [JDK-8369282](https://bugs.openjdk.org/browse/JDK-8369282)

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

  comments from Sean

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28930/files
  - new: https://git.openjdk.org/jdk/pull/28930/files/d3c48d09..fc980f57

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

  Stats: 29 lines in 4 files changed: 13 ins; 7 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/28930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28930/head:pull/28930

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

From mpowers at openjdk.org  Sat Jan  3 03:00:01 2026
From: mpowers at openjdk.org (Mark Powers)
Date: Sat, 3 Jan 2026 03:00:01 GMT
Subject: RFR: 8369282: Distrust TLS server certificates anchored by
 Chunghwa ePKI Root CA [v2]
In-Reply-To: <bE4XXy-Ka6K40xv13BiOfURxI0roPYWFvX43HlqaFGs=.9b7e5e08-6f8a-406c-a6d1-96c4c2c56a01@github.com>
References: <fTAmOVJi88B74grU7hUK5pPmpdDXdfSRiyqqYTvPscM=.53c29683-d76f-42b2-8299-39032b47c620@github.com>
 <MvLEAe_wRx-W5ilMG3Jqy2iHi0gv6b8TWhmfoWhuGGw=.fb6823e1-6db5-4ffe-94c9-ad23bf3c720a@github.com>
 <bE4XXy-Ka6K40xv13BiOfURxI0roPYWFvX43HlqaFGs=.9b7e5e08-6f8a-406c-a6d1-96c4c2c56a01@github.com>
Message-ID: <PtAtUHCf99VYdak6JLwIH2aGGIHNTO6R-guapsYkBGo=.a0d5e453-b6f5-4eeb-b191-4afca070b6b8@github.com>

On Fri, 2 Jan 2026 15:04:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment from Mikhail
>
> src/java.base/share/classes/sun/security/validator/CADistrustPolicy.java line 89:
> 
>> 87: 
>> 88:     /**
>> 89:      * Distrust TLS Server certificates anchored by a Chunghwa ePKI root CA and
> 
> s/a Chunghwa ePKI root CA/the Chunghwa ePKI root CA/

fixed

> src/java.base/share/classes/sun/security/validator/ChunghwaTLSPolicy.java line 46:
> 
>> 44:     private static final Debug debug = Debug.getInstance("certpath");
>> 45: 
>> 46:     // SHA-256 certificate fingerprints of distrusted root for TLS
> 
> s/fingerprints/fingerprint/

fixed

> src/java.base/share/classes/sun/security/validator/ChunghwaTLSPolicy.java line 53:
> 
>> 51:             "C0A6F4DC63A24BFDCF54EF2A6A082A0A72DE35803E2FF5FF527AE5D87206DFD5";
>> 52: 
>> 53:     // Any TLS Server certificate that is anchored by one of the Chunghwa
> 
> s/one of the/the/

fixed

> src/java.base/share/classes/sun/security/validator/ChunghwaTLSPolicy.java line 54:
> 
>> 52: 
>> 53:     // Any TLS Server certificate that is anchored by one of the Chunghwa
>> 54:     // roots above and is issued after this date will be distrusted.
> 
> s/roots/root/

fixed

> test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/Chunghwa.java line 49:
> 
>> 47:     private static final String CERT_PATH = "chains" + File.separator + "chunghwa";
>> 48: 
>> 49:     // Each of the roots have a test certificate chain stored in a file
> 
> Only one root is distrusted, so change this comment to "The ePKI root has a test ..."

fixed

> test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/Chunghwa.java line 63:
> 
>> 61:         String prop = Security.getProperty("jdk.certpath.disabledAlgorithms");
>> 62:         String newProp = prop.replace(", SHA1 jdkCA & usage TLSServer", "");
>> 63:         Security.setProperty("jdk.certpath.disabledAlgorithms", newProp);
> 
> These lines shouldn't be necessary, the test cert is signed with SHA256withRSA.

Good catch. Camerfirma has the same problem but I don't think it's worth the effort to fix.

> test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/chunghwa/chunghwaepkirootca-chain.pem line 1:
> 
>> 1: -----BEGIN CERTIFICATE-----
> 
> Can you add a header describing the main fields of the certificate similar to the camerfirma chain?

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2658672750
PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2658672869
PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2658672903
PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2658672924
PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2658672808
PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2658672827
PR Review Comment: https://git.openjdk.org/jdk/pull/28930#discussion_r2658672790

From mdoerr at openjdk.org  Sat Jan  3 18:18:57 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 3 Jan 2026 18:18:57 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
Message-ID: <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>

On Sat, 3 Jan 2026 02:37:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 154:
>> 
>>> 152:         if (ss.getUsername() != null) {
>>> 153:             // When getpwuid_r fails, username will not be available.
>>> 154:             userPrincipal = new UnixPrincipal(ss.getUsername());
>> 
>> With this change, the test passes on AIX (though the `getpwuid_r` call does not work as expected).
>> @JoKern65, @varada1110: The `getpwuid_r` FFM call doesn't set the `result`. The strange thing is that it works when I call it through a C wrapper (same FFM call):
>> 
>> #include <pwd.h>
>> 
>> __attribute__((visibility("default"))) int call_getpwuid_r(int uid, struct passwd *pwd,
>>                                              char *buf, size_t buflen, struct passwd **result)
>> {
>>   return getpwuid_r(uid, pwd, buf, buflen, result);
>> }
>> 
>> Any idea?
>
> Have you tried `jextract` on AIX? Does the generated code have the same `FunctionDescriptor`?

No, I don't have `jextract` for AIX, but I think @varada1110 does.
The signature is `static int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)` which essentially matches. (A possible problem may be that `uid_t` is unsigned, but we're treating it as `int`. However, the sign bit is 0 in my experiments. All parameters are passed in 64-bit registers in which `int` gets sign extended.)
I have found `extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)` which takes an `int` for the buffer length and that functions works if I call it directly from Java (instead of the one above)!
Calling it through my C wrapper which uses the `size_t` also works as already stated above.
I think the AIX specific investigation could be done in a separate issue if the discussion is getting too long, here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2659065739

From weijun at openjdk.org  Sat Jan  3 18:47:54 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 3 Jan 2026 18:47:54 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
Message-ID: <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>

On Sat, 3 Jan 2026 18:15:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Have you tried `jextract` on AIX? Does the generated code have the same `FunctionDescriptor`?
>
> No, I don't have `jextract` for AIX, but I think @varada1110 does.
> The signature is `static int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)` which essentially matches. (A possible problem may be that `uid_t` is unsigned, but we're treating it as `int`. However, the sign bit is 0 in my experiments. All parameters are passed in 64-bit registers in which `int` gets sign extended.)
> I have found `extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)` which takes an `int` for the buffer length and that functions works if I call it directly from Java (instead of the one above)!
> Calling it through my C wrapper which uses the `size_t` also works as already stated above.
> I think the AIX specific investigation could be done in a separate issue if the discussion is getting too long, here.

Or I can call this `_posix_getpwuid_r` function in an `if (isAix())` block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2659080243

From mpowers at openjdk.org  Sun Jan  4 18:28:30 2026
From: mpowers at openjdk.org (Mark Powers)
Date: Sun, 4 Jan 2026 18:28:30 GMT
Subject: RFR: 8369282: Distrust TLS server certificates anchored by
 Chunghwa ePKI Root CA [v4]
In-Reply-To: <fTAmOVJi88B74grU7hUK5pPmpdDXdfSRiyqqYTvPscM=.53c29683-d76f-42b2-8299-39032b47c620@github.com>
References: <fTAmOVJi88B74grU7hUK5pPmpdDXdfSRiyqqYTvPscM=.53c29683-d76f-42b2-8299-39032b47c620@github.com>
Message-ID: <SgsJ7-W_BDTqXQb1L3PCk9EzNq92YXe82IbWh0aCaj4=.e7a878ec-d934-443d-9f6e-3347595efadd@github.com>

> [JDK-8369282](https://bugs.openjdk.org/browse/JDK-8369282)

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

  wording fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28930/files
  - new: https://git.openjdk.org/jdk/pull/28930/files/fc980f57..d2e10ef5

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

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

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

From jjiang at openjdk.org  Mon Jan  5 02:39:53 2026
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 5 Jan 2026 02:39:53 GMT
Subject: RFR: 8373231: ECDSAOperations::toAffinePoint is redundant [v2]
In-Reply-To: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>
References: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>
Message-ID: <uYzrSXhdNpbYDth69LQbgjztvfgiynAgtSOVMaVBA_U=.ab4a91fa-1142-481c-9ed5-174137488bfe@github.com>

> `ECDSAOperations::toAffinePoint` should be removed, and `AffinePoint::fromECPoint` should be used instead.

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

  Add the JBS ID to the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28691/files
  - new: https://git.openjdk.org/jdk/pull/28691/files/a1cebba7..1837abec

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

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

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

From mdoerr at openjdk.org  Mon Jan  5 11:47:23 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Jan 2026 11:47:23 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
Message-ID: <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>

On Sat, 3 Jan 2026 18:45:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> No, I don't have `jextract` for AIX, but I think @varada1110 does.
>> The signature is `static int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)` which essentially matches. (A possible problem may be that `uid_t` is unsigned, but we're treating it as `int`. However, the sign bit is 0 in my experiments. All parameters are passed in 64-bit registers in which `int` gets sign extended.)
>> I have found `extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)` which takes an `int` for the buffer length and that functions works if I call it directly from Java (instead of the one above)!
>> Calling it through my C wrapper which uses the `size_t` also works as already stated above.
>> I think the AIX specific investigation could be done in a separate issue if the discussion is getting too long, here.
>
> Or I can call this `_posix_getpwuid_r` function if `isAix()` is true. Is this enough?
> 
>      private static final MethodHandle getpwuid_r = LINKER
> -            .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
> +            .downcallHandle(SYMBOL_LOOKUP.findOrThrow(
> +                            OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
>                      FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
> -                            C_SIZE_T, C_POINTER));
> +                            OperatingSystem.isAix() ? C_INT : C_SIZE_T,
> +                            C_POINTER));

Thank you for taking care of it! I appreciate it. This has worked:

diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
index ee2c5effcf0..3afab6f7974 100644
--- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
+++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
@@ -38,6 +38,8 @@
 import java.lang.invoke.MethodHandle;
 import java.lang.invoke.VarHandle;
 
+import jdk.internal.util.OperatingSystem;
+
 import static java.lang.foreign.MemoryLayout.PathElement.groupElement;
 
 /**
@@ -106,9 +108,9 @@ public class UnixSystem {
             .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getgid"),
                     FunctionDescriptor.of(C_INT));
     private static final MethodHandle getpwuid_r = LINKER
-            .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
+            .downcallHandle(SYMBOL_LOOKUP.findOrThrow(OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
                     FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
-                            C_SIZE_T, C_POINTER));
+                            OperatingSystem.isAix() ? C_INT : C_SIZE_T, C_POINTER));
 
     private static final GroupLayout passwd_layout = MemoryLayout.structLayout(
             C_POINTER.withName("pw_name"),
@@ -136,7 +138,7 @@ public class UnixSystem {
     // sysconf(_SC_GETPW_R_SIZE_MAX) on macOS is 4096 and 1024 on Linux.
     // Not calling sysconf() here because _SC_GETPW_R_SIZE_MAX is different
     // on different platforms.
-    private static final long GETPW_R_SIZE_MAX = 4096L;
+    private static final int GETPW_R_SIZE_MAX = 4096;
 
     /**
      * Instantiate a {@code UnixSystem} and load

Note that `GETPW_R_SIZE_MAX` needs to be an `int` because `long` to `int` conversion would require an explicit cast (probably also for arm32). The other way round works implicitly.

I'd like to have feedback from the AIX experts as well. They may still be on vacation for a couple of days.

We still have a potential problem with the UID parameter. We are using an `int`, but the C code expects an `uint32_t`. Some platforms pass 32 bit values in 64 bit registers and expect a proper extension (zero for unsigned and sign for signed). If the UID becomes larger than INT_MAX, we use sign extend which is wrong.
Not sure of anyone uses so large UIDs and if we could restrict them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2661215966

From mcimadamore at openjdk.org  Mon Jan  5 12:28:23 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Jan 2026 12:28:23 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
Message-ID: <YmTo5WCxbz1LGGAcqF4uvO40BE_h140JJd4KgQKdiv0=.55098fd6-44c2-40cb-b7ea-04fa33d0c603@github.com>

On Fri, 2 Jan 2026 17:00:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fail early on Windows, and more comments

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 90:

> 88:             = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("size_t");
> 89: 
> 90:     private static Linker.Option ccs = Linker.Option.captureCallState("errno");

names of static final fields should be capitalized?

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 121:

> 119:             // While we don't need those fields here, the struct needs to be
> 120:             // big enough to avoid buffer overflow when `getpwuid_r` is called.
> 121:             MemoryLayout.sequenceLayout(100, C_CHAR).withName("dummy"));

maybe use a padding layout here? (assuming you don't want clients to access the bytes in `dummy`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2661328588
PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2661324659

From mcimadamore at openjdk.org  Mon Jan  5 12:34:21 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Jan 2026 12:34:21 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
Message-ID: <PFJp0RoH8jLPMfvXxskf6NvXHPaE0bokrIQKKddJFy4=.cac024c3-cc0d-4547-9d04-a63e85b0b86d@github.com>

On Fri, 2 Jan 2026 17:00:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fail early on Windows, and more comments

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 87:

> 85:             = ((AddressLayout) LINKER.canonicalLayouts().get("void*"))
> 86:             .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR));
> 87:     private static final ValueLayout.OfLong C_SIZE_T

Note that portability between 32/64 is hard, even if using canonicalLayouts -- because size_t will likely be an IntLayout on arm32, while a LongLayout in 64 bits. If you never use this layout to access data (e.g. call `MemorySegment::get/set`) I'd suggest to avoid the cast, and leave it just as `ValueLayout`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2661342378

From mullan at openjdk.org  Mon Jan  5 12:53:13 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 5 Jan 2026 12:53:13 GMT
Subject: RFR: 8366058: Outdated comment in WinCAPISeedGenerator
In-Reply-To: <pqiP2995Dmqa236BSaAOT_F03W6A2Tbelw0J1LbdnSI=.268196ea-42cb-423a-a990-00a0eaaed425@github.com>
References: <pqiP2995Dmqa236BSaAOT_F03W6A2Tbelw0J1LbdnSI=.268196ea-42cb-423a-a990-00a0eaaed425@github.com>
Message-ID: <z5Y8I8bwExJBRdYOMyfCBXiQBngpsOGTOxl8FKVjPVk=.9145aa59-9e70-4b3d-92e7-fbbe77abee4e@github.com>

On Sun, 2 Nov 2025 14:25:52 GMT, Daisuke Yamazaki <dyama at openjdk.org> wrote:

> Removed comment about Windows 95 runtime linking, since Windows 95 is no longer supported:
> 
>> Some early versions of Windows 95 do not support the required functions.
>> Use runtime linking to avoid problems.

Please add a `noreg-doc` label to the JBS issue.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28105#pullrequestreview-3626718289

From dyama at openjdk.org  Mon Jan  5 12:58:47 2026
From: dyama at openjdk.org (Daisuke Yamazaki)
Date: Mon, 5 Jan 2026 12:58:47 GMT
Subject: RFR: 8366058: Outdated comment in WinCAPISeedGenerator
In-Reply-To: <pqiP2995Dmqa236BSaAOT_F03W6A2Tbelw0J1LbdnSI=.268196ea-42cb-423a-a990-00a0eaaed425@github.com>
References: <pqiP2995Dmqa236BSaAOT_F03W6A2Tbelw0J1LbdnSI=.268196ea-42cb-423a-a990-00a0eaaed425@github.com>
Message-ID: <tO2jKw3bB6j_9flzHxnjPvTzGKQmjy_wFAo5DuzD-e8=.c1704000-18df-4c6c-99e3-9bbf1738a3bf@github.com>

On Sun, 2 Nov 2025 14:25:52 GMT, Daisuke Yamazaki <dyama at openjdk.org> wrote:

> Removed comment about Windows 95 runtime linking, since Windows 95 is no longer supported:
> 
>> Some early versions of Windows 95 do not support the required functions.
>> Use runtime linking to avoid problems.

Thank you for the review and approval. I've added the `noreg-doc` label.

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

PR Comment: https://git.openjdk.org/jdk/pull/28105#issuecomment-3710303591

From duke at openjdk.org  Mon Jan  5 12:58:48 2026
From: duke at openjdk.org (duke)
Date: Mon, 5 Jan 2026 12:58:48 GMT
Subject: RFR: 8366058: Outdated comment in WinCAPISeedGenerator
In-Reply-To: <pqiP2995Dmqa236BSaAOT_F03W6A2Tbelw0J1LbdnSI=.268196ea-42cb-423a-a990-00a0eaaed425@github.com>
References: <pqiP2995Dmqa236BSaAOT_F03W6A2Tbelw0J1LbdnSI=.268196ea-42cb-423a-a990-00a0eaaed425@github.com>
Message-ID: <wARRSrGtdStSrfOekSP31ABOYJTFySGxNkRHH56HC5c=.5c5df9c4-2910-45f3-8b1b-617bca371d50@github.com>

On Sun, 2 Nov 2025 14:25:52 GMT, Daisuke Yamazaki <dyama at openjdk.org> wrote:

> Removed comment about Windows 95 runtime linking, since Windows 95 is no longer supported:
> 
>> Some early versions of Windows 95 do not support the required functions.
>> Use runtime linking to avoid problems.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/28105#issuecomment-3710306420

From mdonovan at openjdk.org  Mon Jan  5 13:17:25 2026
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 5 Jan 2026 13:17:25 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v6]
In-Reply-To: <iWeGtVvsrO8_8f-cTWXKp1sNTNh2ZyoaEewCeAlLFDA=.1d320ee2-e7ce-418c-bbfd-ee7e79676b6a@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
 <iWeGtVvsrO8_8f-cTWXKp1sNTNh2ZyoaEewCeAlLFDA=.1d320ee2-e7ce-418c-bbfd-ee7e79676b6a@github.com>
Message-ID: <QL63V-o4SeyiQULm5KmD_qQk3D4nJ4jP3SxaA3steWg=.34057286-20c0-453b-bc57-2ca399b455df@github.com>

On Thu, 14 Aug 2025 12:14:48 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * fully automated the test
>> * removed the race condition
>> * client on a thread and server on a thread options are now run together automatically
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing comments

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 47:

> 45:  * @library /test/lib
> 46:  *
> 47:  * @run main/othervm -Dtest.separateThreads=false CloseKeepAliveCached false

The `test.separateThreads` property is used to statically set `separateServerThread` on line 88, but then on line 230, you set `separateServerThread` based on `args[0]`. One of those could go away. I think each `@test` block should only need 1 `@run` instruction, right?

Also, what is being tested differently if the server is in the "sub" thread versus when it is in the "main" thread?

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 122:

> 120:              * Signal Client, we're ready for his connect.
> 121:              */
> 122:             serverReady = true;

Change this to a `CountDownLatch`?

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 203:

> 201:             http.disconnect();
> 202:         } catch (IOException ioex) {
> 203:             if (sslServerSocket != null) {

Is there a reason for closing the server socket in the client thread? If not, `sslServerSocket` could be made local to `doServerSide()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2661448695
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2661405377
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2661399349

From dyama at openjdk.org  Mon Jan  5 13:23:36 2026
From: dyama at openjdk.org (Daisuke Yamazaki)
Date: Mon, 5 Jan 2026 13:23:36 GMT
Subject: Integrated: 8366058: Outdated comment in WinCAPISeedGenerator
In-Reply-To: <pqiP2995Dmqa236BSaAOT_F03W6A2Tbelw0J1LbdnSI=.268196ea-42cb-423a-a990-00a0eaaed425@github.com>
References: <pqiP2995Dmqa236BSaAOT_F03W6A2Tbelw0J1LbdnSI=.268196ea-42cb-423a-a990-00a0eaaed425@github.com>
Message-ID: <eQG4hSHWjfNCNK_9Wy2zJD1touaciEUGYAWmLKnJK1o=.7644ddd5-a378-475b-810a-db9bbeff67c1@github.com>

On Sun, 2 Nov 2025 14:25:52 GMT, Daisuke Yamazaki <dyama at openjdk.org> wrote:

> Removed comment about Windows 95 runtime linking, since Windows 95 is no longer supported:
> 
>> Some early versions of Windows 95 do not support the required functions.
>> Use runtime linking to avoid problems.

This pull request has now been integrated.

Changeset: eee58545
Author:    Daisuke Yamazaki <dyama at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eee58545c8342fc39b3bec5b38da6c01d92d05f2
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8366058: Outdated comment in WinCAPISeedGenerator

Reviewed-by: mullan

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

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

From mdonovan at openjdk.org  Mon Jan  5 14:42:01 2026
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 5 Jan 2026 14:42:01 GMT
Subject: RFR: 8357466: Create test for Ciphers that are using ByteBuffers
 backed by MemorySegments [v5]
In-Reply-To: <JJPA0TJZZBtd8lfYPCgcIak5wZK6mp_gjOVcJAjugPo=.a62a6dd1-bde9-4874-900e-ac2012cbd11f@github.com>
References: <zOK_-UTw7Asuc8XVZmeI0ie1srKAEBRwfO0kzIfKmvg=.eaeff85a-e93e-4624-b49f-d2e93ef9d0c4@github.com>
 <JJPA0TJZZBtd8lfYPCgcIak5wZK6mp_gjOVcJAjugPo=.a62a6dd1-bde9-4874-900e-ac2012cbd11f@github.com>
Message-ID: <1d4EG1pGX1G09chBJWK7CT-GVetLYZxWOyEO88f6_DQ=.d117f6a5-60e2-480e-967d-2ddd374fb94a@github.com>

On Wed, 17 Sep 2025 12:46:17 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR extends security tests to use ByteBuffers backed by MemorySegments. Tests in the areas of Signature, Cipher, MessageDigest, and Mac are updated.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into cipher-ffm
>  - updated additional Cipher tests for MemorySegment-backed ByteBuffers
>  - Merge branch 'master' into cipher-ffm
>  - added null-check for arena argument
>  - addressed PR comments and refactored to use try-with-resources
>  - Merge branch 'master' into cipher-ffm
>  - 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments

I still need a review for this PR. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26967#issuecomment-3710706958

From weijun at openjdk.org  Mon Jan  5 16:13:56 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 16:13:56 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
Message-ID: <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>

On Mon, 5 Jan 2026 11:42:08 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Or I can call this `_posix_getpwuid_r` function if `isAix()` is true. Is this enough?
>> 
>>      private static final MethodHandle getpwuid_r = LINKER
>> -            .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
>> +            .downcallHandle(SYMBOL_LOOKUP.findOrThrow(
>> +                            OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
>>                      FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
>> -                            C_SIZE_T, C_POINTER));
>> +                            OperatingSystem.isAix() ? C_INT : C_SIZE_T,
>> +                            C_POINTER));
>
> Thank you for taking care of it! I appreciate it. This has worked:
> 
> diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
> index ee2c5effcf0..3afab6f7974 100644
> --- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
> +++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
> @@ -38,6 +38,8 @@
>  import java.lang.invoke.MethodHandle;
>  import java.lang.invoke.VarHandle;
>  
> +import jdk.internal.util.OperatingSystem;
> +
>  import static java.lang.foreign.MemoryLayout.PathElement.groupElement;
>  
>  /**
> @@ -106,9 +108,9 @@ public class UnixSystem {
>              .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getgid"),
>                      FunctionDescriptor.of(C_INT));
>      private static final MethodHandle getpwuid_r = LINKER
> -            .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"),
> +            .downcallHandle(SYMBOL_LOOKUP.findOrThrow(OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
>                      FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
> -                            C_SIZE_T, C_POINTER));
> +                            OperatingSystem.isAix() ? C_INT : C_SIZE_T, C_POINTER));
>  
>      private static final GroupLayout passwd_layout = MemoryLayout.structLayout(
>              C_POINTER.withName("pw_name"),
> @@ -136,7 +138,7 @@ public class UnixSystem {
>      // sysconf(_SC_GETPW_R_SIZE_MAX) on macOS is 4096 and 1024 on Linux.
>      // Not calling sysconf() here because _SC_GETPW_R_SIZE_MAX is different
>      // on different platforms.
> -    private static final long GETPW_R_SIZE_MAX = 4096L;
> +    private static final int GETPW_R_SIZE_MAX = 4096;
>  
>      /**
>       * Instantiate a {@code UnixSystem} and load
> 
> Note that `GETPW_R_SIZE_MAX` needs to be an `int` because `long` to `int` conversion would require an explicit cast (probably also for arm32). The other way round works implicitly.
> 
> I'd like to have feedback from the AIX experts as well. They may still be on vacation for a couple of days.
> 
> We still have a potential problem with the UID parameter. We are using an `int`, but the C code expects an `uint32_t`. Some platforms pass 32 bit values in 64 bit registers and expect a proper extension (zero for unsigned and sign for signed). If the UID becomes larger than INT_MAX, we use sign extend which is wrong.
> Not sure of anyone uses so large UIDs and if we could re...

Maybe we can call `Integer.toUnsignedLong()` on `pw_uid` and `pw_gid`? In `UnixSystem`, they are `long`s.

Also, I want to discuss on the `username` issue again. Do you think it's good to login successfully without a `UnixPrincipal`? Now that there is a way on AIX to get it, I'm more inclined to revert the changes made to `UnixLoginModule`. While the old `Unix.c` seems to support username being `null` we know it would fail later with an NPE so this has never really worked before. My current understanding is that silent passing the login without a username might hide a bug and if the user takes it for granted that there should be a `UnixPrincipal` there will be a problem sooner or later. In fact, I would suggest we just throw an exception in `UnixSystem` if `getpwuid_r` cannot find the username.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662017228

From weijun at openjdk.org  Mon Jan  5 16:13:59 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 16:13:59 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <YmTo5WCxbz1LGGAcqF4uvO40BE_h140JJd4KgQKdiv0=.55098fd6-44c2-40cb-b7ea-04fa33d0c603@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <YmTo5WCxbz1LGGAcqF4uvO40BE_h140JJd4KgQKdiv0=.55098fd6-44c2-40cb-b7ea-04fa33d0c603@github.com>
Message-ID: <NKK-NfqezDDUZZV3FstBWr23mwI6Ghn7DBcaVoE5O9o=.9498da1e-71c8-48d0-b2d8-c4549efeef4a@github.com>

On Mon, 5 Jan 2026 12:25:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fail early on Windows, and more comments
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 90:
> 
>> 88:             = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("size_t");
>> 89: 
>> 90:     private static Linker.Option ccs = Linker.Option.captureCallState("errno");
> 
> names of static final fields should be capitalized?

I inlined it instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662029528

From weijun at openjdk.org  Mon Jan  5 16:19:17 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 16:19:17 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <PFJp0RoH8jLPMfvXxskf6NvXHPaE0bokrIQKKddJFy4=.cac024c3-cc0d-4547-9d04-a63e85b0b86d@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <PFJp0RoH8jLPMfvXxskf6NvXHPaE0bokrIQKKddJFy4=.cac024c3-cc0d-4547-9d04-a63e85b0b86d@github.com>
Message-ID: <SAijOJraT5hbaHXrIXVSlRqGyPqusiC9iKZ-LEkzRlI=.a8290ae1-a9d2-41c5-9ccb-6e006dcc777d@github.com>

On Mon, 5 Jan 2026 12:31:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fail early on Windows, and more comments
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 87:
> 
>> 85:             = ((AddressLayout) LINKER.canonicalLayouts().get("void*"))
>> 86:             .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR));
>> 87:     private static final ValueLayout.OfLong C_SIZE_T
> 
> Note that portability between 32/64 is hard, even if using canonicalLayouts -- because size_t will likely be an IntLayout on arm32, while a LongLayout in 64 bits. If you never use this layout to access data (e.g. call `MemorySegment::get/set`) I'd suggest to avoid the cast, and leave it just as `ValueLayout`

Ah yes, thanks for pointing out. I forgot to update it when changing "long" to "size_t".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662046816

From weijun at openjdk.org  Mon Jan  5 16:30:23 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 16:30:23 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v6]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <Zufe94LY_ro6POHQNEfN8MvXOD6TgWzAd7QZ9X4E99U=.3902059a-af7f-42bc-995b-7e5aba8ba82d@github.com>

> Rewrite the native calls with FFM.

Weijun Wang 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 eight additional commits since the last revision:

 - address comments from Maurizio; support AIX-specific `_posix_getpwuid_r`; recover unsigned int
 - Merge branch 'master' into 8277489
 - fail early on Windows, and more comments
 - use size_t
 - error handling
 - rewrite without jextract
 - no tabs
 - the fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/578f1d2e..b54ca67c

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

  Stats: 5209 lines in 1977 files changed: 1372 ins; 600 del; 3237 mod
  Patch: https://git.openjdk.org/jdk/pull/28931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28931/head:pull/28931

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

From mdoerr at openjdk.org  Mon Jan  5 16:39:43 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Jan 2026 16:39:43 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
Message-ID: <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>

On Mon, 5 Jan 2026 16:06:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Maybe we can call Integer.toUnsignedLong() on pw_uid and pw_gid? In UnixSystem, they are longs.

Yes, I had thought about this, too. But, I think we will need to distinguish between the platforms. PPC64 and s390 (and also SPARC which is no longer supported) pass smaller integer type values as 64 bit `long` and `Integer.toUnsignedLong()` would be correct when we change the signature to use `long` instead of `int`.
However, other platforms may require to pass the values as 4 Byte `int`. Especially when they are passed on stack. (Not sure if any supported platform does that. Probably not.) It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?
In hotspot, `CCallingConventionRequiresIntsAsLongs` is used to decide if 4 Byte integer types need to get extended.

> I would suggest we just throw an exception in UnixSystem if getpwuid_r cannot find the username.

Fine with me. I don't like ignoring getpwuid_r failures, either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662113718

From weijun at openjdk.org  Mon Jan  5 16:49:05 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 16:49:05 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
Message-ID: <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>

On Mon, 5 Jan 2026 16:36:50 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Maybe we can call `Integer.toUnsignedLong()` on `pw_uid` and `pw_gid`? In `UnixSystem`, they are `long`s.
>> 
>> Also, I want to discuss on the `username` issue again. Do you think it's good to login successfully without a `UnixPrincipal`? Now that there is a way on AIX to get it, I'm more inclined to revert the changes made to `UnixLoginModule`. While the old `Unix.c` seems to support username being `null` we know it would fail immediately with an NPE so this has never really worked before. My current understanding is that silent passing the login without a username might hide a bug and if the user takes it for granted that there should be a `UnixPrincipal` there will be a problem sooner or later. In fact, I would suggest we just throw an exception in `UnixSystem` if `getpwuid_r` cannot find the username.
>
>> Maybe we can call Integer.toUnsignedLong() on pw_uid and pw_gid? In UnixSystem, they are longs.
> 
> Yes, I had thought about this, too. But, I think we will need to distinguish between the platforms. PPC64 and s390 (and also SPARC which is no longer supported) pass smaller integer type values as 64 bit `long` and `Integer.toUnsignedLong()` would be correct when we change the signature to use `long` instead of `int`.
> However, other platforms may require to pass the values as 4 Byte `int`. Especially when they are passed on stack. (Not sure if any supported platform does that. Probably not.) It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?
> In hotspot, `CCallingConventionRequiresIntsAsLongs` is used to decide if 4 Byte integer types need to get extended.
> 
>> I would suggest we just throw an exception in UnixSystem if getpwuid_r cannot find the username.
> 
> Fine with me. I don't like ignoring getpwuid_r failures, either.

I created fake account and group on my linux-x64 with numbers bigger than `Integer.MAX_VALUE` and call `getgroups` and `getpwuid_r`.  The results always look good after a `Integer.toUnsignedLong()` conversion.

I would think it's safe because it's only called after the C functions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662146915

From weijun at openjdk.org  Mon Jan  5 17:20:29 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 17:20:29 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>

> Rewrite the native calls with FFM.

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

  must have username; more comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/b54ca67c..cfd794b8

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

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

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

From mdoerr at openjdk.org  Mon Jan  5 18:02:11 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Jan 2026 18:02:11 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
Message-ID: <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkNGApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>

On Mon, 5 Jan 2026 16:46:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>>> Maybe we can call Integer.toUnsignedLong() on pw_uid and pw_gid? In UnixSystem, they are longs.
>> 
>> Yes, I had thought about this, too. But, I think we will need to distinguish between the platforms. PPC64 and s390 (and also SPARC which is no longer supported) pass smaller integer type values as 64 bit `long` and `Integer.toUnsignedLong()` would be correct when we change the signature to use `long` instead of `int`.
>> However, other platforms may require to pass the values as 4 Byte `int`. Especially when they are passed on stack. (Not sure if any supported platform does that. Probably not.) It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?
>> In hotspot, `CCallingConventionRequiresIntsAsLongs` is used to decide if 4 Byte integer types need to get extended.
>> 
>>> I would suggest we just throw an exception in UnixSystem if getpwuid_r cannot find the username.
>> 
>> Fine with me. I don't like ignoring getpwuid_r failures, either.
>
> I created fake account and group on my linux-x64 with numbers bigger than `Integer.MAX_VALUE` and call `getgroups` and `getpwuid_r`.  The results always look good after a `Integer.toUnsignedLong()` conversion.
> 
> I would think it's safe because it's only called after the C functions.

What you have done is fine. Thanks! However, there is one potential problem left:
We are passing `tmpUid` to `getpwuid_r` as an `int`. That results in the following sequence (example from AIX):

[2.537s][trace][foreign,downcall]  ;; { argument shuffle
[2.537s][trace][foreign,downcall]   0x0a0001000747d744:   mr      r12,r3
[2.537s][trace][foreign,downcall]   0x0a0001000747d748:   extsw   r3,r4
[2.537s][trace][foreign,downcall]   0x0a0001000747d74c:   mr      r4,r5
[2.537s][trace][foreign,downcall]   0x0a0001000747d750:   mr      r5,r6
[2.537s][trace][foreign,downcall]   0x0a0001000747d754:   extsw   r6,r7
[2.537s][trace][foreign,downcall]   0x0a0001000747d758:   mr      r7,r8
[2.537s][trace][foreign,downcall]  ;; } argument shuffle

The 4 Byte value for `tmpUid` is taken from Register r4, sign extended to 8 Byte long and put into the first argument register r3. The sign extend is wrong because `uid` is an `uint32_t`. That violates the calling convention. We have no way to tell the FFM that we need zero extend.

A possible workaround would be to do the conversion in Java and passing it as long:

diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
index ed520529ac8..573513b7bef 100644
--- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
+++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
@@ -25,6 +25,7 @@
 
 package com.sun.security.auth.module;
 
+import jdk.internal.util.Architecture;
 import jdk.internal.util.OperatingSystem;
 
 import java.lang.foreign.AddressLayout;
@@ -83,6 +84,8 @@ public class UnixSystem {
             = (ValueLayout.OfByte) LINKER.canonicalLayouts().get("char");
     private static final ValueLayout.OfInt C_INT
             = (ValueLayout.OfInt) LINKER.canonicalLayouts().get("int");
+    private static final ValueLayout.OfLong C_LONG
+            = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long");
     private static final AddressLayout C_POINTER
             = ((AddressLayout) LINKER.canonicalLayouts().get("void*"))
             .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR));
@@ -110,10 +113,14 @@ public class UnixSystem {
 
     // getpwuid_r does not work on AIX, instead we use another similar function
     // extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)
+    // At least the following architecture require appropriate zero or sign extension to 64 bit.
+    private static final boolean calling_convention_requires_int_as_long = Architecture.isPPC64() || Architecture.isPPC64LE() || Architecture.isS390();
     private static final MethodHandle getpwuid_r = LINKER
             .downcallHandle(SYMBOL_LOOKUP.findOrThrow(
                             OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
-                    FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER,
+                    FunctionDescriptor.of(C_INT,
+                            calling_convention_requires_int_as_long ? C_LONG : C_INT,
+                            C_POINTER, C_POINTER,
                             OperatingSystem.isAix() ? C_INT : C_SIZE_T,
                             C_POINTER));
 
@@ -179,11 +186,15 @@ public UnixSystem() {
             var pwd = scope.allocate(passwd_layout);
             var result = scope.allocate(C_POINTER);
             var buffer = scope.allocate(GETPW_R_SIZE_MAX);
-            var tmpUid = (int)getuid.invokeExact();
+            long tmpUid = Integer.toUnsignedLong((int) getuid.invokeExact());
             // Do not call invokeExact because the type of buffer_size is not
             // always long in the underlying system.
-            int out = (int) getpwuid_r.invoke(
-                    tmpUid, pwd, buffer, GETPW_R_SIZE_MAX, result);
+            int out = 0;
+            if (calling_convention_requires_int_as_long) {
+                out = (int) getpwuid_r.invoke(tmpUid, pwd, buffer, GETPW_R_SIZE_MAX, result);
+            } else {
+                out = (int) getpwuid_r.invoke((int) tmpUid, pwd, buffer, GETPW_R_SIZE_MAX, result);
+            }
             if (out != 0 || result.get(ValueLayout.ADDRESS, 0).equals(MemorySegment.NULL)) {
                 if (out != 0) {
                     // If ERANGE (Result too large) is detected in a new platform,
@@ -193,7 +204,7 @@ public UnixSystem() {
                 } else {
                     getpwuid_r_error = "the requested entry is not found";
                 }
-                uid = Integer.toUnsignedLong(tmpUid);
+                uid = tmpUid;
                 gid = Integer.toUnsignedLong((int)getgid.invokeExact());
                 username = null;
             } else {

But I don't really like it. I hope we can find a better solution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662361633

From dmlloyd at openjdk.org  Mon Jan  5 18:14:55 2026
From: dmlloyd at openjdk.org (David Lloyd)
Date: Mon, 5 Jan 2026 18:14:55 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkNGApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
Message-ID: <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>

On Mon, 5 Jan 2026 18:00:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I created fake account and group on my linux-x64 with numbers bigger than `Integer.MAX_VALUE` and call `getgroups` and `getpwuid_r`.  The results always look good after a `Integer.toUnsignedLong()` conversion.
>> 
>> I would think it's safe because it's only called after the C functions.
>
> What you have done is fine. Thanks! However, there is one potential problem left:
> We are passing `tmpUid` to `getpwuid_r` as an `int`. That results in the following sequence (example from AIX):
> 
> [2.537s][trace][foreign,downcall]  ;; { argument shuffle
> [2.537s][trace][foreign,downcall]   0x0a0001000747d744:   mr      r12,r3
> [2.537s][trace][foreign,downcall]   0x0a0001000747d748:   extsw   r3,r4
> [2.537s][trace][foreign,downcall]   0x0a0001000747d74c:   mr      r4,r5
> [2.537s][trace][foreign,downcall]   0x0a0001000747d750:   mr      r5,r6
> [2.537s][trace][foreign,downcall]   0x0a0001000747d754:   extsw   r6,r7
> [2.537s][trace][foreign,downcall]   0x0a0001000747d758:   mr      r7,r8
> [2.537s][trace][foreign,downcall]  ;; } argument shuffle
> 
> The 4 Byte value for `tmpUid` is taken from Register r4, sign extended to 8 Byte long and put into the first argument register r3. The sign extend is wrong because `uid` is an `uint32_t`. That violates the calling convention. We have no way to tell the FFM that we need zero extend.
> 
> A possible workaround would be to do the conversion in Java and passing it as long:
> 
> diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
> index ed520529ac8..573513b7bef 100644
> --- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
> +++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
> @@ -25,6 +25,7 @@
>  
>  package com.sun.security.auth.module;
>  
> +import jdk.internal.util.Architecture;
>  import jdk.internal.util.OperatingSystem;
>  
>  import java.lang.foreign.AddressLayout;
> @@ -83,6 +84,8 @@ public class UnixSystem {
>              = (ValueLayout.OfByte) LINKER.canonicalLayouts().get("char");
>      private static final ValueLayout.OfInt C_INT
>              = (ValueLayout.OfInt) LINKER.canonicalLayouts().get("int");
> +    private static final ValueLayout.OfLong C_LONG
> +            = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long");
>      private static final AddressLayout C_POINTER
>              = ((AddressLayout) LINKER.canonicalLayouts().get("void*"))
>              .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR));
> @@ -110,10 +113,14 @@ public class UnixSystem {
>  
>      // getpwuid_r does not work on AIX, instead we use another similar function
>      // extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)
> +  ...

FWIW there is an issue and ML discussion relating to extension of arguments with respect to `ValueLayout`: https://bugs.openjdk.org/browse/JDK-8336664

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662391104

From mdonovan at openjdk.org  Mon Jan  5 19:05:52 2026
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 5 Jan 2026 19:05:52 GMT
Subject: RFR: 8374001: sun/security/ skip without Exceptions
In-Reply-To: <P1xMe3z5wtoG1l84Iu2IJNH-B2sUVchQ46SFYiOThPs=.18e8a2fe-dc84-45a7-98b0-f4568ca949e9@github.com>
References: <P1xMe3z5wtoG1l84Iu2IJNH-B2sUVchQ46SFYiOThPs=.18e8a2fe-dc84-45a7-98b0-f4568ca949e9@github.com>
Message-ID: <cGjSDZJW1K-AKqEkL9mWNn9R-Nv4DpHHchJuEWG7x0A=.6a647779-e02f-4012-ac01-4295187f65e2@github.com>

On Thu, 18 Dec 2025 12:12:15 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Pr cleaning up the tests left after the previous PRs.
> 
> * test/jdk/sun/security/util/Resources/Usages.java
> * test/jdk/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java
> * test/jdk/sun/security/krb5/config/ConfPlusProp.java
> * test/jdk/sun/security/krb5/auto/ReplayCacheTestProc.java

LGTM

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

PR Comment: https://git.openjdk.org/jdk/pull/28898#issuecomment-3711717432

From mullan at openjdk.org  Mon Jan  5 19:22:42 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 5 Jan 2026 19:22:42 GMT
Subject: RFR: 8369282: Distrust TLS server certificates anchored by
 Chunghwa ePKI Root CA [v4]
In-Reply-To: <SgsJ7-W_BDTqXQb1L3PCk9EzNq92YXe82IbWh0aCaj4=.e7a878ec-d934-443d-9f6e-3347595efadd@github.com>
References: <fTAmOVJi88B74grU7hUK5pPmpdDXdfSRiyqqYTvPscM=.53c29683-d76f-42b2-8299-39032b47c620@github.com>
 <SgsJ7-W_BDTqXQb1L3PCk9EzNq92YXe82IbWh0aCaj4=.e7a878ec-d934-443d-9f6e-3347595efadd@github.com>
Message-ID: <71vdS_8AZ2r4aDOPQFZMKDEGQ3q2EP1Bwz7Po4InElk=.f48da0c3-29c0-4f26-aa6e-7e421cf6f49e@github.com>

On Sun, 4 Jan 2026 18:28:30 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8369282](https://bugs.openjdk.org/browse/JDK-8369282)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wording fix

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28930#pullrequestreview-3628128292

From weijun at openjdk.org  Mon Jan  5 21:34:16 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 21:34:16 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
Message-ID: <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>

On Mon, 5 Jan 2026 18:12:08 GMT, David Lloyd <dmlloyd at openjdk.org> wrote:

>> What you have done is fine. Thanks! However, there is one potential problem left:
>> We are passing `tmpUid` to `getpwuid_r` as an `int`. That results in the following sequence (example from AIX):
>> 
>> [2.537s][trace][foreign,downcall]  ;; { argument shuffle
>> [2.537s][trace][foreign,downcall]   0x0a0001000747d744:   mr      r12,r3
>> [2.537s][trace][foreign,downcall]   0x0a0001000747d748:   extsw   r3,r4
>> [2.537s][trace][foreign,downcall]   0x0a0001000747d74c:   mr      r4,r5
>> [2.537s][trace][foreign,downcall]   0x0a0001000747d750:   mr      r5,r6
>> [2.537s][trace][foreign,downcall]   0x0a0001000747d754:   extsw   r6,r7
>> [2.537s][trace][foreign,downcall]   0x0a0001000747d758:   mr      r7,r8
>> [2.537s][trace][foreign,downcall]  ;; } argument shuffle
>> 
>> The 4 Byte value for `tmpUid` is taken from Register r4, sign extended to 8 Byte long and put into the first argument register r3. The sign extend is wrong because `uid` is an `uint32_t`. That violates the calling convention. We have no way to tell the FFM that we need zero extend.
>> 
>> A possible workaround would be to do the conversion in Java and passing it as long:
>> 
>> diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
>> index ed520529ac8..573513b7bef 100644
>> --- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
>> +++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
>> @@ -25,6 +25,7 @@
>>  
>>  package com.sun.security.auth.module;
>>  
>> +import jdk.internal.util.Architecture;
>>  import jdk.internal.util.OperatingSystem;
>>  
>>  import java.lang.foreign.AddressLayout;
>> @@ -83,6 +84,8 @@ public class UnixSystem {
>>              = (ValueLayout.OfByte) LINKER.canonicalLayouts().get("char");
>>      private static final ValueLayout.OfInt C_INT
>>              = (ValueLayout.OfInt) LINKER.canonicalLayouts().get("int");
>> +    private static final ValueLayout.OfLong C_LONG
>> +            = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long");
>>      private static final AddressLayout C_POINTER
>>              = ((AddressLayout) LINKER.canonicalLayouts().get("void*"))
>>              .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR));
>> @@ -110,10 +113,14 @@ public class UnixSystem {
>>  
>>      // getpwuid_r does not work on AIX, instead we use another similar function
>>      // exter...
>
> FWIW there is an issue and ML discussion relating to extension of arguments with respect to `ValueLayout`: https://bugs.openjdk.org/browse/JDK-8336664

\What happens if you create a user on AIX with a uid bigger than 2^31 and call `getpwuid_r` on it (by hardcoding `tmpUid` as a negative number)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662861217

From weijun at openjdk.org  Mon Jan  5 22:29:55 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 Jan 2026 22:29:55 GMT
Subject: RFR: 8374555: No need for visible input warning in s.s.u.Password when
 not reading from System.in
Message-ID: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>

We should only print out `[WARNING: Input may be visible on screen]` when trying to read password from `System.in`. Don't print it if the password is read from a different URL.

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

Commit messages:
 - the fix

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

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

From hchao at openjdk.org  Tue Jan  6 00:53:20 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 6 Jan 2026 00:53:20 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v23]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <Yf2r5J3LWAXRQ0QMSQn7MfyqdUB_sih4VvMN7vMdb4w=.f4f769d8-8276-4c03-9219-d024ecf0b3ea@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

Hai-May Chao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge
 - Use engineEncapsulationSize() and engineSecretSize()
 - small tweak to long line
 - Updates with Brad's comments
 - Remove len check from encapsulate
 - Updates with Weijun's comments(encapsulate/decapsulate len checks)
 - Fix internal JSSE benchmarks to reflect new class location.  Address comments, adjust line lengths
 - Updates with Brad's comments
 - Updates with Brad's and Sean's comments for new HybridProvider class
 - Updates with Weijun's comments for 3rd-party provider
 - ... and 29 more: https://git.openjdk.org/jdk/compare/de81d389...ef6a88a4

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

Changes: https://git.openjdk.org/jdk/pull/27614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=22
  Stats: 1879 lines in 22 files changed: 1759 ins; 40 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/27614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614

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

From dholmes at openjdk.org  Tue Jan  6 02:02:16 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Jan 2026 02:02:16 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v4]
In-Reply-To: <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
Message-ID: <JnDBfpSX2boh4MregZIgWpxg8gmgpal0_p7-cmp92Ok=.53d89bd4-7f69-489b-b18b-d48ff354ecbf@github.com>

On Sun, 28 Dec 2025 03:56:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
>> 
>> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
>> 
>> ~~`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `~~
>> 
>> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`
>
> 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 copy_hotspot
>  - 8374316: Update copyright year to 2025 for hotspot in files where it was missed

Just be aware that if a file was created as part of a refactoring and the code was taken as-is from an existing file, then the copyright year range should have remained the same as the original file. I don't know if any of the files you modified fall into that category but just wanted to point out that looking at the commit date is not always correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3712798915

From duke at openjdk.org  Tue Jan  6 04:28:54 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Tue, 6 Jan 2026 04:28:54 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950
Message-ID: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>

The method ckAssertReturnValueOK will invoke ckAssertReturnValueOK2 which makes multiple calls to JNI functions, such as FindClass or GetMethodID. These calls would be unsafe as there may be a pending exception at this time.
So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.

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

Commit messages:
 - 8367024: JNI exception pending in Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950

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

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

From jpai at openjdk.org  Tue Jan  6 06:30:08 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jan 2026 06:30:08 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods [v4]
In-Reply-To: <91z1GserVQHgwJNfH6VWSSERKpd7qtyAJL7dY2Ynh24=.da80636c-9d89-4467-985d-6f28fd3d63cc@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
 <91z1GserVQHgwJNfH6VWSSERKpd7qtyAJL7dY2Ynh24=.da80636c-9d89-4467-985d-6f28fd3d63cc@github.com>
Message-ID: <4lwNtk0KLDVIiqe9p8aYaUDMTse9boXuJcF2G9hJHGo=.9597ff45-3da9-4865-8a87-084b5984dac1@github.com>

On Thu, 18 Dec 2025 13:53:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Migrates `test/jdk/java/net/httpclient/` to null-safe `SimpleSSLContext` methods introduced in [JDK-8372661], which is a prerequisite for this change set.
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Make sure `get()` returns the same instance
>  - Restore `test/jdk/java/net/httpclient/` changes
>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>  - Overhaul `SimpleSSLContext` and its usages

test/jdk/java/net/httpclient/ALPNProxyFailureTest.java line 47:

> 45: public class ALPNProxyFailureTest extends ALPNFailureTest {
> 46: 
> 47:     private static final SSLContext context = SimpleSSLContext.findSSLContext();

Hello Volkan, there seems to be an oversight here - as far as I can see, the call to `SSLContext.setDefault(context)` is no longer being done after this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28771#discussion_r2663789227

From jpai at openjdk.org  Tue Jan  6 06:47:14 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jan 2026 06:47:14 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods [v4]
In-Reply-To: <91z1GserVQHgwJNfH6VWSSERKpd7qtyAJL7dY2Ynh24=.da80636c-9d89-4467-985d-6f28fd3d63cc@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
 <91z1GserVQHgwJNfH6VWSSERKpd7qtyAJL7dY2Ynh24=.da80636c-9d89-4467-985d-6f28fd3d63cc@github.com>
Message-ID: <hg6GKjrO5C07bVPtvmzvgaX2aVRthjpkRY2WxIzttGE=.c2ddf304-d18f-4690-8ee0-547a3f686890@github.com>

On Thu, 18 Dec 2025 13:53:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Migrates `test/jdk/java/net/httpclient/` to null-safe `SimpleSSLContext` methods introduced in [JDK-8372661], which is a prerequisite for this change set.
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Make sure `get()` returns the same instance
>  - Restore `test/jdk/java/net/httpclient/` changes
>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>  - Overhaul `SimpleSSLContext` and its usages

Thank you for doing this cleanup. Looks simple but is involved because of the number of places this change was required. Apart from one issue to a test change, that I added as a review comment, the rest looks good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/28771#issuecomment-3713347821

From jpai at openjdk.org  Tue Jan  6 06:50:51 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jan 2026 06:50:51 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v2]
In-Reply-To: <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
Message-ID: <Du9iQRzUMlXeAP8mMzYOQh8nDRFq37ueXSc_Z5nu07c=.210ec2d1-cfc6-462a-a824-4f6b990fa81b@github.com>

On Fri, 19 Dec 2025 17:37:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
>> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
>> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
>> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
>> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove wildcard imports

This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28905#pullrequestreview-3629653398

From coffeys at openjdk.org  Tue Jan  6 07:35:40 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 6 Jan 2026 07:35:40 GMT
Subject: RFR: 8374555: No need for visible input warning in s.s.u.Password
 when not reading from System.in
In-Reply-To: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
References: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
Message-ID: <OXTU4v490aDqEw4UHvJ0n-VIbBeStq9Tpu-PETyayaU=.ba1d2733-8476-43e7-bc3d-f49ec6c1bed9@github.com>

On Mon, 5 Jan 2026 22:20:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> We should only print out `[WARNING: Input may be visible on screen]` when trying to read password from `System.in`. Don't print it if the password is read from a different URL.

test/jdk/sun/security/util/Password/EmptyIn.java line 36:

> 34:  * @summary only print warning when reading from System.in
> 35:  * @modules java.base/sun.security.util
> 36:  * @library /test/lib

I think this test needs to run in ovm mode given the System in/out modifications

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29051#discussion_r2663940867

From vyazici at openjdk.org  Tue Jan  6 08:23:16 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 08:23:16 GMT
Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
Message-ID: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>

Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (655dc516c22), which causes regressions reported in [JDK-8374210].

[JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
[JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

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

Commit messages:
 - Revert "8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics"

Changes: https://git.openjdk.org/jdk/pull/29055/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29055&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374523
  Stats: 437 lines in 23 files changed: 25 ins; 331 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/29055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29055/head:pull/29055

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

From vyazici at openjdk.org  Tue Jan  6 08:23:16 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 08:23:16 GMT
Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
References: <R0eSJy-eVdyNzgcTqEpW55CdubZTRdg6xK_Bmd1WQt4=.71411aaa-f14c-4b12-b594-d6e5410c0663@github.com>
Message-ID: <zk3-XGiaG5jLISqVAtPgLgvcEOT9raXjQ_UefbivPCs=.b0496830-92a7-47b8-8696-60b22a7cb106@github.com>

On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (655dc516c22), which causes regressions reported in [JDK-8374210].
> 
> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

Tier 1-3 are clear on c8acc80b8c6.

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

PR Comment: https://git.openjdk.org/jdk/pull/29055#issuecomment-3713645184

From vyazici at openjdk.org  Tue Jan  6 09:01:22 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 09:01:22 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods [v5]
In-Reply-To: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
Message-ID: <jOH1psXH5CpUFpoLm2jS03s8Vr0aC3XnwJFMkn76lMA=.b258ab68-f5ce-486d-bcda-251aa61b6871@github.com>

> Migrates `test/jdk/java/net/httpclient/` to null-safe `SimpleSSLContext` methods introduced in [JDK-8372661], which is a prerequisite for this change set.
> 
> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge remote-tracking branch 'upstream/master' into simpleSslHc
 - Restore incorrectly removed `SSLContext::setDefault` in `ALPNProxyFailureTest`
 - Merge remote-tracking branch 'upstream/master' into simpleSslHc
 - Merge remote-tracking branch 'upstream/master' into simpleSslHc
 - Make sure `get()` returns the same instance
 - Restore `test/jdk/java/net/httpclient/` changes
 - Reverted all changes and only kept `SimpleSSLContext` enhancements
 - Overhaul `SimpleSSLContext` and its usages

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

Changes: https://git.openjdk.org/jdk/pull/28771/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28771&range=04
  Stats: 974 lines in 179 files changed: 53 ins; 662 del; 259 mod
  Patch: https://git.openjdk.org/jdk/pull/28771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28771/head:pull/28771

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

From vyazici at openjdk.org  Tue Jan  6 09:01:25 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 09:01:25 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods [v4]
In-Reply-To: <4lwNtk0KLDVIiqe9p8aYaUDMTse9boXuJcF2G9hJHGo=.9597ff45-3da9-4865-8a87-084b5984dac1@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
 <91z1GserVQHgwJNfH6VWSSERKpd7qtyAJL7dY2Ynh24=.da80636c-9d89-4467-985d-6f28fd3d63cc@github.com>
 <4lwNtk0KLDVIiqe9p8aYaUDMTse9boXuJcF2G9hJHGo=.9597ff45-3da9-4865-8a87-084b5984dac1@github.com>
Message-ID: <qawHl-cni-xAcQR5UpdeMrMZkMtF_heWLYHpB9Tlkr4=.e7d68435-0edb-458d-a5ea-94fb5d9ca422@github.com>

On Tue, 6 Jan 2026 06:26:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>>  - Make sure `get()` returns the same instance
>>  - Restore `test/jdk/java/net/httpclient/` changes
>>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>>  - Overhaul `SimpleSSLContext` and its usages
>
> test/jdk/java/net/httpclient/ALPNProxyFailureTest.java line 47:
> 
>> 45: public class ALPNProxyFailureTest extends ALPNFailureTest {
>> 46: 
>> 47:     private static final SSLContext context = SimpleSSLContext.findSSLContext();
> 
> Hello Volkan, there seems to be an oversight here - as far as I can see, the call to `SSLContext.setDefault(context)` is no longer being done after this change.

Doh! :facepalm: Fixed in 3204e85f57e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28771#discussion_r2664167892

From jpai at openjdk.org  Tue Jan  6 09:12:18 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jan 2026 09:12:18 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods [v5]
In-Reply-To: <jOH1psXH5CpUFpoLm2jS03s8Vr0aC3XnwJFMkn76lMA=.b258ab68-f5ce-486d-bcda-251aa61b6871@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
 <jOH1psXH5CpUFpoLm2jS03s8Vr0aC3XnwJFMkn76lMA=.b258ab68-f5ce-486d-bcda-251aa61b6871@github.com>
Message-ID: <frakj_Lr_FEhIyjssXrikC6DW7CM05lksFE3nycln2s=.b0156721-662d-4b2b-a2ad-c69e9d06cbe6@github.com>

On Tue, 6 Jan 2026 09:01:22 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Migrates `test/jdk/java/net/httpclient/` to null-safe `SimpleSSLContext` methods introduced in [JDK-8372661], which is a prerequisite for this change set.
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Restore incorrectly removed `SSLContext::setDefault` in `ALPNProxyFailureTest`
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Make sure `get()` returns the same instance
>  - Restore `test/jdk/java/net/httpclient/` changes
>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>  - Overhaul `SimpleSSLContext` and its usages

Thank you for the update. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28771#pullrequestreview-3630065748

From vyazici at openjdk.org  Tue Jan  6 10:22:10 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 10:22:10 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods [v4]
In-Reply-To: <hg6GKjrO5C07bVPtvmzvgaX2aVRthjpkRY2WxIzttGE=.c2ddf304-d18f-4690-8ee0-547a3f686890@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
 <91z1GserVQHgwJNfH6VWSSERKpd7qtyAJL7dY2Ynh24=.da80636c-9d89-4467-985d-6f28fd3d63cc@github.com>
 <hg6GKjrO5C07bVPtvmzvgaX2aVRthjpkRY2WxIzttGE=.c2ddf304-d18f-4690-8ee0-547a3f686890@github.com>
Message-ID: <ucS0Wnfj_vjeriM3sTmAtGzIkcFs-0Q5lQtCm_mRtBg=.e18ee30f-98b6-4189-b739-cc6f3bb991a9@github.com>

On Tue, 6 Jan 2026 06:44:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>>  - Make sure `get()` returns the same instance
>>  - Restore `test/jdk/java/net/httpclient/` changes
>>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>>  - Overhaul `SimpleSSLContext` and its usages
>
> Thank you for doing this cleanup. Looks simple but is involved because of the number of places this change was required. Apart from one issue to a test change, that I added as a review comment, the rest looks good to me.

Thanks so much for the review @jaikiran.

All `test/jdk/java/net/httpclient/` tests pass on several platforms using b8544bbff7e.

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

PR Comment: https://git.openjdk.org/jdk/pull/28771#issuecomment-3714105562

From vyazici at openjdk.org  Tue Jan  6 10:24:20 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 10:24:20 GMT
Subject: Integrated: 8373515: Migrate "test/jdk/java/net/httpclient/" to
 null-safe "SimpleSSLContext" methods
In-Reply-To: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
Message-ID: <TMjEQubDdKK7tKX5XKO-Bfa8IewA4rpV5D1OUCb_3gk=.b65b32f3-32d4-45d3-a86a-3c7e1f5a5de3@github.com>

On Thu, 11 Dec 2025 18:49:12 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Migrates `test/jdk/java/net/httpclient/` to null-safe `SimpleSSLContext` methods introduced in [JDK-8372661], which is a prerequisite for this change set.
> 
> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661

This pull request has now been integrated.

Changeset: 3a80c639
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a80c639d804a0697b8eb477fe4c96407709449b
Stats:     974 lines in 179 files changed: 53 ins; 662 del; 259 mod

8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe "SimpleSSLContext" methods

Reviewed-by: jpai

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

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

From hchao at openjdk.org  Tue Jan  6 10:51:21 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 6 Jan 2026 10:51:21 GMT
Subject: RFR: 8374555: No need for visible input warning in s.s.u.Password
 when not reading from System.in
In-Reply-To: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
References: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
Message-ID: <sLu3bWN9c9_YIqEWOR1Q4JoSW88mIovZj763I1YQ7uU=.4a185460-20f3-49ce-bc6a-57674f138b8b@github.com>

On Mon, 5 Jan 2026 22:20:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> We should only print out `[WARNING: Input may be visible on screen]` when trying to read password from `System.in`. Don't print it if the password is read from a different URL.

src/java.base/share/classes/sun/security/util/Password.java line 68:

> 66:                     consoleBytes = ConsoleHolder.convertToBytes(consoleEntered);
> 67:                     in = new ByteArrayInputStream(consoleBytes);
> 68:                 } else if (in == System.in && System.in.available() == 0) {

The additional check looks good as we need to make sure the password is actually read from user's standard input. Suggest to update the comment for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29051#discussion_r2664508342

From fguallini at openjdk.org  Tue Jan  6 10:56:49 2026
From: fguallini at openjdk.org (Fernando Guallini)
Date: Tue, 6 Jan 2026 10:56:49 GMT
Subject: Integrated: 8372950: Pem.pemEncoded should cache the Pattern
In-Reply-To: <5mYwWMub4PCyu7L6pfrilL_7HeX4fFeRhzCke4mSH5Q=.0d8fc616-661a-4e55-905e-fc33563a301e@github.com>
References: <5mYwWMub4PCyu7L6pfrilL_7HeX4fFeRhzCke4mSH5Q=.0d8fc616-661a-4e55-905e-fc33563a301e@github.com>
Message-ID: <w4NurwcA6xLxKpsnsexoEI7NFbqOuHvk6xzEP4ql9O0=.35bb15f5-1ed8-477b-9ade-5c4016a307cb@github.com>

On Thu, 4 Dec 2025 17:13:13 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> PEM is using the String.replaceAll() method that creates a Pattern internally every time. This looks like a minor inefficiency and since it is caching Patterns for other cases, it should do the same here.

This pull request has now been integrated.

Changeset: 532a0a65
Author:    Fernando Guallini <fguallini at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/532a0a65b130e1fbe74ccbd16cdeed258cc2c245
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8372950: Pem.pemEncoded should cache the Pattern

Reviewed-by: ascarpino

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

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

From sshivang at openjdk.org  Tue Jan  6 11:08:34 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Tue, 6 Jan 2026 11:08:34 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
Message-ID: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>

8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
Straight Backport

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

Commit messages:
 - Backport 629e4ac6f45c87898f6a014f28a443c800413869

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

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

From sshivang at openjdk.org  Tue Jan  6 11:08:34 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Tue, 6 Jan 2026 11:08:34 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <5aVQ24ZshlttTck85Da1nc1JzyxzvLB4qOFjFnbhd-w=.5750aebe-734c-4102-8324-ff1a887d0199@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

@dfuch Can you please review this?

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3714286788

From weijun at openjdk.org  Tue Jan  6 13:58:21 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Jan 2026 13:58:21 GMT
Subject: RFR: 8374555: No need for visible input warning in s.s.u.Password
 when not reading from System.in [v2]
In-Reply-To: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
References: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
Message-ID: <1S4P364TlzVuJCMKp9HOjIeFmKznUTdDOg-d3i7AmDk=.a4b24e66-f22a-4fe7-bfc6-f1c56a73229b@github.com>

> We should only print out `[WARNING: Input may be visible on screen]` when trying to read password from `System.in`. Don't print it if the password is read from a different URL.

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

  warn only if VM is booted; more comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29051/files
  - new: https://git.openjdk.org/jdk/pull/29051/files/2bafe786..29612746

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

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

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

From weijun at openjdk.org  Tue Jan  6 13:58:22 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Jan 2026 13:58:22 GMT
Subject: RFR: 8374555: No need for visible input warning in s.s.u.Password
 when not reading from System.in [v2]
In-Reply-To: <OXTU4v490aDqEw4UHvJ0n-VIbBeStq9Tpu-PETyayaU=.ba1d2733-8476-43e7-bc3d-f49ec6c1bed9@github.com>
References: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
 <OXTU4v490aDqEw4UHvJ0n-VIbBeStq9Tpu-PETyayaU=.ba1d2733-8476-43e7-bc3d-f49ec6c1bed9@github.com>
Message-ID: <uxK23B3slxQGgTYsqeU0_q_czk_6rCmLU0aRKCGqnnQ=.575fa1e4-c5e4-468c-9691-5445fd7dbd26@github.com>

On Tue, 6 Jan 2026 07:32:00 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   warn only if VM is booted; more comments
>
> test/jdk/sun/security/util/Password/EmptyIn.java line 36:
> 
>> 34:  * @summary only print warning when reading from System.in
>> 35:  * @modules java.base/sun.security.util
>> 36:  * @library /test/lib
> 
> I think this test needs to run in ovm mode given the System in/out modifications

I've reset the streams in finally. Is it still necessary to use ovm?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29051#discussion_r2665006456

From coffeys at openjdk.org  Tue Jan  6 14:04:38 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 6 Jan 2026 14:04:38 GMT
Subject: RFR: 8374555: No need for visible input warning in s.s.u.Password
 when not reading from System.in [v2]
In-Reply-To: <uxK23B3slxQGgTYsqeU0_q_czk_6rCmLU0aRKCGqnnQ=.575fa1e4-c5e4-468c-9691-5445fd7dbd26@github.com>
References: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
 <OXTU4v490aDqEw4UHvJ0n-VIbBeStq9Tpu-PETyayaU=.ba1d2733-8476-43e7-bc3d-f49ec6c1bed9@github.com>
 <uxK23B3slxQGgTYsqeU0_q_czk_6rCmLU0aRKCGqnnQ=.575fa1e4-c5e4-468c-9691-5445fd7dbd26@github.com>
Message-ID: <fUKHh98gpS1L89yRNTLnWFn7T5m8RaBH5coEhj8GR4c=.537d8c37-d76a-4bf9-8d03-300e80d4b12e@github.com>

On Tue, 6 Jan 2026 13:54:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/sun/security/util/Password/EmptyIn.java line 36:
>> 
>>> 34:  * @summary only print warning when reading from System.in
>>> 35:  * @modules java.base/sun.security.util
>>> 36:  * @library /test/lib
>> 
>> I think this test needs to run in ovm mode given the System in/out modifications
>
> I've reset the streams in finally. Is it still necessary to use ovm?

not sure - couldn't it still interfere with tests running in parallel ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29051#discussion_r2665025865

From coffeys at openjdk.org  Tue Jan  6 14:24:51 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 6 Jan 2026 14:24:51 GMT
Subject: RFR: 8374555: No need for visible input warning in s.s.u.Password
 when not reading from System.in [v2]
In-Reply-To: <1S4P364TlzVuJCMKp9HOjIeFmKznUTdDOg-d3i7AmDk=.a4b24e66-f22a-4fe7-bfc6-f1c56a73229b@github.com>
References: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
 <1S4P364TlzVuJCMKp9HOjIeFmKznUTdDOg-d3i7AmDk=.a4b24e66-f22a-4fe7-bfc6-f1c56a73229b@github.com>
Message-ID: <byzsxoBJ3-ZU8zdYsmO5dMYSGZZjQqc3eU9hwutXj0o=.e07b08b8-a3b3-48e5-8abd-ee0c8fd69776@github.com>

On Tue, 6 Jan 2026 13:58:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> We should only print out `[WARNING: Input may be visible on screen]` when trying to read password from `System.in`. Don't print it if the password is read from a different URL.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   warn only if VM is booted; more comments

Marked as reviewed by coffeys (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29051#pullrequestreview-3631081903

From coffeys at openjdk.org  Tue Jan  6 14:24:53 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 6 Jan 2026 14:24:53 GMT
Subject: RFR: 8374555: No need for visible input warning in s.s.u.Password
 when not reading from System.in [v2]
In-Reply-To: <fUKHh98gpS1L89yRNTLnWFn7T5m8RaBH5coEhj8GR4c=.537d8c37-d76a-4bf9-8d03-300e80d4b12e@github.com>
References: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
 <OXTU4v490aDqEw4UHvJ0n-VIbBeStq9Tpu-PETyayaU=.ba1d2733-8476-43e7-bc3d-f49ec6c1bed9@github.com>
 <uxK23B3slxQGgTYsqeU0_q_czk_6rCmLU0aRKCGqnnQ=.575fa1e4-c5e4-468c-9691-5445fd7dbd26@github.com>
 <fUKHh98gpS1L89yRNTLnWFn7T5m8RaBH5coEhj8GR4c=.537d8c37-d76a-4bf9-8d03-300e80d4b12e@github.com>
Message-ID: <8PP-PnBJSuwqnl0CVzEOMmdKNu9EcqsLaKs1-ii8ZEc=.7bcc29f2-4164-4ec6-a720-6e6cb863d121@github.com>

On Tue, 6 Jan 2026 14:01:23 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> I've reset the streams in finally. Is it still necessary to use ovm?
>
> not sure - couldn't it still interfere with tests running in parallel ?

actually - perhaps the test is fine as is.  jtreg only runs 1 test per time in any one JVM :
https://openjdk.org/jtreg/faq.html#what-are-the-agentvm-and-othervm-modes

jtreg provides the ability to run tests in parallel, using multiple JVMs running at once. (jtreg never runs multiple tests at the same time in any one JVM.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29051#discussion_r2665084634

From sshivang at openjdk.org  Tue Jan  6 14:49:54 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Tue, 6 Jan 2026 14:49:54 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <X9TCD0ph4NedupLHDI3yuzCwx4DkqG29fK-My0X67f0=.951c7f6a-7082-4af9-bd80-eaed216156e6@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

@dfuch Can you please review this?

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3714980944

From jpai at openjdk.org  Tue Jan  6 15:07:37 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jan 2026 15:07:37 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <p2QKik6KDdH4zCC7tiphXRqdCiuIbekzGmL8P7Dp64g=.c771fde7-7d67-40cf-bd08-d2115bb1e6db@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

Hello Shivangi, I will talk to Volkan tomorrow to decide if we should backport this or do it at a later date.

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3715049162

From myankelevich at openjdk.org  Tue Jan  6 15:56:45 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 6 Jan 2026 15:56:45 GMT
Subject: RFR: 8374555: No need for visible input warning in s.s.u.Password
 when not reading from System.in [v2]
In-Reply-To: <8PP-PnBJSuwqnl0CVzEOMmdKNu9EcqsLaKs1-ii8ZEc=.7bcc29f2-4164-4ec6-a720-6e6cb863d121@github.com>
References: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
 <OXTU4v490aDqEw4UHvJ0n-VIbBeStq9Tpu-PETyayaU=.ba1d2733-8476-43e7-bc3d-f49ec6c1bed9@github.com>
 <uxK23B3slxQGgTYsqeU0_q_czk_6rCmLU0aRKCGqnnQ=.575fa1e4-c5e4-468c-9691-5445fd7dbd26@github.com>
 <fUKHh98gpS1L89yRNTLnWFn7T5m8RaBH5coEhj8GR4c=.537d8c37-d76a-4bf9-8d03-300e80d4b12e@github.com>
 <8PP-PnBJSuwqnl0CVzEOMmdKNu9EcqsLaKs1-ii8ZEc=.7bcc29f2-4164-4ec6-a720-6e6cb863d121@github.com>
Message-ID: <b0Rr9OmeIRQJ2Xz-sarybfHGZqTLFWddmPrCefuwX5g=.9903ee50-7346-4ee3-867f-d1bcff0fd22a@github.com>

On Tue, 6 Jan 2026 14:20:17 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> not sure - couldn't it still interfere with tests running in parallel ?
>
> actually - perhaps the test is fine as is.  jtreg only runs 1 test per time in any one JVM :
> https://openjdk.org/jtreg/faq.html#what-are-the-agentvm-and-othervm-modes
> 
> jtreg provides the ability to run tests in parallel, using multiple JVMs running at once. (jtreg never runs multiple tests at the same time in any one JVM.)

I had the same thought at first, but yes in this case this seems to be fine. 
If you are going to have another commit here, what do you think about leaving a comment explaining why it's fine here atm? It's not worth doing if there are no other changes imo

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29051#discussion_r2665329417

From fferrari at openjdk.org  Tue Jan  6 17:23:16 2026
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 6 Jan 2026 17:23:16 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v18]
In-Reply-To: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
Message-ID: <5tKSNHbo1OZtjXQUoqF4h56hZ1ckVdxDn6v6RsKz0IM=.bb61b7f4-618a-4fdb-afd0-e8e30017904f@github.com>

> Hi, this is a proposal to fix [JDK-8352728](https://bugs.openjdk.org/browse/JDK-8352728 "InternalError loading java.security due to Windows parent folder permissions").
> 
> Path resolution with `Path::toRealPath` fails under the following conditions:
> 
> * When there is a restricted [_ACL_](https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-lists) in a parent directory (_Windows_)
> * When dealing with an anonymous file only accesible through the _procfs_, such as `/proc/<pid>/fd/<fd>` (_Linux_)
>     * Such a file can be created by a pipe, deleting an opened file, or with the [`memfd_create` _Linux_ API](https://man7.org/linux/man-pages/man2/memfd_create.2.html)
> 
> Original code from [JDK-8319332: Security properties files inclusion](https://bugs.openjdk.org/browse/JDK-8319332) unconditionally resolves with `Path::toRealPath` all the processed properties files. This PR avoids resolving any paths. Cyclic includes detection is now performed with the unresolved paths and `Files::isSameFile`, so `activePaths` no longer needs to be a `Set`.
> 
> <details>
> <summary>Previous approach and rationale for resolving <strong>file</strong> symlinks (kept here for historical reasons).</summary><br>
> 
> In _Linux_, a relative `include` from an anonymous file referenced as `/proc/<pid>/fd/<fd>` makes little sense.
> 
> However, in _Windows_, a relative `include` from a file where any of the parent directories has a restricted _ACL_ will be expected to work. It's important to note that such a restricted directory permissions scenario occurs to every [_UWP_](https://learn.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide) app (see [JDK-8369741](https://bugs.openjdk.org/browse/JDK-8369741 "cannot use java.security inside of UWP apps")).
> 
> When computing a relative `include`, we were performing symlinks resolution of the parent file under the rationale that the person writing the original properties file is the one who decides where the relative includes should resolve. This reasoning has been nuanced and re-evaluated in a [subsequent discussion](#discussion_r2585623241).
> 
> The original idea was to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The decision wa...

Francisco Ferrari Bihurriet 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 31 additional commits since the last revision:

 - Merge openjdk:master into franferrax:JDK-8352728
 - Update copyright for the New Year
 - Merge openjdk:master into franferrax:JDK-8352728
 - Remove superseded SecurityPropFile
 - Move tests into SecurityPropFile and rename them
 - Merge openjdk:master into franferrax:JDK-8352728
 - 3/3) Adjust ConfigFileTest for unresolved paths
 - 2/3) Refactor ConfigFileTest ExtraMode enum
   
   Move ExtraMode as an ExtraPropsFile field, so we have this information
   as soon as the ExtraPropsFile is created. This will be useful for the
   next change.
 - 1/3) Revert ConfigFileTest adjustment
   
   This reverts commit 7c80874c25bc99783ad24fb22d2c080d33c5503a only for
   ConfigFileTest.
 - Do not resolve symlinks for relative includes
   
   As @wangweij pointed out:
   > The person writing the original properties file may have expected
   > includes to resolve relative to its own location, but whoever created
   > the symlink may have intended a different resolution path. If they
   > wanted the original location, they could have just used the real file
   > directly instead of introducing a symlink.
   
   Since path resolution is causing trouble under certain conditions, let's
   avoid doing it. Other programs with include directives support in their
   configuration files are doing the same.
 - ... and 21 more: https://git.openjdk.org/jdk/compare/fcff1056...d94feb26

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24465/files
  - new: https://git.openjdk.org/jdk/pull/24465/files/6f1ffb66..d94feb26

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

  Stats: 7331 lines in 2233 files changed: 2119 ins; 1526 del; 3686 mod
  Patch: https://git.openjdk.org/jdk/pull/24465.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24465/head:pull/24465

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

From hchao at openjdk.org  Tue Jan  6 17:31:21 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 6 Jan 2026 17:31:21 GMT
Subject: RFR: 8374555: No need for visible input warning in s.s.u.Password
 when not reading from System.in [v2]
In-Reply-To: <1S4P364TlzVuJCMKp9HOjIeFmKznUTdDOg-d3i7AmDk=.a4b24e66-f22a-4fe7-bfc6-f1c56a73229b@github.com>
References: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
 <1S4P364TlzVuJCMKp9HOjIeFmKznUTdDOg-d3i7AmDk=.a4b24e66-f22a-4fe7-bfc6-f1c56a73229b@github.com>
Message-ID: <JZz5UZEczKTiWv6fpjkscCcVUZKzwmjtiXPYj-51ezM=.11bf83c7-3d24-44db-a312-83e6ce679ac1@github.com>

On Tue, 6 Jan 2026 13:58:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> We should only print out `[WARNING: Input may be visible on screen]` when trying to read password from `System.in`. Don't print it if the password is read from a different URL.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   warn only if VM is booted; more comments

Changes look good.

Marked as reviewed by hchao (Reviewer).

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

Marked as reviewed by hchao (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29051#pullrequestreview-3631801464
PR Review: https://git.openjdk.org/jdk/pull/29051#pullrequestreview-3631803191

From weijun at openjdk.org  Tue Jan  6 18:09:46 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Jan 2026 18:09:46 GMT
Subject: Integrated: 8374555: No need for visible input warning in
 s.s.u.Password when not reading from System.in
In-Reply-To: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
References: <JQFqBMTq4pkoGSeEetP0FoN6EcrqurKfLO1DvI0WtH0=.e4a3aca5-a3e9-4193-9a32-f03d210d6b97@github.com>
Message-ID: <uichlxQHG9BkhJ3fbErzZXowfcUKHCoeOBnnIqaLwyE=.5ae871ae-19f6-43fa-91bb-b1f5b2ec1d94@github.com>

On Mon, 5 Jan 2026 22:20:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> We should only print out `[WARNING: Input may be visible on screen]` when trying to read password from `System.in`. Don't print it if the password is read from a different URL.

This pull request has now been integrated.

Changeset: fbc59ac0
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbc59ac0a1248066e9fbcfde3bd6a8eb4d60992c
Stats:     80 lines in 2 files changed: 78 ins; 0 del; 2 mod

8374555: No need for visible input warning in s.s.u.Password when not reading from System.in

Reviewed-by: coffeys, hchao

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

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

From weijun at openjdk.org  Tue Jan  6 22:13:58 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Jan 2026 22:13:58 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v18]
In-Reply-To: <5tKSNHbo1OZtjXQUoqF4h56hZ1ckVdxDn6v6RsKz0IM=.bb61b7f4-618a-4fdb-afd0-e8e30017904f@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <5tKSNHbo1OZtjXQUoqF4h56hZ1ckVdxDn6v6RsKz0IM=.bb61b7f4-618a-4fdb-afd0-e8e30017904f@github.com>
Message-ID: <40BsGsXHC3wjWOHJyFeWoyYiXw1e-2TiE-rNDrrzVtc=.cae57cd3-6410-416a-a43e-311ec34e9b05@github.com>

On Tue, 6 Jan 2026 17:23:16 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this is a proposal to fix [JDK-8352728](https://bugs.openjdk.org/browse/JDK-8352728 "InternalError loading java.security due to Windows parent folder permissions").
>> 
>> Path resolution with `Path::toRealPath` fails under the following conditions:
>> 
>> * When there is a restricted [_ACL_](https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-lists) in a parent directory (_Windows_)
>> * When dealing with an anonymous file only accesible through the _procfs_, such as `/proc/<pid>/fd/<fd>` (_Linux_)
>>     * Such a file can be created by a pipe, deleting an opened file, or with the [`memfd_create` _Linux_ API](https://man7.org/linux/man-pages/man2/memfd_create.2.html)
>> 
>> Original code from [JDK-8319332: Security properties files inclusion](https://bugs.openjdk.org/browse/JDK-8319332) unconditionally resolves with `Path::toRealPath` all the processed properties files. This PR avoids resolving any paths. Cyclic includes detection is now performed with the unresolved paths and `Files::isSameFile`, so `activePaths` no longer needs to be a `Set`.
>> 
>> <details>
>> <summary>Previous approach and rationale for resolving <strong>file</strong> symlinks (kept here for historical reasons).</summary><br>
>> 
>> In _Linux_, a relative `include` from an anonymous file referenced as `/proc/<pid>/fd/<fd>` makes little sense.
>> 
>> However, in _Windows_, a relative `include` from a file where any of the parent directories has a restricted _ACL_ will be expected to work. It's important to note that such a restricted directory permissions scenario occurs to every [_UWP_](https://learn.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide) app (see [JDK-8369741](https://bugs.openjdk.org/browse/JDK-8369741 "cannot use java.security inside of UWP apps")).
>> 
>> When computing a relative `include`, we were performing symlinks resolution of the parent file under the rationale that the person writing the original properties file is the one who decides where the relative includes should resolve. This reasoning has been nuanced and re-evaluated in a [subsequent discussion](#discussion_r2585623241).
>> 
>> The original idea was to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path ca...
>
> Francisco Ferrari Bihurriet 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 31 additional commits since the last revision:
> 
>  - Merge openjdk:master into franferrax:JDK-8352728
>  - Update copyright for the New Year
>  - Merge openjdk:master into franferrax:JDK-8352728
>  - Remove superseded SecurityPropFile
>  - Move tests into SecurityPropFile and rename them
>  - Merge openjdk:master into franferrax:JDK-8352728
>  - 3/3) Adjust ConfigFileTest for unresolved paths
>  - 2/3) Refactor ConfigFileTest ExtraMode enum
>    
>    Move ExtraMode as an ExtraPropsFile field, so we have this information
>    as soon as the ExtraPropsFile is created. This will be useful for the
>    next change.
>  - 1/3) Revert ConfigFileTest adjustment
>    
>    This reverts commit 7c80874c25bc99783ad24fb22d2c080d33c5503a only for
>    ConfigFileTest.
>  - Do not resolve symlinks for relative includes
>    
>    As @wangweij pointed out:
>    > The person writing the original properties file may have expected
>    > includes to resolve relative to its own location, but whoever created
>    > the symlink may have intended a different resolution path. If they
>    > wanted the original location, they could have just used the real file
>    > directly instead of introducing a symlink.
>    
>    Since path resolution is causing trouble under certain conditions, let's
>    avoid doing it. Other programs with include directives support in their
>    configuration files are doing the same.
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/1e5c70be...d94feb26

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24465#pullrequestreview-3632697655

From weijun at openjdk.org  Tue Jan  6 22:20:21 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Jan 2026 22:20:21 GMT
Subject: [jdk26] RFR: 8374555: No need for visible input warning in
 s.s.u.Password when not reading from System.in
Message-ID: <ECqW-RQg15tX59jMxxAKUgvqpEZh2mekk4KdzYSU7so=.4922e1c1-ae72-4290-b8e7-a19e98c7848c@github.com>

8374555: No need for visible input warning in s.s.u.Password when not reading from System.in

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

Commit messages:
 - Backport fbc59ac0a1248066e9fbcfde3bd6a8eb4d60992c

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

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

From hchao at openjdk.org  Tue Jan  6 22:42:45 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 6 Jan 2026 22:42:45 GMT
Subject: [jdk26] RFR: 8374555: No need for visible input warning in
 s.s.u.Password when not reading from System.in
In-Reply-To: <ECqW-RQg15tX59jMxxAKUgvqpEZh2mekk4KdzYSU7so=.4922e1c1-ae72-4290-b8e7-a19e98c7848c@github.com>
References: <ECqW-RQg15tX59jMxxAKUgvqpEZh2mekk4KdzYSU7so=.4922e1c1-ae72-4290-b8e7-a19e98c7848c@github.com>
Message-ID: <ee2ylVOL3NUIAB6szxKi4beZGiiIgO1doT25MPnfl1I=.9226ba64-317e-404a-b8ef-6a5898a15189@github.com>

On Tue, 6 Jan 2026 22:12:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 8374555: No need for visible input warning in s.s.u.Password when not reading from System.in

Marked as reviewed by hchao (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29073#pullrequestreview-3632759572

From vpaprotski at openjdk.org  Wed Jan  7 00:22:35 2026
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 7 Jan 2026 00:22:35 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI and AVX512_VBMI2 [v2]
In-Reply-To: <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>
Message-ID: <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>

On Sat, 3 Jan 2026 00:23:13 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> This change allows use of the AVX512_VBMI/VMBI2 instruction set to further optimize decompression/parsing of polynomial coefficients for ML-KEM.  The speedup gained in the ML-KEM benchmarks for key generation is between 0.2 to 0.5%, encapsulation is  0.3 to 1.5%, and decapsulation is 0 to 0.9%.
>> 
>> Thank you to @sviswa7 and @ferakocz for their help in working through the early stages of this code with me.
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

"Insert 0b0000 nibble after every third nibble". I only have two questions, looks good otherwise.


PS: things I've considered:

- Loop controls?
  - ML_KEM.java guarantees  (per callee comment and assert) lengths are multiple of 64
  - also same as original code
- Why not simply a vpermb? Have zeroes already from the masked load with k1..
  - shuffle granularity is actually 4-bits, not 8-bits
- logical shift already zeroes top bits, so `vpand` not required?
  - odd columns not shifted, so still have extra bits that need clearing
- Why VBMI?
  - needed for `evpermb`

src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 862:

> 860:   __ addptr(condensed, condensedOffs);
> 861: 
> 862:   if (VM_Version::supports_avx512_vbmi2()) {

Which instruction needs vbmi2? All I could spot was that `evpermb` that needs vbmi. Relax the restriction slightly?

src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 906:

> 904:       __ addptr(condensed, 192);
> 905:       __ addptr(parsed, 256);
> 906:       __ subl(parsedLength, 128);

(128 instead of 256 here because `parsedLength` is an index to an `short` array..)

I am confused by the stride. The `twelve2Sixteen()` seems to (almost) guarantee that the parsed length is a multiple of 64 (last block can be 48 bytes). This would imply a stride of 128 bytes for `parsed`. And 96 for `condensed`.

This is exactly how the existing code already behaves so I am less concerned, but I would like an explanation why it works?

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

PR Review: https://git.openjdk.org/jdk/pull/28815#pullrequestreview-3632845110
PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2666594767
PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2666663039

From weijun at openjdk.org  Wed Jan  7 00:38:13 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Jan 2026 00:38:13 GMT
Subject: [jdk26] Integrated: 8374555: No need for visible input warning in
 s.s.u.Password when not reading from System.in
In-Reply-To: <ECqW-RQg15tX59jMxxAKUgvqpEZh2mekk4KdzYSU7so=.4922e1c1-ae72-4290-b8e7-a19e98c7848c@github.com>
References: <ECqW-RQg15tX59jMxxAKUgvqpEZh2mekk4KdzYSU7so=.4922e1c1-ae72-4290-b8e7-a19e98c7848c@github.com>
Message-ID: <8gbSn7rQx_msI_D9gZs5hOj3wXuxz6COmf_UNFiEgbM=.d410b430-3d2c-4d49-b853-d2a95dbc7d2f@github.com>

On Tue, 6 Jan 2026 22:12:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 8374555: No need for visible input warning in s.s.u.Password when not reading from System.in

This pull request has now been integrated.

Changeset: 25462ba4
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25462ba45d9e1459472b6a6dfe13b575cd7ef968
Stats:     80 lines in 2 files changed: 78 ins; 0 del; 2 mod

8374555: No need for visible input warning in s.s.u.Password when not reading from System.in

Reviewed-by: hchao
Backport-of: fbc59ac0a1248066e9fbcfde3bd6a8eb4d60992c

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

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

From serb at openjdk.org  Wed Jan  7 02:24:25 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Jan 2026 02:24:25 GMT
Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files
 where it was missed [v4]
In-Reply-To: <JnDBfpSX2boh4MregZIgWpxg8gmgpal0_p7-cmp92Ok=.53d89bd4-7f69-489b-b18b-d48ff354ecbf@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
 <JnDBfpSX2boh4MregZIgWpxg8gmgpal0_p7-cmp92Ok=.53d89bd4-7f69-489b-b18b-d48ff354ecbf@github.com>
Message-ID: <Y5_mNmjjmMarr5d5NPbcv06zyT2FQh35o3TkJarbr1A=.b0715e43-a3fd-4301-b52e-fdf7e54821e9@github.com>

On Tue, 6 Jan 2026 01:58:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>Just be aware that if a file was created as part of a refactoring and the code was taken as-is from an existing file, then the copyright year range should have remained the same as the original file. I don't know if any of the files you modified fall into that category but just wanted to point out that looking at the commit date is not always correct.

I tried to catch rename/move-only or copyright-only changes, but I?m not 100% sure I filtered all of them out.

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

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3717068454

From weijun at openjdk.org  Wed Jan  7 03:20:17 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Jan 2026 03:20:17 GMT
Subject: RFR: 8367344: Better error message when decryption of AP-REQ fails
 because of kvno mismatch [v6]
In-Reply-To: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com>
References: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com>
Message-ID: <xJgNEpKfHq0N0d8SKJ2QKmIfqpkq9ymlyoVJZhUtf6s=.d930fadd-f3f1-47da-8e4b-11f2c43933c3@github.com>

> For interoperability, AP-REQ decryption uses the key with the highest kvno in the keytab if no exact match is found. If decryption fails, a normal "checksum failed" error is reported, which may hide the real cause that the wrong key is used. This code change throws a KRB_AP_ERR_BADKEYVER error in this case.
> 
> The change is only made in AP-REQ decryption to minimize impact. A previous test is enhanced to cover the case.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into 8367344
 - missing space
 - call fromUserKtab directly with aotomatic isInitiator being false; show exception if not correct code
 - typo
 - more etypes in test
 - different exception for other etypes; test
 - the fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27298/files
  - new: https://git.openjdk.org/jdk/pull/27298/files/aee6aec3..f82bc7d0

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

  Stats: 590634 lines in 7429 files changed: 409328 ins; 113541 del; 67765 mod
  Patch: https://git.openjdk.org/jdk/pull/27298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27298/head:pull/27298

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

From duke at openjdk.org  Wed Jan  7 06:22:48 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 7 Jan 2026 06:22:48 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI and AVX512_VBMI2 [v2]
In-Reply-To: <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>
 <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>
Message-ID: <S30vwocopm1Pihol_RWwjlYUIV2mfB8pDWUx4Z2SQ3A=.2df41e1a-bc53-46ef-b988-6cd31f726b06@github.com>

On Tue, 6 Jan 2026 23:29:52 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 862:
> 
>> 860:   __ addptr(condensed, condensedOffs);
>> 861: 
>> 862:   if (VM_Version::supports_avx512_vbmi2()) {
> 
> Which instruction needs vbmi2? All I could spot was that `evpermb` that needs vbmi. Relax the restriction slightly?

Good catch!  Initially the code was using `vpshldvw`, but was changed to just use `vpsrlvw`.  Fixed in next commit.
I should probably update the bug synopsis to exclude VBMI2?

> src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 906:
> 
>> 904:       __ addptr(condensed, 192);
>> 905:       __ addptr(parsed, 256);
>> 906:       __ subl(parsedLength, 128);
> 
> (128 instead of 256 here because `parsedLength` is an index to an `short` array..)
> 
> I am confused by the stride. The `twelve2Sixteen()` seems to (almost) guarantee that the parsed length is a multiple of 64 (last block can be 48 bytes). This would imply a stride of 128 bytes for `parsed`. And 96 for `condensed`.
> 
> This is exactly how the existing code already behaves so I am less concerned, but I would like an explanation why it works?

I believe the numbers are right: with each pass 256 bytes of coefficients are `parsed` into the parse buffer.  This means that half of the coefficients have been processed (`parseLength` = 128).  Would having a comment stating as such be sufficient for your concerns?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2667206396
PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2667206828

From pminborg at openjdk.org  Wed Jan  7 08:42:52 2026
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 Jan 2026 08:42:52 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <PXM7cvaq12FcA0_MMfWC363-ZEwGIcsKPYAmJldbpAo=.ba23d30e-4941-44ef-b462-df9a233c789f@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <hvzPGrqI0zAz8wtLd40PWgnkeSMGLFGO9moE8PLqLbM=.f605a45f-685c-4f2d-a9c4-073f0b81947d@github.com>
 <IluLLCRKvj27XmeyeHp_7jb6j0nf8mcew0AwBMhLHS4=.e836e787-c6e9-43a0-a2d5-26f93bd67e28@github.com>
 <PXM7cvaq12FcA0_MMfWC363-ZEwGIcsKPYAmJldbpAo=.ba23d30e-4941-44ef-b462-df9a233c789f@github.com>
Message-ID: <R02gC6zZP9ySKeewnlGsQ_Aa48K02yie3qjSX8wA1Ek=.5cb20f20-ab61-4c0c-8f6b-ca9abceb0ad6@github.com>

On Tue, 23 Dec 2025 07:33:14 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> Good idea. There is a `Linker.Option.captureCallState("errno")` feature and I'll see how to use it.
>
> It looks like there has been prior work with this, at least with macos, e.g.: src/java.base/macosx/classes/jdk/internal/ffi/generated/errno/errno_h.java

Also, there is a class `jdk.internal.foreign.CaptureStateUtil` that can be used to simplify and improve performance when working with `errno` and the likes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2667535314

From pminborg at openjdk.org  Wed Jan  7 08:42:56 2026
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 Jan 2026 08:42:56 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
Message-ID: <KVqg7r8bFUy2bHWuEDqVbuXhun4J5nSFRVvNjz0-Nlg=.f81cf4c3-c318-4bac-a8e6-72ae90269fd0@github.com>

On Mon, 5 Jan 2026 17:20:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   must have username; more comments

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88:

> 86:             = (ValueLayout) LINKER.canonicalLayouts().get("size_t");
> 87: 
> 88:     private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout();

Would it be a good idea to use capitalized names for immutable static fields in all places in the class? E.g., `CAPTURED_STATE_LAYOUT` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2667524583

From djelinski at openjdk.org  Wed Jan  7 08:46:38 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Jan 2026 08:46:38 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950
In-Reply-To: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
Message-ID: <uZ57vmbts072GNv2OSNe_cH3XgL_X0QYxgq8-zczDqE=.11986d49-4762-4126-86d7-998304122625@github.com>

On Tue, 6 Jan 2026 04:20:18 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The method ckAssertReturnValueOK will invoke ckAssertReturnValueOK2 which makes multiple calls to JNI functions, such as FindClass or GetMethodID. These calls would be unsafe as there may be a pending exception at this time.
> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.

src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_keymgmt.c line 963:

> 961:         goto cleanup;
> 962:     }
> 963:     if (ckAssertReturnValueOK(env, rv) != CK_ASSERT_OK) {

I think we should move this assertion right after the C_DeriveKey call above instead. No point in copying the keys if derivation fails.

Also, please update the copyright year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29054#discussion_r2667542638

From djelinski at openjdk.org  Wed Jan  7 09:05:34 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Jan 2026 09:05:34 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v2]
In-Reply-To: <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
Message-ID: <04gf4mIw4A8ibXD8SGV_8CrNDyiNiriuGlIGTa1I3JA=.d5eaaabc-e0f0-4ddd-b381-f8aea75f7dca@github.com>

On Fri, 19 Dec 2025 17:37:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
>> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
>> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
>> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
>> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove wildcard imports

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28905#pullrequestreview-3633935001

From vyazici at openjdk.org  Wed Jan  7 09:07:26 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 09:07:26 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v3]
In-Reply-To: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
Message-ID: <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>

> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
> 
> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Update copyright years
 - Migrate forgotten `ClearTextServerSSL`
 - Merge remote-tracking branch 'upstream/master' into simpleSslRest
 - Remove wildcard imports
 - Merge remote-tracking branch 'upstream/master' into simpleSslRest
 - Restore all non-`httpclient`, non-`httpserver` changes in `test/`
 - Make sure `get()` returns the same instance
 - Reverted all changes and only kept `SimpleSSLContext` enhancements
 - Overhaul `SimpleSSLContext` and its usages

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

Changes: https://git.openjdk.org/jdk/pull/28905/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28905&range=02
  Stats: 77 lines in 12 files changed: 4 ins; 39 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/28905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28905/head:pull/28905

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

From djelinski at openjdk.org  Wed Jan  7 09:12:15 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Jan 2026 09:12:15 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v3]
In-Reply-To: <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>
Message-ID: <48aZoJx-DQzKIw3ZBTis2I56oNJHZax_Zh1PVKHhZuM=.abd44f14-aaf9-4d3c-8b86-385105cede40@github.com>

On Wed, 7 Jan 2026 09:07:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
>> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
>> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
>> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
>> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Update copyright years
>  - Migrate forgotten `ClearTextServerSSL`
>  - Merge remote-tracking branch 'upstream/master' into simpleSslRest
>  - Remove wildcard imports
>  - Merge remote-tracking branch 'upstream/master' into simpleSslRest
>  - Restore all non-`httpclient`, non-`httpserver` changes in `test/`
>  - Make sure `get()` returns the same instance
>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>  - Overhaul `SimpleSSLContext` and its usages

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28905#pullrequestreview-3633955099

From vyazici at openjdk.org  Wed Jan  7 09:25:04 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 09:25:04 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v3]
In-Reply-To: <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>
Message-ID: <GBpdvibXcfk6QgI_JLki-rvzjtkIVFCFw3IgRIs03ec=.d2ea029e-02f4-419f-94c1-afada6af3c21@github.com>

On Wed, 7 Jan 2026 09:07:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
>> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
>> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
>> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
>> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Update copyright years
>  - Migrate forgotten `ClearTextServerSSL`
>  - Merge remote-tracking branch 'upstream/master' into simpleSslRest
>  - Remove wildcard imports
>  - Merge remote-tracking branch 'upstream/master' into simpleSslRest
>  - Restore all non-`httpclient`, non-`httpserver` changes in `test/`
>  - Make sure `get()` returns the same instance
>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>  - Overhaul `SimpleSSLContext` and its usages

test/jdk/com/sun/net/httpserver/ClearTextServerSSL.java line 1:

> 1: /*

This should have been addressed in [JDK-8373537], but forgotten. Doing it here.

[JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28905#discussion_r2667658921

From vyazici at openjdk.org  Wed Jan  7 10:00:09 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 10:00:09 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <rXVSDY6AFq06w7eUJenZHZj_MlPDaEx60kJH3tNNROw=.8c388b35-5633-47f7-9872-718a4d9849f2@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

I'm keen on backporting JDK-8372661 and all its sub-tasks (mind that their merge order matters!), preferably ASAP. It is a matter of time we will need to backport a change set touching tests that use `SimpleSSLContext`, and the author will need to deal with the merge conflict. Put another way, I am not able to see a reason to postpone this operation. That said, porting process can be complicated, and @dfuch has extensive experience on the subject. I will defer the _"When shall we backport?"_ question to him.

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3718100043

From myankelevich at openjdk.org  Wed Jan  7 11:22:54 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 7 Jan 2026 11:22:54 GMT
Subject: RFR: 8374001: sun/security/ skip without Exceptions [v2]
In-Reply-To: <P1xMe3z5wtoG1l84Iu2IJNH-B2sUVchQ46SFYiOThPs=.18e8a2fe-dc84-45a7-98b0-f4568ca949e9@github.com>
References: <P1xMe3z5wtoG1l84Iu2IJNH-B2sUVchQ46SFYiOThPs=.18e8a2fe-dc84-45a7-98b0-f4568ca949e9@github.com>
Message-ID: <9UiHxDfiSJwrgZHG1vlJnjwiLZsRFuWiVxeYDvsmqlU=.8dbcfb68-bd31-4345-9fc4-7cc2aee1d395@github.com>

> Pr cleaning up the tests left after the previous PRs.
> 
> * test/jdk/sun/security/util/Resources/Usages.java
> * test/jdk/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java
> * test/jdk/sun/security/krb5/config/ConfPlusProp.java
> * test/jdk/sun/security/krb5/auto/ReplayCacheTestProc.java

Mikhail Yankelevich 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:

 - updating to latest master and copyrights
 - Merge branch 'master' into JDK-8374001
 - JDK-8374001: sun/security/ skip without Exceptions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28898/files
  - new: https://git.openjdk.org/jdk/pull/28898/files/56f2f171..6284930a

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

  Stats: 82758 lines in 3536 files changed: 44853 ins; 16575 del; 21330 mod
  Patch: https://git.openjdk.org/jdk/pull/28898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28898/head:pull/28898

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

From myankelevich at openjdk.org  Wed Jan  7 11:26:08 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 7 Jan 2026 11:26:08 GMT
Subject: RFR: 8373016: Passes instead of skips/ignoring the platform in
 sun/security/mscapi, jarsigner, keytool and pkcs12 tests [v2]
In-Reply-To: <q2cc79w1ZCKBY0ptE05vXLHuwQnAmJAXtMn3_x13ONU=.6cecf1b5-dd34-42a6-b799-4ff6cfbe86a1@github.com>
References: <q2cc79w1ZCKBY0ptE05vXLHuwQnAmJAXtMn3_x13ONU=.6cecf1b5-dd34-42a6-b799-4ff6cfbe86a1@github.com>
Message-ID: <DiuEIbFDl44_jaljB_3NLdI4UyFACzF3uJnCBmMhLA8=.6f53f877-b9ec-48c1-b17c-dfa832dae3ff@github.com>

> Passes when shouldn't in these tests:
> * test/jdk/sun/security/mscapi/IsSunMSCAPIAvailable.java
> * test/jdk/sun/security/mscapi/SignUsingSHA2withRSA.java
> * test/jdk/sun/security/mscapi/SignUsingNONEwithRSA.java
> * test/jdk/sun/security/mscapi/RSAEncryptDecrypt.java
> * test/jdk/sun/security/tools/jarsigner/CertChainUnclosed.java
> * test/jdk/sun/security/tools/keytool/StorePasswords.java
> * test/jdk/sun/security/pkcs12/StoreSecretKeyTest.java

Mikhail Yankelevich 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 'master' into JDK-8373016
 - JDK-8373016: Passes instead of skips/ignoring the platform in sun/security/mscapi, jarsigner, keytool and pkcs12 tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28635/files
  - new: https://git.openjdk.org/jdk/pull/28635/files/26fec979..e5e46900

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

  Stats: 82762 lines in 3540 files changed: 44853 ins; 16575 del; 21334 mod
  Patch: https://git.openjdk.org/jdk/pull/28635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28635/head:pull/28635

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

From myankelevich at openjdk.org  Wed Jan  7 11:26:10 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 7 Jan 2026 11:26:10 GMT
Subject: RFR: 8373016: Passes instead of skips/ignoring the platform in
 sun/security/mscapi, jarsigner, keytool and pkcs12 tests
In-Reply-To: <q2cc79w1ZCKBY0ptE05vXLHuwQnAmJAXtMn3_x13ONU=.6cecf1b5-dd34-42a6-b799-4ff6cfbe86a1@github.com>
References: <q2cc79w1ZCKBY0ptE05vXLHuwQnAmJAXtMn3_x13ONU=.6cecf1b5-dd34-42a6-b799-4ff6cfbe86a1@github.com>
Message-ID: <7RkjOdtuOLpkFAKteBc48if0Hliv1AH-SpU8M1MFlh4=.59223e36-29b7-47c1-bc26-4a3f7f834f25@github.com>

On Wed, 3 Dec 2025 14:00:52 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Passes when shouldn't in these tests:
> * test/jdk/sun/security/mscapi/IsSunMSCAPIAvailable.java
> * test/jdk/sun/security/mscapi/SignUsingSHA2withRSA.java
> * test/jdk/sun/security/mscapi/SignUsingNONEwithRSA.java
> * test/jdk/sun/security/mscapi/RSAEncryptDecrypt.java
> * test/jdk/sun/security/tools/jarsigner/CertChainUnclosed.java
> * test/jdk/sun/security/tools/keytool/StorePasswords.java
> * test/jdk/sun/security/pkcs12/StoreSecretKeyTest.java

Updated copyrights and merged latest master

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

PR Comment: https://git.openjdk.org/jdk/pull/28635#issuecomment-3718419044

From myankelevich at openjdk.org  Wed Jan  7 11:29:56 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 7 Jan 2026 11:29:56 GMT
Subject: RFR: 8372817: Remove test/jdk/sun/security/rsa silent skips [v2]
In-Reply-To: <HKpgBXAhdf_aOsh8Q8djvoYiFXhTmcvCCoC7OQA_YFE=.91798c32-6c45-4e89-ac25-fd555c559e9e@github.com>
References: <HKpgBXAhdf_aOsh8Q8djvoYiFXhTmcvCCoC7OQA_YFE=.91798c32-6c45-4e89-ac25-fd555c559e9e@github.com>
Message-ID: <vY4Itfis8f84-PMq8G0Nw6UMZwHvLfQc-aaqX_LX1xk=.f123d9bd-e3fb-4dec-a6c9-2b50bc7587d4@github.com>

> Removing silent skips and throwing skipped exceptions in the following tests:
> test/jdk/sun/security/rsa/TestSigGen15.java
> test/jdk/sun/security/rsa/TestCACerts.java
> test/jdk/sun/security/rsa/pss/TestSigGenPSS.java
> test/jdk/sun/security/rsa/pss/SignatureTest2.java

Mikhail Yankelevich 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 'master' into JDK-8372817 and update copyright
 - JDK-8372817: Remove test/jdk/sun/security/rsa silent skips

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28580/files
  - new: https://git.openjdk.org/jdk/pull/28580/files/385c32a5..95806b9c

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

  Stats: 82758 lines in 3536 files changed: 44853 ins; 16575 del; 21330 mod
  Patch: https://git.openjdk.org/jdk/pull/28580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28580/head:pull/28580

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

From myankelevich at openjdk.org  Wed Jan  7 11:45:04 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 7 Jan 2026 11:45:04 GMT
Subject: RFR: 8367326: Refactor PEM API tests requiring PEMRecord usage
In-Reply-To: <W-2LrGJGPaKSU7bkwWCyp0V-Rlp9pLJ55x7sUUKVH0w=.22d451d1-f0f3-4205-a585-7b383bd0c7c9@github.com>
References: <2Ow4JVXCRsN-a3SauMcH2lR-HTP-S8e_oNN4T3fxMg8=.7f14fabc-1fa8-4053-a588-c91701734856@github.com>
 <W-2LrGJGPaKSU7bkwWCyp0V-Rlp9pLJ55x7sUUKVH0w=.22d451d1-f0f3-4205-a585-7b383bd0c7c9@github.com>
Message-ID: <2VtCG4Z7SynVrUZffVQZS8uCiMv7RaKx0EMWaBJ0Tuo=.7211bcae-6343-4bbb-aaca-ea8b6654fcaa@github.com>

On Thu, 27 Nov 2025 01:41:46 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I understand the intent to use `PEM` here, but I think this is forcing the new API onto these tests rather than making it easier. For `TestKeyFactory.java` I wouldn't make the change. For the other two, I think it makes more sense to headers and footers to the base64 strings than using `PEM` to workaround it.

Yes, I think this should be easier. However, I'd have to disagree about `PKIXValAndRevCheckTests.java`. I use it intentionally there like this in order to increase the coverage of the PEM::decode method. 
What do you think about keeping it as is and changing `PSSKeyCompatibility` in order not to force PEM?

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

PR Comment: https://git.openjdk.org/jdk/pull/28356#issuecomment-3718493332

From mdoerr at openjdk.org  Wed Jan  7 11:47:37 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 7 Jan 2026 11:47:37 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
Message-ID: <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>

On Mon, 5 Jan 2026 21:30:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> FWIW there is an issue and ML discussion relating to extension of arguments with respect to `ValueLayout`: https://bugs.openjdk.org/browse/JDK-8336664
>
> \What happens if you create a user on AIX with a uid bigger than 2^31 and call `getpwuid_r` on it (by hardcoding `tmpUid` as a negative number)?

I haven't tried (not my machine), but it's undefined behavior. There's no guarantee that `getpwuid_r` does what we expect. We should never use undefined behavior. Also note that not only AIX is affected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2668116234

From lkorinth at openjdk.org  Wed Jan  7 12:35:42 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:35:42 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
Message-ID: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>

On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
> 
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>    
>    Reviewed-by: aboldtch
>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>    
>    Reviewed-by: serb, aivanov, dnguyen
>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767

I will redo the merge, I have done something strange.

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595

From lkorinth at openjdk.org  Wed Jan  7 12:58:43 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:58:43 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3]
In-Reply-To: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
Message-ID: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>

> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
> 
> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
> 
> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
> 
> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.

Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:

 - Merge branch '8373253' into 8367993
 - Merge branch 'master' into _8373253
 - Merge branch 'master' into _8367993
 - 8366058: Outdated comment in WinCAPISeedGenerator
   
   Reviewed-by: mullan
 - 8357258: x86: Improve receiver type profiling reliability
   
   Reviewed-by: kvn, vlivanov
 - 8373704: Improve "SocketException: Protocol family unavailable" message
   
   Reviewed-by: lucy, jpai
 - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
   
   Reviewed-by: jiefu, jbhateja, erfang, qamai
 - 8343809: Add requires tag to mark tests that are incompatible with exploded image
   
   Reviewed-by: alanb, dholmes
 - 8374465: Spurious dot in documentation for JVMTI ClassLoad
   
   Reviewed-by: kbarrett
 - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
   
   Reviewed-by: djelinski, mpowers, ascarpino
 - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

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

Changes: https://git.openjdk.org/jdk/pull/28723/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02
  Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod
  Patch: https://git.openjdk.org/jdk/pull/28723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723

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

From duke at openjdk.org  Wed Jan  7 13:21:35 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 7 Jan 2026 13:21:35 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI and AVX512_VBMI2 [v2]
In-Reply-To: <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>
 <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>
Message-ID: <pkNgMQPwR5rYj5cg9IuhA0mxSpgueeHZ8Prnc2OSa6M=.ce5deeba-83c2-4ab7-9fac-a0319f6102b1@github.com>

On Wed, 7 Jan 2026 00:18:43 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> "Insert 0b0000 nibble after every third nibble". I only have two questions, looks good otherwise.

Yes, that is the idea.

> 
> PS: things I've considered:
> 
> * Loop controls?
>   
>   * ML_KEM.java guarantees  (per callee comment and assert) lengths are multiple of 64
>   * also same as original code
> * Why not simply a vpermb? Have zeroes already from the masked load with k1..

It *is* using vpermb (evpermb() generates the EVEX encoded VPERMB)

>   
>   * shuffle granularity is actually 4-bits, not 8-bits

Really? In what instruction? I hadn't found it in the manual.

> * logical shift already zeroes top bits, so `vpand` not required?

Only every 2nd byte is shifted, the rest needs to be masked.
>   
>   * odd columns not shifted, so still have extra bits that need clearing

Yes, that is what the vpand does. (actually, it also (unnecessarily) masks the shifted bytes.

> * Why VBMI?
>   
>   * needed for `evpermb`

Yes.

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

PR Comment: https://git.openjdk.org/jdk/pull/28815#issuecomment-3718842604

From mcimadamore at openjdk.org  Wed Jan  7 14:10:02 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 7 Jan 2026 14:10:02 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
Message-ID: <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>

On Wed, 7 Jan 2026 11:44:24 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> \What happens if you create a user on AIX with a uid bigger than 2^31 and call `getpwuid_r` on it (by hardcoding `tmpUid` as a negative number)?
>
> I haven't tried (not my machine), but it's undefined behavior. There's no guarantee that `getpwuid_r` does what we expect. We should never use undefined behavior. Also note that not only AIX is affected.

> It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?

Indeed, the status quo with respect to unsigned values passed to downcalls is a bit suboptimal, esp. in certain ABIs where sign/zero extension is required. This is tracked here:

https://bugs.openjdk.org/browse/JDK-8336664

(apologies -- this link was already shared by @dmlloyd )

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2668596071

From fferrari at openjdk.org  Wed Jan  7 14:31:16 2026
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 7 Jan 2026 14:31:16 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <DLTrn6RqFdEs_IQzK0Q6Pm3tAUAh1XXZsA7y2LBkDbg=.eed350f5-3c57-4e86-9e80-54676650a05b@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
 <DLTrn6RqFdEs_IQzK0Q6Pm3tAUAh1XXZsA7y2LBkDbg=.eed350f5-3c57-4e86-9e80-54676650a05b@github.com>
Message-ID: <45KDXEzmwV8nEohWGuKIUxd5hXKRAngJAvNfIYbvRH4=.2fda8508-bfa1-46fb-b7ca-014667ca3259@github.com>

On Tue, 2 Dec 2025 17:02:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address review comments
>>  - Slightly improve ConfigFileTestDirPermissions
>>    
>>    Extract restrictedAcl() AutoCloseable and also use AutoCloseable for the
>>    temporary directory cleanup.
>
> Please confirm if I understand correctly. So the current fix covers both this bug and the Windows UWP regression. However, if relative include is used in Windows UWP, it is still a problem. Is this right?
> 
> If so, if one day someone brings up the relative include problem in Windows UWP, do you expect a different fix that will overwrite this one? Or is it the Windows admin's duty to add more permissions?

Thanks @wangweij for the approval and your contributions to the discussion. I will wait one more day before integrating, just in case anyone else wants to be credited as a reviewer in the commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3719133057

From vyazici at openjdk.org  Wed Jan  7 15:41:19 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 15:41:19 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v2]
In-Reply-To: <Du9iQRzUMlXeAP8mMzYOQh8nDRFq37ueXSc_Z5nu07c=.210ec2d1-cfc6-462a-a824-4f6b990fa81b@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
 <Du9iQRzUMlXeAP8mMzYOQh8nDRFq37ueXSc_Z5nu07c=.210ec2d1-cfc6-462a-a824-4f6b990fa81b@github.com>
Message-ID: <L2UJUrYrTSIoMJkOm2xLVkIghe89aZ6lfXsTsknwPe4=.78a2c70f-73b0-4e3b-9516-c29f2b29c8ac@github.com>

On Tue, 6 Jan 2026 06:48:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove wildcard imports
>
> This looks good to me.

@jaikiran, @djelinski, thanks so much for the reviews, and patience.
`SimpleSSLContext` null-safe static factory methods saga ends with this commit.

Tier 1-2 are clear on 76dae687368.

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

PR Comment: https://git.openjdk.org/jdk/pull/28905#issuecomment-3719466520

From vyazici at openjdk.org  Wed Jan  7 15:41:20 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 15:41:20 GMT
Subject: Integrated: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods
In-Reply-To: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
Message-ID: <X8OYy1PDIL2dy5b_mrT5hQnBs5UbLpGinvMEGY3ZWNE=.b6038750-3c14-4d6f-872c-140e97deac8e@github.com>

On Thu, 18 Dec 2025 18:32:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
> 
> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537

This pull request has now been integrated.

Changeset: 3541bc86
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3541bc8635ad8f5f4151758de3a134c9c105cebd
Stats:     77 lines in 12 files changed: 4 ins; 39 del; 34 mod

8373538: Migrate all tests to null-safe "SimpleSSLContext" methods

Reviewed-by: djelinski, jpai

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

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

From vpaprotski at openjdk.org  Wed Jan  7 16:42:24 2026
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 7 Jan 2026 16:42:24 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI and AVX512_VBMI2 [v2]
In-Reply-To: <pkNgMQPwR5rYj5cg9IuhA0mxSpgueeHZ8Prnc2OSa6M=.ce5deeba-83c2-4ab7-9fac-a0319f6102b1@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>
 <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>
 <pkNgMQPwR5rYj5cg9IuhA0mxSpgueeHZ8Prnc2OSa6M=.ce5deeba-83c2-4ab7-9fac-a0319f6102b1@github.com>
Message-ID: <7gLxGLuYKPYchraxk4Z4hh_ThfgGsGGdYAL2LVaDBvg=.63281063-7480-431f-b24e-1304ef92326e@github.com>

On Wed, 7 Jan 2026 13:18:50 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> > "Insert 0b0000 nibble after every third nibble". I only have two questions, looks good otherwise.

@ferakocz apologies for the misunderstanding; everything after the PS was not a request for change.. those were the questions that occurred to me and I found the answer.. The only reason I put them in was for the next reviewer. Or if I am wrong, e.g. no, I did not find a better instruction than vpermb either. (My first reaction to seeing the java code, was 'oh, this is easy, just a `vpermb`, then had to reason out why not..)

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

PR Comment: https://git.openjdk.org/jdk/pull/28815#issuecomment-3719734572

From vpaprotski at openjdk.org  Wed Jan  7 16:42:27 2026
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 7 Jan 2026 16:42:27 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI and AVX512_VBMI2 [v2]
In-Reply-To: <S30vwocopm1Pihol_RWwjlYUIV2mfB8pDWUx4Z2SQ3A=.2df41e1a-bc53-46ef-b988-6cd31f726b06@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>
 <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>
 <S30vwocopm1Pihol_RWwjlYUIV2mfB8pDWUx4Z2SQ3A=.2df41e1a-bc53-46ef-b988-6cd31f726b06@github.com>
Message-ID: <kMJO2pgM1oqbuK8Zp3MS2yK-c_b7VIerONCJem4CEyg=.bc72d1c3-98bf-4b93-b8e1-4ad3d008005b@github.com>

On Wed, 7 Jan 2026 06:18:55 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 862:
>> 
>>> 860:   __ addptr(condensed, condensedOffs);
>>> 861: 
>>> 862:   if (VM_Version::supports_avx512_vbmi2()) {
>> 
>> Which instruction needs vbmi2? All I could spot was that `evpermb` that needs vbmi. Relax the restriction slightly?
>
> Good catch!  Initially the code was using `vpshldvw`, but was changed to just use `vpsrlvw`.  Fixed in next commit.
> I should probably update the bug synopsis to exclude VBMI2?

I would be happy with just the code being pedantic. Everything else is 'just nice' :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2669186665

From vpaprotski at openjdk.org  Wed Jan  7 16:46:08 2026
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 7 Jan 2026 16:46:08 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI and AVX512_VBMI2 [v2]
In-Reply-To: <S30vwocopm1Pihol_RWwjlYUIV2mfB8pDWUx4Z2SQ3A=.2df41e1a-bc53-46ef-b988-6cd31f726b06@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>
 <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>
 <S30vwocopm1Pihol_RWwjlYUIV2mfB8pDWUx4Z2SQ3A=.2df41e1a-bc53-46ef-b988-6cd31f726b06@github.com>
Message-ID: <BeagYlohcNYsjTc12pzJZ4kpkoxHT-BZwgvkLINDxpE=.ea4ae404-f9eb-4e86-8758-72c708561233@github.com>

On Wed, 7 Jan 2026 06:19:09 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 906:
>> 
>>> 904:       __ addptr(condensed, 192);
>>> 905:       __ addptr(parsed, 256);
>>> 906:       __ subl(parsedLength, 128);
>> 
>> (128 instead of 256 here because `parsedLength` is an index to an `short` array..)
>> 
>> I am confused by the stride. The `twelve2Sixteen()` seems to (almost) guarantee that the parsed length is a multiple of 64 (last block can be 48 bytes). This would imply a stride of 128 bytes for `parsed`. And 96 for `condensed`.
>> 
>> This is exactly how the existing code already behaves so I am less concerned, but I would like an explanation why it works?
>
> I believe the numbers are right: with each pass 256 bytes of coefficients are `parsed` into the parse buffer.  This means that half of the coefficients have been processed (`parsedLength` = 128).  Would having a comment stating as such address your concerns?

I wasn't as clear in my question. The asm is indeed processing the bytes in the increment. What I was trying to convince myself about.. 'how come we are not reading past the end of the array. Or are we?'.

On one hand, this is exactly what the existing asm code does, so I will assume that its correct. However, on the java side/version of this code, I could only convince myself about processing ~two AVX512 vectors at a time, not four.

So either I cant count, or there is some further (implicit) restrictions on the callers of `twelve2Sixteen`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2669202305

From duke at openjdk.org  Wed Jan  7 17:50:06 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 7 Jan 2026 17:50:06 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI and AVX512_VBMI2 [v2]
In-Reply-To: <BeagYlohcNYsjTc12pzJZ4kpkoxHT-BZwgvkLINDxpE=.ea4ae404-f9eb-4e86-8758-72c708561233@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>
 <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>
 <S30vwocopm1Pihol_RWwjlYUIV2mfB8pDWUx4Z2SQ3A=.2df41e1a-bc53-46ef-b988-6cd31f726b06@github.com>
 <BeagYlohcNYsjTc12pzJZ4kpkoxHT-BZwgvkLINDxpE=.ea4ae404-f9eb-4e86-8758-72c708561233@github.com>
Message-ID: <_6Hgz5wXGpIYkofBL-qbExAyU3wAvzbyjiUHFUA4IK8=.40cf0b66-f7ff-458c-86ca-7e997e7c3abf@github.com>

On Wed, 7 Jan 2026 16:43:30 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> I believe the numbers are right: with each pass 256 bytes of coefficients are `parsed` into the parse buffer.  This means that half of the coefficients have been processed (`parsedLength` = 128).  Would having a comment stating as such address your concerns?
>
> I wasn't as clear in my question. The asm is indeed processing the bytes in the increment. What I was trying to convince myself about.. 'how come we are not reading past the end of the array. Or are we?'.
> 
> On one hand, this is exactly what the existing asm code does, so I will assume that its correct. However, on the java side/version of this code, I could only convince myself about processing ~two AVX512 vectors at a time, not four.
> 
> So either I cant count, or there is some further (implicit) restrictions on the callers of `twelve2Sixteen`

In ML_KEM.java there is this  assert (and this is the only call to  implKyber12To16() 

        assert ((remainder == 0) || (remainder == 48)) &&
                (index + i * 96 <= condensed.length);
        implKyber12To16(condensed, index, parsed, parsedLength);

and one can check how the callers of twelve2Sixteen() make sure that this is the case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2669490940

From vpaprotski at openjdk.org  Wed Jan  7 18:04:14 2026
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 7 Jan 2026 18:04:14 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI and AVX512_VBMI2 [v2]
In-Reply-To: <_6Hgz5wXGpIYkofBL-qbExAyU3wAvzbyjiUHFUA4IK8=.40cf0b66-f7ff-458c-86ca-7e997e7c3abf@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>
 <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>
 <S30vwocopm1Pihol_RWwjlYUIV2mfB8pDWUx4Z2SQ3A=.2df41e1a-bc53-46ef-b988-6cd31f726b06@github.com>
 <BeagYlohcNYsjTc12pzJZ4kpkoxHT-BZwgvkLINDxpE=.ea4ae404-f9eb-4e86-8758-72c708561233@github.com>
 <_6Hgz5wXGpIYkofBL-qbExAyU3wAvzbyjiUHFUA4IK8=.40cf0b66-f7ff-458c-86ca-7e997e7c3abf@github.com>
Message-ID: <r3ExzWC1QRMvwhyY4nCJjojTxFHnzIyAxJjfJjjNSjQ=.09d4866c-c7d5-4bac-91d0-b09d99b0cb4e@github.com>

On Wed, 7 Jan 2026 17:47:59 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> I wasn't as clear in my question. The asm is indeed processing the bytes in the increment. What I was trying to convince myself about.. 'how come we are not reading past the end of the array. Or are we?'.
>> 
>> On one hand, this is exactly what the existing asm code does, so I will assume that its correct. However, on the java side/version of this code, I could only convince myself about processing ~two AVX512 vectors at a time, not four.
>> 
>> So either I cant count, or there is some further (implicit) restrictions on the callers of `twelve2Sixteen`
>
> In ML_KEM.java there is this  assert (and this is the only call to  implKyber12To16() 
> 
>         assert ((remainder == 0) || (remainder == 48)) &&
>                 (index + i * 96 <= condensed.length);
>         implKyber12To16(condensed, index, parsed, parsedLength);
> 
> and one can check how the callers of twelve2Sixteen() make sure that this is the case.

Yep, thats exactly the assert I was looking at as well.. looks to me like its dividing the 'expanded-short-array-length' by 64 and ensuring the remainder is zero (ignoring the 48 for a bit.. and the condensed-length check).

(for simplicity) So the 'expanded' array length should be a multiple of 64; i.e. 128-bytes. But we stride the expanded array by 256 bytes? (and parsedLength by 128-shorts..)

I haven't checked the callers of `twelve2Sixteen` but I suspect that the length of the expanded array is always a multiple of 256-bytes (128-shorts).. in which case, the assert is 'incomplete'?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2669535184

From duke at openjdk.org  Wed Jan  7 19:03:03 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 7 Jan 2026 19:03:03 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI and AVX512_VBMI2 [v2]
In-Reply-To: <r3ExzWC1QRMvwhyY4nCJjojTxFHnzIyAxJjfJjjNSjQ=.09d4866c-c7d5-4bac-91d0-b09d99b0cb4e@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>
 <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>
 <S30vwocopm1Pihol_RWwjlYUIV2mfB8pDWUx4Z2SQ3A=.2df41e1a-bc53-46ef-b988-6cd31f726b06@github.com>
 <BeagYlohcNYsjTc12pzJZ4kpkoxHT-BZwgvkLINDxpE=.ea4ae404-f9eb-4e86-8758-72c708561233@github.com>
 <_6Hgz5wXGpIYkofBL-qbExAyU3wAvzbyjiUHFUA4IK8=.40cf0b66-f7ff-458c-86ca-7e997e7c3abf@github.com>
 <r3ExzWC1QRMvwhyY4nCJjojTxFHnzIyAxJjfJjjNSjQ=.09d4866c-c7d5-4bac-91d0-b09d99b0cb4e@github.com>
Message-ID: <kJcfX-TWSTkdSxunqBGkatz-HsVFnrS-FndSYvxlZOI=.97b330b9-0724-4fa0-97d8-5191efad5f62@github.com>

On Wed, 7 Jan 2026 17:59:52 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> In ML_KEM.java there is this  assert (and this is the only call to  implKyber12To16() 
>> 
>>         assert ((remainder == 0) || (remainder == 48)) &&
>>                 (index + i * 96 <= condensed.length);
>>         implKyber12To16(condensed, index, parsed, parsedLength);
>> 
>> and one can check how the callers of twelve2Sixteen() make sure that this is the case.
>
> Yep, thats exactly the assert I was looking at as well.. looks to me like its dividing the 'expanded-short-array-length' by 64 and ensuring the remainder is zero (ignoring the 48 for a bit.. and the condensed-length check).
> 
> (for simplicity) So the 'expanded' array length should be a multiple of 64; i.e. 128-bytes. But we stride the expanded array by 256 bytes? (and parsedLength by 128-shorts..)
> 
> I haven't checked the callers of `twelve2Sixteen` but I suspect that the length of the expanded array is always a multiple of 256-bytes (128-shorts).. in which case, the assert is 'incomplete'?

Oooops, yes, the assert and the comment on twelve2sixteen() should be fixed. All of the calls are processing 192 or 384 bytes (and producing 128 or 256 shorts). The comment and assert belonged to an earlier version and were not updated when I changed my mind about the implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2669726088

From duke at openjdk.org  Wed Jan  7 21:05:55 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 7 Jan 2026 21:05:55 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950 [v2]
In-Reply-To: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
Message-ID: <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>

> The method ckAssertReturnValueOK will invoke ckAssertReturnValueOK2 which makes multiple calls to JNI functions, such as FindClass or GetMethodID. These calls would be unsafe as there may be a pending exception at this time.
> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8367024: Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29054/files
  - new: https://git.openjdk.org/jdk/pull/29054/files/5540f9d4..c0eba306

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

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

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

From ascarpino at openjdk.org  Wed Jan  7 21:18:30 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 7 Jan 2026 21:18:30 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
Message-ID: <1gqGEKeFqHqnWt4UPzS5iXdMQ0oP4BYw6LtvGIaVbkg=.1a20173c-9d85-4539-a3c6-59832656a738@github.com>

On Mon, 5 Jan 2026 17:20:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   must have username; more comments

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88:

> 86:             = (ValueLayout) LINKER.canonicalLayouts().get("size_t");
> 87: 
> 88:     private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout();

Should the variables below be capitalized because they are `static final`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2666736772

From weijun at openjdk.org  Wed Jan  7 21:18:33 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Jan 2026 21:18:33 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <KVqg7r8bFUy2bHWuEDqVbuXhun4J5nSFRVvNjz0-Nlg=.f81cf4c3-c318-4bac-a8e6-72ae90269fd0@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
 <KVqg7r8bFUy2bHWuEDqVbuXhun4J5nSFRVvNjz0-Nlg=.f81cf4c3-c318-4bac-a8e6-72ae90269fd0@github.com>
Message-ID: <LfbtFPz67AFDPj90yWAOhJD_FBW6KYnlKGMvBDFZUSQ=.ddc5a010-9534-4be8-964b-e337d2a609bf@github.com>

On Wed, 7 Jan 2026 08:35:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   must have username; more comments
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88:
> 
>> 86:             = (ValueLayout) LINKER.canonicalLayouts().get("size_t");
>> 87: 
>> 88:     private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout();
> 
> Would it be a good idea to use capitalized names for immutable static fields in all places in the class? E.g., `CAPTURED_STATE_LAYOUT` here.

Sure, I can use `CAPTURED_STATE_LAYOUT` and `ERRNO_HANDLE`. Do you also want me to capitalize those `MethodHandle`s, `pw_xyz_layout`, and `pw_xyz_offset`? I'll be happy to do so if we want to keep this tradition. I was looking into `HBShaper` and it's mixed there. The `jextract` output puts every constant behind a method and avoids this awkwardness.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2670096071

From weijun at openjdk.org  Wed Jan  7 21:50:50 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Jan 2026 21:50:50 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <1gqGEKeFqHqnWt4UPzS5iXdMQ0oP4BYw6LtvGIaVbkg=.1a20173c-9d85-4539-a3c6-59832656a738@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
 <1gqGEKeFqHqnWt4UPzS5iXdMQ0oP4BYw6LtvGIaVbkg=.1a20173c-9d85-4539-a3c6-59832656a738@github.com>
Message-ID: <U6E7zbKhRYpSWOOyne6DBnZdpWanVKaBhL92x37En90=.91db86db-b6b7-40b4-b4bb-f711c96c3ee5@github.com>

On Wed, 7 Jan 2026 01:01:52 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   must have username; more comments
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88:
> 
>> 86:             = (ValueLayout) LINKER.canonicalLayouts().get("size_t");
>> 87: 
>> 88:     private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout();
> 
> Should the variables below be capitalized because they are `static final`?

Per asked the same above. I'm not exactly sure if all of them should be capitalized. I'll willing to choose either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2670175161

From duke at openjdk.org  Wed Jan  7 22:31:24 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 7 Jan 2026 22:31:24 GMT
Subject: RFR: 8366807: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_initializeLibrary of p11_general.c:106
 [v2]
In-Reply-To: <ox_PeEYD6B42hVBiEQCoxhzdxVLRJMR2BxExHLoKCRw=.63b307b8-8209-445a-abf1-cfe71fdf1abf@github.com>
References: <ox_PeEYD6B42hVBiEQCoxhzdxVLRJMR2BxExHLoKCRw=.63b307b8-8209-445a-abf1-cfe71fdf1abf@github.com>
Message-ID: <yz_HaMGWRF9ofQJWIivAryh0oKDpHXOgdars5Opdlfs=.3f69622d-7cf7-4caa-9aef-255b90f0748b@github.com>

> The method createLockObject will return NULL if any exception is thrown, but there is no NULL verification in p11_general.c after the following line is invoked
> notifyListLock = createLockObject(env);
> 
> There may be a pending exception when invoking prefetchFields(env, thisClass);
> 
> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8366807: Updated Copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28799/files
  - new: https://git.openjdk.org/jdk/pull/28799/files/67be25b6..e44edfa5

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

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

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

From hchao at openjdk.org  Thu Jan  8 00:03:40 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 8 Jan 2026 00:03:40 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950 [v2]
In-Reply-To: <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
 <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>
Message-ID: <b5bWdK34fkdtUwFumZzgXsK38ziERxd-8P62AwrgOxE=.94841071-26ba-41b2-b48f-3a592a866b2d@github.com>

On Wed, 7 Jan 2026 21:05:55 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The method ckAssertReturnValueOK will invoke ckAssertReturnValueOK2 which makes multiple calls to JNI functions, such as FindClass or GetMethodID. These calls would be unsafe as there may be a pending exception at this time.
>> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367024: Addressing review comments

Marked as reviewed by hchao (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29054#pullrequestreview-3637228899

From duke at openjdk.org  Thu Jan  8 00:24:11 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 8 Jan 2026 00:24:11 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v3]
In-Reply-To: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
Message-ID: <MRf0QutB82BTJQWLdx_2QdbhXQSC1Rkasv2AnlnhfR0=.7a905805-9679-460c-add4-c5ef61f6838f@github.com>

> This change allows use of the AVX512_VBMI/VMBI2 instruction set to further optimize decompression/parsing of polynomial coefficients for ML-KEM.  The speedup gained in the ML-KEM benchmarks for key generation is between 0.3 to 0.6%, encapsulation is  0.4 to 1.7%, and decapsulation is 0.1 to 0.9%.
> 
> Thank you to @sviswa7 and @ferakocz for their help in working through the early stages of this code with me.

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI
  Change Swap to Dup named function/variable
  Check for only VBMI support (not VBMI2)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28815/files
  - new: https://git.openjdk.org/jdk/pull/28815/files/7cd8de53..4af75963

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

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

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

From duke at openjdk.org  Thu Jan  8 05:17:19 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 8 Jan 2026 05:17:19 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v2]
In-Reply-To: <kJcfX-TWSTkdSxunqBGkatz-HsVFnrS-FndSYvxlZOI=.97b330b9-0724-4fa0-97d8-5191efad5f62@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>
 <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>
 <S30vwocopm1Pihol_RWwjlYUIV2mfB8pDWUx4Z2SQ3A=.2df41e1a-bc53-46ef-b988-6cd31f726b06@github.com>
 <BeagYlohcNYsjTc12pzJZ4kpkoxHT-BZwgvkLINDxpE=.ea4ae404-f9eb-4e86-8758-72c708561233@github.com>
 <_6Hgz5wXGpIYkofBL-qbExAyU3wAvzbyjiUHFUA4IK8=.40cf0b66-f7ff-458c-86ca-7e997e7c3abf@github.com>
 <r3ExzWC1QRMvwhyY4nCJjojTxFHnzIyAxJjfJjjNSjQ=.09d4866c-c7d5-4bac-91d0-b09d99b0cb4e@github.com>
 <kJcfX-TWSTkdSxunqBGkatz-HsVFnrS-FndSYvxlZOI=.97b330b9-0724-4fa0-97d8-5191efad5f62@github.com>
Message-ID: <PURTMiQTIhfOZsFBqTB7C3rqMBArokFB3dk7JIkLEO8=.f3c27acf-3222-4fed-99f5-58a1f64f0dbf@github.com>

On Wed, 7 Jan 2026 18:59:16 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Yep, thats exactly the assert I was looking at as well.. looks to me like its dividing the 'expanded-short-array-length' by 64 and ensuring the remainder is zero (ignoring the 48 for a bit.. and the condensed-length check).
>> 
>> (for simplicity) So the 'expanded' array length should be a multiple of 64; i.e. 128-bytes. But we stride the expanded array by 256 bytes? (and parsedLength by 128-shorts..)
>> 
>> I haven't checked the callers of `twelve2Sixteen` but I suspect that the length of the expanded array is always a multiple of 256-bytes (128-shorts).. in which case, the assert is 'incomplete'?
>
> Oooops, yes, the assert and the comment on twelve2sixteen() should be fixed. All of the calls are processing 192 or 384 bytes (and producing 128 or 256 shorts). The comment and assert belonged to an earlier version and were not updated when I changed my mind about the implementation.

I've filed bug:

[JDK-8374755](https://bugs.openjdk.org/browse/JDK-8374755) ML-KEM's 12-bit decompression uses incorrect assertions

to track this issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2670893072

From djelinski at openjdk.org  Thu Jan  8 07:02:58 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 8 Jan 2026 07:02:58 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950 [v2]
In-Reply-To: <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
 <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>
Message-ID: <8Y4AwjNqSUR-yK1rui2P8P3coVrox2sIDI75wiadyAQ=.e9dc948f-e5a5-4550-93c3-9bde8e8eef1c@github.com>

On Wed, 7 Jan 2026 21:05:55 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The method ckAssertReturnValueOK will invoke ckAssertReturnValueOK2 which makes multiple calls to JNI functions, such as FindClass or GetMethodID. These calls would be unsafe as there may be a pending exception at this time.
>> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367024: Addressing review comments

src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_keymgmt.c line 967:

> 965:     /* Do not continue if any copy-back operation raised an exception */
> 966:     if ((*env)->ExceptionCheck(env)) {
> 967:         goto cleanup;

This shouldn't be necessary now; note that `cleanup` will be executed next whether the `if` branch is taken or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29054#discussion_r2671118904

From vyazici at openjdk.org  Thu Jan  8 09:51:51 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 8 Jan 2026 09:51:51 GMT
Subject: [jdk26] RFR: 8374700: [BACKOUT] Move input validation checks to Java
 for java.lang.StringCoding intrinsics
Message-ID: <VSWSSBWMmja8G_pvHgqm9OIR0-7_6Z1JfNp-cOS5ElU=.bcfa97e6-1c30-4e69-97d2-f8a151ed6d1d@github.com>

Backport of [JDK-8374210] integrated in 7e18de13 by #29055.

[JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

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

Commit messages:
 - Backport 7e18de137c3b5f08a479af2b64eb22923261900b

Changes: https://git.openjdk.org/jdk/pull/29112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374700
  Stats: 437 lines in 23 files changed: 25 ins; 331 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/29112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29112/head:pull/29112

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

From myankelevich at openjdk.org  Thu Jan  8 11:49:25 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 8 Jan 2026 11:49:25 GMT
Subject: RFR: 8367326: Refactor PEM API tests requiring PEMRecord usage
 [v2]
In-Reply-To: <2Ow4JVXCRsN-a3SauMcH2lR-HTP-S8e_oNN4T3fxMg8=.7f14fabc-1fa8-4053-a588-c91701734856@github.com>
References: <2Ow4JVXCRsN-a3SauMcH2lR-HTP-S8e_oNN4T3fxMg8=.7f14fabc-1fa8-4053-a588-c91701734856@github.com>
Message-ID: <XGsOridSG2zTBykxqv3YBk9gc2qcPZrhIqcgGfplhYI=.58005540-7243-4c90-8c91-2e4222754a86@github.com>

> Changed to use PEM API: 
> * test/jdk/sun/security/validator/PKIXValAndRevCheckTests.java
> * test/jdk/sun/security/rsa/pss/PSSKeyCompatibility.java
> * test/jdk/sun/security/pkcs11/rsa/TestKeyFactory.java

Mikhail Yankelevich 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:

 - minor import change
 - rolled back TestKeyFactory and simplified PSSKeyCompatability
 - Merge branch 'master' into JDK-8367326
 - JDK-836732: Refactor PEM API tests requiring PEMRecord usage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28356/files
  - new: https://git.openjdk.org/jdk/pull/28356/files/08e0fdb2..254aa755

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

  Stats: 163080 lines in 4551 files changed: 97394 ins; 36491 del; 29195 mod
  Patch: https://git.openjdk.org/jdk/pull/28356.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28356/head:pull/28356

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

From mullan at openjdk.org  Thu Jan  8 14:45:36 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 8 Jan 2026 14:45:36 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v18]
In-Reply-To: <5tKSNHbo1OZtjXQUoqF4h56hZ1ckVdxDn6v6RsKz0IM=.bb61b7f4-618a-4fdb-afd0-e8e30017904f@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <5tKSNHbo1OZtjXQUoqF4h56hZ1ckVdxDn6v6RsKz0IM=.bb61b7f4-618a-4fdb-afd0-e8e30017904f@github.com>
Message-ID: <krG-eUtTNLlpjzeOlQbac9SB04WlNmjtrB5pW7KVUMM=.4d29681b-da6f-4953-b308-9101d236e8b9@github.com>

On Tue, 6 Jan 2026 17:23:16 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this is a proposal to fix [JDK-8352728](https://bugs.openjdk.org/browse/JDK-8352728 "InternalError loading java.security due to Windows parent folder permissions").
>> 
>> Path resolution with `Path::toRealPath` fails under the following conditions:
>> 
>> * When there is a restricted [_ACL_](https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-lists) in a parent directory (_Windows_)
>> * When dealing with an anonymous file only accesible through the _procfs_, such as `/proc/<pid>/fd/<fd>` (_Linux_)
>>     * Such a file can be created by a pipe, deleting an opened file, or with the [`memfd_create` _Linux_ API](https://man7.org/linux/man-pages/man2/memfd_create.2.html)
>> 
>> Original code from [JDK-8319332: Security properties files inclusion](https://bugs.openjdk.org/browse/JDK-8319332) unconditionally resolves with `Path::toRealPath` all the processed properties files. This PR avoids resolving any paths. Cyclic includes detection is now performed with the unresolved paths and `Files::isSameFile`, so `activePaths` no longer needs to be a `Set`.
>> 
>> <details>
>> <summary>Previous approach and rationale for resolving <strong>file</strong> symlinks (kept here for historical reasons).</summary><br>
>> 
>> In _Linux_, a relative `include` from an anonymous file referenced as `/proc/<pid>/fd/<fd>` makes little sense.
>> 
>> However, in _Windows_, a relative `include` from a file where any of the parent directories has a restricted _ACL_ will be expected to work. It's important to note that such a restricted directory permissions scenario occurs to every [_UWP_](https://learn.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide) app (see [JDK-8369741](https://bugs.openjdk.org/browse/JDK-8369741 "cannot use java.security inside of UWP apps")).
>> 
>> When computing a relative `include`, we were performing symlinks resolution of the parent file under the rationale that the person writing the original properties file is the one who decides where the relative includes should resolve. This reasoning has been nuanced and re-evaluated in a [subsequent discussion](#discussion_r2585623241).
>> 
>> The original idea was to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path ca...
>
> Francisco Ferrari Bihurriet 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 31 additional commits since the last revision:
> 
>  - Merge openjdk:master into franferrax:JDK-8352728
>  - Update copyright for the New Year
>  - Merge openjdk:master into franferrax:JDK-8352728
>  - Remove superseded SecurityPropFile
>  - Move tests into SecurityPropFile and rename them
>  - Merge openjdk:master into franferrax:JDK-8352728
>  - 3/3) Adjust ConfigFileTest for unresolved paths
>  - 2/3) Refactor ConfigFileTest ExtraMode enum
>    
>    Move ExtraMode as an ExtraPropsFile field, so we have this information
>    as soon as the ExtraPropsFile is created. This will be useful for the
>    next change.
>  - 1/3) Revert ConfigFileTest adjustment
>    
>    This reverts commit 7c80874c25bc99783ad24fb22d2c080d33c5503a only for
>    ConfigFileTest.
>  - Do not resolve symlinks for relative includes
>    
>    As @wangweij pointed out:
>    > The person writing the original properties file may have expected
>    > includes to resolve relative to its own location, but whoever created
>    > the symlink may have intended a different resolution path. If they
>    > wanted the original location, they could have just used the real file
>    > directly instead of introducing a symlink.
>    
>    Since path resolution is causing trouble under certain conditions, let's
>    avoid doing it. Other programs with include directives support in their
>    configuration files are doing the same.
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/0c2e850c...d94feb26

Marked as reviewed by mullan (Reviewer).

I have reviewed much of it, so I will also add my name as Reviewer.

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

PR Review: https://git.openjdk.org/jdk/pull/24465#pullrequestreview-3639738923
PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3724184162

From vpaprotski at openjdk.org  Thu Jan  8 16:28:10 2026
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 8 Jan 2026 16:28:10 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v3]
In-Reply-To: <MRf0QutB82BTJQWLdx_2QdbhXQSC1Rkasv2AnlnhfR0=.7a905805-9679-460c-add4-c5ef61f6838f@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <MRf0QutB82BTJQWLdx_2QdbhXQSC1Rkasv2AnlnhfR0=.7a905805-9679-460c-add4-c5ef61f6838f@github.com>
Message-ID: <v6uDFSS5pFrw63k40U53WibrkY2S65FK0eQbGlOKzw0=.9bea9d7c-079b-4500-963b-41126b9b3dec@github.com>

On Thu, 8 Jan 2026 00:24:11 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> This change allows use of the AVX512_VBMI instruction set to further optimize decompression/parsing of polynomial coefficients for ML-KEM.  The speedup gained in the ML-KEM benchmarks for key generation is between 0.3 to 0.6%, encapsulation is  0.4 to 1.7%, and decapsulation is 0.3 to 1.9%.
>> 
>> Thank you to @sviswa7 and @ferakocz for their help in working through the early stages of this code with me.
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI
>   Change Swap to Dup named function/variable
>   Check for only VBMI support (not VBMI2)

Looks good to me

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

Marked as reviewed by vpaprotski (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28815#pullrequestreview-3640216667

From fferrari at openjdk.org  Thu Jan  8 16:49:24 2026
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 8 Jan 2026 16:49:24 GMT
Subject: Integrated: 8352728: InternalError loading java.security due to
 Windows parent folder permissions
In-Reply-To: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
Message-ID: <wRszU2T4jQsYdGBWdbYLRsClYiwa40DWrRMjWRinaCw=.be2ab068-7788-4a2a-a75b-2c0d4acf94a2@github.com>

On Sat, 5 Apr 2025 02:36:43 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

> Hi, this is a proposal to fix [JDK-8352728](https://bugs.openjdk.org/browse/JDK-8352728 "InternalError loading java.security due to Windows parent folder permissions").
> 
> Path resolution with `Path::toRealPath` fails under the following conditions:
> 
> * When there is a restricted [_ACL_](https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-lists) in a parent directory (_Windows_)
> * When dealing with an anonymous file only accesible through the _procfs_, such as `/proc/<pid>/fd/<fd>` (_Linux_)
>     * Such a file can be created by a pipe, deleting an opened file, or with the [`memfd_create` _Linux_ API](https://man7.org/linux/man-pages/man2/memfd_create.2.html)
> 
> Original code from [JDK-8319332: Security properties files inclusion](https://bugs.openjdk.org/browse/JDK-8319332) unconditionally resolves with `Path::toRealPath` all the processed properties files. This PR avoids resolving any paths. Cyclic includes detection is now performed with the unresolved paths and `Files::isSameFile`, so `activePaths` no longer needs to be a `Set`.
> 
> <details>
> <summary>Previous approach and rationale for resolving <strong>file</strong> symlinks (kept here for historical reasons).</summary><br>
> 
> In _Linux_, a relative `include` from an anonymous file referenced as `/proc/<pid>/fd/<fd>` makes little sense.
> 
> However, in _Windows_, a relative `include` from a file where any of the parent directories has a restricted _ACL_ will be expected to work. It's important to note that such a restricted directory permissions scenario occurs to every [_UWP_](https://learn.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide) app (see [JDK-8369741](https://bugs.openjdk.org/browse/JDK-8369741 "cannot use java.security inside of UWP apps")).
> 
> When computing a relative `include`, we were performing symlinks resolution of the parent file under the rationale that the person writing the original properties file is the one who decides where the relative includes should resolve. This reasoning has been nuanced and re-evaluated in a [subsequent discussion](#discussion_r2585623241).
> 
> The original idea was to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The decision wa...

This pull request has now been integrated.

Changeset: 7e1051bf
Author:    Francisco Ferrari Bihurriet <fferrari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e1051bfcc01aad538376c86354e16e25d2eaf7a
Stats:     2106 lines in 7 files changed: 1123 ins; 978 del; 5 mod

8352728: InternalError loading java.security due to Windows parent folder permissions

Reviewed-by: weijun, mullan

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

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

From fferrari at openjdk.org  Thu Jan  8 17:34:01 2026
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 8 Jan 2026 17:34:01 GMT
Subject: [jdk26] RFR: 8352728: InternalError loading java.security due to
 Windows parent folder permissions
Message-ID: <akgWEvuXGhcFCK3kx8yXt1blcdvBxStgTnXykhh5U7I=.ce7b7bcc-197f-4e16-8086-3240df8b2c84@github.com>

Clean backport of the following PR to fix a bug which breaks _Windows UWP_ Java applications when they load the `java.security.Security` class:

* #24465

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

Commit messages:
 - Backport 7e1051bfcc01aad538376c86354e16e25d2eaf7a

Changes: https://git.openjdk.org/jdk/pull/29121/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29121&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352728
  Stats: 2106 lines in 7 files changed: 1123 ins; 978 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/29121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29121/head:pull/29121

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

From mpowers at openjdk.org  Thu Jan  8 17:38:00 2026
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 8 Jan 2026 17:38:00 GMT
Subject: Integrated: 8369282: Distrust TLS server certificates anchored by
 Chunghwa ePKI Root CA
In-Reply-To: <fTAmOVJi88B74grU7hUK5pPmpdDXdfSRiyqqYTvPscM=.53c29683-d76f-42b2-8299-39032b47c620@github.com>
References: <fTAmOVJi88B74grU7hUK5pPmpdDXdfSRiyqqYTvPscM=.53c29683-d76f-42b2-8299-39032b47c620@github.com>
Message-ID: <SpFt1QYiM4ffV67cJX3vxyP76NP_ZO8joCzwASd1g6o=.d54db7db-5515-4500-8156-12d94c59b68f@github.com>

On Fri, 19 Dec 2025 17:24:18 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> [JDK-8369282](https://bugs.openjdk.org/browse/JDK-8369282)

This pull request has now been integrated.

Changeset: 92abc6df
Author:    Mark Powers <mpowers at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92abc6dfe43a2c1f10dcfcf1e197fc9369f70ee3
Stats:     244 lines in 5 files changed: 242 ins; 0 del; 2 mod

8369282: Distrust TLS server certificates anchored by Chunghwa ePKI Root CA

Reviewed-by: mullan

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

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

From duke at openjdk.org  Thu Jan  8 17:59:35 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 8 Jan 2026 17:59:35 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v4]
In-Reply-To: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
Message-ID: <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>

> This change allows use of the AVX512_VBMI instruction set to further optimize decompression/parsing of polynomial coefficients for ML-KEM.  The speedup gained in the ML-KEM benchmarks for key generation is between 0.3 to 0.6%, encapsulation is  0.4 to 1.7%, and decapsulation is 0.3 to 1.9%.
> 
> Thank you to @sviswa7 and @ferakocz for their help in working through the early stages of this code with me.

Shawn M Emery has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge with mainline
 - 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI
   Change Swap to Dup named function/variable
   Check for only VBMI support (not VBMI2)
 - Update copyright year
 - Merge with mainline
 - Swap parameter operation with source
 - Remove wrong mask from evpsrlvw
 - Reverse ordering for vpermb and vpsrlvw instructions
 - Switch from vpshldvw to vpsrlvw
 - Fix whitespaces
 - 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI and AVX512_VBMI2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28815/files
  - new: https://git.openjdk.org/jdk/pull/28815/files/4af75963..373b1339

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

  Stats: 26668 lines in 2610 files changed: 7287 ins; 4136 del; 15245 mod
  Patch: https://git.openjdk.org/jdk/pull/28815.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28815/head:pull/28815

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

From mullan at openjdk.org  Thu Jan  8 18:29:43 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 8 Jan 2026 18:29:43 GMT
Subject: RFR: 8373231: ECDSAOperations::toAffinePoint is redundant [v2]
In-Reply-To: <uYzrSXhdNpbYDth69LQbgjztvfgiynAgtSOVMaVBA_U=.ab4a91fa-1142-481c-9ed5-174137488bfe@github.com>
References: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>
 <uYzrSXhdNpbYDth69LQbgjztvfgiynAgtSOVMaVBA_U=.ab4a91fa-1142-481c-9ed5-174137488bfe@github.com>
Message-ID: <sbkqOURTe8gcQRD1suD8QwBNX5vTyOXkUWU7wvwfhIY=.cefad38a-ad3a-4ab6-95db-5da127e64d9e@github.com>

On Mon, 5 Jan 2026 02:39:53 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> `ECDSAOperations::toAffinePoint` should be removed, and `AffinePoint::fromECPoint` should be used instead.
>
> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the JBS ID to the test

test/jdk/sun/security/ec/ECDSAPrimitive.java line 39:

> 37: /*
> 38:  * @test
> 39:  * @bug 8189189 8147502 8295010 8373231

You are not testing something new here, so you should not add the bugid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28691#discussion_r2673415054

From kfarrell at openjdk.org  Thu Jan  8 19:42:50 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 8 Jan 2026 19:42:50 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command
Message-ID: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>

The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 

This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

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

Commit messages:
 - static helper method for both jcmd calls
 - missing )
 - working with single arg
 - updates
 - update args
 - two args -not yet tested
 - initial patch

Changes: https://git.openjdk.org/jdk/pull/29124/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364182
  Stats: 304 lines in 18 files changed: 186 ins; 77 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

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

From kfarrell at openjdk.org  Thu Jan  8 19:50:08 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 8 Jan 2026 19:50:08 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v2]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

Kieran Farrell 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 eight additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into sec_props2
 - static helper method for both jcmd calls
 - missing )
 - working with single arg
 - updates
 - update args
 - two args -not yet tested
 - initial patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/cda609fc..232feeaa

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

  Stats: 211900 lines in 2740 files changed: 163444 ins; 31329 del; 17127 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

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

From duke at openjdk.org  Thu Jan  8 20:07:45 2026
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 8 Jan 2026 20:07:45 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v2]
In-Reply-To: <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
Message-ID: <o3an77G-d1JaxsjRhw5YFL0rtgqMEno0Mhd3WUeoQ50=.a78fc05b-b71f-4a16-9561-acc3ba9e5b32@github.com>

On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell 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 eight additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into sec_props2
>  - static helper method for both jcmd calls
>  - missing )
>  - working with single arg
>  - updates
>  - update args
>  - two args -not yet tested
>  - initial patch

src/java.base/share/classes/java/security/Security.java line 802:

> 800:     }
> 801: 
> 802:     static Properties getAllSecurityPropertiesReadOnly() {

is this method used?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2673707473

From kfarrell at openjdk.org  Thu Jan  8 20:35:33 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 8 Jan 2026 20:35:33 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v3]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

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

  rm unused code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/232feeaa..81655c07

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

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

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

From kfarrell at openjdk.org  Thu Jan  8 20:35:37 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 8 Jan 2026 20:35:37 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v2]
In-Reply-To: <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <piIU9wsTeF54r_ADGt7Y5JzMH1c0Ne-bgZuZscBO1Ow=.c8ed4598-8ea4-41ab-8b74-57a3329953d8@github.com>
Message-ID: <HP2MuR3CPGXVm15_SO6oYLX6hg8YEB0qnBGSFQEMApM=.fe2d338c-ce68-4b4f-a351-c87a23cc258a@github.com>

On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell 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 eight additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into sec_props2
>  - static helper method for both jcmd calls
>  - missing )
>  - working with single arg
>  - updates
>  - update args
>  - two args -not yet tested
>  - initial patch

it seems the ability to hide JCMD commands via DCmdFactory, _hidden has been removed in JDK-8373441, I will search for an alternative method.

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3725657806

From mullan at openjdk.org  Thu Jan  8 20:48:33 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 8 Jan 2026 20:48:33 GMT
Subject: RFR: 8366522: CodeSource.getCodeSigners() throws NPE within empty
 certs [v4]
In-Reply-To: <tG5uYjOxQSPoNAP2y0dK4KEeZ1Bi77qLDoKsTyOFHJI=.b58be329-19e7-41e8-8813-9170d64aed27@github.com>
References: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
 <tG5uYjOxQSPoNAP2y0dK4KEeZ1Bi77qLDoKsTyOFHJI=.b58be329-19e7-41e8-8813-9170d64aed27@github.com>
Message-ID: <RAPm5s9zYgR9HLV_1B2Drf_Cy4C8cpQZeYoDiqgRRw4=.80fafdfc-19f0-4675-a2a4-e6827cb4268a@github.com>

On Tue, 30 Dec 2025 04:39:43 GMT, Kirill Shirokov <duke at openjdk.org> wrote:

>> The new tests cover only NPE scenarios.
>
> Kirill Shirokov 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:
> 
>  - Make CodeSource.getCodeSigners() return empty array of CodeSigners when constructed with emtpy array of certificates. Update the jtreg test to test null/empty array combinations of certificates and code signers
>  - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>  - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>  - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>  - 8366522: CodeSource.getCodeSigners() throws NPE within empty certs

test/jdk/java/security/CodeSource/CodeSourceNoInputs.java line 1:

> 1: /*

Can you try to keep the lines to within 80 or so characters? Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27105#discussion_r2673840860

From duke at openjdk.org  Thu Jan  8 20:52:35 2026
From: duke at openjdk.org (Larry Cable)
Date: Thu, 8 Jan 2026 20:52:35 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v3]
In-Reply-To: <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
Message-ID: <vpUid8KNRxuS_f7Ra4ybZ7hHRq0mYyDR2o0q4gLaY74=.19c8e5ad-8fd8-42f0-9fb1-10ae2d5c224d@github.com>

On Thu, 8 Jan 2026 20:35:33 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rm unused code

was there a reason why this was not simply added as an option to the existing Vm.system_properties jcmd?

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3725733678

From kevinw at openjdk.org  Thu Jan  8 21:04:41 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 Jan 2026 21:04:41 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v3]
In-Reply-To: <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
Message-ID: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com>

On Thu, 8 Jan 2026 20:35:33 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rm unused code

src/hotspot/share/services/attachListener.cpp line 308:

> 306: }
> 307: 
> 308: // Implementation of "properties -security" command.

We don't need this: the attach API provides some basic commands, but most of the time we use the "jcmd" attach api command, which runs a DiagnosticCommand.  That's how we attach and run VM.properties etc...

This makes your life easier, we don't need serializeSecurityPropertiesToByteArray(), just updated DCmd and register_DCMDFactory lines.
(you'll need to merge in the later repo changes and resolve the register_DCMDFactory changes)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2673891775

From kfarrell at openjdk.org  Thu Jan  8 21:27:18 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Thu, 8 Jan 2026 21:27:18 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v4]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <BOeQkw3Zf4yrkz_kWLcylC-FrtG4saZLnSSdnxCZbNI=.73818470-7d62-4207-bf04-b149b3db99a3@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - merge
 - rm unused code
 - Merge remote-tracking branch 'origin/master' into sec_props2
 - static helper method for both jcmd calls
 - missing )
 - working with single arg
 - updates
 - update args
 - two args -not yet tested
 - initial patch

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

Changes: https://git.openjdk.org/jdk/pull/29124/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=03
  Stats: 29 lines in 6 files changed: 29 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

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

From duke at openjdk.org  Thu Jan  8 22:11:18 2026
From: duke at openjdk.org (Larry Cable)
Date: Thu, 8 Jan 2026 22:11:18 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v3]
In-Reply-To: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
 <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com>
Message-ID: <XuGzZPQlzToWgViTRRHCfcX8Yab3I0eN0LvK5icr6A8=.47c37362-fd31-441e-aa0c-ad030a96f004@github.com>

On Thu, 8 Jan 2026 21:02:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rm unused code
>
> src/hotspot/share/services/attachListener.cpp line 308:
> 
>> 306: }
>> 307: 
>> 308: // Implementation of "properties -security" command.
> 
> We don't need this: the attach API provides some basic commands, but most of the time we use the "jcmd" attach api command, which runs a DiagnosticCommand.  That's how we attach and run VM.properties etc...
> 
> This makes your life easier, we don't need serializeSecurityPropertiesToByteArray(), just updated DCmd and register_DCMDFactory lines.
> (you'll need to merge in the later repo changes and resolve the register_DCMDFactory changes)

I agree, this functionality should probably be added to the existing VM.system_properties jcmd as an option (if necessary)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2674071763

From duke at openjdk.org  Fri Jan  9 00:39:00 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Fri, 9 Jan 2026 00:39:00 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950 [v2]
In-Reply-To: <8Y4AwjNqSUR-yK1rui2P8P3coVrox2sIDI75wiadyAQ=.e9dc948f-e5a5-4550-93c3-9bde8e8eef1c@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
 <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>
 <8Y4AwjNqSUR-yK1rui2P8P3coVrox2sIDI75wiadyAQ=.e9dc948f-e5a5-4550-93c3-9bde8e8eef1c@github.com>
Message-ID: <ERJz7n-m5f6rTPyuh5rO-AH9fgRpqTnSzA5NiqBMP5I=.5de5201b-f4ba-47a1-9508-f286380151d7@github.com>

On Thu, 8 Jan 2026 07:00:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8367024: Addressing review comments
>
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_keymgmt.c line 967:
> 
>> 965:     /* Do not continue if any copy-back operation raised an exception */
>> 966:     if ((*env)->ExceptionCheck(env)) {
>> 967:         goto cleanup;
> 
> This shouldn't be necessary now; note that `cleanup` will be executed next whether the `if` branch is taken or not.

I think we might still need that. Cleanup will indeed execute either way, but the purpose of the ExceptionCheck() is not to ensure cleanup, it is to prevent further native logic from executing while a JNI exception is pending.

The copy-back helpers perform JNI operations that may raise exceptions independently of the PKCS#11 return value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29054#discussion_r2674378071

From jjiang at openjdk.org  Fri Jan  9 02:24:16 2026
From: jjiang at openjdk.org (John Jiang)
Date: Fri, 9 Jan 2026 02:24:16 GMT
Subject: RFR: 8373231: ECDSAOperations::toAffinePoint is redundant [v3]
In-Reply-To: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>
References: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>
Message-ID: <56LdX7eSi5gm2o5X0BtFVU7cSe5MRj6UfVm4zU_QNJg=.a03fdf8c-838d-4072-8143-2076affc1328@github.com>

> `ECDSAOperations::toAffinePoint` should be removed, and `AffinePoint::fromECPoint` should be used instead.

John Jiang has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:

  8373231: ECDSAOperations::toAffinePoint is redundant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28691/files
  - new: https://git.openjdk.org/jdk/pull/28691/files/1837abec..a1cebba7

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

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

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

From jjiang at openjdk.org  Fri Jan  9 02:56:18 2026
From: jjiang at openjdk.org (John Jiang)
Date: Fri, 9 Jan 2026 02:56:18 GMT
Subject: RFR: 8373231: ECDSAOperations::toAffinePoint is redundant [v2]
In-Reply-To: <sbkqOURTe8gcQRD1suD8QwBNX5vTyOXkUWU7wvwfhIY=.cefad38a-ad3a-4ab6-95db-5da127e64d9e@github.com>
References: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>
 <uYzrSXhdNpbYDth69LQbgjztvfgiynAgtSOVMaVBA_U=.ab4a91fa-1142-481c-9ed5-174137488bfe@github.com>
 <sbkqOURTe8gcQRD1suD8QwBNX5vTyOXkUWU7wvwfhIY=.cefad38a-ad3a-4ab6-95db-5da127e64d9e@github.com>
Message-ID: <gBsvu2zAJNsg-g0J0_kfbgbQELbZD4dDo0_S7PTphCU=.86ea8ab6-77ec-4eaa-b657-cad33faea43f@github.com>

On Thu, 8 Jan 2026 18:25:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> John Jiang has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> test/jdk/sun/security/ec/ECDSAPrimitive.java line 39:
> 
>> 37: /*
>> 38:  * @test
>> 39:  * @bug 8189189 8147502 8295010 8373231
> 
> You are not testing something new here, so you should not add the bugid.

Just withdrew the last commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28691#discussion_r2674619358

From djelinski at openjdk.org  Fri Jan  9 06:46:04 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 9 Jan 2026 06:46:04 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950 [v2]
In-Reply-To: <ERJz7n-m5f6rTPyuh5rO-AH9fgRpqTnSzA5NiqBMP5I=.5de5201b-f4ba-47a1-9508-f286380151d7@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
 <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>
 <8Y4AwjNqSUR-yK1rui2P8P3coVrox2sIDI75wiadyAQ=.e9dc948f-e5a5-4550-93c3-9bde8e8eef1c@github.com>
 <ERJz7n-m5f6rTPyuh5rO-AH9fgRpqTnSzA5NiqBMP5I=.5de5201b-f4ba-47a1-9508-f286380151d7@github.com>
Message-ID: <QIqFF4dLnQlOvcBx_-TooeFQCus-3CtPjHjDmgrihQ0=.4f080326-2d0c-4273-aae8-5596619cc1a9@github.com>

On Fri, 9 Jan 2026 00:35:46 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_keymgmt.c line 967:
>> 
>>> 965:     /* Do not continue if any copy-back operation raised an exception */
>>> 966:     if ((*env)->ExceptionCheck(env)) {
>>> 967:         goto cleanup;
>> 
>> This shouldn't be necessary now; note that `cleanup` will be executed next whether the `if` branch is taken or not.
>
> I think we might still need that. Cleanup will indeed execute either way, but the purpose of the ExceptionCheck() is not to ensure cleanup, it is to prevent further native logic from executing while a JNI exception is pending.
> 
> The copy-back helpers perform JNI operations that may raise exceptions independently of the PKCS#11 return value.

Well after c0eba3064f61bc8a19122f52aa491f00c6884092 there's no further native logic after this call, so there's nothing to prevent. The copy-back helpers are only invoked after a successful PKCS11 call now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29054#discussion_r2675042900

From alanb at openjdk.org  Fri Jan  9 08:04:24 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jan 2026 08:04:24 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v3]
In-Reply-To: <XuGzZPQlzToWgViTRRHCfcX8Yab3I0eN0LvK5icr6A8=.47c37362-fd31-441e-aa0c-ad030a96f004@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <ZZrvr-QWrDu5tglz1eEZ_XU-HV5aROHbuLw0dCeUTTM=.712f8dd5-d5db-43da-aa7b-c39631da7597@github.com>
 <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com>
 <XuGzZPQlzToWgViTRRHCfcX8Yab3I0eN0LvK5icr6A8=.47c37362-fd31-441e-aa0c-ad030a96f004@github.com>
Message-ID: <BPQSgCDzySWsGDQ8aLbw6-lrt6QUvf0_1ji46PKKtGg=.b09d4fe8-5715-4b25-a834-0426dd4fdc09@github.com>

On Thu, 8 Jan 2026 22:08:21 GMT, Larry Cable <duke at openjdk.org> wrote:

>> src/hotspot/share/services/attachListener.cpp line 308:
>> 
>>> 306: }
>>> 307: 
>>> 308: // Implementation of "properties -security" command.
>> 
>> We don't need this: the attach API provides some basic commands, but most of the time we use the "jcmd" attach api command, which runs a DiagnosticCommand.  That's how we attach and run VM.properties etc...
>> 
>> This makes your life easier, we don't need serializeSecurityPropertiesToByteArray(), just updated DCmd and register_DCMDFactory lines.
>> (you'll need to merge in the later repo changes and resolve the register_DCMDFactory changes)
>
> I agree, this functionality should probably be added to the existing VM.system_properties jcmd as an option (if necessary)

Just some more history there. The reason the attachListener knows about the system properties command is because it dates back to JDK 6 when we introduced the attach mechanism and the Attach API. The Attach API defines VirtualMachine::getSystemProperties so both the tool and VM know about this "command". This all pre-dates jcmd and the diagnostic command framework that has been added since then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2675223455

From sjohanss at openjdk.org  Fri Jan  9 08:47:01 2026
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 9 Jan 2026 08:47:01 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3]
In-Reply-To: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
Message-ID: <CNxPXaG8qXqVrPo5NsiiGa6M6r3hPE9UcLKaDYkr5is=.26f84708-d442-45b0-b787-fda252292bee@github.com>

On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:
> 
>  - Merge branch '8373253' into 8367993
>  - Merge branch 'master' into _8373253
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

Thanks for looking into this Leo. 

Overall I think it looks good, just some small questions and suggestions.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1637:

> 1635: 
> 1636: bool G1CollectedHeap::concurrent_mark_is_terminating() const {
> 1637:   assert(_cm != nullptr, "thread must exist in order to check if mark is terminating");

I think it would make sense to add `&& _cm->is_fully_initialized()` to really make sure the thread has been created.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2427:

> 2425:   if (_cm->is_fully_initialized()) {
> 2426:     tc->do_thread(_cm->cm_thread());
> 2427:   }

Since the _cm_thread is now in `G1ConcurrentMark` this should be handled in `G1ConcurrentMark::threads_do()`

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2549:

> 2547: void G1CollectedHeap::start_concurrent_cycle(bool concurrent_operation_is_full_mark) {
> 2548:   assert(!_cm->in_progress(), "Can not start concurrent operation while in progress");
> 2549:   assert(_cm->is_fully_initialized(), "sanity");

Not sure this sanity assert is needed `_cm->in_progress()` will always return `false` if not fully initialized, so the above assert will cover this. If we still want it, I think it should be moved above the `in_progress()` assert.

src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46:

> 44:     return false;
> 45:   }
> 46: 

Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right?

src/hotspot/share/gc/g1/g1Policy.cpp line 744:

> 742:   if (!_g1h->concurrent_mark()->is_fully_initialized()) {
> 743:     return false;
> 744:   }

Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized.

src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1127:

> 1125: 
> 1126: void G1YoungCollector::collect() {
> 1127:   _g1h->_cm->fully_initialize();

I think it would make more sense to do this in `G1CollectedHeap::do_collection_pause_at_safepoint()`. There we check if we should start concurrent mark, so maybe the initialization could be done only if we are about to start concurrent mark. If we can do the initialization after the actual young collection, then we could maybe even move the initialization into `G1CollectedHeap::start_concurrent_cycle(...)`

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

Changes requested by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3639436840
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2672366755
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675276733
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675291347
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675313622
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675328503
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675249630

From alanb at openjdk.org  Fri Jan  9 08:53:59 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jan 2026 08:53:59 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v4]
In-Reply-To: <BOeQkw3Zf4yrkz_kWLcylC-FrtG4saZLnSSdnxCZbNI=.73818470-7d62-4207-bf04-b149b3db99a3@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <BOeQkw3Zf4yrkz_kWLcylC-FrtG4saZLnSSdnxCZbNI=.73818470-7d62-4207-bf04-b149b3db99a3@github.com>
Message-ID: <2vYchq-CkYIofednbT3mCis7UFBKeajU134sdoyssRo=.015da7ff-63ba-4105-8054-1991c339d742@github.com>

On Thu, 8 Jan 2026 21:27:18 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - merge
>  - rm unused code
>  - Merge remote-tracking branch 'origin/master' into sec_props2
>  - static helper method for both jcmd calls
>  - missing )
>  - working with single arg
>  - updates
>  - update args
>  - two args -not yet tested
>  - initial patch

> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

Security properties are a somewhat niche set of non-system properties for the security/crypto area. They can't be set on the command line, need to use -Djava.security.properties==<url>  to locate a properties file to augment the security properties defined in java.security. So very confusing to developers and maybe it's time to think about whether security properties make sense in 2026.

As regards the proposal then my initial reaction is to keep it separate, meaning a security_properties rather than properties command.

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3727870283

From kfarrell at openjdk.org  Fri Jan  9 09:54:08 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Fri, 9 Jan 2026 09:54:08 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v5]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

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

  hide command

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/6675081d..ee7d4707

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

  Stats: 65 lines in 1 file changed: 25 ins; 10 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

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

From coffeys at openjdk.org  Fri Jan  9 11:24:26 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 9 Jan 2026 11:24:26 GMT
Subject: RFR: 8371333: Optimize static initialization of SSLContextImpl
 classes and improve logging [v4]
In-Reply-To: <TZF1SzuB8Pps8O10qrKtOXRrGWWyiGxSFqfZVjvUj0I=.4de2e8f8-bc38-49c7-96bc-8205118c7fc7@github.com>
References: <TZF1SzuB8Pps8O10qrKtOXRrGWWyiGxSFqfZVjvUj0I=.4de2e8f8-bc38-49c7-96bc-8205118c7fc7@github.com>
Message-ID: <a_Gt-yWgJ2fur8MDhAlAElHjUDS5Z-RMYKna2eL57Mk=.d08c5a20-a3e0-47ff-8ad4-61613f578dca@github.com>

> Introduce lazy static initialization logic to SSLContextImpl via use of the new LazyConstant API and improve logging output
> 
> As per JBS comments:
> 
> * Each subclass of AbstractTLSContext (TLSv10. TLSv11 etc) is being initialization at framework initialization time due to the getApplicableSupportedCipherSuites(..) calls made in static block. Such calls are unnecessary if the subclass isn't required. This is especially true for the default JDK configuration where TLSv10, TLSv11 protocols are disabled. I've moved logic to lazy initialization of these fields via LazyConstant
> 
> * The debug prints output never made clear what protocol version each cipher suite was being disabled for. Improved logging there
> * The debug prints never printed out the resulting set of enabled/allowed cipher suites
> 
> There's efficiency gain also in having one less call to the getApplicableEnabledCipherSuites method in the scenario where customized cipher suites are not in use.
> 
> example of new debug output:
> 
> 
> javax.net.ssl|TRACE|30|main|2025-11-26 14:31:31.997 GMT|SSLContextImpl.java:425|Ignore disabled cipher suites for protocols:[TLSv1.3, TLSv1.2]
> [TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384
> TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA
> TLS_RSA_WITH_AES_128_CBC_SHA]
> javax.net.ssl|TRACE|30|main|2025-11-26 14:31:31.997 GMT|SSLContextImpl.java:425|Available cipher suites for protocols:[TLSv1.3, TLSv1.2]
> [TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> TLS_ECDHE_E...

Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Incorportate comments from Jamil
 - Merge branch 'master' into 8371333-ssl-debug
 - Merge branch 'master' into 8371333-ssl-debug
 - Move wrapText method to Utilities
 - Merge branch 'master' into 8371333-ssl-debug
 - use LINE_SEP
 - 8371333

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28511/files
  - new: https://git.openjdk.org/jdk/pull/28511/files/65777933..fdaa2a70

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

  Stats: 32173 lines in 2758 files changed: 10708 ins; 5534 del; 15931 mod
  Patch: https://git.openjdk.org/jdk/pull/28511.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28511/head:pull/28511

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

From kfarrell at openjdk.org  Fri Jan  9 11:34:44 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Fri, 9 Jan 2026 11:34:44 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v5]
In-Reply-To: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com>
Message-ID: <pFneoc7ufp19IH-oYIFksyL-V2JAzaUFk-I7-J4k_mQ=.7eba636f-5df9-42dc-81c8-61697cd50120@github.com>

On Fri, 9 Jan 2026 09:54:08 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   hide command

> Security properties are a somewhat niche set of non-system properties for the security/crypto area. They can't be set on the command line, need to use -Djava.security.properties== to locate a properties file to augment the security properties defined in java.security. So very confusing to developers and maybe it's time to think about whether security properties make sense in 2026.
> 
Should this PR be put on hold until such a disccusion takes place or maybe that would be something a little further down the line?

> As regards the proposal then my initial reaction is to keep it separate, meaning a security_properties rather than properties command.

My initial patch added a seperate command `VM.security_properties` but I merged the two following a suggestion reduce clutter in the the `jcmd <PID> help` output. Happy to revert to a seperate command if we proceed with this and there is a preference to do so.

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3728531839

From coffeys at openjdk.org  Fri Jan  9 11:53:30 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 9 Jan 2026 11:53:30 GMT
Subject: RFR: 8371333: Optimize static initialization of SSLContextImpl
 classes and improve logging [v4]
In-Reply-To: <a_Gt-yWgJ2fur8MDhAlAElHjUDS5Z-RMYKna2eL57Mk=.d08c5a20-a3e0-47ff-8ad4-61613f578dca@github.com>
References: <TZF1SzuB8Pps8O10qrKtOXRrGWWyiGxSFqfZVjvUj0I=.4de2e8f8-bc38-49c7-96bc-8205118c7fc7@github.com>
 <a_Gt-yWgJ2fur8MDhAlAElHjUDS5Z-RMYKna2eL57Mk=.d08c5a20-a3e0-47ff-8ad4-61613f578dca@github.com>
Message-ID: <OmAei3N4_fJtpFEixu8FlS8YkK6oZoyqFDudkkusuoc=.94a5738f-04a0-49a2-b567-b0f1ecda3f49@github.com>

On Fri, 9 Jan 2026 11:24:26 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Introduce lazy static initialization logic to SSLContextImpl via use of the new LazyConstant API and improve logging output
>> 
>> As per JBS comments:
>> 
>> * Each subclass of AbstractTLSContext (TLSv10. TLSv11 etc) is being initialization at framework initialization time due to the getApplicableSupportedCipherSuites(..) calls made in static block. Such calls are unnecessary if the subclass isn't required. This is especially true for the default JDK configuration where TLSv10, TLSv11 protocols are disabled. I've moved logic to lazy initialization of these fields via LazyConstant
>> 
>> * The debug prints output never made clear what protocol version each cipher suite was being disabled for. Improved logging there
>> * The debug prints never printed out the resulting set of enabled/allowed cipher suites
>> 
>> There's efficiency gain also in having one less call to the getApplicableEnabledCipherSuites method in the scenario where customized cipher suites are not in use.
>> 
>> example of new debug output:
>> 
>> 
>> javax.net.ssl|TRACE|30|main|2025-11-26 14:31:31.997 GMT|SSLContextImpl.java:425|Ignore disabled cipher suites for protocols:[TLSv1.3, TLSv1.2]
>> [TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
>> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384
>> TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA
>> TLS_RSA_WITH_AES_128_CBC_SHA]
>> javax.net.ssl|TRACE|30|main|2025-11-26 14:31:31.997 GMT|SSLContextImpl.java:425|Available cipher suites for protocols:[TLSv1.3, TLSv1.2]
>> [TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SH...
>
> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Incorportate comments from Jamil
>  - Merge branch 'master' into 8371333-ssl-debug
>  - Merge branch 'master' into 8371333-ssl-debug
>  - Move wrapText method to Utilities
>  - Merge branch 'master' into 8371333-ssl-debug
>  - use LINE_SEP
>  - 8371333

Thanks for the comments @jnimeh  - latest commit should address issues you raised

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

PR Comment: https://git.openjdk.org/jdk/pull/28511#issuecomment-3728595148

From stefank at openjdk.org  Fri Jan  9 12:09:22 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jan 2026 12:09:22 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
 <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
Message-ID: <aSHHOBAAdNFMkL3dy7qiMutT8mTtX0R5pLQU6kB4Diw=.38610782-7ad7-44f6-9d44-4cf8164b9562@github.com>

On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into _8367993
>>  - 8366058: Outdated comment in WinCAPISeedGenerator
>>    
>>    Reviewed-by: mullan
>>  - 8357258: x86: Improve receiver type profiling reliability
>>    
>>    Reviewed-by: kvn, vlivanov
>>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>>    
>>    Reviewed-by: lucy, jpai
>>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>>    
>>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>>    
>>    Reviewed-by: alanb, dholmes
>>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>>    
>>    Reviewed-by: kbarrett
>>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>>    
>>    Reviewed-by: djelinski, mpowers, ascarpino
>>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>>    
>>    Reviewed-by: aboldtch
>>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>>    
>>    Reviewed-by: serb, aivanov, dnguyen
>>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767
>
> I will redo the merge, I have done something strange.

@lkorinth Something went wrong with your merge and now there's a bunch of unrelated labels, which results in updates being sent to misc mailing lists that has no interest in this PR. Could you remove all those labels?

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3728642315

From mullan at openjdk.org  Fri Jan  9 14:12:51 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 Jan 2026 14:12:51 GMT
Subject: RFR: 8373231: ECDSAOperations::toAffinePoint is redundant [v3]
In-Reply-To: <56LdX7eSi5gm2o5X0BtFVU7cSe5MRj6UfVm4zU_QNJg=.a03fdf8c-838d-4072-8143-2076affc1328@github.com>
References: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>
 <56LdX7eSi5gm2o5X0BtFVU7cSe5MRj6UfVm4zU_QNJg=.a03fdf8c-838d-4072-8143-2076affc1328@github.com>
Message-ID: <IW5ZtV4aCOTgTRG1AVK0jEwr9sbsQ5LcFT8K8nlQr3s=.fd0b6ce7-f18a-492b-b983-5485b84b7d00@github.com>

On Fri, 9 Jan 2026 02:24:16 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> `ECDSAOperations::toAffinePoint` should be removed, and `AffinePoint::fromECPoint` should be used instead.
>
> John Jiang has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8373231: ECDSAOperations::toAffinePoint is redundant

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28691#pullrequestreview-3644079904

From alanb at openjdk.org  Fri Jan  9 14:33:22 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jan 2026 14:33:22 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v5]
In-Reply-To: <pFneoc7ufp19IH-oYIFksyL-V2JAzaUFk-I7-J4k_mQ=.7eba636f-5df9-42dc-81c8-61697cd50120@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com>
 <pFneoc7ufp19IH-oYIFksyL-V2JAzaUFk-I7-J4k_mQ=.7eba636f-5df9-42dc-81c8-61697cd50120@github.com>
Message-ID: <CuZJc6rlOnkQQcx_MnFCf88oo9v3VqdlH5eiRV6mNKs=.71e51174-39be-4540-b939-9b8ef01eef76@github.com>

On Fri, 9 Jan 2026 11:31:17 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

> My initial patch added a seperate command `VM.security_properties` 

Maybe revert to that as it's a better starting point to discuss.

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3729139127

From duke at openjdk.org  Fri Jan  9 14:50:14 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 9 Jan 2026 14:50:14 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect assertions
Message-ID: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>

The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.

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

Commit messages:
 - 8374755: ML-KEM's 12-bit decompression uses incorrect assertions

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

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

From sshivang at openjdk.org  Fri Jan  9 16:43:08 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Fri, 9 Jan 2026 16:43:08 GMT
Subject: [jdk26] RFR: 8373793: TestDynamicStore.java '/manual' disables use of
 '/timeout'
Message-ID: <3ndTpl-ZpZcGLhCJX0TEOLCtvgaN97kJJqV7XTvbYgo=.1f82f75b-38f8-4cea-b3fd-b81eb03fc450@github.com>

Hi all,

This pull request contains a backport of commit [400d8cfb](https://github.com/openjdk/jdk/commit/400d8cfb6914982e636b23bacf810ef61fc90ee1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Mikhail Yankelevich on 19 Dec 2025 and was reviewed by Weijun Wang.

Thanks!

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

Commit messages:
 - Backport 400d8cfb6914982e636b23bacf810ef61fc90ee1

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

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

From kfarrell at openjdk.org  Fri Jan  9 18:38:53 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Fri, 9 Jan 2026 18:38:53 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v6]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

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

  sperate VM.sec_props command

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/ee7d4707..db9e0e97

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

  Stats: 63 lines in 3 files changed: 0 ins; 26 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

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

From duke at openjdk.org  Fri Jan  9 19:53:31 2026
From: duke at openjdk.org (Kirill Shirokov)
Date: Fri, 9 Jan 2026 19:53:31 GMT
Subject: RFR: 8366522: CodeSource.getCodeSigners() throws NPE within empty
 certs [v6]
In-Reply-To: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
References: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
Message-ID: <unPBj3wtgAQyq48eO94o8Uvkcz8oeQE9XMreQg_Ql_I=.2db15ca6-c2d1-4dea-97c1-b6e30a5077e1@github.com>

> The new tests cover only NPE scenarios.

Kirill Shirokov 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 eight additional commits since the last revision:

 - Fixed java/security/CodeSource/CodeSourceNoInputs code style. Updated copyright year
 - Merge remote-tracking branch 'origin' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
 - Fixed java/security/CodeSource/CodeSourceNoInputs test description
 - Make CodeSource.getCodeSigners() return empty array of CodeSigners when constructed with emtpy array of certificates. Update the jtreg test to test null/empty array combinations of certificates and code signers
 - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
 - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
 - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
 - 8366522: CodeSource.getCodeSigners() throws NPE within empty certs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27105/files
  - new: https://git.openjdk.org/jdk/pull/27105/files/31aef48f..a134a9ae

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

  Stats: 24928 lines in 1606 files changed: 7050 ins; 4179 del; 13699 mod
  Patch: https://git.openjdk.org/jdk/pull/27105.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27105/head:pull/27105

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

From duke at openjdk.org  Fri Jan  9 19:53:35 2026
From: duke at openjdk.org (Kirill Shirokov)
Date: Fri, 9 Jan 2026 19:53:35 GMT
Subject: RFR: 8366522: CodeSource.getCodeSigners() throws NPE within empty
 certs [v4]
In-Reply-To: <RAPm5s9zYgR9HLV_1B2Drf_Cy4C8cpQZeYoDiqgRRw4=.80fafdfc-19f0-4675-a2a4-e6827cb4268a@github.com>
References: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
 <tG5uYjOxQSPoNAP2y0dK4KEeZ1Bi77qLDoKsTyOFHJI=.b58be329-19e7-41e8-8813-9170d64aed27@github.com>
 <RAPm5s9zYgR9HLV_1B2Drf_Cy4C8cpQZeYoDiqgRRw4=.80fafdfc-19f0-4675-a2a4-e6827cb4268a@github.com>
Message-ID: <osy9eOAoPlLHG_BLtuTqo1chocND37K6J0l8e4EUU_w=.3c35adae-1e17-461d-b1c1-493cf0b9bcc5@github.com>

On Thu, 8 Jan 2026 20:44:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kirill Shirokov 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:
>> 
>>  - Make CodeSource.getCodeSigners() return empty array of CodeSigners when constructed with emtpy array of certificates. Update the jtreg test to test null/empty array combinations of certificates and code signers
>>  - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>>  - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>>  - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>>  - 8366522: CodeSource.getCodeSigners() throws NPE within empty certs
>
> test/jdk/java/security/CodeSource/CodeSourceNoInputs.java line 1:
> 
>> 1: /*
> 
> Can you try to keep the lines to within 80 or so characters? Thanks.

Fixed. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27105#discussion_r2677434678

From ascarpino at openjdk.org  Fri Jan  9 20:15:12 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 9 Jan 2026 20:15:12 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
Message-ID: <AGdB79JAbaK2TB-mHV_mXuuRJ7Xr2PD8VgVu-tEhJDg=.35dffdc6-238a-4ffa-9328-dab91dd27a30@github.com>

On Mon, 5 Jan 2026 17:20:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   must have username; more comments

Marked as reviewed by ascarpino (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28931#pullrequestreview-3645433959

From ascarpino at openjdk.org  Fri Jan  9 20:15:15 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 9 Jan 2026 20:15:15 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7]
In-Reply-To: <U6E7zbKhRYpSWOOyne6DBnZdpWanVKaBhL92x37En90=.91db86db-b6b7-40b4-b4bb-f711c96c3ee5@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <xCPETi8ZpKVYhTqaZQXS5bRrMqun_KDlg6Lk_5GIukA=.28ac201b-b7f0-4714-b797-b066429250e7@github.com>
 <1gqGEKeFqHqnWt4UPzS5iXdMQ0oP4BYw6LtvGIaVbkg=.1a20173c-9d85-4539-a3c6-59832656a738@github.com>
 <U6E7zbKhRYpSWOOyne6DBnZdpWanVKaBhL92x37En90=.91db86db-b6b7-40b4-b4bb-f711c96c3ee5@github.com>
Message-ID: <GfmoHmESGlNGFlNBF_XxakhrlPkkO4xOV_q3-jFcBg0=.b95d8e1e-35da-4918-9a6b-a5a73652d818@github.com>

On Wed, 7 Jan 2026 21:47:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88:
>> 
>>> 86:             = (ValueLayout) LINKER.canonicalLayouts().get("size_t");
>>> 87: 
>>> 88:     private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout();
>> 
>> Should the variables below be capitalized because they are `static final`?
>
> Per asked the same above. I'm not exactly sure if all of them should be capitalized. I'm willing to choose either.

I'm thinking the `static final` convention applies for all of them, but if someone says different because they are FFM related, I'm fine with not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2677493814

From duke at openjdk.org  Fri Jan  9 22:33:34 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Fri, 9 Jan 2026 22:33:34 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950 [v2]
In-Reply-To: <QIqFF4dLnQlOvcBx_-TooeFQCus-3CtPjHjDmgrihQ0=.4f080326-2d0c-4273-aae8-5596619cc1a9@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
 <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>
 <8Y4AwjNqSUR-yK1rui2P8P3coVrox2sIDI75wiadyAQ=.e9dc948f-e5a5-4550-93c3-9bde8e8eef1c@github.com>
 <ERJz7n-m5f6rTPyuh5rO-AH9fgRpqTnSzA5NiqBMP5I=.5de5201b-f4ba-47a1-9508-f286380151d7@github.com>
 <QIqFF4dLnQlOvcBx_-TooeFQCus-3CtPjHjDmgrihQ0=.4f080326-2d0c-4273-aae8-5596619cc1a9@github.com>
Message-ID: <9iHRLn0H-X1mEm40Gcb3h_riDpLqokseGZMzHs9W1GM=.14075bb9-2eaa-4dae-bfc3-bfaa256f340f@github.com>

On Fri, 9 Jan 2026 06:43:50 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> I think we might still need that. Cleanup will indeed execute either way, but the purpose of the ExceptionCheck() is not to ensure cleanup, it is to prevent further native logic from executing while a JNI exception is pending.
>> 
>> The copy-back helpers perform JNI operations that may raise exceptions independently of the PKCS#11 return value.
>
> Well after c0eba3064f61bc8a19122f52aa491f00c6884092 there's no further native logic after this call, so there's nothing to prevent. The copy-back helpers are only invoked after a successful PKCS11 call now.

Yes. However, the purpose of the ExceptionCheck is not to bypass code but to clearly establish that copy-back helpers may raise JNI exceptions independently of PKCS11 success, and that from that point onward we must avoid further JNI interaction except controlled cleanup and return.

Keeping the explicit ExceptionCheck also serves as a defensive guard for future maintenance: if additional logic is ever added before the cleanup label.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29054#discussion_r2677793857

From duke at openjdk.org  Fri Jan  9 22:52:10 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 9 Jan 2026 22:52:10 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v2]
In-Reply-To: <7gLxGLuYKPYchraxk4Z4hh_ThfgGsGGdYAL2LVaDBvg=.63281063-7480-431f-b24e-1304ef92326e@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <Eo9p-Eqw8q3egz_62Uf9EN4jeXr-K1lcsGhL1cIeT0Q=.74bc27a7-0ac9-4dad-922b-e0c7686ec3c4@github.com>
 <dCmZiEFjW4-XRoe0t1n8gPkz7GS-jqZ44VdAIIkGPjM=.3711f889-19ad-405f-965b-49d782cce70c@github.com>
 <pkNgMQPwR5rYj5cg9IuhA0mxSpgueeHZ8Prnc2OSa6M=.ce5deeba-83c2-4ab7-9fac-a0319f6102b1@github.com>
 <7gLxGLuYKPYchraxk4Z4hh_ThfgGsGGdYAL2LVaDBvg=.63281063-7480-431f-b24e-1304ef92326e@github.com>
Message-ID: <Tm39UZWYnEC7eaVHJm1N1akR-ZfyeD73cgs12BB8nSs=.60b38515-d459-4be3-b25e-6339e67eef6e@github.com>

On Wed, 7 Jan 2026 16:36:52 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>>> "Insert 0b0000 nibble after every third nibble". I only have two questions, looks good otherwise.
>> 
>> Yes, that is the idea.
>> 
>>> 
>>> PS: things I've considered:
>>> 
>>> * Loop controls?
>>>   
>>>   * ML_KEM.java guarantees  (per callee comment and assert) lengths are multiple of 64
>>>   * also same as original code
>>> * Why not simply a vpermb? Have zeroes already from the masked load with k1..
>> 
>> It *is* using vpermb (evpermb() generates the EVEX encoded VPERMB)
>> 
>>>   
>>>   * shuffle granularity is actually 4-bits, not 8-bits
>> 
>> Really? In what instruction? I hadn't found it in the manual.
>> 
>>> * logical shift already zeroes top bits, so `vpand` not required?
>> 
>> Only every 2nd byte is shifted, the rest needs to be masked.
>>>   
>>>   * odd columns not shifted, so still have extra bits that need clearing
>> 
>> Yes, that is what the vpand does. (actually, it also (unnecessarily) masks the shifted bytes.
>> 
>>> * Why VBMI?
>>>   
>>>   * needed for `evpermb`
>> 
>> Yes.
>
>> > "Insert 0b0000 nibble after every third nibble". I only have two questions, looks good otherwise.
> 
> @ferakocz apologies for the misunderstanding; everything after the PS was not a request for change.. those were the questions that occurred to me and I found the answer.. The only reason I put them in was for the next reviewer. Or if I am wrong, e.g. no, I did not find a better instruction than vpermb either. (My first reaction to seeing the java code, was 'oh, this is easy, just a `vpermb`, then had to reason out why not..)

@vpaprotsk I've reran related regression tests and benchmarks after implementing your code review comments and remerging with the master branch.  These have all came back with the expected results.  Could you reapprove after the merge commit?  Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/28815#issuecomment-3730835813

From vpaprotski at openjdk.org  Fri Jan  9 23:21:24 2026
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Fri, 9 Jan 2026 23:21:24 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v4]
In-Reply-To: <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
Message-ID: <WLfxQiJ8mCscZF9al8V9Z97kbtBMj_wAjzc0zEqhX8A=.c7cbc6d6-bef5-4f26-a5f2-d33e97912215@github.com>

On Thu, 8 Jan 2026 17:59:35 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> This change allows use of the AVX512_VBMI instruction set to further optimize decompression/parsing of polynomial coefficients for ML-KEM.  The speedup gained in the ML-KEM benchmarks for key generation is between 0.3 to 0.6%, encapsulation is  0.4 to 1.7%, and decapsulation is 0.3 to 1.9%.
>> 
>> Thank you to @sviswa7 and @ferakocz for their help in working through the early stages of this code with me.
>
> Shawn M Emery has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge with mainline
>  - 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI
>    Change Swap to Dup named function/variable
>    Check for only VBMI support (not VBMI2)
>  - Update copyright year
>  - Merge with mainline
>  - Swap parameter operation with source
>  - Remove wrong mask from evpsrlvw
>  - Reverse ordering for vpermb and vpsrlvw instructions
>  - Switch from vpshldvw to vpsrlvw
>  - Fix whitespaces
>  - 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI and AVX512_VBMI2

> @vpaprotsk I've reran related regression tests and benchmarks after implementing your code review comments and remerging with the master branch. These have all came back with the expected results. Could you reapprove after the merge commit? Thank you.

Sure! Though my approval wont let you integrate, I am a committer, not a reviewer. Maybe we can ask @ascarpino

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

Marked as reviewed by vpaprotski (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28815#pullrequestreview-3645900397

From jjiang at openjdk.org  Sat Jan 10 00:56:03 2026
From: jjiang at openjdk.org (John Jiang)
Date: Sat, 10 Jan 2026 00:56:03 GMT
Subject: Integrated: 8373231: ECDSAOperations::toAffinePoint is redundant
In-Reply-To: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>
References: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>
Message-ID: <EUG-k9ASEUPZGrjbt1TamiENNH4lQLrWdMby6UknGQ0=.29876360-b76b-41c1-b5c3-24db76005d6a@github.com>

On Mon, 8 Dec 2025 02:55:31 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `ECDSAOperations::toAffinePoint` should be removed, and `AffinePoint::fromECPoint` should be used instead.

This pull request has now been integrated.

Changeset: a726e834
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a726e834b6d3674f0d573d8a0df6eb00464b825b
Stats:     12 lines in 2 files changed: 0 ins; 8 del; 4 mod

8373231: ECDSAOperations::toAffinePoint is redundant

Reviewed-by: mullan

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

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

From jbhateja at openjdk.org  Sat Jan 10 03:26:20 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 10 Jan 2026 03:26:20 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v4]
In-Reply-To: <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
Message-ID: <Qq1hD_zx6FsvunA2HDp8-Oa9YDSOAZDKK-M2ObSyAEY=.21bda4b0-3186-4e85-9e49-bb70e69b3c33@github.com>

On Thu, 8 Jan 2026 17:59:35 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> This change allows use of the AVX512_VBMI instruction set to further optimize decompression/parsing of polynomial coefficients for ML-KEM.  The speedup gained in the ML-KEM benchmarks for key generation is between 0.3 to 0.6%, encapsulation is  0.4 to 1.7%, and decapsulation is 0.3 to 1.9%.
>> 
>> Thank you to @sviswa7 and @ferakocz for their help in working through the early stages of this code with me.
>
> Shawn M Emery has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge with mainline
>  - 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI
>    Change Swap to Dup named function/variable
>    Check for only VBMI support (not VBMI2)
>  - Update copyright year
>  - Merge with mainline
>  - Swap parameter operation with source
>  - Remove wrong mask from evpsrlvw
>  - Reverse ordering for vpermb and vpsrlvw instructions
>  - Switch from vpshldvw to vpsrlvw
>  - Fix whitespaces
>  - 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI and AVX512_VBMI2

src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 876:

> 874:     __ evmovdquq(xmm22, Address(perms), Assembler::AVX_512bit);
> 875: 
> 876:     __ BIND(VBMILoop);

Better to align loop sarting address to OptoLoopAlignment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2678272848

From jbhateja at openjdk.org  Sat Jan 10 03:26:21 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 10 Jan 2026 03:26:21 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v4]
In-Reply-To: <Qq1hD_zx6FsvunA2HDp8-Oa9YDSOAZDKK-M2ObSyAEY=.21bda4b0-3186-4e85-9e49-bb70e69b3c33@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
 <Qq1hD_zx6FsvunA2HDp8-Oa9YDSOAZDKK-M2ObSyAEY=.21bda4b0-3186-4e85-9e49-bb70e69b3c33@github.com>
Message-ID: <htQOcf4BCZXgh3P3FoMBou09Zhcg4deRYuu8DHLDtWc=.b2247e7f-b41b-461f-b3d0-73737f52b535@github.com>

On Sat, 10 Jan 2026 03:18:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Merge with mainline
>>  - 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI
>>    Change Swap to Dup named function/variable
>>    Check for only VBMI support (not VBMI2)
>>  - Update copyright year
>>  - Merge with mainline
>>  - Swap parameter operation with source
>>  - Remove wrong mask from evpsrlvw
>>  - Reverse ordering for vpermb and vpsrlvw instructions
>>  - Switch from vpshldvw to vpsrlvw
>>  - Fix whitespaces
>>  - 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI and AVX512_VBMI2
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 876:
> 
>> 874:     __ evmovdquq(xmm22, Address(perms), Assembler::AVX_512bit);
>> 875: 
>> 876:     __ BIND(VBMILoop);
> 
> Better to align loop sarting address to OptoLoopAlignment

I will run the micro benchmark on AMD Turin and report by back early next week.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2678273572

From duke at openjdk.org  Sat Jan 10 07:15:50 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Sat, 10 Jan 2026 07:15:50 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v4]
In-Reply-To: <htQOcf4BCZXgh3P3FoMBou09Zhcg4deRYuu8DHLDtWc=.b2247e7f-b41b-461f-b3d0-73737f52b535@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
 <Qq1hD_zx6FsvunA2HDp8-Oa9YDSOAZDKK-M2ObSyAEY=.21bda4b0-3186-4e85-9e49-bb70e69b3c33@github.com>
 <htQOcf4BCZXgh3P3FoMBou09Zhcg4deRYuu8DHLDtWc=.b2247e7f-b41b-461f-b3d0-73737f52b535@github.com>
Message-ID: <28KSbLDo353fDhRsW-5aaLpYvQ9XGPnyOqO1YN_LnPs=.eaa3ddbf-9228-4fce-a973-dda88d5abf75@github.com>

On Sat, 10 Jan 2026 03:20:18 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 876:
>> 
>>> 874:     __ evmovdquq(xmm22, Address(perms), Assembler::AVX_512bit);
>>> 875: 
>>> 876:     __ BIND(VBMILoop);
>> 
>> Better to align loop sarting address to OptoLoopAlignment
>
> I will run the micro benchmark on AMD Turin and report back by early next week.

> Better to align loop sarting address to OptoLoopAlignment

For parity, should I do this for the other labels in the file as well?

> I will run the micro benchmark on AMD Turin and report by back early next week.

That would be great, thank you for doing this!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2678401684

From djelinski at openjdk.org  Sat Jan 10 07:16:51 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sat, 10 Jan 2026 07:16:51 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950 [v2]
In-Reply-To: <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
 <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>
Message-ID: <2hmpjPy6QJ_3-DnthLNtzesQkfd_t2ES580JuZyoC9o=.537bd973-9137-4aeb-aacc-86ca4fb8119b@github.com>

On Wed, 7 Jan 2026 21:05:55 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The method ckAssertReturnValueOK will invoke ckAssertReturnValueOK2 which makes multiple calls to JNI functions, such as FindClass or GetMethodID. These calls would be unsafe as there may be a pending exception at this time.
>> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367024: Addressing review comments

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29054#pullrequestreview-3646526416

From duke at openjdk.org  Sun Jan 11 06:59:20 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Sun, 11 Jan 2026 06:59:20 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v5]
In-Reply-To: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
Message-ID: <yD21sqxEcOTPTN56PzOqIEsQBKHOeVJy8-hMGmJRirU=.27ca3b7a-123d-4585-97f1-38844a579eb5@github.com>

> This change allows use of the AVX512_VBMI instruction set to further optimize decompression/parsing of polynomial coefficients for ML-KEM.  The speedup gained in the ML-KEM benchmarks for key generation is between 0.4 to 0.5%, encapsulation is  0.2 to 1.7%, and decapsulation is 0.3 to 2.0%.
> 
> Thank you to @sviswa7 and @ferakocz for their help in working through the early stages of this code with me.

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Update to use OptoLoopAlignment for VBMILoop

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28815/files
  - new: https://git.openjdk.org/jdk/pull/28815/files/373b1339..f278a63f

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

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

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

From jbhateja at openjdk.org  Sun Jan 11 09:55:14 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 11 Jan 2026 09:55:14 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v4]
In-Reply-To: <28KSbLDo353fDhRsW-5aaLpYvQ9XGPnyOqO1YN_LnPs=.eaa3ddbf-9228-4fce-a973-dda88d5abf75@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
 <Qq1hD_zx6FsvunA2HDp8-Oa9YDSOAZDKK-M2ObSyAEY=.21bda4b0-3186-4e85-9e49-bb70e69b3c33@github.com>
 <htQOcf4BCZXgh3P3FoMBou09Zhcg4deRYuu8DHLDtWc=.b2247e7f-b41b-461f-b3d0-73737f52b535@github.com>
 <28KSbLDo353fDhRsW-5aaLpYvQ9XGPnyOqO1YN_LnPs=.eaa3ddbf-9228-4fce-a973-dda88d5abf75@github.com>
Message-ID: <GHlrs3IAFzOaPIWNo8cmK9yXd2cGwEcsM9SzbwvKJrU=.ee4699ee-b835-4c84-b18c-1775376ce43c@github.com>

On Sat, 10 Jan 2026 07:11:48 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> I will run the micro benchmark on AMD Turin and report back by early next week.
>
>> Better to align loop sarting address to OptoLoopAlignment
> 
> For parity, should I do this for the other labels in the file as well?
> 
>> I will run the micro benchmark on AMD Turin and report by back early next week.
> 
> That would be great, thank you for doing this!

Just a note on LoopAlignment, there are multiple moving parts here, first aligning starting addresses of loop to 64 ([recommendation from Zen5 optimization guide](https://docs.amd.com/v/u/en-US/58455_1.00) section 2.8.3) ensure small loop bodies are not split-across the cache line, if that happens then there is a code entry penalty since for first iteration of loop front-end will have to read multiple L1I cachelines, once its decoded and uops are part of Op-cache (AMD) or DSB (Intel) then uops stream for successive loop iterations are emitted from op-cache. Since op-cache is shared b/w 2 HW threads in SMT configuration hence in case of noisy neighbor scenarios or context-switches we may hit code-entry penalty during lifetime of loop. 

So its advisable to add alignment in this case for other labels before loops we already have OptoLoopAlignment in place.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2679380724

From jbhateja at openjdk.org  Sun Jan 11 09:55:15 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 11 Jan 2026 09:55:15 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v4]
In-Reply-To: <GHlrs3IAFzOaPIWNo8cmK9yXd2cGwEcsM9SzbwvKJrU=.ee4699ee-b835-4c84-b18c-1775376ce43c@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
 <Qq1hD_zx6FsvunA2HDp8-Oa9YDSOAZDKK-M2ObSyAEY=.21bda4b0-3186-4e85-9e49-bb70e69b3c33@github.com>
 <htQOcf4BCZXgh3P3FoMBou09Zhcg4deRYuu8DHLDtWc=.b2247e7f-b41b-461f-b3d0-73737f52b535@github.com>
 <28KSbLDo353fDhRsW-5aaLpYvQ9XGPnyOqO1YN_LnPs=.eaa3ddbf-9228-4fce-a973-dda88d5abf75@github.com>
 <GHlrs3IAFzOaPIWNo8cmK9yXd2cGwEcsM9SzbwvKJrU=.ee4699ee-b835-4c84-b18c-1775376ce43c@github.com>
Message-ID: <IDULCOeuqXv0x51xZNCckEuz15kBikJEDAVHO2ruuC8=.52018b85-8abf-46e4-84f6-b148a1ffa7ed@github.com>

On Sun, 11 Jan 2026 09:31:03 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> Better to align loop sarting address to OptoLoopAlignment
>> 
>> For parity, should I do this for the other labels in the file as well?
>> 
>>> I will run the micro benchmark on AMD Turin and report by back early next week.
>> 
>> That would be great, thank you for doing this!
>
> Just a note on LoopAlignment, there are multiple moving parts here, first aligning starting addresses of loop to 64 ([recommendation from Zen5 optimization guide](https://docs.amd.com/v/u/en-US/58455_1.00) section 2.8.3) ensure small loop bodies are not split-across the cache line, if that happens then there is a code entry penalty since for first iteration of loop front-end will have to read multiple L1I cachelines, once its decoded and uops are part of Op-cache (AMD) or DSB (Intel) then uops stream for successive loop iterations are emitted from op-cache. Since op-cache is shared b/w 2 HW threads in SMT configuration hence in case of noisy neighbor scenarios or context-switches we may hit code-entry penalty during lifetime of loop. 
> 
> So its advisable to add alignment in this case for other labels before loops we already have OptoLoopAlignment in place.

> > Better to align loop sarting address to OptoLoopAlignment
> 
> For parity, should I do this for the other labels in the file as well?
> 
> > I will run the micro benchmark on AMD Turin and report back by early next week.
> 
> That would be great, thank you for doing this!

Here are the score on Turin.


Baseline:
Benchmark                                    (algorithm)  (keyLength)  (provider)   Mode  Cnt      Score   Error  Units
KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-512            0              thrpt    2  62235.790          ops/s
KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-768            0              thrpt    2  38238.390          ops/s
KeyPairGeneratorBench.MLKEM.generateKeyPair  ML-KEM-1024            0              thrpt    2  24725.512          ops/s

Withopt:
Benchmark                                    (algorithm)  (keyLength)  (provider)   Mode  Cnt      Score   Error  Units
KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-512            0              thrpt    2  62483.697          ops/s
KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-768            0              thrpt    2  38464.272          ops/s
KeyPairGeneratorBench.MLKEM.generateKeyPair  ML-KEM-1024            0              thrpt    2  24702.044          ops/s



Baseline:
Benchmark             (algorithm)  (provider)   Mode  Cnt      Score   Error  Units
KEMBench.decapsulate   ML-KEM-512              thrpt    2  46416.479          ops/s
KEMBench.decapsulate   ML-KEM-768              thrpt    2  28516.289          ops/s
KEMBench.decapsulate  ML-KEM-1024              thrpt    2  19250.020          ops/s
KEMBench.encapsulate   ML-KEM-512              thrpt    2  60374.724          ops/s
KEMBench.encapsulate   ML-KEM-768              thrpt    2  36226.100          ops/s
KEMBench.encapsulate  ML-KEM-1024              thrpt    2  23656.223          ops/s

Withopt:
Benchmark             (algorithm)  (provider)   Mode  Cnt      Score   Error  Units
KEMBench.decapsulate   ML-KEM-512              thrpt    2  46730.153          ops/s
KEMBench.decapsulate   ML-KEM-768              thrpt    2  28650.349          ops/s
KEMBench.decapsulate  ML-KEM-1024              thrpt    2  19390.927          ops/s
KEMBench.encapsulate   ML-KEM-512              thrpt    2  60238.211          ops/s
KEMBench.encapsulate   ML-KEM-768              thrpt    2  36454.138          ops/s
KEMBench.encapsulate  ML-KEM-1024              thrpt    2  23649.839          ops/s


System was set at fixed frequency of 2.7 Ghz during benchmarking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2679382599

From duke at openjdk.org  Mon Jan 12 07:26:11 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Mon, 12 Jan 2026 07:26:11 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v4]
In-Reply-To: <IDULCOeuqXv0x51xZNCckEuz15kBikJEDAVHO2ruuC8=.52018b85-8abf-46e4-84f6-b148a1ffa7ed@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
 <Qq1hD_zx6FsvunA2HDp8-Oa9YDSOAZDKK-M2ObSyAEY=.21bda4b0-3186-4e85-9e49-bb70e69b3c33@github.com>
 <htQOcf4BCZXgh3P3FoMBou09Zhcg4deRYuu8DHLDtWc=.b2247e7f-b41b-461f-b3d0-73737f52b535@github.com>
 <28KSbLDo353fDhRsW-5aaLpYvQ9XGPnyOqO1YN_LnPs=.eaa3ddbf-9228-4fce-a973-dda88d5abf75@github.com>
 <GHlrs3IAFzOaPIWNo8cmK9yXd2cGwEcsM9SzbwvKJrU=.ee4699ee-b835-4c84-b18c-1775376ce43c@github.com>
 <IDULCOeuqXv0x51xZNCckEuz15kBikJEDAVHO2ruuC8=.52018b85-8abf-46e4-84f6-b148a1ffa7ed@github.com>
Message-ID: <ac8EBuu2VzwQMVxPjT-v5abMlaY4EIOJZ8h95DWAVOM=.e16566c1-6add-4c99-b427-78a3cdfcdbb9@github.com>

On Sun, 11 Jan 2026 09:33:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Just a note on LoopAlignment, there are multiple moving parts here, first aligning starting addresses of loop to 64 ([recommendation from Zen5 optimization guide](https://docs.amd.com/v/u/en-US/58455_1.00) section 2.8.3) ensure small loop bodies are not split-across the cache line, if that happens then there is a cold entry penalty in the first iteration of loop, where front-end will have to read multiple L1I cache lines, once its decoded and uops are part of Op-cache (AMD) or DSB (Intel). There onwards uops stream for successive loop iterations are issued from op-cache. Since op-cache is shared b/w 2 HW threads in SMT configuration hence in case of noisy neighbor scenarios or context-switches we may hit cold-entry penalty during lifetime of loop. 
>> 
>> So its advisable to add alignment in this case for other labels before loops we already have OptoLoopAlignment in place.
>
>> > Better to align loop sarting address to OptoLoopAlignment
>> 
>> For parity, should I do this for the other labels in the file as well?
>> 
>> > I will run the micro benchmark on AMD Turin and report back by early next week.
>> 
>> That would be great, thank you for doing this!
> 
> Here are the score on Turin.
> 
> 
> Baseline:
> Benchmark                                    (algorithm)  (keyLength)  (provider)   Mode  Cnt      Score   Error  Units
> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-512            0              thrpt    2  62235.790          ops/s
> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-768            0              thrpt    2  38238.390          ops/s
> KeyPairGeneratorBench.MLKEM.generateKeyPair  ML-KEM-1024            0              thrpt    2  24725.512          ops/s
> 
> Withopt:
> Benchmark                                    (algorithm)  (keyLength)  (provider)   Mode  Cnt      Score   Error  Units
> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-512            0              thrpt    2  62483.697          ops/s
> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-768            0              thrpt    2  38464.272          ops/s
> KeyPairGeneratorBench.MLKEM.generateKeyPair  ML-KEM-1024            0              thrpt    2  24702.044          ops/s
> 
> 
> 
> Baseline:
> Benchmark             (algorithm)  (provider)   Mode  Cnt      Score   Error  Units
> KEMBench.decapsulate   ML-KEM-512              thrpt    2  46416.479          ops/s
> KEMBench.decapsulate   ML-KEM-768              thrpt    2  28516.289          ops/s
> KEMBench.decapsulate  ML-KEM-1024              thrpt    2  19250.020          ops/s
> KEMBench.encapsulate   ML-KEM-512              thrpt    2  60374.724          ops/s
> KEMBench.encapsulate   ML-KEM-768              thrpt    2  36226.100          ops/s
> KEMBench.encapsulate  ML-KEM-1024              thrpt    2  23656.223          ops/s
> 
> Withopt:
> Benchmark             (algorithm)  (provider)   Mode  Cnt      Score   Error  Units
> KEMBench.decapsulate   ML-KEM-512              thrpt    2  46730.153          ops/s
> KEMBench.decapsulate   ML-KEM-768              thrpt    2  28650.349          ops/s
> KEMBench.decapsulate  ML-KEM-1024              thrpt    2  19390.927          ops/s
> KEMBench.encapsulate   ML-KEM-512              thrpt    2  60238.211          ops/s
> KEMBench.encapsulate   ML-KEM-768              thrpt    2  36454.138          ops/s
> KEMBench.encapsulate  ML-KEM-1024              thrpt    2  23649.839          ops/s
> 
> 
> System was...

Thank you for sharing these results.  It is disconcerting to see the drop in performance for i) key gen-1024, ii) encapsulation-512, and iii) enacapsulation-1024, though I don't know the SE for these runs.  During my testing on a AMD EPYC 9J14 96-Core Processor I consistently get noticeable performance increases for all ML-KEM operations:

[Publish ML_KEM Benchmarks - Sheet1.pdf](https://github.com/user-attachments/files/24559070/Publish.ML_KEM.Benchmarks.-.Sheet1.pdf)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2681114748

From myankelevich at openjdk.org  Mon Jan 12 09:56:46 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 12 Jan 2026 09:56:46 GMT
Subject: [jdk26] RFR: 8373793: TestDynamicStore.java '/manual' disables use
 of '/timeout'
In-Reply-To: <3ndTpl-ZpZcGLhCJX0TEOLCtvgaN97kJJqV7XTvbYgo=.1f82f75b-38f8-4cea-b3fd-b81eb03fc450@github.com>
References: <3ndTpl-ZpZcGLhCJX0TEOLCtvgaN97kJJqV7XTvbYgo=.1f82f75b-38f8-4cea-b3fd-b81eb03fc450@github.com>
Message-ID: <XdfIQCumWhi5bBV142iTyrwg7mOEWRBrMOSMu0Se52g=.300549d0-282f-4beb-9941-347f01c2fbdf@github.com>

On Fri, 9 Jan 2026 16:34:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [400d8cfb](https://github.com/openjdk/jdk/commit/400d8cfb6914982e636b23bacf810ef61fc90ee1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mikhail Yankelevich on 19 Dec 2025 and was reviewed by Weijun Wang.
> 
> Thanks!
> 
> Ran the test manually on MacOS using sudo and the test passed.

Marked as reviewed by myankelevich (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29142#pullrequestreview-3649939759

From adinn at openjdk.org  Mon Jan 12 10:39:35 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 12 Jan 2026 10:39:35 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions
In-Reply-To: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
Message-ID: <Q_J9bZJ-0RBUNRI_9INN7XtiFvQkmiro9ex0UjJZ30E=.3196ecc9-6c2f-48f0-85e5-8da07176ce72@github.com>

On Fri, 9 Jan 2026 14:41:07 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.

Changes look good. What testing have you run?

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

PR Comment: https://git.openjdk.org/jdk/pull/29141#issuecomment-3737885979

From mdoerr at openjdk.org  Mon Jan 12 11:41:05 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 12 Jan 2026 11:41:05 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
Message-ID: <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>

On Wed, 7 Jan 2026 14:05:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I haven't tried (not my machine), but it's undefined behavior. There's no guarantee that `getpwuid_r` does what we expect. We should never use undefined behavior. Also note that not only AIX is affected.
>
>> It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?
> 
> Indeed, the status quo with respect to unsigned values passed to downcalls is a bit suboptimal, esp. in certain ABIs where sign/zero extension is required. This is tracked here:
> 
> https://bugs.openjdk.org/browse/JDK-8336664
> 
> (apologies -- this link was already shared by @dmlloyd )

Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2681912656

From mcimadamore at openjdk.org  Mon Jan 12 13:27:59 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 Jan 2026 13:27:59 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
Message-ID: <uLtjpxSm_9oOJqhkyASoPG9Tz_rccTerc1v6uwf9yNo=.68ff8f24-a8e0-4b39-b124-b36ca7d07776@github.com>

On Mon, 12 Jan 2026 11:37:17 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>> It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?
>> 
>> Indeed, the status quo with respect to unsigned values passed to downcalls is a bit suboptimal, esp. in certain ABIs where sign/zero extension is required. This is tracked here:
>> 
>> https://bugs.openjdk.org/browse/JDK-8336664
>> 
>> (apologies -- this link was already shared by @dmlloyd )
>
> Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions?

At the moment doing the conversion in Java and using a bigger carrier type (like `long`) is the only possible workaround.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2682268844

From weijun at openjdk.org  Mon Jan 12 15:14:33 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 12 Jan 2026 15:14:33 GMT
Subject: [jdk26] RFR: 8352728: InternalError loading java.security due to
 Windows parent folder permissions
In-Reply-To: <akgWEvuXGhcFCK3kx8yXt1blcdvBxStgTnXykhh5U7I=.ce7b7bcc-197f-4e16-8086-3240df8b2c84@github.com>
References: <akgWEvuXGhcFCK3kx8yXt1blcdvBxStgTnXykhh5U7I=.ce7b7bcc-197f-4e16-8086-3240df8b2c84@github.com>
Message-ID: <qC_wjd55sG-n1Si7Fw_GTRgzaOiG3Fizu2Vxm98oUGk=.13b5b161-982e-49d2-9564-c1de540bb459@github.com>

On Thu, 8 Jan 2026 17:24:37 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

> Clean backport of the following PR to fix a bug which breaks _Windows UWP_ Java applications when they load the `java.security.Security` class:
> 
> * #24465

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29121#pullrequestreview-3651267307

From mullan at openjdk.org  Mon Jan 12 17:40:47 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 Jan 2026 17:40:47 GMT
Subject: RFR: 8366522: CodeSource.getCodeSigners() throws NPE within empty
 certs [v6]
In-Reply-To: <unPBj3wtgAQyq48eO94o8Uvkcz8oeQE9XMreQg_Ql_I=.2db15ca6-c2d1-4dea-97c1-b6e30a5077e1@github.com>
References: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
 <unPBj3wtgAQyq48eO94o8Uvkcz8oeQE9XMreQg_Ql_I=.2db15ca6-c2d1-4dea-97c1-b6e30a5077e1@github.com>
Message-ID: <e6tgRJAwBHKC4X5L8q06HDlSOvQJjr2_AvJqGQ_PVkk=.bc3daff0-38c1-486d-a71f-2ec4bd50dd50@github.com>

On Fri, 9 Jan 2026 19:53:31 GMT, Kirill Shirokov <duke at openjdk.org> wrote:

>> The new tests cover only NPE scenarios.
>
> Kirill Shirokov 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 eight additional commits since the last revision:
> 
>  - Fixed java/security/CodeSource/CodeSourceNoInputs code style. Updated copyright year
>  - Merge remote-tracking branch 'origin' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>  - Fixed java/security/CodeSource/CodeSourceNoInputs test description
>  - Make CodeSource.getCodeSigners() return empty array of CodeSigners when constructed with emtpy array of certificates. Update the jtreg test to test null/empty array combinations of certificates and code signers
>  - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>  - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>  - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>  - 8366522: CodeSource.getCodeSigners() throws NPE within empty certs

test/jdk/java/security/CodeSource/CodeSourceNoInputs.java line 33:

> 31:  * @bug 8366522
> 32:  * @summary Verify that getCertificates() and getCodeSigners() return correct
> 33:  *          results when CodeSource is created with emtpy or null Certificate[]

Typo: s/emtpy/empty/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27105#discussion_r2683227124

From fferrari at openjdk.org  Mon Jan 12 18:42:07 2026
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Mon, 12 Jan 2026 18:42:07 GMT
Subject: [jdk26] Integrated: 8352728: InternalError loading java.security due
 to Windows parent folder permissions
In-Reply-To: <akgWEvuXGhcFCK3kx8yXt1blcdvBxStgTnXykhh5U7I=.ce7b7bcc-197f-4e16-8086-3240df8b2c84@github.com>
References: <akgWEvuXGhcFCK3kx8yXt1blcdvBxStgTnXykhh5U7I=.ce7b7bcc-197f-4e16-8086-3240df8b2c84@github.com>
Message-ID: <gFcYXkt00cI46IT5nMXr1fXZeWryPdC2pJoUmrSk0ag=.a6dacdce-68c5-4c48-b45b-0efa0375385e@github.com>

On Thu, 8 Jan 2026 17:24:37 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

> Clean backport of the following PR to fix a bug which breaks _Windows UWP_ Java applications when they load the `java.security.Security` class:
> 
> * #24465

This pull request has now been integrated.

Changeset: 31775fd2
Author:    Francisco Ferrari Bihurriet <fferrari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/31775fd27f247ba5d594dbf771ea7a1481422fb8
Stats:     2106 lines in 7 files changed: 1123 ins; 978 del; 5 mod

8352728: InternalError loading java.security due to Windows parent folder permissions

Reviewed-by: weijun
Backport-of: 7e1051bfcc01aad538376c86354e16e25d2eaf7a

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

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

From duke at openjdk.org  Mon Jan 12 22:09:14 2026
From: duke at openjdk.org (Kirill Shirokov)
Date: Mon, 12 Jan 2026 22:09:14 GMT
Subject: RFR: 8366522: CodeSource.getCodeSigners() throws NPE within empty
 certs [v7]
In-Reply-To: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
References: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
Message-ID: <sRGSzDdqAmHt6MTeiGNZUzOcpftHcWigUVR7wz3x40s=.8e4c9574-e69f-48fd-90d9-74051510b7d8@github.com>

> The new tests cover only NPE scenarios.

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

  Fixed a typo in a comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27105/files
  - new: https://git.openjdk.org/jdk/pull/27105/files/a134a9ae..64673e1f

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

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

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

From duke at openjdk.org  Mon Jan 12 22:09:19 2026
From: duke at openjdk.org (Kirill Shirokov)
Date: Mon, 12 Jan 2026 22:09:19 GMT
Subject: RFR: 8366522: CodeSource.getCodeSigners() throws NPE within empty
 certs [v6]
In-Reply-To: <e6tgRJAwBHKC4X5L8q06HDlSOvQJjr2_AvJqGQ_PVkk=.bc3daff0-38c1-486d-a71f-2ec4bd50dd50@github.com>
References: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
 <unPBj3wtgAQyq48eO94o8Uvkcz8oeQE9XMreQg_Ql_I=.2db15ca6-c2d1-4dea-97c1-b6e30a5077e1@github.com>
 <e6tgRJAwBHKC4X5L8q06HDlSOvQJjr2_AvJqGQ_PVkk=.bc3daff0-38c1-486d-a71f-2ec4bd50dd50@github.com>
Message-ID: <y22T3REuRTq8uyf-JhInEwKj-VpGE-v_Iql09stDXaI=.b8e59f04-d119-40a7-a105-b418fd08c55d@github.com>

On Mon, 12 Jan 2026 17:30:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kirill Shirokov 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 eight additional commits since the last revision:
>> 
>>  - Fixed java/security/CodeSource/CodeSourceNoInputs code style. Updated copyright year
>>  - Merge remote-tracking branch 'origin' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>>  - Fixed java/security/CodeSource/CodeSourceNoInputs test description
>>  - Make CodeSource.getCodeSigners() return empty array of CodeSigners when constructed with emtpy array of certificates. Update the jtreg test to test null/empty array combinations of certificates and code signers
>>  - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>>  - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>>  - Merge branch 'master' into JDK-8366522-fix-npe-codeSourceGetCodeSigners
>>  - 8366522: CodeSource.getCodeSigners() throws NPE within empty certs
>
> test/jdk/java/security/CodeSource/CodeSourceNoInputs.java line 33:
> 
>> 31:  * @bug 8366522
>> 32:  * @summary Verify that getCertificates() and getCodeSigners() return correct
>> 33:  *          results when CodeSource is created with emtpy or null Certificate[]
> 
> Typo: s/emtpy/empty/

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27105#discussion_r2684065589

From hchao at openjdk.org  Tue Jan 13 07:55:32 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 13 Jan 2026 07:55:32 GMT
Subject: RFR: 8373408: SHA1withECDSA is not required for ECDHE and ECDSA
Message-ID: <ZBDSdP8PhO2q3gjF10Xv8GKaWjxmwD5vO4p2ro_6qz4=.6e8e40fc-6087-41f1-8635-1239c755861f@github.com>

SunJSSE should not probe SHA1withECDSA signature availably when determining if elliptic curve cryptography is available, as it is deprecated and not required for ECDHE and ECDSA signature schemes. This change removes SHA1withECDSA from the EC availability probe. TLS signature scheme availability is validated later during handshake negotiation.

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

Commit messages:
 - 8373408: SHA1withECDSA is not required for ECDHE and ECDSA

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

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

From dfuchs at openjdk.org  Tue Jan 13 10:48:15 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 13 Jan 2026 10:48:15 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <Bf2QVEG7njXtnz_a6KYQ63HW0y18ITbOLOHKCVQrsj4=.02988e96-6a8e-4333-b591-b9931215aff5@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

If no other backport needs it then maybe we can backport it in some (the first?) update after GA.

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3743613367

From djelinski at openjdk.org  Tue Jan 13 11:03:09 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 13 Jan 2026 11:03:09 GMT
Subject: RFR: 8373408: SHA1withECDSA is not required for ECDHE and ECDSA
In-Reply-To: <ZBDSdP8PhO2q3gjF10Xv8GKaWjxmwD5vO4p2ro_6qz4=.6e8e40fc-6087-41f1-8635-1239c755861f@github.com>
References: <ZBDSdP8PhO2q3gjF10Xv8GKaWjxmwD5vO4p2ro_6qz4=.6e8e40fc-6087-41f1-8635-1239c755861f@github.com>
Message-ID: <i-iGO-kWjmBqfybfCYPiU0QBMw6FIj7ZnQNB3S6w2L0=.1631522d-62f3-4892-9d66-7955687b94f2@github.com>

On Tue, 13 Jan 2026 07:47:15 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> SunJSSE should not probe SHA1withECDSA signature availably when determining if elliptic curve cryptography is available, as it is deprecated and not required for ECDHE and ECDSA signature schemes. This change removes SHA1withECDSA from the EC availability probe. TLS signature scheme availability is validated later during handshake negotiation.

LGTM.

SHA1withECDSA (`SIGNATURE_ECDSA`) is required for ECDHE_ECDSA in TLS 1.1 and older. Starting with TLS 1.2, there are several hash algorithms available to choose from, and SHA1 is no longer required.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29184#pullrequestreview-3655185613

From abarashev at openjdk.org  Tue Jan 13 14:15:58 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 13 Jan 2026 14:15:58 GMT
Subject: RFR: 8375183: Remove unused SSLConfiguration.maximumProtocolVersion
 variable
Message-ID: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>

"SSLConfiguration.maximumProtocolVersion" is not being used in practice. It's used to initialize "TransportContext.protocolVersion" which is being later set to the negotiated protocol before being ever accessed.

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

Commit messages:
 - 8375183: Remove unused SSLConfiguration.maximumProtocolVersion variable

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

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

From myankelevich at openjdk.org  Tue Jan 13 14:19:48 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 13 Jan 2026 14:19:48 GMT
Subject: RFR: 8375183: Remove unused
 SSLConfiguration.maximumProtocolVersion variable
In-Reply-To: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
References: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
Message-ID: <RPt2N6ZSec6cfiotG0ly61nEDPk1WHrJw9hk-YT3kRU=.a7ec2382-929d-4c38-a218-d034cd1a7b62@github.com>

On Tue, 13 Jan 2026 14:08:09 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> "SSLConfiguration.maximumProtocolVersion" is not being used in practice. It's used to initialize "TransportContext.protocolVersion" which is being later set to the negotiated protocol before being ever accessed.

src/java.base/share/classes/sun/security/ssl/TransportContext.java line 147:

> 145:         // initial security parameters
> 146:         this.conSession = new SSLSessionImpl();
> 147:         this.protocolVersion = this.sslConfig.maximumProtocolVersion;

Wouldn't this make `protocolVersion` unassigned? I can't see it being set anywhere here, am I missing something?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29192#discussion_r2686620719

From abarashev at openjdk.org  Tue Jan 13 14:30:13 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 13 Jan 2026 14:30:13 GMT
Subject: RFR: 8375183: Remove unused
 SSLConfiguration.maximumProtocolVersion variable
In-Reply-To: <RPt2N6ZSec6cfiotG0ly61nEDPk1WHrJw9hk-YT3kRU=.a7ec2382-929d-4c38-a218-d034cd1a7b62@github.com>
References: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
 <RPt2N6ZSec6cfiotG0ly61nEDPk1WHrJw9hk-YT3kRU=.a7ec2382-929d-4c38-a218-d034cd1a7b62@github.com>
Message-ID: <V0wQhebqM1GkdpOhqBHEv95CKEpzTBEzj4pU_Z1DhSE=.c1668f0c-a514-4a5c-9c35-32bf5a46c106@github.com>

On Tue, 13 Jan 2026 14:15:47 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> "SSLConfiguration.maximumProtocolVersion" is not being used in practice. It's used to initialize "TransportContext.protocolVersion" which is being later set to the negotiated protocol before being ever accessed.
>
> src/java.base/share/classes/sun/security/ssl/TransportContext.java line 147:
> 
>> 145:         // initial security parameters
>> 146:         this.conSession = new SSLSessionImpl();
>> 147:         this.protocolVersion = this.sslConfig.maximumProtocolVersion;
> 
> Wouldn't this make `protocolVersion` unassigned? I can't see it being set anywhere here, am I missing something?

It will have a default `null` value. It's being assigned to the negotiated protocol outside of this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29192#discussion_r2686665077

From mpowers at openjdk.org  Tue Jan 13 15:00:14 2026
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 13 Jan 2026 15:00:14 GMT
Subject: [jdk26] RFR: 8369282: Distrust TLS server certificates anchored by
 Chunghwa ePKI Root CA
Message-ID: <9SE1pjsKAYckihVY-QdCz0n_CKynznBcRVbX5fOBpy8=.31a83aaa-1ed1-489d-a141-73e520a56cf6@github.com>

Hi all,

This pull request contains a backport of commit [92abc6df](https://github.com/openjdk/jdk/commit/92abc6dfe43a2c1f10dcfcf1e197fc9369f70ee3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Mark Powers on 8 Jan 2026 and was reviewed by Sean Mullan.

Thanks!

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

Commit messages:
 - Backport 92abc6dfe43a2c1f10dcfcf1e197fc9369f70ee3

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

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

From mullan at openjdk.org  Tue Jan 13 15:34:32 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 Jan 2026 15:34:32 GMT
Subject: [jdk26] RFR: 8369282: Distrust TLS server certificates anchored by
 Chunghwa ePKI Root CA
In-Reply-To: <9SE1pjsKAYckihVY-QdCz0n_CKynznBcRVbX5fOBpy8=.31a83aaa-1ed1-489d-a141-73e520a56cf6@github.com>
References: <9SE1pjsKAYckihVY-QdCz0n_CKynznBcRVbX5fOBpy8=.31a83aaa-1ed1-489d-a141-73e520a56cf6@github.com>
Message-ID: <LdpKdkUHq9IfjNrymteYXhaJ-31v_xCxO7oBDPig6qQ=.62a023e1-ef09-415f-b859-1872a0762d06@github.com>

On Tue, 13 Jan 2026 14:52:30 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [92abc6df](https://github.com/openjdk/jdk/commit/92abc6dfe43a2c1f10dcfcf1e197fc9369f70ee3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mark Powers on 8 Jan 2026 and was reviewed by Sean Mullan.
> 
> Thanks!

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29193#pullrequestreview-3656445578

From myankelevich at openjdk.org  Tue Jan 13 18:12:33 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 13 Jan 2026 18:12:33 GMT
Subject: RFR: 8375183: Remove unused
 SSLConfiguration.maximumProtocolVersion variable
In-Reply-To: <V0wQhebqM1GkdpOhqBHEv95CKEpzTBEzj4pU_Z1DhSE=.c1668f0c-a514-4a5c-9c35-32bf5a46c106@github.com>
References: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
 <RPt2N6ZSec6cfiotG0ly61nEDPk1WHrJw9hk-YT3kRU=.a7ec2382-929d-4c38-a218-d034cd1a7b62@github.com>
 <V0wQhebqM1GkdpOhqBHEv95CKEpzTBEzj4pU_Z1DhSE=.c1668f0c-a514-4a5c-9c35-32bf5a46c106@github.com>
Message-ID: <Gu6xJdMBEtYx0UMB-VMemUxa1nm1VkU1j3n57KotGmQ=.e89f1f77-307b-4589-9c89-1c31773065ad@github.com>

On Tue, 13 Jan 2026 14:26:37 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/TransportContext.java line 147:
>> 
>>> 145:         // initial security parameters
>>> 146:         this.conSession = new SSLSessionImpl();
>>> 147:         this.protocolVersion = this.sslConfig.maximumProtocolVersion;
>> 
>> Wouldn't this make `protocolVersion` unassigned? I can't see it being set anywhere here, am I missing something?
>
> It will have a default `null` value. It's being assigned to the negotiated protocol outside of this file.

Won't it require additional null checks then? Now it essentially defaults to a max protocol version, which was always present (`ProtocolVersion.NONE` by default)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29192#discussion_r2687520708

From mpowers at openjdk.org  Tue Jan 13 18:15:49 2026
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 13 Jan 2026 18:15:49 GMT
Subject: [jdk26] Integrated: 8369282: Distrust TLS server certificates anchored
 by Chunghwa ePKI Root CA
In-Reply-To: <9SE1pjsKAYckihVY-QdCz0n_CKynznBcRVbX5fOBpy8=.31a83aaa-1ed1-489d-a141-73e520a56cf6@github.com>
References: <9SE1pjsKAYckihVY-QdCz0n_CKynznBcRVbX5fOBpy8=.31a83aaa-1ed1-489d-a141-73e520a56cf6@github.com>
Message-ID: <7r_mBgVbjceeVoJJ34s0KGj4xduusA_sv1KDvjNzKFo=.964b764b-84aa-487b-84a3-5e904cd592ef@github.com>

On Tue, 13 Jan 2026 14:52:30 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [92abc6df](https://github.com/openjdk/jdk/commit/92abc6dfe43a2c1f10dcfcf1e197fc9369f70ee3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mark Powers on 8 Jan 2026 and was reviewed by Sean Mullan.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 17351930
Author:    Mark Powers <mpowers at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/17351930ac0cb93fdd222489041a60de7cf9e1ef
Stats:     244 lines in 5 files changed: 242 ins; 0 del; 2 mod

8369282: Distrust TLS server certificates anchored by Chunghwa ePKI Root CA

Reviewed-by: mullan
Backport-of: 92abc6dfe43a2c1f10dcfcf1e197fc9369f70ee3

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

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

From rhalade at openjdk.org  Tue Jan 13 18:16:18 2026
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 13 Jan 2026 18:16:18 GMT
Subject: [jdk26] RFR: 8373793: TestDynamicStore.java '/manual' disables use
 of '/timeout'
In-Reply-To: <3ndTpl-ZpZcGLhCJX0TEOLCtvgaN97kJJqV7XTvbYgo=.1f82f75b-38f8-4cea-b3fd-b81eb03fc450@github.com>
References: <3ndTpl-ZpZcGLhCJX0TEOLCtvgaN97kJJqV7XTvbYgo=.1f82f75b-38f8-4cea-b3fd-b81eb03fc450@github.com>
Message-ID: <GUwOoVaiJzXOdxUKEJzhQlF-BFKPf_pi65fceL-xXsc=.e3e012ef-2d65-4a77-a3c0-c69ef4d09f92@github.com>

On Fri, 9 Jan 2026 16:34:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [400d8cfb](https://github.com/openjdk/jdk/commit/400d8cfb6914982e636b23bacf810ef61fc90ee1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mikhail Yankelevich on 19 Dec 2025 and was reviewed by Weijun Wang.
> 
> Thanks!
> 
> Ran the test manually on MacOS using sudo and the test passed.

Why do we need this fix in JDK 26 at this time of the release? Please fix it in 26u release.

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

PR Comment: https://git.openjdk.org/jdk/pull/29142#issuecomment-3745718234

From abarashev at openjdk.org  Tue Jan 13 20:52:32 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 13 Jan 2026 20:52:32 GMT
Subject: RFR: 8375183: Remove unused
 SSLConfiguration.maximumProtocolVersion variable
In-Reply-To: <Gu6xJdMBEtYx0UMB-VMemUxa1nm1VkU1j3n57KotGmQ=.e89f1f77-307b-4589-9c89-1c31773065ad@github.com>
References: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
 <RPt2N6ZSec6cfiotG0ly61nEDPk1WHrJw9hk-YT3kRU=.a7ec2382-929d-4c38-a218-d034cd1a7b62@github.com>
 <V0wQhebqM1GkdpOhqBHEv95CKEpzTBEzj4pU_Z1DhSE=.c1668f0c-a514-4a5c-9c35-32bf5a46c106@github.com>
 <Gu6xJdMBEtYx0UMB-VMemUxa1nm1VkU1j3n57KotGmQ=.e89f1f77-307b-4589-9c89-1c31773065ad@github.com>
Message-ID: <o-qdLkxV9IpONmmU_4m9y-zbOAQ96UrI--KpPUZh4Ac=.b198f786-6f95-4c04-811b-400ddf6a8479@github.com>

On Tue, 13 Jan 2026 18:08:50 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> It will have a default `null` value. It's being assigned to the negotiated protocol outside of this file.
>
> Won't it require additional null checks then? Now it essentially defaults to a max protocol version, which was always present (`ProtocolVersion.NONE` by default)

We don't need null checks, `protocolVersion` currently is not used before it's set to the negotiated protocol, and we'll get a NPE if somebody tries to use it before it's set. It is basically a representation of negotiated protocol in `TransportContext`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29192#discussion_r2688081660

From weijun at openjdk.org  Tue Jan 13 21:17:13 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Jan 2026 21:17:13 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v8]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com>

> Rewrite the native calls with FFM.

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

  new naming style; use VarHandle to access fields

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/cfd794b8..bf91106e

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

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

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

From weijun at openjdk.org  Tue Jan 13 21:27:03 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Jan 2026 21:27:03 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v8]
In-Reply-To: <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com>
Message-ID: <CZoOTCNqfVxnOPmEudA6rdfwidfVlKnwiQnwE5M4MOA=.d50dbabe-c645-41f6-8dfd-6df593e0aa0b@github.com>

On Tue, 13 Jan 2026 21:17:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   new naming style; use VarHandle to access fields

A new commit pushed after some offline discussion. Now using a new naming style with an uppercase PREFIX followed by the original C name. For example, a `MethodHandle` for `getgroups` becomes `MH_getgroups`. Also, switching to `VarHandle` for struct field retrieval.

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

PR Comment: https://git.openjdk.org/jdk/pull/28931#issuecomment-3746638101

From weijun at openjdk.org  Tue Jan 13 21:27:04 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Jan 2026 21:27:04 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
Message-ID: <HqlfAlkuLwwHJQGV_04tSQ4F8HG2ZyOvVUHXPAtaCeI=.cfe8933e-0cd8-49ec-9c94-382818738fed@github.com>

On Mon, 12 Jan 2026 11:37:17 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>> It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement?
>> 
>> Indeed, the status quo with respect to unsigned values passed to downcalls is a bit suboptimal, esp. in certain ABIs where sign/zero extension is required. This is tracked here:
>> 
>> https://bugs.openjdk.org/browse/JDK-8336664
>> 
>> (apologies -- this link was already shared by @dmlloyd )
>
> Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions?

@TheRealMDoerr I haven't used your `calling_convention_requires_int_as_long` flag in my new commit. Can you investigate the approach in a different JBS issue?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2688164522

From valeriep at openjdk.org  Tue Jan 13 21:46:57 2026
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 13 Jan 2026 21:46:57 GMT
Subject: RFR: 8366807: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_initializeLibrary of p11_general.c:106
 [v2]
In-Reply-To: <yz_HaMGWRF9ofQJWIivAryh0oKDpHXOgdars5Opdlfs=.3f69622d-7cf7-4caa-9aef-255b90f0748b@github.com>
References: <ox_PeEYD6B42hVBiEQCoxhzdxVLRJMR2BxExHLoKCRw=.63b307b8-8209-445a-abf1-cfe71fdf1abf@github.com>
 <yz_HaMGWRF9ofQJWIivAryh0oKDpHXOgdars5Opdlfs=.3f69622d-7cf7-4caa-9aef-255b90f0748b@github.com>
Message-ID: <k4ArN1m11v3wU6Kjw1uxhhWvW-vcmpV5x6FLQRLmZQg=.1e625568-b1bc-4cc5-bdb6-b024debb4d04@github.com>

On Wed, 7 Jan 2026 22:31:24 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The method createLockObject will return NULL if any exception is thrown, but there is no NULL verification in p11_general.c after the following line is invoked
>> notifyListLock = createLockObject(env);
>> 
>> There may be a pending exception when invoking prefetchFields(env, thisClass);
>> 
>> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366807: Updated Copyright

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28799#pullrequestreview-3658052464

From valeriep at openjdk.org  Tue Jan 13 21:50:28 2026
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 13 Jan 2026 21:50:28 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950 [v2]
In-Reply-To: <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
 <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>
Message-ID: <cGZDjIMsVMJTEth2UPwTMbJqDdsY31bKMnH7jyyNAiY=.17caaedc-d0c0-4894-b625-d717b0924240@github.com>

On Wed, 7 Jan 2026 21:05:55 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The method ckAssertReturnValueOK will invoke ckAssertReturnValueOK2 which makes multiple calls to JNI functions, such as FindClass or GetMethodID. These calls would be unsafe as there may be a pending exception at this time.
>> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367024: Addressing review comments

src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_keymgmt.c line 934:

> 932:     /* If derivation failed, do not attempt copy-back */
> 933:     if (ckAssertReturnValueOK(env, rv) != CK_ASSERT_OK) {
> 934:         jKeyHandle = 0L;

Why is this needed? `jKeyHandle` is initialized with 0L and no other assignment before this line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29054#discussion_r2688227896

From sshivang at openjdk.org  Wed Jan 14 03:45:33 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Wed, 14 Jan 2026 03:45:33 GMT
Subject: [jdk26] RFR: 8373793: TestDynamicStore.java '/manual' disables use
 of '/timeout'
In-Reply-To: <3ndTpl-ZpZcGLhCJX0TEOLCtvgaN97kJJqV7XTvbYgo=.1f82f75b-38f8-4cea-b3fd-b81eb03fc450@github.com>
References: <3ndTpl-ZpZcGLhCJX0TEOLCtvgaN97kJJqV7XTvbYgo=.1f82f75b-38f8-4cea-b3fd-b81eb03fc450@github.com>
Message-ID: <VUkNGGIHMMeByOUWJsgfBGYqk6a6CfsqT-moFU0G98g=.9ec00613-d2ce-4dde-aa59-d04f6bec69e1@github.com>

On Fri, 9 Jan 2026 16:34:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [400d8cfb](https://github.com/openjdk/jdk/commit/400d8cfb6914982e636b23bacf810ef61fc90ee1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mikhail Yankelevich on 19 Dec 2025 and was reviewed by Weijun Wang.
> 
> Thanks!
> 
> Ran the test manually on MacOS using sudo and the test passed.

I will close this and fix in  26u

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

PR Comment: https://git.openjdk.org/jdk/pull/29142#issuecomment-3747546091

From sshivang at openjdk.org  Wed Jan 14 03:45:34 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Wed, 14 Jan 2026 03:45:34 GMT
Subject: [jdk26] Withdrawn: 8373793: TestDynamicStore.java '/manual' disables
 use of '/timeout'
In-Reply-To: <3ndTpl-ZpZcGLhCJX0TEOLCtvgaN97kJJqV7XTvbYgo=.1f82f75b-38f8-4cea-b3fd-b81eb03fc450@github.com>
References: <3ndTpl-ZpZcGLhCJX0TEOLCtvgaN97kJJqV7XTvbYgo=.1f82f75b-38f8-4cea-b3fd-b81eb03fc450@github.com>
Message-ID: <9rrdrXLrv95NQW3GmULwcfYrNn4gARCIqvpq6XXw2Jg=.7eebc3ca-c859-4143-a313-ad212637765f@github.com>

On Fri, 9 Jan 2026 16:34:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [400d8cfb](https://github.com/openjdk/jdk/commit/400d8cfb6914982e636b23bacf810ef61fc90ee1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mikhail Yankelevich on 19 Dec 2025 and was reviewed by Weijun Wang.
> 
> Thanks!
> 
> Ran the test manually on MacOS using sudo and the test passed.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Wed Jan 14 03:48:01 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 14 Jan 2026 03:48:01 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950 [v3]
In-Reply-To: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
Message-ID: <bmdNNR8d2Ihke0j0tpJE76eZTC7bBpGxc5ue0OYKWK8=.fdd93bce-b53d-4e22-855c-b9695c6acd1b@github.com>

> The method ckAssertReturnValueOK will invoke ckAssertReturnValueOK2 which makes multiple calls to JNI functions, such as FindClass or GetMethodID. These calls would be unsafe as there may be a pending exception at this time.
> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8367024: Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29054/files
  - new: https://git.openjdk.org/jdk/pull/29054/files/c0eba306..d65d64a5

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

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

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

From duke at openjdk.org  Wed Jan 14 03:48:04 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 14 Jan 2026 03:48:04 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950 [v2]
In-Reply-To: <cGZDjIMsVMJTEth2UPwTMbJqDdsY31bKMnH7jyyNAiY=.17caaedc-d0c0-4894-b625-d717b0924240@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
 <xHh27iDAjy8H6672rxD9RWqNh1lrg_KJycNUJWPRoso=.68e1474e-328f-4482-8a4d-699b89b319ec@github.com>
 <cGZDjIMsVMJTEth2UPwTMbJqDdsY31bKMnH7jyyNAiY=.17caaedc-d0c0-4894-b625-d717b0924240@github.com>
Message-ID: <SXsBkTM9GjvlG1WJnI3ueKeTjHGbqRRbbbMUW8aituw=.ef8dfcbf-6d46-42c1-bf1f-c47a0ef71922@github.com>

On Tue, 13 Jan 2026 21:47:04 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8367024: Addressing review comments
>
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_keymgmt.c line 934:
> 
>> 932:     /* If derivation failed, do not attempt copy-back */
>> 933:     if (ckAssertReturnValueOK(env, rv) != CK_ASSERT_OK) {
>> 934:         jKeyHandle = 0L;
> 
> Why is this needed? `jKeyHandle` is initialized with 0L and no other assignment before this line?

Good catch ? jKeyHandle is already initialized. Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29054#discussion_r2688827083

From duke at openjdk.org  Wed Jan 14 04:09:32 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 14 Jan 2026 04:09:32 GMT
Subject: RFR: 8375183: Remove unused
 SSLConfiguration.maximumProtocolVersion variable
In-Reply-To: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
References: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
Message-ID: <L3EkCNsn3qRPeCIaz9G9gIQTLMWt-N_ntk1_3GdRsB8=.db11247c-a84f-47b8-8926-c9216af24df6@github.com>

On Tue, 13 Jan 2026 14:08:09 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> "SSLConfiguration.maximumProtocolVersion" is not being used in practice. It's used to initialize "TransportContext.protocolVersion" which is being later set to the negotiated protocol before being ever accessed.

Marked as reviewed by koushikthirupattur at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/29192#pullrequestreview-3658759256

From duke at openjdk.org  Wed Jan 14 04:09:34 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 14 Jan 2026 04:09:34 GMT
Subject: RFR: 8375183: Remove unused
 SSLConfiguration.maximumProtocolVersion variable
In-Reply-To: <o-qdLkxV9IpONmmU_4m9y-zbOAQ96UrI--KpPUZh4Ac=.b198f786-6f95-4c04-811b-400ddf6a8479@github.com>
References: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
 <RPt2N6ZSec6cfiotG0ly61nEDPk1WHrJw9hk-YT3kRU=.a7ec2382-929d-4c38-a218-d034cd1a7b62@github.com>
 <V0wQhebqM1GkdpOhqBHEv95CKEpzTBEzj4pU_Z1DhSE=.c1668f0c-a514-4a5c-9c35-32bf5a46c106@github.com>
 <Gu6xJdMBEtYx0UMB-VMemUxa1nm1VkU1j3n57KotGmQ=.e89f1f77-307b-4589-9c89-1c31773065ad@github.com>
 <o-qdLkxV9IpONmmU_4m9y-zbOAQ96UrI--KpPUZh4Ac=.b198f786-6f95-4c04-811b-400ddf6a8479@github.com>
Message-ID: <mWQUGKKmmMS3h8Ocisrqrw3Jk7s5bkK_6NMkM-VvGzY=.cf6c9154-2da4-4470-9d7e-9246bde2386a@github.com>

On Tue, 13 Jan 2026 20:50:11 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Won't it require additional null checks then? Now it essentially defaults to a max protocol version, which was always present (`ProtocolVersion.NONE` by default)
>
> We don't need null checks, `protocolVersion` currently is not used before it's set to the negotiated protocol, and we'll get a NPE if somebody tries to use it before it's set. It is basically a representation of negotiated protocol in `TransportContext`.

In that case, instead of leaving it null, can we consider initializing protocolVersion to ProtocolVersion.NONE with a short comment? That would avoid using null as state and make the intent more explicit/readable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29192#discussion_r2688865119

From duke at openjdk.org  Wed Jan 14 06:46:18 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 14 Jan 2026 06:46:18 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions
In-Reply-To: <Q_J9bZJ-0RBUNRI_9INN7XtiFvQkmiro9ex0UjJZ30E=.3196ecc9-6c2f-48f0-85e5-8da07176ce72@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <Q_J9bZJ-0RBUNRI_9INN7XtiFvQkmiro9ex0UjJZ30E=.3196ecc9-6c2f-48f0-85e5-8da07176ce72@github.com>
Message-ID: <Hnez5IrYYlIfPGffBMLuuy8iX75AwlDZ_fF_FZgwZwE=.af8d8784-7953-4fa7-9bcc-d6fc19cd9ab1@github.com>

On Mon, 12 Jan 2026 10:37:31 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Changes look good. What testing have you run?

Thank you for your review.  I've ran the ACVP tests for ML-KEM, which have all passed (default and intrinsics (aarch64)).

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

PR Comment: https://git.openjdk.org/jdk/pull/29141#issuecomment-3748038784

From duke at openjdk.org  Wed Jan 14 07:50:17 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 14 Jan 2026 07:50:17 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions
In-Reply-To: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
Message-ID: <oAsdoY3Lzx2ciK91bwpLePfXA-OOhHr1Mhq2owVdjBE=.feca4759-d0c2-4e77-ab21-dbe3d16bdfc7@github.com>

On Fri, 9 Jan 2026 14:41:07 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6217:

> 6215:     __ sub(parsedLength, parsedLength, 64);
> 6216:     __ cmp(parsedLength, (u1)0);
> 6217:     __ br(Assembler::GE, L_loop);

Should this be GT now?

src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java line 1364:

> 1362:         int n = (parsedLength + 127) / 128;
> 1363:         assert ((parsed.length >= n * 128) &&
> 1364:                 (condensed.length >= index + n * 192));

Given the comments, can this be simplified to just:


-    int n = (parsedLength + 127) / 128;
-    assert ((parsed.length >= n * 128) &&
-                (condensed.length >= index + n * 192));
+   assert((parsed.length % 128) == 0) && (condensed.length % 192 == 0));


If the length is smaller than the constant then the remainder will be non-zero.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2689338785
PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2689173853

From duke at openjdk.org  Wed Jan 14 08:00:39 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 14 Jan 2026 08:00:39 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v4]
In-Reply-To: <ac8EBuu2VzwQMVxPjT-v5abMlaY4EIOJZ8h95DWAVOM=.e16566c1-6add-4c99-b427-78a3cdfcdbb9@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
 <Qq1hD_zx6FsvunA2HDp8-Oa9YDSOAZDKK-M2ObSyAEY=.21bda4b0-3186-4e85-9e49-bb70e69b3c33@github.com>
 <htQOcf4BCZXgh3P3FoMBou09Zhcg4deRYuu8DHLDtWc=.b2247e7f-b41b-461f-b3d0-73737f52b535@github.com>
 <28KSbLDo353fDhRsW-5aaLpYvQ9XGPnyOqO1YN_LnPs=.eaa3ddbf-9228-4fce-a973-dda88d5abf75@github.com>
 <GHlrs3IAFzOaPIWNo8cmK9yXd2cGwEcsM9SzbwvKJrU=.ee4699ee-b835-4c84-b18c-1775376ce43c@github.com>
 <IDULCOeuqXv0x51xZNCckEuz15kBikJEDAVHO2ruuC8=.52018b85-8abf-46e4-84f6-b148a1ffa7ed@github.com>
 <ac8EBuu2VzwQMVxPjT-v5abMlaY4EIOJZ8h95DWAVOM=.e16566c1-6add-4c99-b427-78a3cdfcdbb9@github.com>
Message-ID: <5IwyH3qhmxTV8x8xU5aOym1D79yzowjLmhFb9o4PD0Q=.9280e8d0-caad-4310-af42-3b272963dde1@github.com>

On Mon, 12 Jan 2026 07:23:39 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>>> > Better to align loop sarting address to OptoLoopAlignment
>>> 
>>> For parity, should I do this for the other labels in the file as well?
>>> 
>>> > I will run the micro benchmark on AMD Turin and report back by early next week.
>>> 
>>> That would be great, thank you for doing this!
>> 
>> Here are the score on Turin.
>> 
>> 
>> Baseline:
>> Benchmark                                    (algorithm)  (keyLength)  (provider)   Mode  Cnt      Score   Error  Units
>> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-512            0              thrpt    2  62235.790          ops/s
>> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-768            0              thrpt    2  38238.390          ops/s
>> KeyPairGeneratorBench.MLKEM.generateKeyPair  ML-KEM-1024            0              thrpt    2  24725.512          ops/s
>> 
>> Withopt:
>> Benchmark                                    (algorithm)  (keyLength)  (provider)   Mode  Cnt      Score   Error  Units
>> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-512            0              thrpt    2  62483.697          ops/s
>> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-768            0              thrpt    2  38464.272          ops/s
>> KeyPairGeneratorBench.MLKEM.generateKeyPair  ML-KEM-1024            0              thrpt    2  24702.044          ops/s
>> 
>> 
>> 
>> Baseline:
>> Benchmark             (algorithm)  (provider)   Mode  Cnt      Score   Error  Units
>> KEMBench.decapsulate   ML-KEM-512              thrpt    2  46416.479          ops/s
>> KEMBench.decapsulate   ML-KEM-768              thrpt    2  28516.289          ops/s
>> KEMBench.decapsulate  ML-KEM-1024              thrpt    2  19250.020          ops/s
>> KEMBench.encapsulate   ML-KEM-512              thrpt    2  60374.724          ops/s
>> KEMBench.encapsulate   ML-KEM-768              thrpt    2  36226.100          ops/s
>> KEMBench.encapsulate  ML-KEM-1024              thrpt    2  23656.223          ops/s
>> 
>> Withopt:
>> Benchmark             (algorithm)  (provider)   Mode  Cnt      Score   Error  Units
>> KEMBench.decapsulate   ML-KEM-512              thrpt    2  46730.153          ops/s
>> KEMBench.decapsulate   ML-KEM-768              thrpt    2  28650.349          ops/s
>> KEMBench.decapsulate  ML-KEM-1024              thrpt    2  19390.927          ops/s
>> KEMBench.encapsulate   ML-KEM-512              thrpt    2  60238.211          ops/s
>> KEMBench.encapsulate   ML-KEM-768              thrpt    2  36454.138          ops/s
>> KEMBench.encapsulat...
>
> Thank you for sharing these results.  It is disconcerting to see the drop in performance for i) key gen-1024, ii) encapsulation-512, and iii) enacapsulation-1024, though I don't know the SE for these runs.  During my testing on a AMD EPYC 9J14 96-Core Processor I consistently get noticeable performance increases for all ML-KEM operations:
> 
> [Publish ML_KEM Benchmarks - Sheet1.pdf](https://github.com/user-attachments/files/24559070/Publish.ML_KEM.Benchmarks.-.Sheet1.pdf)

Here are results comparing pre and post OptoLoopAlignment:

[Alignment ML_KEM Benchmarks - Sheet1.pdf](https://github.com/user-attachments/files/24607923/Alignment.ML_KEM.Benchmarks.-.Sheet1.pdf)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2689366713

From djelinski at openjdk.org  Wed Jan 14 08:03:39 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 14 Jan 2026 08:03:39 GMT
Subject: RFR: 8375183: Remove unused
 SSLConfiguration.maximumProtocolVersion variable
In-Reply-To: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
References: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
Message-ID: <oEDLePv0GSy1rD5Pes4w2hGqmJVRfxw5rBx96fTGH2w=.ec532d9d-25e4-4ee1-a18d-d6b71025506d@github.com>

On Tue, 13 Jan 2026 14:08:09 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> "SSLConfiguration.maximumProtocolVersion" is not being used in practice. It's used to initialize "TransportContext.protocolVersion" which is being later set to the negotiated protocol before being ever accessed.

LGTM.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29192#pullrequestreview-3659373216

From djelinski at openjdk.org  Wed Jan 14 08:03:39 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 14 Jan 2026 08:03:39 GMT
Subject: RFR: 8375183: Remove unused
 SSLConfiguration.maximumProtocolVersion variable
In-Reply-To: <mWQUGKKmmMS3h8Ocisrqrw3Jk7s5bkK_6NMkM-VvGzY=.cf6c9154-2da4-4470-9d7e-9246bde2386a@github.com>
References: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
 <RPt2N6ZSec6cfiotG0ly61nEDPk1WHrJw9hk-YT3kRU=.a7ec2382-929d-4c38-a218-d034cd1a7b62@github.com>
 <V0wQhebqM1GkdpOhqBHEv95CKEpzTBEzj4pU_Z1DhSE=.c1668f0c-a514-4a5c-9c35-32bf5a46c106@github.com>
 <Gu6xJdMBEtYx0UMB-VMemUxa1nm1VkU1j3n57KotGmQ=.e89f1f77-307b-4589-9c89-1c31773065ad@github.com>
 <o-qdLkxV9IpONmmU_4m9y-zbOAQ96UrI--KpPUZh4Ac=.b198f786-6f95-4c04-811b-400ddf6a8479@github.com>
 <mWQUGKKmmMS3h8Ocisrqrw3Jk7s5bkK_6NMkM-VvGzY=.cf6c9154-2da4-4470-9d7e-9246bde2386a@github.com>
Message-ID: <mQPZLepAkCwlJ1Y22X3LN90SAeliF5taYoWmdPiqpA8=.514de925-7384-498c-94b7-8b8e94efdb6f@github.com>

On Wed, 14 Jan 2026 04:06:01 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> We don't need null checks, `protocolVersion` currently is not used before it's set to the negotiated protocol, and we'll get a NPE if somebody tries to use it before it's set. It is basically a representation of negotiated protocol in `TransportContext`.
>
> In that case, instead of leaving it null, can we consider initializing protocolVersion to ProtocolVersion.NONE with a short comment? That would avoid using null as state and make the intent more explicit/readable.

That would be more risky; any uninitialized use is a bug, and null pointer exceptions are easier to spot.

The protocol version is set to the maximum active protocol [here](https://github.com/openjdk/jdk/blob/1b6c2bdd7b57891ed35e3c067871d2c0bf282824/src/java.base/share/classes/sun/security/ssl/HandshakeContext.java#L253), which is still long before the variable is used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29192#discussion_r2689374894

From myankelevich at openjdk.org  Wed Jan 14 10:00:51 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 14 Jan 2026 10:00:51 GMT
Subject: RFR: 8375183: Remove unused
 SSLConfiguration.maximumProtocolVersion variable
In-Reply-To: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
References: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
Message-ID: <yLaiL14Sw8G2GAFMVfds_k3NbM-WRqncFj6DNvPqeas=.4651d10b-895f-4500-a411-9fb4dd58a84d@github.com>

On Tue, 13 Jan 2026 14:08:09 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> "SSLConfiguration.maximumProtocolVersion" is not being used in practice. It's used to initialize "TransportContext.protocolVersion" which is being later set to the negotiated protocol before being ever accessed.

Marked as reviewed by myankelevich (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29192#pullrequestreview-3659844689

From myankelevich at openjdk.org  Wed Jan 14 10:00:53 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 14 Jan 2026 10:00:53 GMT
Subject: RFR: 8375183: Remove unused
 SSLConfiguration.maximumProtocolVersion variable
In-Reply-To: <o-qdLkxV9IpONmmU_4m9y-zbOAQ96UrI--KpPUZh4Ac=.b198f786-6f95-4c04-811b-400ddf6a8479@github.com>
References: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
 <RPt2N6ZSec6cfiotG0ly61nEDPk1WHrJw9hk-YT3kRU=.a7ec2382-929d-4c38-a218-d034cd1a7b62@github.com>
 <V0wQhebqM1GkdpOhqBHEv95CKEpzTBEzj4pU_Z1DhSE=.c1668f0c-a514-4a5c-9c35-32bf5a46c106@github.com>
 <Gu6xJdMBEtYx0UMB-VMemUxa1nm1VkU1j3n57KotGmQ=.e89f1f77-307b-4589-9c89-1c31773065ad@github.com>
 <o-qdLkxV9IpONmmU_4m9y-zbOAQ96UrI--KpPUZh4Ac=.b198f786-6f95-4c04-811b-400ddf6a8479@github.com>
Message-ID: <d1INRdZDbJQMzwqHNmikZVSldowKHN7yXb459KqerQ8=.583558d1-0b50-46cf-91cb-631ce53b441d@github.com>

On Tue, 13 Jan 2026 20:50:11 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Won't it require additional null checks then? Now it essentially defaults to a max protocol version, which was always present (`ProtocolVersion.NONE` by default)
>
> We don't need null checks, `protocolVersion` currently is not used before it's set to the negotiated protocol, and we'll get a NPE if somebody tries to use it before it's set. It is basically a representation of negotiated protocol in `TransportContext`.

Yeah, I see your point and since it's not supposed to be used uninitialised anyway this way is ok. Thanks for explaining @artur-oracle @djelinski

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29192#discussion_r2689751489

From adinn at openjdk.org  Wed Jan 14 10:46:54 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 14 Jan 2026 10:46:54 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions
In-Reply-To: <oAsdoY3Lzx2ciK91bwpLePfXA-OOhHr1Mhq2owVdjBE=.feca4759-d0c2-4e77-ab21-dbe3d16bdfc7@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <oAsdoY3Lzx2ciK91bwpLePfXA-OOhHr1Mhq2owVdjBE=.feca4759-d0c2-4e77-ab21-dbe3d16bdfc7@github.com>
Message-ID: <QsHmanuvxcEXa7aUKYsJ7yf0-dGARWhg9SAXJzSOX0E=.75c5ba8e-0507-47f3-a5ca-d71fa3b8bfe9@github.com>

On Wed, 14 Jan 2026 07:45:26 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6217:
> 
>> 6215:     __ sub(parsedLength, parsedLength, 64);
>> 6216:     __ cmp(parsedLength, (u1)0);
>> 6217:     __ br(Assembler::GE, L_loop);
> 
> Should this be GT now?

Yes, I believe it should. That makes me wonder why the test did not fail. I would have expected it to loop back to the top and try to consume an extra 96 bytes of non-existent input and write it to 64 bytes of of non-existent output buffer? Did this erroneous computation not happen? or was the error simply not manifest?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2689924512

From alanb at openjdk.org  Wed Jan 14 12:02:29 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jan 2026 12:02:29 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v6]
In-Reply-To: <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@github.com>
Message-ID: <udqQcMSS1iZjs-vADproU-vaRpg69JuekqRLmXyKJK4=.c196eade-9de1-4ae8-bcae-bc9ca8783ff2@github.com>

On Fri, 9 Jan 2026 18:38:53 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   sperate VM.sec_props command

I think the latest proposal with `jcmd VM.security_properties` looks reasonable. My guess is that many developers don't know about security properties, or might think they are system properties that do something magic with security. So I think expand the current help/description from "Print security properties" to include "java.security.Security" in the text so there is somewhere to go and learn what this is.

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3749232175

From duke at openjdk.org  Wed Jan 14 13:06:15 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 14 Jan 2026 13:06:15 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions [v2]
In-Reply-To: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
Message-ID: <MwtIHUJSbX80tKnY_xDYiVmFWfg_qyj6AHKyTg-1zP0=.7d180f11-0e80-4886-a37e-336f144d3787@github.com>

> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.

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

  Fix off-by-one error discovered by Shawn

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29141/files
  - new: https://git.openjdk.org/jdk/pull/29141/files/f2437a69..2fca58bd

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

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

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

From duke at openjdk.org  Wed Jan 14 13:12:34 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 14 Jan 2026 13:12:34 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions [v2]
In-Reply-To: <QsHmanuvxcEXa7aUKYsJ7yf0-dGARWhg9SAXJzSOX0E=.75c5ba8e-0507-47f3-a5ca-d71fa3b8bfe9@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <oAsdoY3Lzx2ciK91bwpLePfXA-OOhHr1Mhq2owVdjBE=.feca4759-d0c2-4e77-ab21-dbe3d16bdfc7@github.com>
 <QsHmanuvxcEXa7aUKYsJ7yf0-dGARWhg9SAXJzSOX0E=.75c5ba8e-0507-47f3-a5ca-d71fa3b8bfe9@github.com>
Message-ID: <DWypx1bJGVd_rYUFnFHgvbDMAUhGqGxSdYpAnjxBTX4=.643c937e-0f5e-4283-a683-4839bbbe4974@github.com>

On Wed, 14 Jan 2026 10:43:23 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6217:
>> 
>>> 6215:     __ sub(parsedLength, parsedLength, 64);
>>> 6216:     __ cmp(parsedLength, (u1)0);
>>> 6217:     __ br(Assembler::GE, L_loop);
>> 
>> Should this be GT now?
>
> Yes, I believe it should. That makes me wonder why the test did not fail. I would have expected it to loop back to the top and try to consume an extra 96 bytes of non-existent input and write it to 64 bytes of of non-existent output buffer? Did this erroneous computation not happen? or was the error simply not manifest?

It is a buffer overflow, so if the memory after the arrays is there, it would be read/written, if you are lucky, it doesn't overwrite anything that is used later, so it might be able to pass a test program (which definitely had happened here).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2690369308

From duke at openjdk.org  Wed Jan 14 13:31:23 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 14 Jan 2026 13:31:23 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions [v2]
In-Reply-To: <DWypx1bJGVd_rYUFnFHgvbDMAUhGqGxSdYpAnjxBTX4=.643c937e-0f5e-4283-a683-4839bbbe4974@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <oAsdoY3Lzx2ciK91bwpLePfXA-OOhHr1Mhq2owVdjBE=.feca4759-d0c2-4e77-ab21-dbe3d16bdfc7@github.com>
 <QsHmanuvxcEXa7aUKYsJ7yf0-dGARWhg9SAXJzSOX0E=.75c5ba8e-0507-47f3-a5ca-d71fa3b8bfe9@github.com>
 <DWypx1bJGVd_rYUFnFHgvbDMAUhGqGxSdYpAnjxBTX4=.643c937e-0f5e-4283-a683-4839bbbe4974@github.com>
Message-ID: <ttd8pnpgToX4fiSZBv06N7eJZ0Pt0Kab-GonVbRCdss=.c50fe3ae-caa4-40b2-8a3e-db74bb12e8db@github.com>

On Wed, 14 Jan 2026 13:09:29 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Yes, I believe it should. That makes me wonder why the test did not fail. I would have expected it to loop back to the top and try to consume an extra 96 bytes of non-existent input and write it to 64 bytes of of non-existent output buffer? Did this erroneous computation not happen? or was the error simply not manifest?
>
> It is a buffer overflow, so if the memory after the arrays is there, it would be read/written, if you are lucky, it doesn't overwrite anything that is used later, so it might be able to pass a test program (which definitely had happened here).

Yes, it should. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2690431947

From duke at openjdk.org  Wed Jan 14 13:31:28 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 14 Jan 2026 13:31:28 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions [v2]
In-Reply-To: <oAsdoY3Lzx2ciK91bwpLePfXA-OOhHr1Mhq2owVdjBE=.feca4759-d0c2-4e77-ab21-dbe3d16bdfc7@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <oAsdoY3Lzx2ciK91bwpLePfXA-OOhHr1Mhq2owVdjBE=.feca4759-d0c2-4e77-ab21-dbe3d16bdfc7@github.com>
Message-ID: <p3WywVlRjk4edJlMBOQefpS2fbZuTRGGGwzSfnH6GPQ=.5fba9ba3-547e-4ffe-9bfa-c0f9ddaf6f35@github.com>

On Wed, 14 Jan 2026 06:51:00 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix off-by-one error discovered by Shawn
>
> src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java line 1364:
> 
>> 1362:         int n = (parsedLength + 127) / 128;
>> 1363:         assert ((parsed.length >= n * 128) &&
>> 1364:                 (condensed.length >= index + n * 192));
> 
> Given the comments, can this be simplified to just:
> 
> 
> -    int n = (parsedLength + 127) / 128;
> -    assert ((parsed.length >= n * 128) &&
> -                (condensed.length >= index + n * 192));
> +   assert((parsed.length % 128) == 0) && (condensed.length % 192 == 0));
> 
> 
> If the length is smaller than the constant then the remainder will be non-zero.

These are the exact conditions that the most demanding intrinsic (the AVX-512 one) requires. If we would rely on that the callers satisfy these, we wouldn't need the assert :-) . The loop in the intrinsic will read n * 192 bytes and write n * 128 shorts, your suggestion would not ensure that the arrays have at least that much space.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2690431489

From weijun at openjdk.org  Wed Jan 14 14:25:00 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Jan 2026 14:25:00 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v10]
In-Reply-To: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
Message-ID: <7GibXbpYksp4f8ltqrU5CfPzApSKW6zgI0IJfSvEZh0=.b0b6c420-5d25-4b99-b595-3088430f969b@github.com>

> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded when a new key pair is generated or when `KeyFactory::translateKey` is called.
> 
> By default, the choice is "seed".
> 
> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is calculated from the input if it's seed only.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into 8347938
 - one RFC; some java.security word changes
 - fixed merge error
 - merge
 - merge
 - Ben comment
 - combine security properties description; remove one test
 - Merge branch 'master' into 8347938
 - KeyChoices class
 - allow expanded to be null
 - ... and 4 more: https://git.openjdk.org/jdk/compare/20bd178b...dfbcaa09

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

Changes: https://git.openjdk.org/jdk/pull/24969/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24969&range=09
  Stats: 2458 lines in 24 files changed: 1699 ins; 548 del; 211 mod
  Patch: https://git.openjdk.org/jdk/pull/24969.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24969/head:pull/24969

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

From kfarrell at openjdk.org  Wed Jan 14 15:31:21 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Wed, 14 Jan 2026 15:31:21 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v7]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <fxpQxoernzRZw_unqS-Pj-8UxYy8QHHv-Kh3bpUXxpY=.20979ccb-b80c-4633-9bbb-1992cdf468d8@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

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

  update to print java.security.Security properties

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/db9e0e97..bb3b243c

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

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

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

From myankelevich at openjdk.org  Wed Jan 14 15:50:06 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 14 Jan 2026 15:50:06 GMT
Subject: RFR: 8374808: Add an Instance in place of Date for KeyStore and
 KeyStoreSpi
Message-ID: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>

Hi!

This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
I would be very grateful for your comments and suggestions.

Thanks!

P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)

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

Commit messages:
 - renamed timestamp to instant
 - renamed timestamp to instant
 - test
 - test
 - comments
 - Weijun's comments
 - JDK-8374808: Attempt to add an Instance in place of Date for KeyStore and KeyStoreSpi

Changes: https://git.openjdk.org/jdk/pull/29140/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29140&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374808
  Stats: 268 lines in 8 files changed: 197 ins; 4 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/29140.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29140/head:pull/29140

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

From weijun at openjdk.org  Wed Jan 14 15:50:11 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Jan 2026 15:50:11 GMT
Subject: RFR: 8374808: Add an Instance in place of Date for KeyStore and
 KeyStoreSpi
In-Reply-To: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
Message-ID: <_NWrc0GIpsL1jTruJcHqMsI7xDEuPlJ4fRPWsDDRAQI=.ec8bf4ce-f3e3-4cc9-8805-f8cbb9051572@github.com>

On Fri, 9 Jan 2026 14:16:41 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Hi!
> 
> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
> I would be very grateful for your comments and suggestions.
> 
> Thanks!
> 
> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)

Mostly looks good. Do you have a plan to update the callers of `KeyStore::getCreationDate`?

Also, I see you skipped the SunPKCS11 and MSCAPI implementations. Are they too trivial and the default implementation is enough?

src/java.base/share/classes/java/security/KeyStore.java line 1187:

> 1185:      * Returns the creation date of the entry identified by the given alias.
> 1186:      * <p>
> 1187:      * Please consider using {@code getCreationTimestamp} instead.

Better add a reason. For example, something like "This method returns a Date, which is mutable and more error-prone. Use getCreationTimestamp() instead." I feel hesitated to mention "legacy" or "modern" directly.

Here I'm following the [`Thread::getId` words](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/Thread.html#getId()).

src/java.base/share/classes/java/security/KeyStore.java line 1208:

> 1206: 
> 1207:     /**
> 1208:      * Returns the creation timestamp (Instant) of the entry identified

Maybe change `(Instance)` to `as an {@code Instant} value`, if you think it's worth mentioning the difference. Anyway, don't leave "Instant" in plain text.

There should be a `@since 27`.

src/java.base/share/classes/java/security/KeyStore.java line 1215:

> 1213:      *
> 1214:      * @throws    KeyStoreException if the keystore has not been initialized
> 1215:      * (loaded).

Although `getCreationDate` is not deprecated, I wonder if you can add some comment there recommending the new method with some reason.

src/java.base/share/classes/java/security/KeyStoreSpi.java line 138:

> 136:      * {@code engineGetCreationDate(alias)} which returns a {@code Date}.
> 137:      * If the result is not @{code null} returns
> 138:      * Instance equivalent to received {@code Date}.

The sentence should start with "The default implementation". For example, "The default implementation calls engineGetCreationDate(alias) and returns the output as an Instant value".

There is no need to be so detailed about `null`.

There should be a `@since 27`.

src/java.base/share/classes/java/security/KeyStoreSpi.java line 141:

> 139:      */
> 140:     public Instant engineGetCreationTimestamp(String alias) {
> 141:         return engineGetCreationDate(alias).toInstant();

1. You might need to check for null first.
2. There should be an `@implSpec` saying "The default implementation returns..."

src/java.base/share/classes/sun/security/provider/DomainKeyStore.java line 238:

> 236:     }
> 237: 
> 238:     /**

For this class, does it make sense to rewrite `engineGetCreationDate` like the other implementations?

src/java.base/share/classes/sun/security/provider/JavaKeyStore.java line 240:

> 238:      */
> 239:     public Date engineGetCreationDate(String alias) {
> 240:         return Date.from(this.engineGetCreationTimestamp(alias));

Could `engineGetCreationTimestamp(alias)` return `null`?

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

PR Review: https://git.openjdk.org/jdk/pull/29140#pullrequestreview-3645351472
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2677424331
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2677428454
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2676561054
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2677440504
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2676552098
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2677463193
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2677465677

From myankelevich at openjdk.org  Wed Jan 14 15:50:12 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 14 Jan 2026 15:50:12 GMT
Subject: RFR: 8374808: Add an Instance in place of Date for KeyStore and
 KeyStoreSpi
In-Reply-To: <_NWrc0GIpsL1jTruJcHqMsI7xDEuPlJ4fRPWsDDRAQI=.ec8bf4ce-f3e3-4cc9-8805-f8cbb9051572@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <_NWrc0GIpsL1jTruJcHqMsI7xDEuPlJ4fRPWsDDRAQI=.ec8bf4ce-f3e3-4cc9-8805-f8cbb9051572@github.com>
Message-ID: <drpf0nh8Np5iiJkay-WCIK6ex11TNkc-72m9TxbkzZw=.cb432d6f-81e1-4423-9ac1-4f0139819c6b@github.com>

On Fri, 9 Jan 2026 20:01:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Mostly looks good. Do you have a plan to update the callers of `KeyStore::getCreationDate`?
> 
> Also, I see you skipped the SunPKCS11 and MSCAPI implementations. Are they too trivial and the default implementation is enough?

Apologies, missed this comment the last time I went through them. 
`P11KeyStore` has no support for creation date and throws an exception so I think the default should be enough. 
As for `CKeyStore` It seems that it just creates a new date and nothing else. I'm not sure if writing a whole separate method to always provide current time is worth it when we have a default implementation. But if you believe it is - I'm happy to add it

> src/java.base/share/classes/java/security/KeyStore.java line 1187:
> 
>> 1185:      * Returns the creation date of the entry identified by the given alias.
>> 1186:      * <p>
>> 1187:      * Please consider using {@code getCreationTimestamp} instead.
> 
> Better add a reason. For example, something like "This method returns a Date, which is mutable and more error-prone. Use getCreationTimestamp() instead." I feel hesitated to mention "legacy" or "modern" directly.
> 
> Here I'm following the [`Thread::getId` words](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/Thread.html#getId()).

Yes, this sounds better, thanks. Changed in the next commit.

> src/java.base/share/classes/java/security/KeyStore.java line 1208:
> 
>> 1206: 
>> 1207:     /**
>> 1208:      * Returns the creation timestamp (Instant) of the entry identified
> 
> Maybe change `(Instance)` to `as an {@code Instant} value`, if you think it's worth mentioning the difference. Anyway, don't leave "Instant" in plain text.
> 
> There should be a `@since 27`.

Done in the next commit

> src/java.base/share/classes/java/security/KeyStore.java line 1215:
> 
>> 1213:      *
>> 1214:      * @throws    KeyStoreException if the keystore has not been initialized
>> 1215:      * (loaded).
> 
> Although `getCreationDate` is not deprecated, I wonder if you can add some comment there recommending the new method with some reason.

Done in the next commit

> src/java.base/share/classes/java/security/KeyStoreSpi.java line 138:
> 
>> 136:      * {@code engineGetCreationDate(alias)} which returns a {@code Date}.
>> 137:      * If the result is not @{code null} returns
>> 138:      * Instance equivalent to received {@code Date}.
> 
> The sentence should start with "The default implementation". For example, "The default implementation calls engineGetCreationDate(alias) and returns the output as an Instant value".
> 
> There is no need to be so detailed about `null`.
> 
> There should be a `@since 27`.

Done in the next commit

> src/java.base/share/classes/java/security/KeyStoreSpi.java line 141:
> 
>> 139:      */
>> 140:     public Instant engineGetCreationTimestamp(String alias) {
>> 141:         return engineGetCreationDate(alias).toInstant();
> 
> 1. You might need to check for null first.
> 2. There should be an `@implSpec` saying "The default implementation returns..."

Yes, you're right. Done in the next commit.

> src/java.base/share/classes/sun/security/provider/DomainKeyStore.java line 238:
> 
>> 236:     }
>> 237: 
>> 238:     /**
> 
> For this class, does it make sense to rewrite `engineGetCreationDate` like the other implementations?

I believe so, otherwise we will be either getting `Date` as before via `engineGetCreationDate` or have a default implementation from `KeyStoreSpi` which converts the result of `engineGetCreationDate`. This seems to me just an extra operation, which I'm not convinced is necessary. 
However, if you think in this case it might be ok - I'm happy to remove this and simplify.

> src/java.base/share/classes/sun/security/provider/JavaKeyStore.java line 240:
> 
>> 238:      */
>> 239:     public Date engineGetCreationDate(String alias) {
>> 240:         return Date.from(this.engineGetCreationTimestamp(alias));
> 
> Could `engineGetCreationTimestamp(alias)` return `null`?

Yes, missed it in the last change, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/29140#issuecomment-3743866087
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2681869462
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2681871215
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2676803707
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2681901615
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2676803086
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2681920481
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2681926844

From mullan at openjdk.org  Wed Jan 14 16:05:21 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 14 Jan 2026 16:05:21 GMT
Subject: RFR: 8374808: Add an Instance in place of Date for KeyStore and
 KeyStoreSpi
In-Reply-To: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
Message-ID: <f9j6z6KipqTN-5LKLElL0zocmbIEyniYoiUGHhKdwao=.c72d86a6-2401-493f-80cf-e0e14a168255@github.com>

On Fri, 9 Jan 2026 14:16:41 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Hi!
> 
> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
> I would be very grateful for your comments and suggestions.
> 
> Thanks!
> 
> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)

Can you change the title of the issue to be more descriptive that these are new APIs, ex: "Add new methods to KeyStore and KeyStoreSpi that return the creation date as an Instant instead of Date"

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

PR Comment: https://git.openjdk.org/jdk/pull/29140#issuecomment-3750273990

From myankelevich at openjdk.org  Wed Jan 14 17:19:36 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 14 Jan 2026 17:19:36 GMT
Subject: RFR: 8374808: Add an Instance in place of Date for KeyStore and
 KeyStoreSpi [v2]
In-Reply-To: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
Message-ID: <XDo4dFouVjJGK58F6v0CI1XVIkdj6JyFIpORVpVfV4I=.d1eaf65a-8a18-4c2a-92bb-18fd81172b3d@github.com>

> Hi!
> 
> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
> I would be very grateful for your comments and suggestions.
> 
> Thanks!
> 
> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)

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

  DKS tests enhanced

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29140/files
  - new: https://git.openjdk.org/jdk/pull/29140/files/553ed938..6c35e980

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

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

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

From hchao at openjdk.org  Wed Jan 14 18:01:56 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 14 Jan 2026 18:01:56 GMT
Subject: RFR: 8375183: Remove unused
 SSLConfiguration.maximumProtocolVersion variable
In-Reply-To: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
References: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
Message-ID: <qw5Rr6rW5px7u2apXPl0c6GcxMfcg5_kjrM2Ahd_oTg=.00733c7d-accd-4d31-a969-4a8a364d4747@github.com>

On Tue, 13 Jan 2026 14:08:09 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> "SSLConfiguration.maximumProtocolVersion" is not being used in practice. It's used to initialize "TransportContext.protocolVersion" which is being later set to the negotiated protocol before being ever accessed.

Marked as reviewed by hchao (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29192#pullrequestreview-3662059355

From valeriep at openjdk.org  Wed Jan 14 18:22:08 2026
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 14 Jan 2026 18:22:08 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950 [v3]
In-Reply-To: <bmdNNR8d2Ihke0j0tpJE76eZTC7bBpGxc5ue0OYKWK8=.fdd93bce-b53d-4e22-855c-b9695c6acd1b@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
 <bmdNNR8d2Ihke0j0tpJE76eZTC7bBpGxc5ue0OYKWK8=.fdd93bce-b53d-4e22-855c-b9695c6acd1b@github.com>
Message-ID: <HCuEHXq7lYYcf0B6df6GIyVT7-TqhHNv_Y6z8Ar9Hko=.89e133c6-aec4-4a34-b208-800552fef1fa@github.com>

On Wed, 14 Jan 2026 03:48:01 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The method ckAssertReturnValueOK will invoke ckAssertReturnValueOK2 which makes multiple calls to JNI functions, such as FindClass or GetMethodID. These calls would be unsafe as there may be a pending exception at this time.
>> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367024: Addressing review comments

Changes look good, have you run the security regression tests?

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29054#pullrequestreview-3662148293

From weijun at openjdk.org  Wed Jan 14 21:16:30 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Jan 2026 21:16:30 GMT
Subject: RFR: 8374808: Add an Instance in place of Date for KeyStore and
 KeyStoreSpi [v2]
In-Reply-To: <XDo4dFouVjJGK58F6v0CI1XVIkdj6JyFIpORVpVfV4I=.d1eaf65a-8a18-4c2a-92bb-18fd81172b3d@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <XDo4dFouVjJGK58F6v0CI1XVIkdj6JyFIpORVpVfV4I=.d1eaf65a-8a18-4c2a-92bb-18fd81172b3d@github.com>
Message-ID: <RxuCqwVJYP4uSijqy4IJy3einJfbuIYJ53TXv8RX70o=.027459c1-d0fc-4320-a546-952f99377f47@github.com>

On Wed, 14 Jan 2026 17:19:36 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Hi!
>> 
>> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
>> I would be very grateful for your comments and suggestions.
>> 
>> Thanks!
>> 
>> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DKS tests enhanced

Some comments.

I have a small concern on the `Instant.now()` calls  everywhere. As you can see in your `TestKeyStoreBasic.java` test, the value is truncated when persisting inside a keystore and when loaded again it's not identical to the old value. Will this create any interop issue in the real world? If we know a keystore implementation only support the precision of milliseconds, should we truncate it early?

src/java.base/share/classes/java/security/KeyStore.java line 1187:

> 1185:      * Returns the creation date of the entry identified by the given alias.
> 1186:      * <p>
> 1187:      * This method returns a Date, which is mutable and more error-prone.

Put `Date` in `{@code}`.

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

PR Review: https://git.openjdk.org/jdk/pull/29140#pullrequestreview-3662667039
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2691998489

From weijun at openjdk.org  Wed Jan 14 21:16:33 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Jan 2026 21:16:33 GMT
Subject: RFR: 8374808: Add an Instance in place of Date for KeyStore and
 KeyStoreSpi [v2]
In-Reply-To: <drpf0nh8Np5iiJkay-WCIK6ex11TNkc-72m9TxbkzZw=.cb432d6f-81e1-4423-9ac1-4f0139819c6b@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <_NWrc0GIpsL1jTruJcHqMsI7xDEuPlJ4fRPWsDDRAQI=.ec8bf4ce-f3e3-4cc9-8805-f8cbb9051572@github.com>
 <drpf0nh8Np5iiJkay-WCIK6ex11TNkc-72m9TxbkzZw=.cb432d6f-81e1-4423-9ac1-4f0139819c6b@github.com>
Message-ID: <Cpc8g62VXGXMFSHa7LCGUFj-DXzwM53NqdGGhaH4Efw=.485d7565-2812-4d5d-b865-df83692ff342@github.com>

On Mon, 12 Jan 2026 11:39:54 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/DomainKeyStore.java line 238:
>> 
>>> 236:     }
>>> 237: 
>>> 238:     /**
>> 
>> For this class, does it make sense to rewrite `engineGetCreationDate` like the other implementations?
>
> I believe so, otherwise we will be either getting `Date` as before via `engineGetCreationDate` or have a default implementation from `KeyStoreSpi` which converts the result of `engineGetCreationDate`. This seems to me just an extra operation, which I'm not convinced is necessary. 
> However, if you think in this case it might be ok - I'm happy to remove this and simplify.

I would rewrite this `engineGetCreationDate` to call `engineGetCreationInstant` and convert it. After all this code change is about migrating from calling `getCreationDate` and it's called here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2691961145

From weijun at openjdk.org  Wed Jan 14 21:16:31 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Jan 2026 21:16:31 GMT
Subject: RFR: 8374808: Add an Instance in place of Date for KeyStore and
 KeyStoreSpi [v2]
In-Reply-To: <RxuCqwVJYP4uSijqy4IJy3einJfbuIYJ53TXv8RX70o=.027459c1-d0fc-4320-a546-952f99377f47@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <XDo4dFouVjJGK58F6v0CI1XVIkdj6JyFIpORVpVfV4I=.d1eaf65a-8a18-4c2a-92bb-18fd81172b3d@github.com>
 <RxuCqwVJYP4uSijqy4IJy3einJfbuIYJ53TXv8RX70o=.027459c1-d0fc-4320-a546-952f99377f47@github.com>
Message-ID: <Sk52lphe_JEMqfP6DFVcdTFLbRjGZgd2Jjire6Z1qio=.59032396-02fa-4c27-a24d-3066b3a46707@github.com>

On Wed, 14 Jan 2026 20:48:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   DKS tests enhanced
>
> src/java.base/share/classes/java/security/KeyStore.java line 1187:
> 
>> 1185:      * Returns the creation date of the entry identified by the given alias.
>> 1186:      * <p>
>> 1187:      * This method returns a Date, which is mutable and more error-prone.
> 
> Put `Date` in `{@code}`.

I'm a little unsure of the "more" word. When you say more, it sounds like you are comparing it to something else. Since we haven't spelled out the other thing, maybe we can remove this word.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2692006297

From mullan at openjdk.org  Wed Jan 14 21:57:05 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 14 Jan 2026 21:57:05 GMT
Subject: RFR: 8374808: Add an Instance in place of Date for KeyStore and
 KeyStoreSpi [v2]
In-Reply-To: <XDo4dFouVjJGK58F6v0CI1XVIkdj6JyFIpORVpVfV4I=.d1eaf65a-8a18-4c2a-92bb-18fd81172b3d@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <XDo4dFouVjJGK58F6v0CI1XVIkdj6JyFIpORVpVfV4I=.d1eaf65a-8a18-4c2a-92bb-18fd81172b3d@github.com>
Message-ID: <rzZjpUTLsELivnlLKm06W5PYspEEEqXPQNPu32LFT04=.ef4811d3-12c0-46bc-9d35-b504761cc15c@github.com>

On Wed, 14 Jan 2026 17:19:36 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Hi!
>> 
>> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
>> I would be very grateful for your comments and suggestions.
>> 
>> Thanks!
>> 
>> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DKS tests enhanced

src/java.base/share/classes/java/security/KeyStore.java line 1187:

> 1185:      * Returns the creation date of the entry identified by the given alias.
> 1186:      * <p>
> 1187:      * This method returns a Date, which is mutable and more error-prone.

I think this could be misinterpreted to mean that the KeyStore's internal Date is mutable, when implementations typically should be returning new objects or clones. Suggest something simpler like "It is recommended to use the {@link #getCreationInstant(String)} method instead."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2692193133

From duke at openjdk.org  Thu Jan 15 01:55:59 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 15 Jan 2026 01:55:59 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions [v2]
In-Reply-To: <p3WywVlRjk4edJlMBOQefpS2fbZuTRGGGwzSfnH6GPQ=.5fba9ba3-547e-4ffe-9bfa-c0f9ddaf6f35@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <oAsdoY3Lzx2ciK91bwpLePfXA-OOhHr1Mhq2owVdjBE=.feca4759-d0c2-4e77-ab21-dbe3d16bdfc7@github.com>
 <p3WywVlRjk4edJlMBOQefpS2fbZuTRGGGwzSfnH6GPQ=.5fba9ba3-547e-4ffe-9bfa-c0f9ddaf6f35@github.com>
Message-ID: <j1Ef0xPBTTFBTo_NQs6qPcgvLE8fKX6n4HT3oa2vH2M=.6771437c-d26a-4750-a915-d12d3ee10bbe@github.com>

On Wed, 14 Jan 2026 13:27:50 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java line 1364:
>> 
>>> 1362:         int n = (parsedLength + 127) / 128;
>>> 1363:         assert ((parsed.length >= n * 128) &&
>>> 1364:                 (condensed.length >= index + n * 192));
>> 
>> Given the comments, can this be simplified to just:
>> 
>> 
>> -    int n = (parsedLength + 127) / 128;
>> -    assert ((parsed.length >= n * 128) &&
>> -                (condensed.length >= index + n * 192));
>> +   assert((parsed.length % 128) == 0) && (condensed.length % 192 == 0));
>> 
>> 
>> If the length is smaller than the constant then the remainder will be non-zero.
>
> These are the exact conditions that the most demanding intrinsic (the AVX-512 one) requires. If we would rely on that the callers satisfy these, we wouldn't need the assert :-) . The loop in the intrinsic will read n * 192 bytes and write n * 128 shorts, your suggestion would not ensure that the arrays have at least that much space.

Ah, I see that now.  Maybe an update to the comments would alleviate my confusion?:
NEW:
    // An intrinsic implementation assumes that the input and output buffers
    // are such that condensed can be read in n-multiples of 192 bytes and
    // parsed can be written in n-multiples of 128 shorts, so callers should allocate
    // the condensed and parsed arrays to at least these amounts, see the assert()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2692668352

From mdoerr at openjdk.org  Thu Jan 15 09:34:47 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 15 Jan 2026 09:34:47 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <HqlfAlkuLwwHJQGV_04tSQ4F8HG2ZyOvVUHXPAtaCeI=.cfe8933e-0cd8-49ec-9c94-382818738fed@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
 <HqlfAlkuLwwHJQGV_04tSQ4F8HG2ZyOvVUHXPAtaCeI=.cfe8933e-0cd8-49ec-9c94-382818738fed@github.com>
Message-ID: <dtkJ9M8YMpq4xq8BCq7Fr1bc1ETY7NX-at0rFBQiU9o=.089ab056-830b-4529-8388-9be1486bf5a3@github.com>

On Tue, 13 Jan 2026 21:21:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions?
>
> @TheRealMDoerr I haven't used your `calling_convention_requires_int_as_long` flag in my new commit. Can you investigate the approach in a different JBS issue?

I would prefer to have no undefined behavior from the beginning. However, if you don't feed comfortable with it, we could file a follow-up issue. I don't think there's much to investigate because there's no alternative before we get [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2693634221

From hchao at openjdk.org  Thu Jan 15 10:27:06 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 15 Jan 2026 10:27:06 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints [v4]
In-Reply-To: <SvUGi7_7e6pvwmVOec0MTv33yavtP2Ve3ixb7WanHnQ=.c3cfc626-657b-4076-ada1-3b5eae49418a@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
 <SvUGi7_7e6pvwmVOec0MTv33yavtP2Ve3ixb7WanHnQ=.c3cfc626-657b-4076-ada1-3b5eae49418a@github.com>
Message-ID: <O7mQex_5qoyhEEhmzGyX2NwU1RhTtqN6hQQjnICXAjY=.e8e707f7-2c5d-45cf-9ed8-61a191152c54@github.com>

On Fri, 2 Jan 2026 15:02:31 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> NamedGroup.SupportedGroups.namedGroups values are not being filtered against algorithm constraints, unlike other SSLParameters returned by SSLConfiguration#getSSLParameters() call. Those are the values being displayed to the user with "java -XshowSettings:security:tls" command.
>> 
>> Also making changes to avoid needless default group names lookup while we are touching this file.
>
> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8370885
>    
>    # Conflicts:
>    #	src/java.base/share/classes/sun/security/ssl/NamedGroup.java
>  - Update copyright year
>  - Merge branch 'master' into JDK-8370885
>  - Merge branch 'master' into JDK-8370885
>    
>    # Conflicts:
>    #	src/java.base/share/classes/sun/security/ssl/NamedGroup.java
>  - 8370885: Default namedGroups values are not being filtered against algorithm constraints

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 780:

> 778:                 customizedGroups == null ?
> 779:                         null : Arrays.stream(customizedGroups)
> 780:                         .map(ng -> ng.name)

The filtering against algorithm constraints is not being done for customizedNames. Is it to preserve user?s selection and let constraints to be applied during handshake as before? It is different from defaultNames?s. Suggest to add some comments for it.

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 799:

> 797:         // Avoid the group lookup for default and customized groups.
> 798:         static NamedGroup[] getGroupsFromConfig(SSLConfiguration sslConfig) {
> 799:             if (sslConfig.namedGroups == defaultNames) {

Nit: getGroupsFromConfig() can choose from pre-initialized defaultGroups, customizedGroups, or sslConfig.namedGroups. Its name sounds like it reads something directly from SSLConfiguration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28397#discussion_r2693798265
PR Review Comment: https://git.openjdk.org/jdk/pull/28397#discussion_r2693809343

From myankelevich at openjdk.org  Thu Jan 15 10:52:56 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 15 Jan 2026 10:52:56 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v2]
In-Reply-To: <rzZjpUTLsELivnlLKm06W5PYspEEEqXPQNPu32LFT04=.ef4811d3-12c0-46bc-9d35-b504761cc15c@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <XDo4dFouVjJGK58F6v0CI1XVIkdj6JyFIpORVpVfV4I=.d1eaf65a-8a18-4c2a-92bb-18fd81172b3d@github.com>
 <rzZjpUTLsELivnlLKm06W5PYspEEEqXPQNPu32LFT04=.ef4811d3-12c0-46bc-9d35-b504761cc15c@github.com>
Message-ID: <InyJxOiepkR07BfzvtCS7iME39W5-PEPdZ8MJq5jHYA=.51d7e4e9-f047-4723-954b-3e78c28a7f04@github.com>

On Wed, 14 Jan 2026 21:52:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   DKS tests enhanced
>
> src/java.base/share/classes/java/security/KeyStore.java line 1187:
> 
>> 1185:      * Returns the creation date of the entry identified by the given alias.
>> 1186:      * <p>
>> 1187:      * This method returns a Date, which is mutable and more error-prone.
> 
> I think this could be misinterpreted to mean that the KeyStore's internal Date is mutable, when implementations typically should be returning new objects or clones. Suggest something simpler like "It is recommended to use the {@link #getCreationInstant(String)} method instead."

Changed in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2693890166

From myankelevich at openjdk.org  Thu Jan 15 10:52:58 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 15 Jan 2026 10:52:58 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v2]
In-Reply-To: <Sk52lphe_JEMqfP6DFVcdTFLbRjGZgd2Jjire6Z1qio=.59032396-02fa-4c27-a24d-3066b3a46707@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <XDo4dFouVjJGK58F6v0CI1XVIkdj6JyFIpORVpVfV4I=.d1eaf65a-8a18-4c2a-92bb-18fd81172b3d@github.com>
 <RxuCqwVJYP4uSijqy4IJy3einJfbuIYJ53TXv8RX70o=.027459c1-d0fc-4320-a546-952f99377f47@github.com>
 <Sk52lphe_JEMqfP6DFVcdTFLbRjGZgd2Jjire6Z1qio=.59032396-02fa-4c27-a24d-3066b3a46707@github.com>
Message-ID: <6kTcfKoRabarvXZ3DHpSvWs1B9deXxBeVfYmIkx1LeU=.152a8834-c794-41ea-825b-c620e3ffe07d@github.com>

On Wed, 14 Jan 2026 20:51:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/KeyStore.java line 1187:
>> 
>>> 1185:      * Returns the creation date of the entry identified by the given alias.
>>> 1186:      * <p>
>>> 1187:      * This method returns a Date, which is mutable and more error-prone.
>> 
>> Put `Date` in `{@code}`.
>
> I'm a little unsure of the "more" word. When you say more, it sounds like you are comparing it to something else. Since we haven't spelled out the other thing, maybe we can remove this word.

I have replaced this with 'It is recommended to use the {@link #getCreationInstant(String)} method instead.' as per Sean's suggestion

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2693898349

From myankelevich at openjdk.org  Thu Jan 15 10:53:00 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 15 Jan 2026 10:53:00 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v2]
In-Reply-To: <Cpc8g62VXGXMFSHa7LCGUFj-DXzwM53NqdGGhaH4Efw=.485d7565-2812-4d5d-b865-df83692ff342@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <_NWrc0GIpsL1jTruJcHqMsI7xDEuPlJ4fRPWsDDRAQI=.ec8bf4ce-f3e3-4cc9-8805-f8cbb9051572@github.com>
 <drpf0nh8Np5iiJkay-WCIK6ex11TNkc-72m9TxbkzZw=.cb432d6f-81e1-4423-9ac1-4f0139819c6b@github.com>
 <Cpc8g62VXGXMFSHa7LCGUFj-DXzwM53NqdGGhaH4Efw=.485d7565-2812-4d5d-b865-df83692ff342@github.com>
Message-ID: <E-AIuLWdxrGUT2_t75fUJjqceJ9lMz9-w14HNbHGPpk=.f0d899ac-59bd-4850-83d8-e78c1aaa796c@github.com>

On Wed, 14 Jan 2026 20:35:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I believe so, otherwise we will be either getting `Date` as before via `engineGetCreationDate` or have a default implementation from `KeyStoreSpi` which converts the result of `engineGetCreationDate`. This seems to me just an extra operation, which I'm not convinced is necessary. 
>> However, if you think in this case it might be ok - I'm happy to remove this and simplify.
>
> I would rewrite this `engineGetCreationDate` to call `engineGetCreationInstant` and convert it. After all this code change is about migrating from calling `getCreationDate` and it's called here.

Ok, should be done in the next commit. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2693888840

From aph at openjdk.org  Thu Jan 15 10:59:34 2026
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 15 Jan 2026 10:59:34 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions [v2]
In-Reply-To: <MwtIHUJSbX80tKnY_xDYiVmFWfg_qyj6AHKyTg-1zP0=.7d180f11-0e80-4886-a37e-336f144d3787@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <MwtIHUJSbX80tKnY_xDYiVmFWfg_qyj6AHKyTg-1zP0=.7d180f11-0e80-4886-a37e-336f144d3787@github.com>
Message-ID: <WAiQ07KdowulstQEiP-ObhKNXmTVRYMN888RpcudKvo=.b7e4eadc-6eb4-44d2-80f4-9935b8b56a13@github.com>

On Wed, 14 Jan 2026 13:06:15 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix off-by-one error discovered by Shawn

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6084:

> 6082:   //         byte[] condensed, int index, short[] parsed, int parsedLength) {}
> 6083:   //
> 6084:   // it is assumed that parsed and condensed are allocated such that for

By whom? :-)
Suggestion:

  // we assume that parsed and condensed are allocated such that for

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6280:

> 6278:     vs_st2_post(vs_front(vs_front(vb)), __ T8H, parsed);
> 6279: 
> 6280:     __ BIND(L_end);

This is a substantial change, not a mere matter of "incorrect assertions". Perhaps this PR needs a more appropriate title.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2693915262
PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2693920223

From hchao at openjdk.org  Thu Jan 15 11:09:18 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 15 Jan 2026 11:09:18 GMT
Subject: RFR: 8286032: keytool -list -alias should not assume it is always a
 certificate
Message-ID: <pDbmUpIbWqEu0ePvYLXfxKrdxjmHlF_ZFb7rzDGu2s8=.cf440bba-086a-4973-82f8-3e3ee942b9cb@github.com>

This fix the warnings of the keytool -list -alias for a secret key that was created with a legacy algorithm.

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

Commit messages:
 - 8286032: keytool -list -alias should not assume it is always a certificate

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

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

From myankelevich at openjdk.org  Thu Jan 15 11:26:54 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 15 Jan 2026 11:26:54 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v2]
In-Reply-To: <RxuCqwVJYP4uSijqy4IJy3einJfbuIYJ53TXv8RX70o=.027459c1-d0fc-4320-a546-952f99377f47@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <XDo4dFouVjJGK58F6v0CI1XVIkdj6JyFIpORVpVfV4I=.d1eaf65a-8a18-4c2a-92bb-18fd81172b3d@github.com>
 <RxuCqwVJYP4uSijqy4IJy3einJfbuIYJ53TXv8RX70o=.027459c1-d0fc-4320-a546-952f99377f47@github.com>
Message-ID: <9pVVnF50Rh1y5Il_UJbFTdYiH3Pc2YrL-kHzwnc2Gp0=.7677235f-944e-432d-b139-e82e46cc9761@github.com>

On Wed, 14 Jan 2026 21:12:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Some comments.
> 
> I have a small concern on the `Instant.now()` calls everywhere. As you can see in your `TestKeyStoreBasic.java` test, the value is truncated when persisting inside a keystore and when loaded again it's not identical to the old value. Will this create any interop issue in the real world? If we know a keystore implementation only support the precision of milliseconds, should we truncate it early?

I believe this would be the safest thing to do. Existing implementation is relying on `new Date()` which is actually calling `System.currentTimeMillis()` which is sufficient. Even though it shouldn't cause any interop issues as Date still remains unchanged `Instant` values can cause confusion as in the test.

I have changed these 'Instant.now()' to `Instant.now().truncatedTo(ChronoUnit.MILLIS);`

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

PR Comment: https://git.openjdk.org/jdk/pull/29140#issuecomment-3754263534

From myankelevich at openjdk.org  Thu Jan 15 11:29:05 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 15 Jan 2026 11:29:05 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v3]
In-Reply-To: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
Message-ID: <T6FtMYRrRheMiPrmRvzxeBYShaExuhvoO7end7pgwBU=.866dcecb-bd21-4760-82b6-839ad052880a@github.com>

> Hi!
> 
> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
> I would be very grateful for your comments and suggestions.
> 
> Thanks!
> 
> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)

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

  documentation change and truncated instances to millis

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29140/files
  - new: https://git.openjdk.org/jdk/pull/29140/files/6c35e980..a7fd4678

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

  Stats: 44 lines in 7 files changed: 4 ins; 19 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/29140.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29140/head:pull/29140

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

From myankelevich at openjdk.org  Thu Jan 15 13:06:46 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 15 Jan 2026 13:06:46 GMT
Subject: RFR: 8286032: keytool -list -alias should not assume it is always
 a certificate
In-Reply-To: <pDbmUpIbWqEu0ePvYLXfxKrdxjmHlF_ZFb7rzDGu2s8=.cf440bba-086a-4973-82f8-3e3ee942b9cb@github.com>
References: <pDbmUpIbWqEu0ePvYLXfxKrdxjmHlF_ZFb7rzDGu2s8=.cf440bba-086a-4973-82f8-3e3ee942b9cb@github.com>
Message-ID: <2mRBv-vTNTVCNSjfZ6jruTpdZ3q7hMoTacpsvPrrmSQ=.952e4c4e-e86f-43fa-9fb3-8c4ced5287a6@github.com>

On Thu, 15 Jan 2026 10:58:10 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This fix the warnings of the keytool -list -alias for a secret key that was created with a legacy algorithm.

This looks good to me

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

PR Review: https://git.openjdk.org/jdk/pull/29250#pullrequestreview-3665512957

From abarashev at openjdk.org  Thu Jan 15 13:22:16 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 15 Jan 2026 13:22:16 GMT
Subject: Integrated: 8375183: Remove unused
 SSLConfiguration.maximumProtocolVersion variable
In-Reply-To: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
References: <UmmvmO1ua8Hol0eAhrXa_mSJAMriwA1ld7bZ6rfViN4=.e7c09374-9ccf-4879-aac2-29ae9eab2fb7@github.com>
Message-ID: <NHLREczy55HUu_EonCLFa5VUGVnC_d1KvKKc8Kt1XxA=.26abc5eb-c97b-4526-952d-2f738c9ec642@github.com>

On Tue, 13 Jan 2026 14:08:09 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> "SSLConfiguration.maximumProtocolVersion" is not being used in practice. It's used to initialize "TransportContext.protocolVersion" which is being later set to the negotiated protocol before being ever accessed.

This pull request has now been integrated.

Changeset: 78a106ff
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78a106ffbba0e056e7421ca9d77af02f9b8379d3
Stats:     20 lines in 2 files changed: 0 ins; 18 del; 2 mod

8375183: Remove unused SSLConfiguration.maximumProtocolVersion variable

Reviewed-by: djelinski, myankelevich, hchao

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

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

From adinn at openjdk.org  Thu Jan 15 14:34:54 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 15 Jan 2026 14:34:54 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions [v2]
In-Reply-To: <WAiQ07KdowulstQEiP-ObhKNXmTVRYMN888RpcudKvo=.b7e4eadc-6eb4-44d2-80f4-9935b8b56a13@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <MwtIHUJSbX80tKnY_xDYiVmFWfg_qyj6AHKyTg-1zP0=.7d180f11-0e80-4886-a37e-336f144d3787@github.com>
 <WAiQ07KdowulstQEiP-ObhKNXmTVRYMN888RpcudKvo=.b7e4eadc-6eb4-44d2-80f4-9935b8b56a13@github.com>
Message-ID: <PE18_iVA29Cj0W_q7eL2RdfZ_NW17lmOCHstnNK8QQk=.ac6a5b81-4cf2-466e-b337-908939ccfe91@github.com>

On Thu, 15 Jan 2026 10:55:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix off-by-one error discovered by Shawn
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6280:
> 
>> 6278:     vs_st2_post(vs_front(vs_front(vb)), __ T8H, parsed);
>> 6279: 
>> 6280:     __ BIND(L_end);
> 
> This is a substantial change, not a mere matter of "incorrect assertions". Perhaps this PR needs a more appropriate title.

Also, the description in the JIRA and the opening comment in this PR should mention that the intrinsic can be simplified in response to the stricter preconditions maintained by the Java client.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2694623478

From mullan at openjdk.org  Thu Jan 15 16:11:02 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 15 Jan 2026 16:11:02 GMT
Subject: RFR: 8366522: CodeSource.getCodeSigners() throws NPE within empty
 certs [v7]
In-Reply-To: <sRGSzDdqAmHt6MTeiGNZUzOcpftHcWigUVR7wz3x40s=.8e4c9574-e69f-48fd-90d9-74051510b7d8@github.com>
References: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
 <sRGSzDdqAmHt6MTeiGNZUzOcpftHcWigUVR7wz3x40s=.8e4c9574-e69f-48fd-90d9-74051510b7d8@github.com>
Message-ID: <tRirQ9qBY4_I1Uy9OKUy2etQnqZ7A2eJO6TwpWmI8qY=.b7f49c9b-9542-4e9a-83e5-e7d941e06c49@github.com>

On Mon, 12 Jan 2026 22:09:14 GMT, Kirill Shirokov <duke at openjdk.org> wrote:

>> The new tests cover only NPE scenarios.
>
> Kirill Shirokov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a typo in a comment

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27105#pullrequestreview-3666412373

From mullan at openjdk.org  Thu Jan 15 16:30:56 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 15 Jan 2026 16:30:56 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v7]
In-Reply-To: <fxpQxoernzRZw_unqS-Pj-8UxYy8QHHv-Kh3bpUXxpY=.20979ccb-b80c-4633-9bbb-1992cdf468d8@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <fxpQxoernzRZw_unqS-Pj-8UxYy8QHHv-Kh3bpUXxpY=.20979ccb-b80c-4633-9bbb-1992cdf468d8@github.com>
Message-ID: <D8iOsv3z_aVsOSG4w7Yh3o6ZRYHLv0zu_K-Ndg50-wU=.7d4e7e8c-d120-4cd8-b7ca-9dab64f1f24d@github.com>

On Wed, 14 Jan 2026 15:31:21 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to print java.security.Security properties

Please wait until someone from the Security Group reviews this.

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3755710214

From abarashev at openjdk.org  Thu Jan 15 17:40:44 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 15 Jan 2026 17:40:44 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints [v4]
In-Reply-To: <O7mQex_5qoyhEEhmzGyX2NwU1RhTtqN6hQQjnICXAjY=.e8e707f7-2c5d-45cf-9ed8-61a191152c54@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
 <SvUGi7_7e6pvwmVOec0MTv33yavtP2Ve3ixb7WanHnQ=.c3cfc626-657b-4076-ada1-3b5eae49418a@github.com>
 <O7mQex_5qoyhEEhmzGyX2NwU1RhTtqN6hQQjnICXAjY=.e8e707f7-2c5d-45cf-9ed8-61a191152c54@github.com>
Message-ID: <PbBbgMVbyHrkp7jtCVqY7Z4TioHhlkGUJzkzxbNm2GM=.3560193f-6c07-4190-b1f2-dcc8996a7aa0@github.com>

On Thu, 15 Jan 2026 10:22:58 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into JDK-8370885
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/sun/security/ssl/NamedGroup.java
>>  - Update copyright year
>>  - Merge branch 'master' into JDK-8370885
>>  - Merge branch 'master' into JDK-8370885
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/sun/security/ssl/NamedGroup.java
>>  - 8370885: Default namedGroups values are not being filtered against algorithm constraints
>
> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 799:
> 
>> 797:         // Avoid the group lookup for default and customized groups.
>> 798:         static NamedGroup[] getGroupsFromConfig(SSLConfiguration sslConfig) {
>> 799:             if (sslConfig.namedGroups == defaultNames) {
> 
> Nit: getGroupsFromConfig() can choose from pre-initialized defaultGroups, customizedGroups, or sslConfig.namedGroups. Its name sounds like it reads something directly from SSLConfiguration.

The meaning is that we are getting groups from the config being passed as a parameter, so I think the naming of this method looks fine. We just avoid needless group names lookup for defaultGroups and customizedGroups.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28397#discussion_r2695341640

From abarashev at openjdk.org  Thu Jan 15 17:51:00 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 15 Jan 2026 17:51:00 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints [v4]
In-Reply-To: <O7mQex_5qoyhEEhmzGyX2NwU1RhTtqN6hQQjnICXAjY=.e8e707f7-2c5d-45cf-9ed8-61a191152c54@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
 <SvUGi7_7e6pvwmVOec0MTv33yavtP2Ve3ixb7WanHnQ=.c3cfc626-657b-4076-ada1-3b5eae49418a@github.com>
 <O7mQex_5qoyhEEhmzGyX2NwU1RhTtqN6hQQjnICXAjY=.e8e707f7-2c5d-45cf-9ed8-61a191152c54@github.com>
Message-ID: <Xi3BCY2r9qaxOnOTtGAKPpWxNqnprrLkvPxs8FB7GDA=.8e705368-501d-4e20-b250-10da6834e2f7@github.com>

On Thu, 15 Jan 2026 10:19:33 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into JDK-8370885
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/sun/security/ssl/NamedGroup.java
>>  - Update copyright year
>>  - Merge branch 'master' into JDK-8370885
>>  - Merge branch 'master' into JDK-8370885
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/sun/security/ssl/NamedGroup.java
>>  - 8370885: Default namedGroups values are not being filtered against algorithm constraints
>
> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 780:
> 
>> 778:                 customizedGroups == null ?
>> 779:                         null : Arrays.stream(customizedGroups)
>> 780:                         .map(ng -> ng.name)
> 
> The filtering against algorithm constraints is not being done for customizedNames. Is it to preserve user?s selection and let constraints to be applied during handshake as before? It is different from defaultNames?s. Suggest to add some comments for it.

Yes, that's correct. I figured we should display the user-passed groups as-is. Adding a comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28397#discussion_r2695360055

From abarashev at openjdk.org  Thu Jan 15 17:55:31 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 15 Jan 2026 17:55:31 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints [v5]
In-Reply-To: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
Message-ID: <PU2aAvObH11_DJg7AG6A7zC3_ARudZTNr8OBXRlS6d4=.eeb70fc9-1983-432e-9657-899fdd84937f@github.com>

> NamedGroup.SupportedGroups.namedGroups values are not being filtered against algorithm constraints, unlike other SSLParameters returned by SSLConfiguration#getSSLParameters() call. Those are the values being displayed to the user with "java -XshowSettings:security:tls" command.
> 
> Also making changes to avoid needless default group names lookup while we are touching this file.

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

  Update comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28397/files
  - new: https://git.openjdk.org/jdk/pull/28397/files/00c5d6db..4eed0710

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

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

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

From weijun at openjdk.org  Thu Jan 15 18:11:14 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 Jan 2026 18:11:14 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <uLtjpxSm_9oOJqhkyASoPG9Tz_rccTerc1v6uwf9yNo=.68ff8f24-a8e0-4b39-b124-b36ca7d07776@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
 <uLtjpxSm_9oOJqhkyASoPG9Tz_rccTerc1v6uwf9yNo=.68ff8f24-a8e0-4b39-b124-b36ca7d07776@github.com>
Message-ID: <Tf3g4VZ5xTQ5EkiugzVAL-9NUsmYtV0lxCz0FK5TB78=.01c55ced-599c-432d-afca-91d25c625939@github.com>

On Mon, 12 Jan 2026 13:25:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions?
>
> At the moment doing the conversion in Java and using a bigger carrier type (like `long`) is the only possible workaround.

I don't have the expertise to confirm the correctness of that code change. @mcimadamore, are you comfortable to  include the patch for PPC64 as described in https://github.com/openjdk/jdk/pull/28931#discussion_r2662361633?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2695433254

From weijun at openjdk.org  Thu Jan 15 18:25:43 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 Jan 2026 18:25:43 GMT
Subject: RFR: 8286032: keytool -list -alias should not assume it is always
 a certificate
In-Reply-To: <pDbmUpIbWqEu0ePvYLXfxKrdxjmHlF_ZFb7rzDGu2s8=.cf440bba-086a-4973-82f8-3e3ee942b9cb@github.com>
References: <pDbmUpIbWqEu0ePvYLXfxKrdxjmHlF_ZFb7rzDGu2s8=.cf440bba-086a-4973-82f8-3e3ee942b9cb@github.com>
Message-ID: <_R_2L0fvUfFFKK2dak6Wu4-dyBtmWCBnECCEyGyJT-0=.dc432aa3-640b-4f3c-bb3a-7a785cdb1bea@github.com>

On Thu, 15 Jan 2026 10:58:10 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This fix the warnings of the keytool -list -alias for a secret key that was created with a legacy algorithm.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1297:

> 1295: 
> 1296:             if (alias != null) {
> 1297:                 doPrintEntry("<" + alias + ">", alias, out);

`doPrintEntry` is called twice and now the 1st arg is always `"<" + alias + ">"`, how about remove the parameter and add `String label = "<" + alias + ">";` as a local variable inside the method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29250#discussion_r2695484072

From duke at openjdk.org  Thu Jan 15 18:43:42 2026
From: duke at openjdk.org (duke)
Date: Thu, 15 Jan 2026 18:43:42 GMT
Subject: RFR: 8366522: CodeSource.getCodeSigners() throws NPE within empty
 certs [v7]
In-Reply-To: <sRGSzDdqAmHt6MTeiGNZUzOcpftHcWigUVR7wz3x40s=.8e4c9574-e69f-48fd-90d9-74051510b7d8@github.com>
References: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
 <sRGSzDdqAmHt6MTeiGNZUzOcpftHcWigUVR7wz3x40s=.8e4c9574-e69f-48fd-90d9-74051510b7d8@github.com>
Message-ID: <k-_81HsQSHYwKrXzx5vd_xThUQnBYWhyxrCQKghUXDY=.16ae261d-7fd5-437d-b14f-c36b616d13b7@github.com>

On Mon, 12 Jan 2026 22:09:14 GMT, Kirill Shirokov <duke at openjdk.org> wrote:

>> The new tests cover only NPE scenarios.
>
> Kirill Shirokov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a typo in a comment

@kirill-shirokov 
Your change (at version 64673e1fd3c4aeb60c736b20c9922f8a493bc8f9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27105#issuecomment-3756335850

From duke at openjdk.org  Thu Jan 15 18:54:18 2026
From: duke at openjdk.org (duke)
Date: Thu, 15 Jan 2026 18:54:18 GMT
Subject: RFR: 8366807: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_initializeLibrary of p11_general.c:106
 [v2]
In-Reply-To: <yz_HaMGWRF9ofQJWIivAryh0oKDpHXOgdars5Opdlfs=.3f69622d-7cf7-4caa-9aef-255b90f0748b@github.com>
References: <ox_PeEYD6B42hVBiEQCoxhzdxVLRJMR2BxExHLoKCRw=.63b307b8-8209-445a-abf1-cfe71fdf1abf@github.com>
 <yz_HaMGWRF9ofQJWIivAryh0oKDpHXOgdars5Opdlfs=.3f69622d-7cf7-4caa-9aef-255b90f0748b@github.com>
Message-ID: <BBiPnvw78x053FrCoDakqYToV7rr4Ol78nfavZ5BxG8=.d1971332-d7ed-4263-b6cc-287d0291c0db@github.com>

On Wed, 7 Jan 2026 22:31:24 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The method createLockObject will return NULL if any exception is thrown, but there is no NULL verification in p11_general.c after the following line is invoked
>> notifyListLock = createLockObject(env);
>> 
>> There may be a pending exception when invoking prefetchFields(env, thisClass);
>> 
>> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366807: Updated Copyright

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

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

PR Comment: https://git.openjdk.org/jdk/pull/28799#issuecomment-3756366874

From duke at openjdk.org  Thu Jan 15 18:54:21 2026
From: duke at openjdk.org (duke)
Date: Thu, 15 Jan 2026 18:54:21 GMT
Subject: RFR: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950 [v3]
In-Reply-To: <bmdNNR8d2Ihke0j0tpJE76eZTC7bBpGxc5ue0OYKWK8=.fdd93bce-b53d-4e22-855c-b9695c6acd1b@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
 <bmdNNR8d2Ihke0j0tpJE76eZTC7bBpGxc5ue0OYKWK8=.fdd93bce-b53d-4e22-855c-b9695c6acd1b@github.com>
Message-ID: <RoEqpDI59KrEwN-MhtTQjQWmcEBVwkKrc3U0uDz13ps=.6d22c3db-ef91-432d-af87-2e76f89b066f@github.com>

On Wed, 14 Jan 2026 03:48:01 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The method ckAssertReturnValueOK will invoke ckAssertReturnValueOK2 which makes multiple calls to JNI functions, such as FindClass or GetMethodID. These calls would be unsafe as there may be a pending exception at this time.
>> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367024: Addressing review comments

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

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

PR Comment: https://git.openjdk.org/jdk/pull/29054#issuecomment-3756366339

From duke at openjdk.org  Thu Jan 15 18:56:02 2026
From: duke at openjdk.org (Kirill Shirokov)
Date: Thu, 15 Jan 2026 18:56:02 GMT
Subject: Integrated: 8366522: CodeSource.getCodeSigners() throws NPE within
 empty certs
In-Reply-To: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
References: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
Message-ID: <N9MCD9hxHmQM1VwXkLwZpP3GLsqsusFpSRRO3DiPbOI=.a1fdcd61-6043-4669-a4a0-5636856047f8@github.com>

On Thu, 4 Sep 2025 16:20:18 GMT, Kirill Shirokov <duke at openjdk.org> wrote:

> The new tests cover only NPE scenarios.

This pull request has now been integrated.

Changeset: 3f01e8b9
Author:    Kirill Shirokov <kirshiro at amazon.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f01e8b9b8f68560545540f9a70391a7ff7726d0
Stats:     117 lines in 2 files changed: 115 ins; 0 del; 2 mod

8366522: CodeSource.getCodeSigners() throws NPE within empty certs

Reviewed-by: mullan

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

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

From duke at openjdk.org  Thu Jan 15 19:05:09 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 15 Jan 2026 19:05:09 GMT
Subject: Integrated: 8367024: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950
In-Reply-To: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
References: <xl2JYxa75taWw_duQDFMpeUOBUagYXpSaFyszuGq-hw=.987908b6-a08c-476b-a1a5-8f58cf0a760b@github.com>
Message-ID: <DAB9SE1GQBIuFi74X2PkJAb4XjkmqNCwV7qZPzPfEps=.1ce7cbd7-e1fa-4eef-b981-e0d09bd880c3@github.com>

On Tue, 6 Jan 2026 04:20:18 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The method ckAssertReturnValueOK will invoke ckAssertReturnValueOK2 which makes multiple calls to JNI functions, such as FindClass or GetMethodID. These calls would be unsafe as there may be a pending exception at this time.
> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.

This pull request has now been integrated.

Changeset: e97fb0e2
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e97fb0e2072a16c59014599719b64e8ea52a4976
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8367024: JNI exception pending in Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950

Reviewed-by: valeriep, hchao, djelinski

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

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

From duke at openjdk.org  Thu Jan 15 19:07:48 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 15 Jan 2026 19:07:48 GMT
Subject: Integrated: 8366807: JNI exception pending in
 Java_sun_security_pkcs11_wrapper_PKCS11_initializeLibrary of p11_general.c:106
In-Reply-To: <ox_PeEYD6B42hVBiEQCoxhzdxVLRJMR2BxExHLoKCRw=.63b307b8-8209-445a-abf1-cfe71fdf1abf@github.com>
References: <ox_PeEYD6B42hVBiEQCoxhzdxVLRJMR2BxExHLoKCRw=.63b307b8-8209-445a-abf1-cfe71fdf1abf@github.com>
Message-ID: <1jG4WBdehekJO7WUsYcWbCGf9GdZM-RjOmQKCVMG0nk=.edeea9dd-daa8-4ed1-bfd8-3696649efb00@github.com>

On Fri, 12 Dec 2025 18:46:52 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The method createLockObject will return NULL if any exception is thrown, but there is no NULL verification in p11_general.c after the following line is invoked
> notifyListLock = createLockObject(env);
> 
> There may be a pending exception when invoking prefetchFields(env, thisClass);
> 
> So adding exception check to return immediately and do not call any further JNI functions when there is exception pending.

This pull request has now been integrated.

Changeset: 25c834a8
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25c834a897ac0cac94942a019c9e377a53851f2c
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8366807: JNI exception pending in Java_sun_security_pkcs11_wrapper_PKCS11_initializeLibrary of p11_general.c:106

Reviewed-by: valeriep

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

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

From hchao at openjdk.org  Thu Jan 15 21:12:25 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 15 Jan 2026 21:12:25 GMT
Subject: RFR: 8286032: keytool -list -alias should not assume it is always
 a certificate [v2]
In-Reply-To: <pDbmUpIbWqEu0ePvYLXfxKrdxjmHlF_ZFb7rzDGu2s8=.cf440bba-086a-4973-82f8-3e3ee942b9cb@github.com>
References: <pDbmUpIbWqEu0ePvYLXfxKrdxjmHlF_ZFb7rzDGu2s8=.cf440bba-086a-4973-82f8-3e3ee942b9cb@github.com>
Message-ID: <YgwnWOG_k3VLjZ0w7kOr14Sp_H9rYPJlcdFoLrCuDPU=.d87c2262-dfb3-4d5b-9496-d1ccc28d6006@github.com>

> This fix the warnings of the keytool -list -alias for a secret key that was created with a legacy algorithm.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Update with Weijun's comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29250/files
  - new: https://git.openjdk.org/jdk/pull/29250/files/8a528500..06ef1f7c

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

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

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

From weijun at openjdk.org  Thu Jan 15 22:10:13 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 Jan 2026 22:10:13 GMT
Subject: RFR: 8286032: keytool -list -alias should not assume it is always
 a certificate [v2]
In-Reply-To: <YgwnWOG_k3VLjZ0w7kOr14Sp_H9rYPJlcdFoLrCuDPU=.d87c2262-dfb3-4d5b-9496-d1ccc28d6006@github.com>
References: <pDbmUpIbWqEu0ePvYLXfxKrdxjmHlF_ZFb7rzDGu2s8=.cf440bba-086a-4973-82f8-3e3ee942b9cb@github.com>
 <YgwnWOG_k3VLjZ0w7kOr14Sp_H9rYPJlcdFoLrCuDPU=.d87c2262-dfb3-4d5b-9496-d1ccc28d6006@github.com>
Message-ID: <iC1GmZMAGKrG55zE44h9BZBtyLHWwNe3Zm1jACSvtB8=.d30bde2d-1822-4222-95c5-e08651fa2ba7@github.com>

On Thu, 15 Jan 2026 21:12:25 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This fix the warnings of the keytool -list -alias for a secret key that was created with a legacy algorithm.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update with Weijun's comment

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29250#pullrequestreview-3667821946

From jnimeh at openjdk.org  Thu Jan 15 22:30:31 2026
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 15 Jan 2026 22:30:31 GMT
Subject: RFR: 8371333: Optimize static initialization of SSLContextImpl
 classes and improve logging [v4]
In-Reply-To: <a_Gt-yWgJ2fur8MDhAlAElHjUDS5Z-RMYKna2eL57Mk=.d08c5a20-a3e0-47ff-8ad4-61613f578dca@github.com>
References: <TZF1SzuB8Pps8O10qrKtOXRrGWWyiGxSFqfZVjvUj0I=.4de2e8f8-bc38-49c7-96bc-8205118c7fc7@github.com>
 <a_Gt-yWgJ2fur8MDhAlAElHjUDS5Z-RMYKna2eL57Mk=.d08c5a20-a3e0-47ff-8ad4-61613f578dca@github.com>
Message-ID: <Wdx3EX2smFzLu-eiOw0nYEHiqpNKkM4NyTWul7Oa75c=.59c1aebe-42f0-4204-88fb-bc8c0c59b56a@github.com>

On Fri, 9 Jan 2026 11:24:26 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Introduce lazy static initialization logic to SSLContextImpl via use of the new LazyConstant API and improve logging output
>> 
>> As per JBS comments:
>> 
>> * Each subclass of AbstractTLSContext (TLSv10. TLSv11 etc) is being initialization at framework initialization time due to the getApplicableSupportedCipherSuites(..) calls made in static block. Such calls are unnecessary if the subclass isn't required. This is especially true for the default JDK configuration where TLSv10, TLSv11 protocols are disabled. I've moved logic to lazy initialization of these fields via LazyConstant
>> 
>> * The debug prints output never made clear what protocol version each cipher suite was being disabled for. Improved logging there
>> * The debug prints never printed out the resulting set of enabled/allowed cipher suites
>> 
>> There's efficiency gain also in having one less call to the getApplicableEnabledCipherSuites method in the scenario where customized cipher suites are not in use.
>> 
>> example of new debug output:
>> 
>> 
>> javax.net.ssl|TRACE|30|main|2025-11-26 14:31:31.997 GMT|SSLContextImpl.java:425|Ignore disabled cipher suites for protocols:[TLSv1.3, TLSv1.2]
>> [TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
>> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384
>> TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA
>> TLS_RSA_WITH_AES_128_CBC_SHA]
>> javax.net.ssl|TRACE|30|main|2025-11-26 14:31:31.997 GMT|SSLContextImpl.java:425|Available cipher suites for protocols:[TLSv1.3, TLSv1.2]
>> [TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SH...
>
> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Incorportate comments from Jamil
>  - Merge branch 'master' into 8371333-ssl-debug
>  - Merge branch 'master' into 8371333-ssl-debug
>  - Move wrapText method to Utilities
>  - Merge branch 'master' into 8371333-ssl-debug
>  - use LINE_SEP
>  - 8371333

Looks good

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

Marked as reviewed by jnimeh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28511#pullrequestreview-3667899312

From hchao at openjdk.org  Thu Jan 15 22:37:05 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 15 Jan 2026 22:37:05 GMT
Subject: RFR: 8286032: keytool -list -alias should not assume it is always
 a certificate [v2]
In-Reply-To: <2mRBv-vTNTVCNSjfZ6jruTpdZ3q7hMoTacpsvPrrmSQ=.952e4c4e-e86f-43fa-9fb3-8c4ced5287a6@github.com>
References: <pDbmUpIbWqEu0ePvYLXfxKrdxjmHlF_ZFb7rzDGu2s8=.cf440bba-086a-4973-82f8-3e3ee942b9cb@github.com>
 <2mRBv-vTNTVCNSjfZ6jruTpdZ3q7hMoTacpsvPrrmSQ=.952e4c4e-e86f-43fa-9fb3-8c4ced5287a6@github.com>
Message-ID: <fmlgx9aIWYVb79EYva68vHNuiC4ETRu_zfHcuIIYYQE=.594afe7d-1944-4c7e-9153-2469a9a81f8f@github.com>

On Thu, 15 Jan 2026 13:03:08 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update with Weijun's comment
>
> This looks good to me

@myankelev @wangweij Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/29250#issuecomment-3757209576

From hchao at openjdk.org  Thu Jan 15 22:37:09 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 15 Jan 2026 22:37:09 GMT
Subject: Integrated: 8286032: keytool -list -alias should not assume it is
 always a certificate
In-Reply-To: <pDbmUpIbWqEu0ePvYLXfxKrdxjmHlF_ZFb7rzDGu2s8=.cf440bba-086a-4973-82f8-3e3ee942b9cb@github.com>
References: <pDbmUpIbWqEu0ePvYLXfxKrdxjmHlF_ZFb7rzDGu2s8=.cf440bba-086a-4973-82f8-3e3ee942b9cb@github.com>
Message-ID: <JCuO8BCdM02KItRH-s-bfM1qE9MBz68LbMhx2cVVCgk=.c7a2bf6b-9ac4-487b-8fe0-28bdc385a1dd@github.com>

On Thu, 15 Jan 2026 10:58:10 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This fix the warnings of the keytool -list -alias for a secret key that was created with a legacy algorithm.

This pull request has now been integrated.

Changeset: a1b039aa
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1b039aa989ca91b6e70962363f720f581c5bfaf
Stats:     83 lines in 3 files changed: 72 ins; 0 del; 11 mod

8286032: keytool -list -alias should not assume it is always a certificate

Reviewed-by: weijun

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

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

From lmesnik at openjdk.org  Thu Jan 15 23:02:23 2026
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 15 Jan 2026 23:02:23 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v7]
In-Reply-To: <fxpQxoernzRZw_unqS-Pj-8UxYy8QHHv-Kh3bpUXxpY=.20979ccb-b80c-4633-9bbb-1992cdf468d8@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <fxpQxoernzRZw_unqS-Pj-8UxYy8QHHv-Kh3bpUXxpY=.20979ccb-b80c-4633-9bbb-1992cdf468d8@github.com>
Message-ID: <dpc56DVRmXq1MK9XseCzSoQLOqCYtP4Tiz9quTsy7r4=.40e8ad2f-c19a-435f-859d-c223bbb38365@github.com>

On Wed, 14 Jan 2026 15:31:21 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to print java.security.Security properties

This fix requires test for new added functionality.

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

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3757287652

From mdoerr at openjdk.org  Thu Jan 15 23:11:02 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 15 Jan 2026 23:11:02 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <Tf3g4VZ5xTQ5EkiugzVAL-9NUsmYtV0lxCz0FK5TB78=.01c55ced-599c-432d-afca-91d25c625939@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
 <uLtjpxSm_9oOJqhkyASoPG9Tz_rccTerc1v6uwf9yNo=.68ff8f24-a8e0-4b39-b124-b36ca7d07776@github.com>
 <Tf3g4VZ5xTQ5EkiugzVAL-9NUsmYtV0lxCz0FK5TB78=.01c55ced-599c-432d-afca-91d25c625939@github.com>
Message-ID: <un--qP6HOPN7VyxKxZLIUwJbVHgZbqZ_dwQYYbdF004=.4dee79fb-20f2-47ef-8965-a1e01e0e30c5@github.com>

On Thu, 15 Jan 2026 18:06:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> At the moment doing the conversion in Java and using a bigger carrier type (like `long`) is the only possible workaround.
>
> I don't have the expertise to confirm the correctness of that code change. @mcimadamore, are you comfortable to  include the patch for PPC64 as described in https://github.com/openjdk/jdk/pull/28931#discussion_r2662361633?

For reference: hotspot uses the platform dependent constant `CCallingConventionRequiresIntsAsLongs`  for such issues. The value is `true` on PPC64 and s390 platforms (and SPARC in earlier JDK versions).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2696282888

From duke at openjdk.org  Fri Jan 16 00:55:46 2026
From: duke at openjdk.org (Roger Calnan)
Date: Fri, 16 Jan 2026 00:55:46 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
Message-ID: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>

adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option

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

Commit messages:
 - add anchors to the command line options
 - Update full name

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

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

From weijun at openjdk.org  Fri Jan 16 18:05:55 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Jan 2026 18:05:55 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
In-Reply-To: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
Message-ID: <Puv816hROYv1OHONzyE5ihr_IciMEFJxRktr12G9csE=.c360c499-2e81-4619-bd53-ac209a710f69@github.com>

On Fri, 16 Jan 2026 00:46:48 GMT, Roger Calnan <duke at openjdk.org> wrote:

> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option

Looks good. Some might not be necessary.

src/java.base/share/man/keytool.md line 1591:

> 1589: The command creates the keystore named `mykeystore` in the working directory
> 1590: (provided it doesn't already exist), and assigns it the password specified by
> 1591: [`-keypass`]{#-keypass}. It generates a public/private key pair for the entity whose

I'd rather not giving this an anchor. It just happens to be mentioned here. It's not the formal spec for it.

src/java.base/share/man/keytool.md line 2366:

> 2364: that don't conform to the standard might be rejected by the JDK or other
> 2365: applications. Users should ensure that they provide the correct options for
> 2366: [`-dname`]{#-dname}, `-ext`, and so on.

Same for this one. No need to add an anchor here.

src/jdk.jartool/share/man/jarsigner.md line 800:

> 798:     path-separator character.
> 799: 
> 800: [`-J`]{#-J}*javaoption*

Maybe this one is not necessary. It's a general option for extra VM options.

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

PR Review: https://git.openjdk.org/jdk/pull/29258#pullrequestreview-3672060086
PR Review Comment: https://git.openjdk.org/jdk/pull/29258#discussion_r2699459977
PR Review Comment: https://git.openjdk.org/jdk/pull/29258#discussion_r2699461011
PR Review Comment: https://git.openjdk.org/jdk/pull/29258#discussion_r2699471280

From duke at openjdk.org  Fri Jan 16 18:53:04 2026
From: duke at openjdk.org (Roger Calnan)
Date: Fri, 16 Jan 2026 18:53:04 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v2]
In-Reply-To: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
Message-ID: <DGvH5UyBxpE2Q_aN4PNtPCA42uXU-79iQji8eeAvdAo=.2a57b77e-7d11-4c53-b758-2229b7590e36@github.com>

> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option

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

  updates from feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29258/files
  - new: https://git.openjdk.org/jdk/pull/29258/files/c159e3ab..f6f21177

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

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

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

From duke at openjdk.org  Fri Jan 16 18:53:07 2026
From: duke at openjdk.org (Roger Calnan)
Date: Fri, 16 Jan 2026 18:53:07 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v2]
In-Reply-To: <Puv816hROYv1OHONzyE5ihr_IciMEFJxRktr12G9csE=.c360c499-2e81-4619-bd53-ac209a710f69@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
 <Puv816hROYv1OHONzyE5ihr_IciMEFJxRktr12G9csE=.c360c499-2e81-4619-bd53-ac209a710f69@github.com>
Message-ID: <n8aoFo6FozswsTtbT-3YHgy9xOQxjTIPVXBPAe03XVo=.0d730862-f2e4-41d1-b375-d4961871e7c5@github.com>

On Fri, 16 Jan 2026 17:56:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Roger Calnan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates from feedback
>
> src/java.base/share/man/keytool.md line 1591:
> 
>> 1589: The command creates the keystore named `mykeystore` in the working directory
>> 1590: (provided it doesn't already exist), and assigns it the password specified by
>> 1591: [`-keypass`]{#-keypass}. It generates a public/private key pair for the entity whose
> 
> I'd rather not giving this an anchor. It just happens to be mentioned here. It's not the formal spec for it.

yes, that is a mistake removed

> src/java.base/share/man/keytool.md line 2366:
> 
>> 2364: that don't conform to the standard might be rejected by the JDK or other
>> 2365: applications. Users should ensure that they provide the correct options for
>> 2366: [`-dname`]{#-dname}, `-ext`, and so on.
> 
> Same for this one. No need to add an anchor here.

removed

> src/jdk.jartool/share/man/jarsigner.md line 800:
> 
>> 798:     path-separator character.
>> 799: 
>> 800: [`-J`]{#-J}*javaoption*
> 
> Maybe this one is not necessary. It's a general option for extra VM options.

removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29258#discussion_r2699612707
PR Review Comment: https://git.openjdk.org/jdk/pull/29258#discussion_r2699613094
PR Review Comment: https://git.openjdk.org/jdk/pull/29258#discussion_r2699611754

From mullan at openjdk.org  Fri Jan 16 20:47:09 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 16 Jan 2026 20:47:09 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v3]
In-Reply-To: <T6FtMYRrRheMiPrmRvzxeBYShaExuhvoO7end7pgwBU=.866dcecb-bd21-4760-82b6-839ad052880a@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <T6FtMYRrRheMiPrmRvzxeBYShaExuhvoO7end7pgwBU=.866dcecb-bd21-4760-82b6-839ad052880a@github.com>
Message-ID: <1tvWhMwklLj6sfT19vMjSKsWymiAf9sOCEf6paTp4lc=.0b716040-2bdb-49c2-a49e-a422f47e808f@github.com>

On Thu, 15 Jan 2026 11:29:05 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Hi!
>> 
>> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
>> I would be very grateful for your comments and suggestions.
>> 
>> Thanks!
>> 
>> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation change and truncated instances to millis

src/java.base/share/classes/java/security/KeyStore.java line 1210:

> 1208:     /**
> 1209:      * Returns the creation {@code Instant} value
> 1210:      * of the entry identified by the given alias.

I would probably rephrase this as "Returns the instant that the entry identified by the given alias was created."
I don't think you need to put instant in code font as other methods that return instants do not do that.

src/java.base/share/classes/java/security/KeyStore.java line 1215:

> 1213:      *
> 1214:      * @return the creation instant of this entry, or {@code null} if the given
> 1215:      * alias does not exist

Suggest similar rewording as above, i.e. "the instant that the entry identified by the given alias was created, or {@code null} if the given alias does not exist"

src/java.base/share/classes/java/security/KeyStoreSpi.java line 133:

> 131:     /**
> 132:      * Returns the creation {@code Instant} value
> 133:      * of the entry identified by the given alias.

Same comment on the wording as in `KeyStore.getCreationInstant`.

src/java.base/share/classes/java/security/KeyStoreSpi.java line 137:

> 135:      * @implSpec
> 136:      * The default implementation calls {@code engineGetCreationDate(alias)}
> 137:      * and returns the output as an {@code Instant} value.

Suggest you add something like "Subclasses should override this method to directly return an instant."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2699898772
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2699899247
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2699914585
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2699913353

From duke at openjdk.org  Fri Jan 16 22:50:12 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 16 Jan 2026 22:50:12 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v4]
In-Reply-To: <IDULCOeuqXv0x51xZNCckEuz15kBikJEDAVHO2ruuC8=.52018b85-8abf-46e4-84f6-b148a1ffa7ed@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
 <Qq1hD_zx6FsvunA2HDp8-Oa9YDSOAZDKK-M2ObSyAEY=.21bda4b0-3186-4e85-9e49-bb70e69b3c33@github.com>
 <htQOcf4BCZXgh3P3FoMBou09Zhcg4deRYuu8DHLDtWc=.b2247e7f-b41b-461f-b3d0-73737f52b535@github.com>
 <28KSbLDo353fDhRsW-5aaLpYvQ9XGPnyOqO1YN_LnPs=.eaa3ddbf-9228-4fce-a973-dda88d5abf75@github.com>
 <GHlrs3IAFzOaPIWNo8cmK9yXd2cGwEcsM9SzbwvKJrU=.ee4699ee-b835-4c84-b18c-1775376ce43c@github.com>
 <IDULCOeuqXv0x51xZNCckEuz15kBikJEDAVHO2ruuC8=.52018b85-8abf-46e4-84f6-b148a1ffa7ed@github.com>
Message-ID: <mNPAnLviKyDySNCk-gsDFEzhL9KxDSe7Sv5M7yYwrbc=.f22c20c8-7115-4da0-a76c-ad7a9cfa97ac@github.com>

On Sun, 11 Jan 2026 09:33:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Just a note on LoopAlignment, there are multiple moving parts here, first aligning starting addresses of loop to 64 ([recommendation from Zen5 optimization guide](https://docs.amd.com/v/u/en-US/58455_1.00) section 2.8.3) ensure small loop bodies are not split-across the cache line, if that happens then there is a cold entry penalty in the first iteration of loop, where front-end will have to read multiple L1I cache lines, once its decoded and uops are part of Op-cache (AMD) or DSB (Intel). There onwards uops stream for successive loop iterations are issued from op-cache. Since op-cache is shared b/w 2 HW threads in SMT configuration hence in case of noisy neighbor scenarios or context-switches we may hit cold-entry penalty during lifetime of loop. 
>> 
>> So its advisable to add alignment in this case for other labels before loops we already have OptoLoopAlignment in place.
>
>> > Better to align loop sarting address to OptoLoopAlignment
>> 
>> For parity, should I do this for the other labels in the file as well?
>> 
>> > I will run the micro benchmark on AMD Turin and report back by early next week.
>> 
>> That would be great, thank you for doing this!
> 
> Here are the score on Turin.
> 
> 
> Baseline:
> Benchmark                                    (algorithm)  (keyLength)  (provider)   Mode  Cnt      Score   Error  Units
> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-512            0              thrpt    2  62235.790          ops/s
> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-768            0              thrpt    2  38238.390          ops/s
> KeyPairGeneratorBench.MLKEM.generateKeyPair  ML-KEM-1024            0              thrpt    2  24725.512          ops/s
> 
> Withopt:
> Benchmark                                    (algorithm)  (keyLength)  (provider)   Mode  Cnt      Score   Error  Units
> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-512            0              thrpt    2  62483.697          ops/s
> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-768            0              thrpt    2  38464.272          ops/s
> KeyPairGeneratorBench.MLKEM.generateKeyPair  ML-KEM-1024            0              thrpt    2  24702.044          ops/s
> 
> 
> 
> Baseline:
> Benchmark             (algorithm)  (provider)   Mode  Cnt      Score   Error  Units
> KEMBench.decapsulate   ML-KEM-512              thrpt    2  46416.479          ops/s
> KEMBench.decapsulate   ML-KEM-768              thrpt    2  28516.289          ops/s
> KEMBench.decapsulate  ML-KEM-1024              thrpt    2  19250.020          ops/s
> KEMBench.encapsulate   ML-KEM-512              thrpt    2  60374.724          ops/s
> KEMBench.encapsulate   ML-KEM-768              thrpt    2  36226.100          ops/s
> KEMBench.encapsulate  ML-KEM-1024              thrpt    2  23656.223          ops/s
> 
> Withopt:
> Benchmark             (algorithm)  (provider)   Mode  Cnt      Score   Error  Units
> KEMBench.decapsulate   ML-KEM-512              thrpt    2  46730.153          ops/s
> KEMBench.decapsulate   ML-KEM-768              thrpt    2  28650.349          ops/s
> KEMBench.decapsulate  ML-KEM-1024              thrpt    2  19390.927          ops/s
> KEMBench.encapsulate   ML-KEM-512              thrpt    2  60238.211          ops/s
> KEMBench.encapsulate   ML-KEM-768              thrpt    2  36454.138          ops/s
> KEMBench.encapsulate  ML-KEM-1024              thrpt    2  23649.839          ops/s
> 
> 
> System was...

@jatin-bhateja are there any outstanding issues with this PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2700237409

From jbhateja at openjdk.org  Sat Jan 17 05:58:30 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 17 Jan 2026 05:58:30 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v5]
In-Reply-To: <yD21sqxEcOTPTN56PzOqIEsQBKHOeVJy8-hMGmJRirU=.27ca3b7a-123d-4585-97f1-38844a579eb5@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <yD21sqxEcOTPTN56PzOqIEsQBKHOeVJy8-hMGmJRirU=.27ca3b7a-123d-4585-97f1-38844a579eb5@github.com>
Message-ID: <ID4WyowkL5C2pq1EMckvN1RE_pqZ5Ex1qa4WJB0mUwY=.5e7022c7-6868-4eb3-af6c-0b8163262112@github.com>

On Sun, 11 Jan 2026 06:59:20 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> This change allows use of the AVX512_VBMI instruction set to further optimize decompression/parsing of polynomial coefficients for ML-KEM.  The speedup gained in the ML-KEM benchmarks for key generation is between 0.4 to 0.5%, encapsulation is  0.2 to 1.7%, and decapsulation is 0.3 to 2.0%.
>> 
>> Thank you to @sviswa7 and @ferakocz for their help in working through the early stages of this code with me.
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to use OptoLoopAlignment for VBMILoop

Marked as reviewed by jbhateja (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28815#pullrequestreview-3673509627

From jbhateja at openjdk.org  Sat Jan 17 05:58:30 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 17 Jan 2026 05:58:30 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v4]
In-Reply-To: <mNPAnLviKyDySNCk-gsDFEzhL9KxDSe7Sv5M7yYwrbc=.f22c20c8-7115-4da0-a76c-ad7a9cfa97ac@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
 <Qq1hD_zx6FsvunA2HDp8-Oa9YDSOAZDKK-M2ObSyAEY=.21bda4b0-3186-4e85-9e49-bb70e69b3c33@github.com>
 <htQOcf4BCZXgh3P3FoMBou09Zhcg4deRYuu8DHLDtWc=.b2247e7f-b41b-461f-b3d0-73737f52b535@github.com>
 <28KSbLDo353fDhRsW-5aaLpYvQ9XGPnyOqO1YN_LnPs=.eaa3ddbf-9228-4fce-a973-dda88d5abf75@github.com>
 <GHlrs3IAFzOaPIWNo8cmK9yXd2cGwEcsM9SzbwvKJrU=.ee4699ee-b835-4c84-b18c-1775376ce43c@github.com>
 <IDULCOeuqXv0x51xZNCckEuz15kBikJEDAVHO2ruuC8=.52018b85-8abf-46e4-84f6-b148a1ffa7ed@github.com>
 <mNPAnLviKyDySNCk-gsDFEzhL9KxDSe7Sv5M7yYwrbc=.f22c20c8-7115-4da0-a76c-ad7a9cfa97ac@github.com>
Message-ID: <m8l_fMLy0VsPzfEeKQudcUPPnpa8JnErs9HVFnyoZFM=.c447f800-aba2-4ab6-93a2-e88d522ab70f@github.com>

On Fri, 16 Jan 2026 22:46:33 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>>> > Better to align loop sarting address to OptoLoopAlignment
>>> 
>>> For parity, should I do this for the other labels in the file as well?
>>> 
>>> > I will run the micro benchmark on AMD Turin and report back by early next week.
>>> 
>>> That would be great, thank you for doing this!
>> 
>> Here are the score on Turin.
>> 
>> 
>> Baseline:
>> Benchmark                                    (algorithm)  (keyLength)  (provider)   Mode  Cnt      Score   Error  Units
>> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-512            0              thrpt    2  62235.790          ops/s
>> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-768            0              thrpt    2  38238.390          ops/s
>> KeyPairGeneratorBench.MLKEM.generateKeyPair  ML-KEM-1024            0              thrpt    2  24725.512          ops/s
>> 
>> Withopt:
>> Benchmark                                    (algorithm)  (keyLength)  (provider)   Mode  Cnt      Score   Error  Units
>> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-512            0              thrpt    2  62483.697          ops/s
>> KeyPairGeneratorBench.MLKEM.generateKeyPair   ML-KEM-768            0              thrpt    2  38464.272          ops/s
>> KeyPairGeneratorBench.MLKEM.generateKeyPair  ML-KEM-1024            0              thrpt    2  24702.044          ops/s
>> 
>> 
>> 
>> Baseline:
>> Benchmark             (algorithm)  (provider)   Mode  Cnt      Score   Error  Units
>> KEMBench.decapsulate   ML-KEM-512              thrpt    2  46416.479          ops/s
>> KEMBench.decapsulate   ML-KEM-768              thrpt    2  28516.289          ops/s
>> KEMBench.decapsulate  ML-KEM-1024              thrpt    2  19250.020          ops/s
>> KEMBench.encapsulate   ML-KEM-512              thrpt    2  60374.724          ops/s
>> KEMBench.encapsulate   ML-KEM-768              thrpt    2  36226.100          ops/s
>> KEMBench.encapsulate  ML-KEM-1024              thrpt    2  23656.223          ops/s
>> 
>> Withopt:
>> Benchmark             (algorithm)  (provider)   Mode  Cnt      Score   Error  Units
>> KEMBench.decapsulate   ML-KEM-512              thrpt    2  46730.153          ops/s
>> KEMBench.decapsulate   ML-KEM-768              thrpt    2  28650.349          ops/s
>> KEMBench.decapsulate  ML-KEM-1024              thrpt    2  19390.927          ops/s
>> KEMBench.encapsulate   ML-KEM-512              thrpt    2  60238.211          ops/s
>> KEMBench.encapsulate   ML-KEM-768              thrpt    2  36454.138          ops/s
>> KEMBench.encapsulat...
>
> @jatin-bhateja are there any outstanding issues with this PR?

Thanks for the sharp details and analysis.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2700672393

From duke at openjdk.org  Sat Jan 17 06:08:33 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Sat, 17 Jan 2026 06:08:33 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v4]
In-Reply-To: <m8l_fMLy0VsPzfEeKQudcUPPnpa8JnErs9HVFnyoZFM=.c447f800-aba2-4ab6-93a2-e88d522ab70f@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <-zQuk2uNHFvht7KASCP7OUrLploN8tVFFAldVmkzcuo=.0249f1ba-e2c9-4b33-b438-4fb7f2edf4c6@github.com>
 <Qq1hD_zx6FsvunA2HDp8-Oa9YDSOAZDKK-M2ObSyAEY=.21bda4b0-3186-4e85-9e49-bb70e69b3c33@github.com>
 <htQOcf4BCZXgh3P3FoMBou09Zhcg4deRYuu8DHLDtWc=.b2247e7f-b41b-461f-b3d0-73737f52b535@github.com>
 <28KSbLDo353fDhRsW-5aaLpYvQ9XGPnyOqO1YN_LnPs=.eaa3ddbf-9228-4fce-a973-dda88d5abf75@github.com>
 <GHlrs3IAFzOaPIWNo8cmK9yXd2cGwEcsM9SzbwvKJrU=.ee4699ee-b835-4c84-b18c-1775376ce43c@github.com>
 <IDULCOeuqXv0x51xZNCckEuz15kBikJEDAVHO2ruuC8=.52018b85-8abf-46e4-84f6-b148a1ffa7ed@github.com>
 <mNPAnLviKyDySNCk-gsDFEzhL9KxDSe7Sv5M7yYwrbc=.f22c20c8-7115-4da0-a76c-ad7a9cfa97ac@github.com>
 <m8l_fMLy0VsPzfEeKQudcUPPnpa8JnErs9HVFnyoZFM=.c447f800-aba2-4ab6-93a2-e88d522ab70f@github.com>
Message-ID: <G6dYiSiAiOLVNpVCh3FhWc-tQ30g6adigt61B9ofgas=.f8ce0ac3-a960-46c0-bc4d-a4e09d64dde1@github.com>

On Sat, 17 Jan 2026 05:54:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> @jatin-bhateja are there any outstanding issues with this PR?
>
> Thanks for the sharp details and analysis.

Thank you for your comments and review @jatin-bhateja.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28815#discussion_r2700677869

From duke at openjdk.org  Sat Jan 17 06:28:25 2026
From: duke at openjdk.org (duke)
Date: Sat, 17 Jan 2026 06:28:25 GMT
Subject: RFR: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on
 AVX512_VBMI [v5]
In-Reply-To: <yD21sqxEcOTPTN56PzOqIEsQBKHOeVJy8-hMGmJRirU=.27ca3b7a-123d-4585-97f1-38844a579eb5@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
 <yD21sqxEcOTPTN56PzOqIEsQBKHOeVJy8-hMGmJRirU=.27ca3b7a-123d-4585-97f1-38844a579eb5@github.com>
Message-ID: <pEZe-gj0WYSDq18BNA2TtWpz7tuwYvwf8YqZKM_0Pv0=.1d6a9804-9fca-4c8a-8e83-3fd433088cb6@github.com>

On Sun, 11 Jan 2026 06:59:20 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> This change allows use of the AVX512_VBMI instruction set to further optimize decompression/parsing of polynomial coefficients for ML-KEM.  The speedup gained in the ML-KEM benchmarks for key generation is between 0.4 to 0.5%, encapsulation is  0.2 to 1.7%, and decapsulation is 0.3 to 2.0%.
>> 
>> Thank you to @sviswa7 and @ferakocz for their help in working through the early stages of this code with me.
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to use OptoLoopAlignment for VBMILoop

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

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

PR Comment: https://git.openjdk.org/jdk/pull/28815#issuecomment-3762780881

From duke at openjdk.org  Sat Jan 17 11:11:21 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Sat, 17 Jan 2026 11:11:21 GMT
Subject: Integrated: 8360934: Add AVX-512 intrinsics for ML-KEM - enhancement
 on AVX512_VBMI
In-Reply-To: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
References: <kFzfntHdsZYMKtkqniNWOABxiunKVLH0Wa-lG-UGgWs=.5d06a528-0ee6-491b-8c07-8e807aeebf7c@github.com>
Message-ID: <WrMysxKKJ5MkxNXRsdO0G8DcXkKclnuD3UeuKzYZaQs=.f5ffce3a-396d-4846-9f65-6cdab23a5459@github.com>

On Sun, 14 Dec 2025 04:56:39 GMT, Shawn M Emery <duke at openjdk.org> wrote:

> This change allows use of the AVX512_VBMI instruction set to further optimize decompression/parsing of polynomial coefficients for ML-KEM.  The speedup gained in the ML-KEM benchmarks for key generation is between 0.4 to 0.5%, encapsulation is  0.2 to 1.7%, and decapsulation is 0.3 to 2.0%.
> 
> Thank you to @sviswa7 and @ferakocz for their help in working through the early stages of this code with me.

This pull request has now been integrated.

Changeset: a0e6f028
Author:    Shawn M Emery <shawn.emery at oracle.com>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0e6f028a8952f61d9115f7bdf04b8a87f8ebba4
Stats:     90 lines in 1 file changed: 88 ins; 0 del; 2 mod

8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI

Co-authored-by: Sandhya Viswanathan <sviswanathan at openjdk.org>
Reviewed-by: jbhateja, vpaprotski

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

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

From weijun at openjdk.org  Sat Jan 17 15:05:25 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 17 Jan 2026 15:05:25 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v2]
In-Reply-To: <DGvH5UyBxpE2Q_aN4PNtPCA42uXU-79iQji8eeAvdAo=.2a57b77e-7d11-4c53-b758-2229b7590e36@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
 <DGvH5UyBxpE2Q_aN4PNtPCA42uXU-79iQji8eeAvdAo=.2a57b77e-7d11-4c53-b758-2229b7590e36@github.com>
Message-ID: <x1XvgmtUm2XsKfQ2QT8n5cbA83hqiqKs2-H85NNDs1c=.1ad30dfc-850e-4ecb-a1a9-707821ec5030@github.com>

On Fri, 16 Jan 2026 18:53:04 GMT, Roger Calnan <duke at openjdk.org> wrote:

>> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option
>
> Roger Calnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates from feedback

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29258#pullrequestreview-3674194823

From azeller at openjdk.org  Mon Jan 19 08:40:50 2026
From: azeller at openjdk.org (Arno Zeller)
Date: Mon, 19 Jan 2026 08:40:50 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
Message-ID: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>

This pull request is a clean backport of [JDK-8371559](https://bugs.openjdk.org/browse/JDK-8371559). 
It is a test only change.

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

Commit messages:
 - Backport af18fbd42d2a437dd35f33e557a8906ca0c3bd07

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

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

From myankelevich at openjdk.org  Mon Jan 19 09:43:16 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 19 Jan 2026 09:43:16 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
Message-ID: <YcaWjq7ZdxRBq26b7TeFa0YYvmD4S7ggSvWG-e2q8Rk=.451d9f22-d772-4e06-a978-13264e9f5de6@github.com>

On Mon, 19 Jan 2026 08:33:02 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> This pull request is a clean backport of [JDK-8371559](https://bugs.openjdk.org/browse/JDK-8371559). 
> It is a test only change.

This looks good, but wouldn't it make more sense to just add this fix to [26u](https://wiki.openjdk.org/spaces/JDKUpdates/pages/191168551/JDK+26u)?

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

PR Review: https://git.openjdk.org/jdk/pull/29294#pullrequestreview-3677177005

From myankelevich at openjdk.org  Mon Jan 19 10:18:43 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 19 Jan 2026 10:18:43 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v4]
In-Reply-To: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
Message-ID: <Ts-nn4n_cXWYwApR0zoHzW-_cqh5H5N0YcUdU22wrK4=.c06e1c20-7a85-4e43-ad5d-ade11f7827fc@github.com>

> Hi!
> 
> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
> I would be very grateful for your comments and suggestions.
> 
> Thanks!
> 
> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)

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

  Sean's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29140/files
  - new: https://git.openjdk.org/jdk/pull/29140/files/a7fd4678..940ec507

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

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

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

From myankelevich at openjdk.org  Mon Jan 19 10:18:45 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 19 Jan 2026 10:18:45 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v3]
In-Reply-To: <1tvWhMwklLj6sfT19vMjSKsWymiAf9sOCEf6paTp4lc=.0b716040-2bdb-49c2-a49e-a422f47e808f@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <T6FtMYRrRheMiPrmRvzxeBYShaExuhvoO7end7pgwBU=.866dcecb-bd21-4760-82b6-839ad052880a@github.com>
 <1tvWhMwklLj6sfT19vMjSKsWymiAf9sOCEf6paTp4lc=.0b716040-2bdb-49c2-a49e-a422f47e808f@github.com>
Message-ID: <DYLAKboDkz04V-RHwOCzo2Vk0YFzsWXwlIJ2ogKKZUs=.eb01dfe2-8097-446c-a873-7cdbffa6b027@github.com>

On Fri, 16 Jan 2026 20:37:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   documentation change and truncated instances to millis
>
> src/java.base/share/classes/java/security/KeyStore.java line 1210:
> 
>> 1208:     /**
>> 1209:      * Returns the creation {@code Instant} value
>> 1210:      * of the entry identified by the given alias.
> 
> I would probably rephrase this as "Returns the instant that the entry identified by the given alias was created."
> I don't think you need to put instant in code font as other methods that return instants do not do that.

Done in the next commit, same applies to other comments

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2704108935

From azeller at openjdk.org  Mon Jan 19 10:24:40 2026
From: azeller at openjdk.org (Arno Zeller)
Date: Mon, 19 Jan 2026 10:24:40 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <YcaWjq7ZdxRBq26b7TeFa0YYvmD4S7ggSvWG-e2q8Rk=.451d9f22-d772-4e06-a978-13264e9f5de6@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
 <YcaWjq7ZdxRBq26b7TeFa0YYvmD4S7ggSvWG-e2q8Rk=.451d9f22-d772-4e06-a978-13264e9f5de6@github.com>
Message-ID: <Io6FVb24q78ajEaVxTuScjMF4LbmBFco6w2WqdRCzCw=.d922f0aa-5c26-448e-bc8a-fb9dc6b45ca9@github.com>

On Mon, 19 Jan 2026 09:39:32 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> This looks good. But wouldn't it make more sense to just add this fix to [26u](https://wiki.openjdk.org/spaces/JDKUpdates/pages/191168551/JDK+26u)?

I thought it would be nice to have it in jdk26 from the beginning as it is a clean test only fix. But I can of course go to 26u only and close this - what do you prefer?

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

PR Comment: https://git.openjdk.org/jdk/pull/29294#issuecomment-3767559258

From myankelevich at openjdk.org  Mon Jan 19 10:28:58 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 19 Jan 2026 10:28:58 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v5]
In-Reply-To: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
Message-ID: <7tb6jEtYkId-0hgKeeyisNhWWwyKizLnILnoNf29GcU=.28be927a-09ca-45d8-a0b7-467e1483c802@github.com>

> Hi!
> 
> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
> I would be very grateful for your comments and suggestions.
> 
> Thanks!
> 
> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)

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

  updated implementations to the latest docs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29140/files
  - new: https://git.openjdk.org/jdk/pull/29140/files/940ec507..aebf247c

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

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

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

From kfarrell at openjdk.org  Mon Jan 19 11:25:41 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Mon, 19 Jan 2026 11:25:41 GMT
Subject: RFR: 8364182: Add jcmd VM.properties command [v8]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <JujEAnglZiuLMQn0edlR1DPfgKfyIEaQTzxsl8A48N8=.b4c9a6ec-c4c7-4028-bd2e-5fcaaebdb6e5@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

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

  add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/bb3b243c..2b1de0f0

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

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

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

From myankelevich at openjdk.org  Mon Jan 19 13:56:09 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 19 Jan 2026 13:56:09 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <Io6FVb24q78ajEaVxTuScjMF4LbmBFco6w2WqdRCzCw=.d922f0aa-5c26-448e-bc8a-fb9dc6b45ca9@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
 <YcaWjq7ZdxRBq26b7TeFa0YYvmD4S7ggSvWG-e2q8Rk=.451d9f22-d772-4e06-a978-13264e9f5de6@github.com>
 <Io6FVb24q78ajEaVxTuScjMF4LbmBFco6w2WqdRCzCw=.d922f0aa-5c26-448e-bc8a-fb9dc6b45ca9@github.com>
Message-ID: <KWi9_D6mYJ6DwOcsrpUOZaaDLfnZukW_CQEF9ufNN9s=.30797119-f58c-48c7-85d0-cba47296e0a1@github.com>

On Mon, 19 Jan 2026 10:21:56 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> > This looks good. But wouldn't it make more sense to just add this fix to [26u](https://wiki.openjdk.org/spaces/JDKUpdates/pages/191168551/JDK+26u)?
> 
> @myankelev: I thought it would be nice to have it in jdk26 from the beginning as it is a clean test only fix. But I can of course go to 26u only and close this - what do you prefer?

Well, if it blocks your CI - go for it. Otherwise I'd personally hold off until the 26 update as we are in [RDP2](https://wiki.openjdk.org/spaces/jdk8u/pages/42598432/Rampdown+Phase+2+Process) now and unless it's critical it should be going to 26u or even just mainline. This is my understanding at least. What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/29294#issuecomment-3768453717

From duke at openjdk.org  Mon Jan 19 14:01:56 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 19 Jan 2026 14:01:56 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions [v3]
In-Reply-To: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
Message-ID: <USCU_XBZpwk-x4wNEubmF6sg9VfBz1lA8PO1-2fIjZ8=.cb62b145-7b95-48bd-89c1-db408367b408@github.com>

> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.

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

  improve comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29141/files
  - new: https://git.openjdk.org/jdk/pull/29141/files/2fca58bd..da86c0bb

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

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

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

From duke at openjdk.org  Mon Jan 19 14:01:59 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 19 Jan 2026 14:01:59 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions [v2]
In-Reply-To: <WAiQ07KdowulstQEiP-ObhKNXmTVRYMN888RpcudKvo=.b7e4eadc-6eb4-44d2-80f4-9935b8b56a13@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <MwtIHUJSbX80tKnY_xDYiVmFWfg_qyj6AHKyTg-1zP0=.7d180f11-0e80-4886-a37e-336f144d3787@github.com>
 <WAiQ07KdowulstQEiP-ObhKNXmTVRYMN888RpcudKvo=.b7e4eadc-6eb4-44d2-80f4-9935b8b56a13@github.com>
Message-ID: <eTLbTdYJlmpgDsDD8K0Vj6eC2l9tLPZTuj7xKH96l4E=.51b60370-a2bc-41fa-9439-545261a03ac1@github.com>

On Thu, 15 Jan 2026 10:54:08 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix off-by-one error discovered by Shawn
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6084:
> 
>> 6082:   //         byte[] condensed, int index, short[] parsed, int parsedLength) {}
>> 6083:   //
>> 6084:   // it is assumed that parsed and condensed are allocated such that for
> 
> By whom? :-)
> Suggestion:
> 
>   // we assume that parsed and condensed are allocated such that for

Changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2704885970

From duke at openjdk.org  Mon Jan 19 14:02:02 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 19 Jan 2026 14:02:02 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect
 assertions [v3]
In-Reply-To: <PE18_iVA29Cj0W_q7eL2RdfZ_NW17lmOCHstnNK8QQk=.ac6a5b81-4cf2-466e-b337-908939ccfe91@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <MwtIHUJSbX80tKnY_xDYiVmFWfg_qyj6AHKyTg-1zP0=.7d180f11-0e80-4886-a37e-336f144d3787@github.com>
 <WAiQ07KdowulstQEiP-ObhKNXmTVRYMN888RpcudKvo=.b7e4eadc-6eb4-44d2-80f4-9935b8b56a13@github.com>
 <PE18_iVA29Cj0W_q7eL2RdfZ_NW17lmOCHstnNK8QQk=.ac6a5b81-4cf2-466e-b337-908939ccfe91@github.com>
Message-ID: <TBK4BJnQrZ4TyNx20t0hwFC8aHc_hlOKNOAGK888hDo=.ccac44bc-ff56-4c71-a96c-f5c727e17173@github.com>

On Thu, 15 Jan 2026 14:31:58 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6280:
>> 
>>> 6278:     vs_st2_post(vs_front(vs_front(vb)), __ T8H, parsed);
>>> 6279: 
>>> 6280:     __ BIND(L_end);
>> 
>> This is a substantial change, not a mere matter of "incorrect assertions". Perhaps this PR needs a more appropriate title.
>
> Also, the description in the JIRA and the opening comment in this PR should mention that the intrinsic can be simplified in response to the stricter preconditions maintained by the Java client.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2704886149

From azeller at openjdk.org  Mon Jan 19 14:51:40 2026
From: azeller at openjdk.org (Arno Zeller)
Date: Mon, 19 Jan 2026 14:51:40 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
Message-ID: <Vu49EyRQh2XEe5-BmcgXNQcf5PIyvc3A7UTYT0ASyRA=.e30290b8-0b27-4c2c-8796-b35164c81401@github.com>

On Mon, 19 Jan 2026 08:33:02 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> This pull request is a clean backport of [JDK-8371559](https://bugs.openjdk.org/browse/JDK-8371559). 
> It is a test only change.

Then I would like to go for JDK26, as I do see this failure once or twice a day (probably related to high load on our test machines) in our CI for 26 and haven't had any issue in head since I pushed it there.
@myankelev: Would you be so kind to review it? And do I need a second review because it is after RDP2?

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

PR Comment: https://git.openjdk.org/jdk/pull/29294#issuecomment-3768695608

From clanger at openjdk.org  Mon Jan 19 14:54:46 2026
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 19 Jan 2026 14:54:46 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
Message-ID: <u23STX-6IPnrMFzIWRDPkUZOPnDpyUtPAHCrEwU6fC4=.cb97b803-a288-40e8-bdac-4db5e2955b05@github.com>

On Mon, 19 Jan 2026 08:33:02 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> This pull request is a clean backport of [JDK-8371559](https://bugs.openjdk.org/browse/JDK-8371559). 
> It is a test only change.

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29294#pullrequestreview-3678466666

From clanger at openjdk.org  Mon Jan 19 14:54:47 2026
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 19 Jan 2026 14:54:47 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <KWi9_D6mYJ6DwOcsrpUOZaaDLfnZukW_CQEF9ufNN9s=.30797119-f58c-48c7-85d0-cba47296e0a1@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
 <YcaWjq7ZdxRBq26b7TeFa0YYvmD4S7ggSvWG-e2q8Rk=.451d9f22-d772-4e06-a978-13264e9f5de6@github.com>
 <Io6FVb24q78ajEaVxTuScjMF4LbmBFco6w2WqdRCzCw=.d922f0aa-5c26-448e-bc8a-fb9dc6b45ca9@github.com>
 <KWi9_D6mYJ6DwOcsrpUOZaaDLfnZukW_CQEF9ufNN9s=.30797119-f58c-48c7-85d0-cba47296e0a1@github.com>
Message-ID: <7OPDOaxj8xvmDxAZkTDzJC_PERceTiq0y-C6gzray6E=.1162646e-739e-4372-947e-edf73f8dee6c@github.com>

On Mon, 19 Jan 2026 13:53:52 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> > > This looks good. But wouldn't it make more sense to just add this fix to [26u](https://wiki.openjdk.org/spaces/JDKUpdates/pages/191168551/JDK+26u)?
> > 
> > 
> > @myankelev: I thought it would be nice to have it in jdk26 from the beginning as it is a clean test only fix. But I can of course go to 26u only and close this - what do you prefer?
> 
> Well, if it blocks your CI - go for it. Otherwise I'd personally hold off until the 26 update as we are in [RDP2](https://wiki.openjdk.org/spaces/jdk8u/pages/42598432/Rampdown+Phase+2+Process) now and unless it's critical it should be going to 26u or even just mainline. This is my understanding at least. What do you think?

@myankelev as per the RDP2 rules, test fixes are still accepted, see here: https://openjdk.org/jeps/3. And for our regular testing it would definitely remove noise also in the JDK26 tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/29294#issuecomment-3768712595

From jpai at openjdk.org  Mon Jan 19 15:31:31 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Jan 2026 15:31:31 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
Message-ID: <k6bw0rbZxdywUfjtxLVZcVUUn6HeamA7rV4kGA1kxhU=.ae65f7e8-7c5f-4913-965f-4093493907a7@github.com>

On Mon, 19 Jan 2026 08:33:02 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> This pull request is a clean backport of [JDK-8371559](https://bugs.openjdk.org/browse/JDK-8371559). 
> It is a test only change.

For RDP2, test and doc fixes are noted to require explicit approval https://openjdk.org/jeps/3#rdp-2. The approval process itself is explained here https://openjdk.org/jeps/3#Fix-Request-Process.

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

PR Comment: https://git.openjdk.org/jdk/pull/29294#issuecomment-3768874162

From azeller at openjdk.org  Mon Jan 19 16:05:52 2026
From: azeller at openjdk.org (Arno Zeller)
Date: Mon, 19 Jan 2026 16:05:52 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <k6bw0rbZxdywUfjtxLVZcVUUn6HeamA7rV4kGA1kxhU=.ae65f7e8-7c5f-4913-965f-4093493907a7@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
 <k6bw0rbZxdywUfjtxLVZcVUUn6HeamA7rV4kGA1kxhU=.ae65f7e8-7c5f-4913-965f-4093493907a7@github.com>
Message-ID: <KjevZQBPJY9Ts-tUhFVjOpfVIP-D6PPK42Vf6TKmOk4=.04a47f79-2305-4cef-ad3b-cc90b7790d9d@github.com>

On Mon, 19 Jan 2026 15:27:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This pull request is a clean backport of [JDK-8371559](https://bugs.openjdk.org/browse/JDK-8371559). 
>> It is a test only change.
>
> For RDP2, test and doc fixes are noted to require explicit approval https://openjdk.org/jeps/3#rdp-2. The approval process itself is explained here https://openjdk.org/jeps/3#Fix-Request-Process.

@jaikiran: I am sorry and I might have misunderstood it, but in https://openjdk.org/jeps/3#rdp-2 it says:

Test and documentation bugs and enhancements
Bugs and enhancements of any priority that only affect tests, or test-problem lists, or documentation may be addressed in RDP 1 and RDP 2. You don?t need to request approval for such a change in order to integrate it, but please do make sure that the issue has a [noreg-self or noreg-doc label](https://openjdk.org/guide/#noreg), as appropriate.

And in https://openjdk.org/jeps/3#Fix-Request-Process it states:

Enhancements to tests and documentation during RDP 1 and RDP 2 do not require approval, as long as the relevant issues are identified with a [noreg-self or noreg-doc label](https://openjdk.org/guide/#noreg), as appropriate.

Therefore I thought that I would not need an approval process for this test enhancement with a [noreg-self] label.
But I am new to this RDP2 process and might have gotten it wrong. What should I do now?

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

PR Comment: https://git.openjdk.org/jdk/pull/29294#issuecomment-3769094337

From jpai at openjdk.org  Mon Jan 19 16:28:36 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Jan 2026 16:28:36 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
Message-ID: <SIouMrAP9l4bnDM6OuSdtfzlXG0DNXywQQNaubEMcjk=.b163e363-d4bb-43a2-b4ca-8d19e61fa24d@github.com>

On Mon, 19 Jan 2026 08:33:02 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> This pull request is a clean backport of [JDK-8371559](https://bugs.openjdk.org/browse/JDK-8371559). 
> It is a test only change.

Hello Arno, the sentence you quoted from https://openjdk.org/jeps/3#Test-and-documentation-bugs-and-enhancements:
> Bugs and enhancements of any priority that only affect tests, or test-problem lists, or documentation may be addressed in RDP 1 and RDP 2. You don?t need to request approval for such a change in order to integrate it

does seem to contradict with the "Fix" column for RDP2 row in the table https://openjdk.org/jeps/3#rdp-2, which says:
> Current P1?P2, with approval P1?P5 doc/test changes

I'll check internally for clarification on the expected process.

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

PR Comment: https://git.openjdk.org/jdk/pull/29294#issuecomment-3769202734

From jpai at openjdk.org  Mon Jan 19 16:44:58 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Jan 2026 16:44:58 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <SIouMrAP9l4bnDM6OuSdtfzlXG0DNXywQQNaubEMcjk=.b163e363-d4bb-43a2-b4ca-8d19e61fa24d@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
 <SIouMrAP9l4bnDM6OuSdtfzlXG0DNXywQQNaubEMcjk=.b163e363-d4bb-43a2-b4ca-8d19e61fa24d@github.com>
Message-ID: <t5NeJoLingrOvmUnoXu0YHBUeRoQFRMjk2WZPSuJf-o=.8346595b-1f94-4451-86b7-f596ec623870@github.com>

On Mon, 19 Jan 2026 16:25:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>  Current P1?P2, with approval P1?P5 doc/test changes
>
> I'll check internally for clarification on the expected process.

After checking internally, I realize that I misunderstood that text. It's supposed to read something like "It's OK to fix current P1-P2 issues after getting an approval and OK to fix any P1-P5 doc/test changes". I was also pointed to this section in the OpenJDK guide https://openjdk.org/guide/#push-or-defer-during-ramp-down which has an illustration.

Given this, test-only fixes (like this) are OK in RDP2 and doesn't require an approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/29294#issuecomment-3769285903

From myankelevich at openjdk.org  Mon Jan 19 17:21:57 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 19 Jan 2026 17:21:57 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
Message-ID: <kGGVC6A4LxtqRP2r5kVA43BN1bEPlykxLdrE0-0S4x4=.7d5311d9-cfc7-46fa-a7d5-7c866309b9fe@github.com>

On Mon, 19 Jan 2026 08:33:02 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> This pull request is a clean backport of [JDK-8371559](https://bugs.openjdk.org/browse/JDK-8371559). 
> It is a test only change.

Marked as reviewed by myankelevich (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29294#pullrequestreview-3679061305

From smonteith at openjdk.org  Tue Jan 20 09:37:08 2026
From: smonteith at openjdk.org (Stuart Monteith)
Date: Tue, 20 Jan 2026 09:37:08 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <Uagao4pRdbSEELHfvD4OyFwyhG8dVcCSqk3lkAbCeaQ=.c9c9aaa1-d740-4a59-aa90-49078d6051d6@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <Uagao4pRdbSEELHfvD4OyFwyhG8dVcCSqk3lkAbCeaQ=.c9c9aaa1-d740-4a59-aa90-49078d6051d6@github.com>
Message-ID: <uTpKLMgW_uKXr9vk2F5y8xjq33HBF4yLTvw0XFh8nt8=.617dded6-0b66-40dc-829a-0ae711a1d4b9@github.com>

On Thu, 4 Dec 2025 16:22:08 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

>> MemorySegments allocated from shared Arena from
>> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
>> 
>> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
>> 
>> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
>> 
>> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
>> |---------|-------|-------|-------|-------|-------|-------|
>> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
>> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
>> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
>> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
>> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
>> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
>> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
>> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
>> 
>> After:
>> 
>> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
>> |---------|-------|-------|-------|-------|-------|-------|
>> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
>> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
>> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
>> |    8  |    58...
>
> I'll start a discussion soon on panama-dev. At the very least, this PR provides a point of discussion.

> @stooart-mon This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a `/touch` or `/keepalive` command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

It's OK bot, I'm sure people are looking at this.

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3771899705

From duke at openjdk.org  Tue Jan 20 12:56:58 2026
From: duke at openjdk.org (Roger Calnan)
Date: Tue, 20 Jan 2026 12:56:58 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v3]
In-Reply-To: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
Message-ID: <SgSXm67_H3uwtwjLq_Vc89cJYq9EN3JTpdhGtxU10Z4=.ba224fd7-987d-43c1-8d3c-d673b45bd375@github.com>

> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option

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

  adjust anchors to have a "option" prefix to match the anchors in javac/javadoc.md

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29258/files
  - new: https://git.openjdk.org/jdk/pull/29258/files/f6f21177..872ae076

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

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

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

From mullan at openjdk.org  Tue Jan 20 14:08:22 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 20 Jan 2026 14:08:22 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v5]
In-Reply-To: <7tb6jEtYkId-0hgKeeyisNhWWwyKizLnILnoNf29GcU=.28be927a-09ca-45d8-a0b7-467e1483c802@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <7tb6jEtYkId-0hgKeeyisNhWWwyKizLnILnoNf29GcU=.28be927a-09ca-45d8-a0b7-467e1483c802@github.com>
Message-ID: <jT8k0Dty9yWdBK9Q2Hg99QRjJc9o_g0qpqFWOHKHark=.e4022e07-a964-479f-bbfb-914b3acf52ca@github.com>

On Mon, 19 Jan 2026 10:28:58 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Hi!
>> 
>> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
>> I would be very grateful for your comments and suggestions.
>> 
>> Thanks!
>> 
>> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated implementations to the latest docs

src/java.base/share/classes/java/security/KeyStore.java line 1210:

> 1208:     /**
> 1209:      * Returns the instant that the entry identified
> 1210:      * by the given alias was created.

Nit: you can fit more text on the first line before adding a line break.

src/java.base/share/classes/java/security/KeyStore.java line 1215:

> 1213:      *
> 1214:      * @return the instant that the entry identified by the given alias
> 1215:      * was created, or {@code null} if the given alias does not exist.

Nit - no period at end.

src/java.base/share/classes/java/security/KeyStore.java line 1217:

> 1215:      * was created, or {@code null} if the given alias does not exist.
> 1216:      *
> 1217:      * @throws    KeyStoreException if the keystore has not been initialized

Nit - no period at end. 
Remove extra spaces between @throws and KeyStoreException.

src/java.base/share/classes/java/security/KeyStoreSpi.java line 133:

> 131:     /**
> 132:      * Returns the instant that the entry identified
> 133:      * by the given alias was created.

Nit: you can fit more text on the first line before adding a line break.

src/java.base/share/classes/java/security/KeyStoreSpi.java line 143:

> 141:      * @param alias the alias name
> 142:      *
> 143:      * @return the creation instant of this entry, or {@code null}

Make wording consistent with `getCreationInstant`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2708491676
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2708483539
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2708487717
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2708499409
PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2708496653

From abarashev at openjdk.org  Tue Jan 20 14:17:54 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 20 Jan 2026 14:17:54 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
Message-ID: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>

Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
https://datatracker.ietf.org/doc/html/rfc8879

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

Commit messages:
 - Merge branch 'master' into JDK-8372526
 - Correct log message. Reformat file.
 - Update unit test
 - Merge branch 'master' into JDK-8372526
 - Add DefaultCertCompression unit test
 - Update copyright year and bug number plus some small changes
 - Revert SSLLogger changes
 - Fix merge errors
 - Merge branch 'master' into JDK-8273042
 - Support ZLIB compression only
 - ... and 13 more: https://git.openjdk.org/jdk/compare/e7432d57...f2ccafd0

Changes: https://git.openjdk.org/jdk/pull/28682/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372526
  Stats: 1365 lines in 17 files changed: 1336 ins; 11 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

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

From mdonovan at openjdk.org  Tue Jan 20 14:49:07 2026
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 20 Jan 2026 14:49:07 GMT
Subject: RFR: 8373018: Build OpenSSL 3.5.4 with ZLIB
Message-ID: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>

This small PR updates the OpenSSL library version to 3.5.4

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

Commit messages:
 - 8373018: Build OpenSSL 3.5.4 with ZLIB

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

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

From myankelevich at openjdk.org  Tue Jan 20 15:12:48 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 20 Jan 2026 15:12:48 GMT
Subject: RFR: 8373018: Build OpenSSL 3.5.4 with ZLIB
In-Reply-To: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>
References: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>
Message-ID: <Od5Z6twLAyeO66QMXMcNlegwkzoNLSPeskerh8r_Iu8=.16619a8b-6c01-42cf-bda1-f890df9c6447@github.com>

On Tue, 20 Jan 2026 14:39:41 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This small PR updates the OpenSSL library version to 3.5.4

test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.

Nit: copyright

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29323#discussion_r2708773489

From azeller at openjdk.org  Tue Jan 20 15:48:19 2026
From: azeller at openjdk.org (Arno Zeller)
Date: Tue, 20 Jan 2026 15:48:19 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <t5NeJoLingrOvmUnoXu0YHBUeRoQFRMjk2WZPSuJf-o=.8346595b-1f94-4451-86b7-f596ec623870@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
 <SIouMrAP9l4bnDM6OuSdtfzlXG0DNXywQQNaubEMcjk=.b163e363-d4bb-43a2-b4ca-8d19e61fa24d@github.com>
 <t5NeJoLingrOvmUnoXu0YHBUeRoQFRMjk2WZPSuJf-o=.8346595b-1f94-4451-86b7-f596ec623870@github.com>
Message-ID: <SltNkhhhyUPf5_n1oJ3NQXpidS58A1zfOx-gF2O23FM=.2ced50a2-1fb9-47a8-9570-d5bbea554579@github.com>

On Mon, 19 Jan 2026 16:41:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello Arno, the sentence you quoted from https://openjdk.org/jeps/3#Test-and-documentation-bugs-and-enhancements:
>>> Bugs and enhancements of any priority that only affect tests, or test-problem lists, or documentation may be addressed in RDP 1 and RDP 2. You don?t need to request approval for such a change in order to integrate it
>> 
>> does seem to contradict with the "Fix" column for RDP2 row in the table https://openjdk.org/jeps/3#rdp-2, which says:
>>> Current P1?P2, with approval P1?P5 doc/test changes
>> 
>> I'll check internally for clarification on the expected process.
>
>>>  Current P1?P2, with approval P1?P5 doc/test changes
>>
>> I'll check internally for clarification on the expected process.
> 
> After checking internally, I realize that I misunderstood that text. It's supposed to read something like "It's OK to fix current P1-P2 issues after getting an approval and OK to fix any P1-P5 doc/test changes". I was also pointed to this section in the OpenJDK guide https://openjdk.org/guide/#push-or-defer-during-ramp-down which has an illustration.
> 
> Given this, test-only fixes (like this) are OK in RDP2 and doesn't require an approval.

@jaikiran: Thanks for the clarification.
@myankelev and @RealCLanger: Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/29294#issuecomment-3773561820

From hchao at openjdk.org  Tue Jan 20 16:16:16 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 20 Jan 2026 16:16:16 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v23]
In-Reply-To: <-BHn7e2Xg8oBWHWMgsI0BBzGJwFspg2phtUEahM9qcA=.707c0636-4215-4554-9e21-7b87d5f26009@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <xXc8ZoZfwWR19Sf0sfEbeaH5omp3V2CdaRiFUxseVDA=.733b7c31-3f76-4111-a289-60791e8e8b79@github.com>
 <-BHn7e2Xg8oBWHWMgsI0BBzGJwFspg2phtUEahM9qcA=.707c0636-4215-4554-9e21-7b87d5f26009@github.com>
Message-ID: <f5UzKmnyOsB7sNJfMJAnf9vJmAymW8bMl-mYnfiBA1M=.096db1da-f8be-4783-8ff4-7a2d5395963e@github.com>

On Wed, 10 Dec 2025 21:38:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
>> 
>>  - Merge
>>  - Use engineEncapsulationSize() and engineSecretSize()
>>  - small tweak to long line
>>  - Updates with Brad's comments
>>  - Remove len check from encapsulate
>>  - Updates with Weijun's comments(encapsulate/decapsulate len checks)
>>  - Fix internal JSSE benchmarks to reflect new class location.  Address comments, adjust line lengths
>>  - Updates with Brad's comments
>>  - Updates with Brad's and Sean's comments for new HybridProvider class
>>  - Updates with Weijun's comments for 3rd-party provider
>>  - ... and 29 more: https://git.openjdk.org/jdk/compare/de81d389...ef6a88a4
>
> Marked as reviewed by mullan (Reviewer).

@seanjmullan @bradfordwetmore @wangweij @artur-oracle @ecki @XueleiFan Thank you all for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/27614#issuecomment-3773748868

From hchao at openjdk.org  Tue Jan 20 16:19:29 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 20 Jan 2026 16:19:29 GMT
Subject: Integrated: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <GT-oB4t8D7V11JoO1Yi_OHwNqxmyIqn519PRZJi249U=.1cb4b973-a48c-4bae-b243-ea8271884c35@github.com>

On Thu, 2 Oct 2025 22:52:49 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

This pull request has now been integrated.

Changeset: 21dc41f7
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21dc41f744edd138e77970d4e25e3a7eda41621f
Stats:     1879 lines in 22 files changed: 1759 ins; 40 del; 80 mod

8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange

Co-authored-by: Jamil Nimeh <jnimeh at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: wetmore, mullan

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

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

From adinn at openjdk.org  Tue Jan 20 16:39:43 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 20 Jan 2026 16:39:43 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression can be simplified on
 aarch64 [v3]
In-Reply-To: <USCU_XBZpwk-x4wNEubmF6sg9VfBz1lA8PO1-2fIjZ8=.cb62b145-7b95-48bd-89c1-db408367b408@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <USCU_XBZpwk-x4wNEubmF6sg9VfBz1lA8PO1-2fIjZ8=.cb62b145-7b95-48bd-89c1-db408367b408@github.com>
Message-ID: <M9yxUi-Qf0SK5NJrSdbmdM2ldtN6_uS0gcy2zoqMMwc=.3285b39c-5e57-4db3-bcc4-ff132f5b4738@github.com>

On Mon, 19 Jan 2026 14:01:56 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve comment

This looks good now, thank you.

I'm a little unhappy that the initial test did not detect the reads and writes that overflowed the end of, respectively, the input and output arrays. That may indeed be fixed now but it would have been nicer it the test had been able to catch the error. However, I understand that it is hard to achieve that when driving the VM from Java. So, let's hope we don't need any more changes or, if we do, we do our best to ensure (by eyeball) that we don't overshoot the end of the arrays.

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

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29141#pullrequestreview-3683152734

From myankelevich at openjdk.org  Tue Jan 20 16:48:15 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 20 Jan 2026 16:48:15 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v6]
In-Reply-To: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
Message-ID: <xv-A-k6AdppP_rZKbqp0qzwyvPmVPwvEM9dG9VdeJjc=.fea025af-5c5c-4cfc-9499-4939e93dd14d@github.com>

> Hi!
> 
> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
> I would be very grateful for your comments and suggestions.
> 
> Thanks!
> 
> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)

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

  Doc changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29140/files
  - new: https://git.openjdk.org/jdk/pull/29140/files/aebf247c..a01ca622

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

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

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

From myankelevich at openjdk.org  Tue Jan 20 16:48:19 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 20 Jan 2026 16:48:19 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v5]
In-Reply-To: <jT8k0Dty9yWdBK9Q2Hg99QRjJc9o_g0qpqFWOHKHark=.e4022e07-a964-479f-bbfb-914b3acf52ca@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <7tb6jEtYkId-0hgKeeyisNhWWwyKizLnILnoNf29GcU=.28be927a-09ca-45d8-a0b7-467e1483c802@github.com>
 <jT8k0Dty9yWdBK9Q2Hg99QRjJc9o_g0qpqFWOHKHark=.e4022e07-a964-479f-bbfb-914b3acf52ca@github.com>
Message-ID: <tRF9DqQtxVc5zRi3x5_fEnPn78YMG-GHxXm2LocXIrM=.1107dee8-62e2-4e4b-a5ce-79948699976b@github.com>

On Tue, 20 Jan 2026 14:02:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated implementations to the latest docs
>
> src/java.base/share/classes/java/security/KeyStore.java line 1210:
> 
>> 1208:     /**
>> 1209:      * Returns the instant that the entry identified
>> 1210:      * by the given alias was created.
> 
> Nit: you can fit more text on the first line before adding a line break.

Made the changes, thank you

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2709192915

From mbaesken at openjdk.org  Tue Jan 20 16:56:25 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 20 Jan 2026 16:56:25 GMT
Subject: RFR: 8375684: Avoid leak in KeystoreImpl.m when using
 CFArrayCreateMutable
Message-ID: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>

In KeystoreImpl.m we use CFArrayCreateMutable, but we do not always CFRelease the resources we created.
This should be adjusted.

See
https://developer.apple.com/documentation/corefoundation/cfarraycreatemutable(_:_:_:)

return value is  
A new mutable array, or NULL if there was a problem creating the object. Ownership follows the [The Create Rule](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/20001148-103029).

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

Commit messages:
 - JDK-8375684

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

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

From mbaesken at openjdk.org  Tue Jan 20 16:56:26 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 20 Jan 2026 16:56:26 GMT
Subject: RFR: 8375684: Avoid leak in KeystoreImpl.m when using
 CFArrayCreateMutable
In-Reply-To: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
References: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
Message-ID: <imAr6qfNuaZAUOkSIUTe2hoy-btdN-19t29Z186-Avg=.33f7bfb8-7beb-4a95-9f08-09da4e7c122d@github.com>

On Tue, 20 Jan 2026 16:47:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In KeystoreImpl.m we use CFArrayCreateMutable, but we do not always CFRelease the resources we created.
> This should be adjusted.
> 
> See
> https://developer.apple.com/documentation/corefoundation/cfarraycreatemutable(_:_:_:)
> 
> return value is  
> A new mutable array, or NULL if there was a problem creating the object. Ownership follows the [The Create Rule](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/20001148-103029).

When looking at the same file, seems privateKeyRef from this coding

SecKeyRef privateKeyRef;
err = SecIdentityCopyPrivateKey(theIdentity, &privateKeyRef);

https://github.com/openjdk/jdk/blob/5ba91fed345b078a67ad6bead1d8893bd9289f58/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m#L343

needs to be handled by CFRelease too according to
https://developer.apple.com/documentation/security/secidentitycopyprivatekey(_:_:)
Do you agree ?

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

PR Comment: https://git.openjdk.org/jdk/pull/29326#issuecomment-3773911913

From hchao at openjdk.org  Tue Jan 20 17:50:31 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 20 Jan 2026 17:50:31 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v3]
In-Reply-To: <SgSXm67_H3uwtwjLq_Vc89cJYq9EN3JTpdhGtxU10Z4=.ba224fd7-987d-43c1-8d3c-d673b45bd375@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
 <SgSXm67_H3uwtwjLq_Vc89cJYq9EN3JTpdhGtxU10Z4=.ba224fd7-987d-43c1-8d3c-d673b45bd375@github.com>
Message-ID: <YYAYbtXHYctWXfhs6Q9M4kW49L4lmP6klFoMfa-K_IE=.085a593e-4204-44e5-8853-1023d43c623b@github.com>

On Tue, 20 Jan 2026 12:56:58 GMT, Roger Calnan <duke at openjdk.org> wrote:

>> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option
>
> Roger Calnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust anchors to have a "option" prefix to match the anchors in javac/javadoc.md

Looks good. Thanks.

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

Marked as reviewed by hchao (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29258#pullrequestreview-3683505309

From dfenacci at openjdk.org  Tue Jan 20 18:54:04 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 20 Jan 2026 18:54:04 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
Message-ID: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>

## Issue

This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.

This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.

## Causes

The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.

## Fix

A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.

# Testing

* Tier 1-3+
* 2 JTReg tests added
  * `TestRangeCheck.java` as regression test for the reported issue
  * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

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

Commit messages:
 - JDK-8374852: revert unchanged tests
 - JDK-8374852: shorten line lenght in test
 - JDK-8374852: revert comment change
 - JDK-8374852: correct  comment and make more concise
 - Update test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java
 - JDK-8374852: fix generate_limit_guard opaque handling and remove unneeded positive flag
 - JDK-8374852: remove compileonly
 - JDK-8374852: remove VerifyIntrinsicChecks and refactor opaque flag
 - JDK-8374852: add forgotten opaque guard node handling in clone_iff
 - JDK-8374852: 120 max char for comment
 - ... and 8 more: https://git.openjdk.org/jdk/compare/6d1bfdf7...ff228576

Changes: https://git.openjdk.org/jdk/pull/29164/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374582
  Stats: 435 lines in 28 files changed: 328 ins; 20 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/29164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164

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

From vyazici at openjdk.org  Tue Jan 20 18:54:09 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 Jan 2026 18:54:09 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>

On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Marked as reviewed by vyazici (Committer).

Verified that 3c466d372b7 is a clean revert of 7e18de137c3 delivered in [JDK-8374210].

[JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

src/hotspot/share/opto/c2_globals.hpp line 680:

> 678:   develop(bool, VerifyIntrinsicChecks, false,                               \
> 679:           "Verify in intrinsic that Java level checks work as expected")    \
> 680:                                                                             \

I suggest removing the `VerifyIntrinsicChecks` flag. Given `OpaqueGuard` already verifies the value when `#ifdef ASSERT`, does `VerifyIntrinsicChecks` serve any purpose anymore?

src/hotspot/share/opto/library_call.hpp line 170:

> 168:                                     Node* length, bool char_count,
> 169:                                     bool halt_on_oob = false,
> 170:                                     bool is_opaque = false);

Do we really need to introduce two new toggles: `halt_on_oob` and `is_opaque`? At all call-sites either one of the following is used:

1. `halt_on_oob=true, is_opaque=!VerifyIntrinsicChecks`
2. defaults (i.e., `halt_on_oob=is_opaque=false`)

Can we instead only settle one, e.g., `halt_on_oob=VerifyIntrinsicChecks`?

src/hotspot/share/opto/loopopts.cpp line 1:

> 1: /*

What is the reason that the new `OpaqueGuard` is not taken into account in `PhaseIdealLoop::clone_iff`?

src/hotspot/share/opto/macro.cpp line 2565:

> 2563:         // Tests with OpaqueGuard nodes are implicitly known to be true or false. Replace the node with appropriate value. In debug builds,
> 2564:         // we leave the test in the graph to have an additional sanity check at runtime. If the test fails (i.e. a bug),
> 2565:         // we will execute a Halt node.

*Nit:* Can we adhere to the max. 120 (or even better, 80!) characters per line limit of the file?

src/hotspot/share/opto/macro.cpp line 2569:

> 2567:         _igvn.replace_node(n, n->in(1));
> 2568: #else
> 2569:         _igvn.replace_node(n, _igvn.intcon(0));

Curious: why do we invoke `intcon(0)` for `OpaqueGuard`, whereas it was `intcon(1)` for `OpaqueNotNull` slightly above?

src/hotspot/share/opto/opaquenode.hpp line 160:

> 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode
> 159: // inputs instead).
> 160: class OpaqueGuardNode : public Node {

With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of?

test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 1:

> 1: /*

Since the `VerifyIntrinsicChecks` flag is gone, AFAICT, all following changes can be reverted:


git rm test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java
git checkout upstream/HEAD -- \
test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java \
test/hotspot/jtreg/compiler/intrinsics/string/TestEncodeIntrinsics.java \
test/hotspot/jtreg/compiler/intrinsics/string/TestHasNegatives.java \
test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java

test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 32:

> 30:  *      -XX:CompileCommand=inline,java.lang.StringCoding::*
> 31:  *      -XX:CompileCommand=exclude,jdk.internal.util.Preconditions::checkFromIndexSize
> 32:  *      -XX:CompileCommand=compileonly,compiler.intrinsics.string.TestRangeCheck::test

Is this necessary? (This wasn't used in `TestStringConstruction`.)

test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 58:

> 56:             // cut off the dead code. As a result, -1 is fed as input into the
> 57:             // StringCoding::countPositives0 intrinsic which is replaced by TOP and causes a
> 58:             // failure in the matcher.

I'd appreciate it if we can be more elaborate for less C2-illiterate people like myself. ?

Suggestion:

            // Calling `StringCoding::countPositives`, which is a "front door"
            // to the `StringCoding::countPositives0` intrinsic.
            // `countPositives` validates its input using
            // `Preconditions::checkFromIndexSize`, which also maps to an
            // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not
            // know about the explicit range checks, and does not cut off the
            // dead code. As a result, an invalid value (e.g., `-1`) can be fed
            // as input into the `countPositives0` intrinsic, got replaced
            // by TOP, and cause a failure in the matcher.

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

PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3681112226
PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3738455817
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689568427
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2687948444
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2685859575
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2685838328
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2705884654
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2705885810
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2704760982
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689735070
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689780537

From dfenacci at openjdk.org  Tue Jan 20 18:54:10 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 20 Jan 2026 18:54:10 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
Message-ID: <Jb0WcdejyobjlQaehsAQ0xIcMZoojkfDASIFQMgiKh0=.3450989a-44c1-4037-bf36-86ce665882e7@github.com>

On Mon, 12 Jan 2026 13:03:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> Verified that 3c466d372b7 is a clean revert of 7e18de137c3 delivered in [JDK-8374210].
> 
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210

Thanks for your review @vy.
In addition to the changes you suggested I also fixed the opaque node value in `LibraryCallKit::generate_limit_guard` which was wrong (I then removed the `is_positive` flag altogether since it was `false` in both cases) and added `TestOpaqueGuardNodes.java` to test that the opaque nodes are added and later removed.

> src/hotspot/share/opto/c2_globals.hpp line 680:
> 
>> 678:   develop(bool, VerifyIntrinsicChecks, false,                               \
>> 679:           "Verify in intrinsic that Java level checks work as expected")    \
>> 680:                                                                             \
> 
> I suggest removing the `VerifyIntrinsicChecks` flag. Given `OpaqueGuard` already verifies the value when `#ifdef ASSERT`, does `VerifyIntrinsicChecks` serve any purpose anymore?

Done.

> src/hotspot/share/opto/loopopts.cpp line 1:
> 
>> 1: /*
> 
> What is the reason that the new `OpaqueGuard` is not taken into account in `PhaseIdealLoop::clone_iff`?

Oversight ? Thanks! Fixed.

> src/hotspot/share/opto/macro.cpp line 2565:
> 
>> 2563:         // Tests with OpaqueGuard nodes are implicitly known to be true or false. Replace the node with appropriate value. In debug builds,
>> 2564:         // we leave the test in the graph to have an additional sanity check at runtime. If the test fails (i.e. a bug),
>> 2565:         // we will execute a Halt node.
> 
> *Nit:* Can we adhere to the max. 120 (or even better, 80!) characters per line limit of the file?

Fair enough (good to know: I wasn't aware of such limit).

> src/hotspot/share/opto/macro.cpp line 2569:
> 
>> 2567:         _igvn.replace_node(n, n->in(1));
>> 2568: #else
>> 2569:         _igvn.replace_node(n, _igvn.intcon(0));
> 
> Curious: why do we invoke `intcon(0)` for `OpaqueGuard`, whereas it was `intcon(1)` for `OpaqueNotNull` slightly above?

In `OpaqueGuard`'s case we know that the input is always "false" (so, we set 0 as its input). For `OpaqueNotNull` we know that the input is always "true" (so, we set 1 as its input).

> src/hotspot/share/opto/opaquenode.hpp line 160:
> 
>> 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode
>> 159: // inputs instead).
>> 160: class OpaqueGuardNode : public Node {
> 
> With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of?

It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. ?

> test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 1:
> 
>> 1: /*
> 
> Since the `VerifyIntrinsicChecks` flag is gone, AFAICT, all following changes can be reverted:
> 
> 
> git rm test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java
> git checkout upstream/HEAD -- \
> test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java \
> test/hotspot/jtreg/compiler/intrinsics/string/TestEncodeIntrinsics.java \
> test/hotspot/jtreg/compiler/intrinsics/string/TestHasNegatives.java \
> test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java

Totally. Done.

> test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 32:
> 
>> 30:  *      -XX:CompileCommand=inline,java.lang.StringCoding::*
>> 31:  *      -XX:CompileCommand=exclude,jdk.internal.util.Preconditions::checkFromIndexSize
>> 32:  *      -XX:CompileCommand=compileonly,compiler.intrinsics.string.TestRangeCheck::test
> 
> Is this necessary? (This wasn't used in `TestStringConstruction`.)

Nope (leftover from debugging). Removed

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

PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3755585217
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694787876
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694785777
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694785429
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707280040
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707283139
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707272331
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694788432

From vyazici at openjdk.org  Tue Jan 20 18:54:11 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 Jan 2026 18:54:11 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
Message-ID: <DyFi7eM3XWx_t19uqsI95RRb8q40ujL5papopdG1n4k=.679a5d13-3be8-4e9a-bc2e-59392aae9bb9@github.com>

On Tue, 13 Jan 2026 20:01:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> src/hotspot/share/opto/library_call.hpp line 170:
> 
>> 168:                                     Node* length, bool char_count,
>> 169:                                     bool halt_on_oob = false,
>> 170:                                     bool is_opaque = false);
> 
> Do we really need to introduce two new toggles: `halt_on_oob` and `is_opaque`? At all call-sites either one of the following is used:
> 
> 1. `halt_on_oob=true, is_opaque=!VerifyIntrinsicChecks`
> 2. defaults (i.e., `halt_on_oob=is_opaque=false`)
> 
> Can we instead only settle one, e.g., `halt_on_oob=VerifyIntrinsicChecks`?

Giving this a second thought, do we need these two flags anyway? That is,

1. We can remove `if (is_opaque)` add the `OpaqueGuard` anyway, since it is ineffective for `!ASSERT`. (This is what `must_be_not_null` does too.)
2. We can replace `if (halt_on_oob) { ... } else { ... }` with `#ifdef ASSERT ...`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689690430

From dfenacci at openjdk.org  Tue Jan 20 18:54:12 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 20 Jan 2026 18:54:12 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <DyFi7eM3XWx_t19uqsI95RRb8q40ujL5papopdG1n4k=.679a5d13-3be8-4e9a-bc2e-59392aae9bb9@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
 <DyFi7eM3XWx_t19uqsI95RRb8q40ujL5papopdG1n4k=.679a5d13-3be8-4e9a-bc2e-59392aae9bb9@github.com>
Message-ID: <LWPcI2BXdfYrOXTOJZNvsxG_QpCSk-MY_Vc_LWIe9zg=.a5bdf5b5-0d79-44a1-baca-aed0bfa8eaaf@github.com>

On Wed, 14 Jan 2026 09:38:40 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.hpp line 170:
>> 
>>> 168:                                     Node* length, bool char_count,
>>> 169:                                     bool halt_on_oob = false,
>>> 170:                                     bool is_opaque = false);
>> 
>> Do we really need to introduce two new toggles: `halt_on_oob` and `is_opaque`? At all call-sites either one of the following is used:
>> 
>> 1. `halt_on_oob=true, is_opaque=!VerifyIntrinsicChecks`
>> 2. defaults (i.e., `halt_on_oob=is_opaque=false`)
>> 
>> Can we instead only settle one, e.g., `halt_on_oob=VerifyIntrinsicChecks`?
>
> Giving this a second thought, do we need these two flags anyway? That is,
> 
> 1. We can remove `if (is_opaque)` add the `OpaqueGuard` anyway, since it is ineffective for `!ASSERT`. (This is what `must_be_not_null` does too.)
> 2. We can replace `if (halt_on_oob) { ... } else { ... }` with `#ifdef ASSERT ...`.

1. I'm not sure we can always do that: `LibraryCallKit::generate_string_range_check` is called from places that don't yet have Java range checks and we must not add an opaque node in those cases (or we end up without checks in prod builds).
2. For a similar reason I'd leave `if (halt_on_oob)` condition: for calls to  `LibraryCallKit::generate_string_range_check` that don't yet have Java range checks the method behaves like it did before. For "new" calls it adds the `Halt` node (which will then be removed together with the guard in prod builds).

So, on the one hand we can keep `halt_on_oob` alone as discriminant between "new" and "old" call sites. On the other we can get rid of `VerifyIntrinsicChecks` because we implicitly add the additional range check in debug builds (always). 

I've modified the code accordingly. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694787303

From vyazici at openjdk.org  Tue Jan 20 18:54:12 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 Jan 2026 18:54:12 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <Jb0WcdejyobjlQaehsAQ0xIcMZoojkfDASIFQMgiKh0=.3450989a-44c1-4037-bf36-86ce665882e7@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
 <Jb0WcdejyobjlQaehsAQ0xIcMZoojkfDASIFQMgiKh0=.3450989a-44c1-4037-bf36-86ce665882e7@github.com>
Message-ID: <sn2GOc4tdoyMYCNjYB4yg9k31OCYDhvJYlugbmN34l8=.d6e02dd6-f8ab-442f-a0f2-ee87bfd4464f@github.com>

On Tue, 20 Jan 2026 08:27:59 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> src/hotspot/share/opto/opaquenode.hpp line 160:
>> 
>>> 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode
>>> 159: // inputs instead).
>>> 160: class OpaqueGuardNode : public Node {
>> 
>> With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of?
>
> It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. ?

Fair enough ? I was just curious.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707418513

From duke at openjdk.org  Tue Jan 20 18:54:14 2026
From: duke at openjdk.org (ExE Boss)
Date: Tue, 20 Jan 2026 18:54:14 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
Message-ID: <osGEnkaCSFQ19GH0FRlPwOrUCB4rlDC8laKd2_LB3w0=.96c5cc4e-e660-4f05-8ddd-096a0769298e@github.com>

On Wed, 14 Jan 2026 10:05:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 58:
> 
>> 56:             // cut off the dead code. As a result, -1 is fed as input into the
>> 57:             // StringCoding::countPositives0 intrinsic which is replaced by TOP and causes a
>> 58:             // failure in the matcher.
> 
> I'd appreciate it if we can be more elaborate for less C2-illiterate people like myself. ?
> 
> Suggestion:
> 
>             // Calling `StringCoding::countPositives`, which is a "front door"
>             // to the `StringCoding::countPositives0` intrinsic.
>             // `countPositives` validates its input using
>             // `Preconditions::checkFromIndexSize`, which also maps to an
>             // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not
>             // know about the explicit range checks, and does not cut off the
>             // dead code. As a result, an invalid value (e.g., `-1`) can be fed
>             // as input into the `countPositives0` intrinsic, got replaced
>             // by TOP, and cause a failure in the matcher.

**Nit:** Using??get??here is?grammatically?better:

             // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not
             // know about the explicit range checks, and does not cut off the
-            // as input into the `countPositives0` intrinsic, got replaced
+            // as input into the `countPositives0` intrinsic, get replaced
             // by TOP, and cause a failure in the matcher.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2690260434

From dfenacci at openjdk.org  Tue Jan 20 18:54:14 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 20 Jan 2026 18:54:14 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <osGEnkaCSFQ19GH0FRlPwOrUCB4rlDC8laKd2_LB3w0=.96c5cc4e-e660-4f05-8ddd-096a0769298e@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
 <osGEnkaCSFQ19GH0FRlPwOrUCB4rlDC8laKd2_LB3w0=.96c5cc4e-e660-4f05-8ddd-096a0769298e@github.com>
Message-ID: <TPGnDnZFFM1qT-a4tHKrTJFzWf61CUIGgcjlWp2ZtWc=.08cade4c-029e-4f51-af1e-c02d86d7a4c4@github.com>

On Wed, 14 Jan 2026 12:34:51 GMT, ExE Boss <duke at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 58:
>> 
>>> 56:             // cut off the dead code. As a result, -1 is fed as input into the
>>> 57:             // StringCoding::countPositives0 intrinsic which is replaced by TOP and causes a
>>> 58:             // failure in the matcher.
>> 
>> I'd appreciate it if we can be more elaborate for less C2-illiterate people like myself. ?
>> 
>> Suggestion:
>> 
>>             // Calling `StringCoding::countPositives`, which is a "front door"
>>             // to the `StringCoding::countPositives0` intrinsic.
>>             // `countPositives` validates its input using
>>             // `Preconditions::checkFromIndexSize`, which also maps to an
>>             // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not
>>             // know about the explicit range checks, and does not cut off the
>>             // dead code. As a result, an invalid value (e.g., `-1`) can be fed
>>             // as input into the `countPositives0` intrinsic, got replaced
>>             // by TOP, and cause a failure in the matcher.
>
> **Nit:** Using??get??here is?grammatically?better:
> 
>              // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not
>              // know about the explicit range checks, and does not cut off the
> -            // as input into the `countPositives0` intrinsic, got replaced
> +            // as input into the `countPositives0` intrinsic, get replaced
>              // by TOP, and cause a failure in the matcher.

Done. Thanks for the suggestion!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694948915

From bchristi at openjdk.org  Tue Jan 20 20:31:18 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 20 Jan 2026 20:31:18 GMT
Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
Message-ID: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>

This brings in cpu26_01 changes.

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

Commit messages:
 - 8368032: Enhance Certificate Checking
 - 8365280: Enhance JOptionPane
 - 8359501: Enhance Handling of URIs
 - 8362632: Improve HttpServer Request handling
 - 8367277: Fix copyright header in JMXInterfaceBindingTest.java
 - 8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently
 - 8341496: Improve JMX connections
 - 8365058: Enhance CopyOnWriteArraySet
 - 8365271: Improve Swing supports
 - 8362308: Enhance Bitmap operations
 - ... and 2 more: https://git.openjdk.org/jdk/compare/a67979c4...07f981f6

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/29331/files
  Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod
  Patch: https://git.openjdk.org/jdk/pull/29331.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29331/head:pull/29331

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

From djelinski at openjdk.org  Tue Jan 20 20:34:19 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 20 Jan 2026 20:34:19 GMT
Subject: RFR: 8328046: Need to keep leading zeros in TlsPremasterSecret of
 TLS1.3 DHKeyAgreement [v4]
In-Reply-To: <HFMfI-Mpd5KEUXNZ6qhyHs8UFRLDbZFBA1qvoWpQLqI=.c36c897d-6af8-4bc5-be99-fdcee492887d@github.com>
References: <HFMfI-Mpd5KEUXNZ6qhyHs8UFRLDbZFBA1qvoWpQLqI=.c36c897d-6af8-4bc5-be99-fdcee492887d@github.com>
Message-ID: <s0kEjUuUFTMBK-ONcxzRKXxKknk4Al9WdFVcI0DKEGM=.8b80ee2e-41cd-4648-bac8-15e204fbde7c@github.com>

> TLS 1.3 changed the way it generates the FFDHE shared secret. In TLS 1.2, the leading zeroes in the shared secret were stripped, and in TLS 1.3 the leading zeroes are preserved.
> 
> Thanks to the recent work in [JDK-8189441](https://bugs.openjdk.org/browse/JDK-8189441), we now have a new algorithm name `Generic` that can be used to generate a shared secret with the leading zeroes preserved.
> 
> This PR changes the TLS 1.3 handshake to use the new algorithm name.
> 
> I didn't add any tests to verify the correctness of the handshake. This can be verified using tlsfuzzer, see JBS for details.
> 
> Tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into tls13-ffdhe
 - Merge branch 'master' into tls13-ffdhe
 - Revert PKCS11 changes
 - Update copyright, add bug IDs
 - Fix PKCS11 DH key derivation
 - Keep leading zeroes in tls13

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

Changes: https://git.openjdk.org/jdk/pull/27343/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27343&range=03
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27343.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27343/head:pull/27343

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

From bchristi at openjdk.org  Tue Jan 20 20:34:55 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 20 Jan 2026 20:34:55 GMT
Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284
Message-ID: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>

This brings in cpu26_01 changes.

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

Commit messages:
 - 8368032: Enhance Certificate Checking
 - 8365280: Enhance JOptionPane
 - 8359501: Enhance Handling of URIs
 - 8362632: Improve HttpServer Request handling
 - 8367277: Fix copyright header in JMXInterfaceBindingTest.java
 - 8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently
 - 8341496: Improve JMX connections
 - 8365058: Enhance CopyOnWriteArraySet
 - 8365271: Improve Swing supports
 - 8362308: Enhance Bitmap operations
 - ... and 2 more: https://git.openjdk.org/jdk/compare/f4ddafcd...4b0189c4

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/29332/files
  Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod
  Patch: https://git.openjdk.org/jdk/pull/29332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29332/head:pull/29332

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

From abarashev at openjdk.org  Tue Jan 20 20:57:08 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 20 Jan 2026 20:57:08 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v2]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <1baiHDKLxm7F0ymn9mPmxcxuEjdy_wQfswRo5gwMVSk=.2a692a90-84b8-4c67-972f-ef6b30c8f490@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Cache compressed local certificates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/f2ccafd0..7e965242

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

  Stats: 60 lines in 1 file changed: 29 ins; 10 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

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

From ascarpino at openjdk.org  Tue Jan 20 21:10:41 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 20 Jan 2026 21:10:41 GMT
Subject: RFR: 8373408: SHA1withECDSA is not required for ECDHE and ECDSA
In-Reply-To: <ZBDSdP8PhO2q3gjF10Xv8GKaWjxmwD5vO4p2ro_6qz4=.6e8e40fc-6087-41f1-8635-1239c755861f@github.com>
References: <ZBDSdP8PhO2q3gjF10Xv8GKaWjxmwD5vO4p2ro_6qz4=.6e8e40fc-6087-41f1-8635-1239c755861f@github.com>
Message-ID: <GqfWdKUQSNXNLGulU0Qi-ohIgD0NClDZRxok5R5xXds=.dc467140-cc9f-468c-83ad-ab105ca9a857@github.com>

On Tue, 13 Jan 2026 07:47:15 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> SunJSSE should not probe SHA1withECDSA signature availably when determining if elliptic curve cryptography is available, as it is deprecated and not required for ECDHE and ECDSA signature schemes. This change removes SHA1withECDSA from the EC availability probe. TLS signature scheme availability is validated later during handshake negotiation.

Looks good to me.

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29184#pullrequestreview-3684291737

From kcr at openjdk.org  Tue Jan 20 21:34:45 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Jan 2026 21:34:45 GMT
Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <lgyZ6v95aJQ2wc93EdoJ-t0CX8-HASEbzT8M0yss3Qk=.f6545aa5-52ed-4849-ae60-8ff75fd4cd55@github.com>

On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

LGTM

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684377505

From kcr at openjdk.org  Tue Jan 20 21:35:46 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Jan 2026 21:35:46 GMT
Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <tAakA6ADGd9sqbZll-xqpgZDUV6VtWUgCSm3oJQlhV4=.93c63002-5987-481a-b194-341b5faaa3d5@github.com>

On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

LGTM

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684378038

From prr at openjdk.org  Tue Jan 20 22:05:29 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Jan 2026 22:05:29 GMT
Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <L7ot0RSGxYxlzRYGMKEMjILOCiC7wGYhsO7vVvEzPXc=.ba5698e7-be06-497e-8234-395f2cac7556@github.com>

On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684486562

From prr at openjdk.org  Tue Jan 20 22:08:39 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Jan 2026 22:08:39 GMT
Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <R0Q7zCwwhcmbvB3Z-GT8SyVv88FiNpJE1sRGDKWVWKs=.1d63c771-76ba-455e-8c48-738cd1cae0f7@github.com>

On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684495706

From valeriep at openjdk.org  Tue Jan 20 23:06:57 2026
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 20 Jan 2026 23:06:57 GMT
Subject: RFR: 8375549: ConcurrentModificationException if
 jdk.crypto.disabledAlgorithms has multiple entries with known oid
Message-ID: <9RX9ppMiYrgBmp9W8Lwn9KdcGd9O6xQU2WhJQ-I0W3M=.9c831100-bb9b-479d-9994-7de269b093b6@github.com>

Inside the CryptoAlgorithmConstraints constructor, there is a loop looking up the known oid. Iterating over the "disabledServices" set and inserting the found oid(s) into it leads to ConcurrentModificationException when the set contains multiple entries. The proposed fix is to iterating over the array converted from the set which is also used for debugging output instead of the "disabledServices" set itself.

Thanks,
Valerie

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

Commit messages:
 - 8375549: ConcurrentModificationException if jdk.crypto.disabledAlgorithms has multiple entries with known oid

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

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

From smarks at openjdk.org  Wed Jan 21 01:16:18 2026
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 21 Jan 2026 01:16:18 GMT
Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <16L6cSilYiC8tbhpmKW2g3X19hE5-A0jHERAtsCJ9S4=.3211d9ae-c184-4ec9-823f-43b77fd49d68@github.com>

On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

The changes in this PR match the list of approved changes for this release.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684928489

From smarks at openjdk.org  Wed Jan 21 01:16:22 2026
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 21 Jan 2026 01:16:22 GMT
Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <d4UEBfgDPeaTQ6MJmVaGLhkMF4MGbJjvaNc4UF0VUPc=.de637b15-3139-4dbf-b863-9d6355b07503@github.com>

On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

The changes in this PR match the list of approved changes for this release.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684928880

From bchristi at openjdk.org  Wed Jan 21 01:33:46 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Jan 2026 01:33:46 GMT
Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 [v2]
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <m6au9jDA--T9V-5h9StQxGa1b8s6tQMUQYjj1jGeods=.3d7846c9-f8de-46b2-ad4c-73626b6fdb15@github.com>

> This brings in cpu26_01 changes.

Brent Christian 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29332/files
  - new: https://git.openjdk.org/jdk/pull/29332/files/4b0189c4..4b0189c4

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

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

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

From bchristi at openjdk.org  Wed Jan 21 01:33:48 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Jan 2026 01:33:48 GMT
Subject: [jdk26] Integrated: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <bzGdXAI0-0khn6oK_-Lf3InoJyVt9CL5hoRFPXlHu_w=.3b3e93b5-7484-4499-aecf-80b589c1663a@github.com>

On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

This pull request has now been integrated.

Changeset: 7ac780da
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ac780da7b98d1a44effc86e75b62a1bedc7954b
Stats:     1268 lines in 37 files changed: 965 ins; 148 del; 155 mod

Merge

Reviewed-by: kcr, prr, smarks

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

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

From bchristi at openjdk.org  Wed Jan 21 01:34:06 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Jan 2026 01:34:06 GMT
Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 [v2]
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <_R8gyRrfwT8U_cL4_T9ImlWVN5Q3zLKoa61ZVBXQP5E=.8fbf5d4d-4be3-46a9-94c2-b14c0ddef43d@github.com>

> This brings in cpu26_01 changes.

Brent Christian 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29331/files
  - new: https://git.openjdk.org/jdk/pull/29331/files/07f981f6..07f981f6

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

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

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

From bchristi at openjdk.org  Wed Jan 21 01:34:09 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Jan 2026 01:34:09 GMT
Subject: Integrated: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <bxGQ21sSA_6fGAy2JNV_X9oo_Q5DnkUjXtfGEKwjJCw=.66feccd4-289e-49a9-bd8c-1accc12fced0@github.com>

On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

This pull request has now been integrated.

Changeset: e25a5a48
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e25a5a4821d03680d00ab6bdbec727732add8206
Stats:     1268 lines in 37 files changed: 965 ins; 148 del; 155 mod

Merge

Reviewed-by: kcr, prr, smarks

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

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

From hchao at openjdk.org  Wed Jan 21 05:55:53 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 21 Jan 2026 05:55:53 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints [v5]
In-Reply-To: <PU2aAvObH11_DJg7AG6A7zC3_ARudZTNr8OBXRlS6d4=.eeb70fc9-1983-432e-9657-899fdd84937f@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
 <PU2aAvObH11_DJg7AG6A7zC3_ARudZTNr8OBXRlS6d4=.eeb70fc9-1983-432e-9657-899fdd84937f@github.com>
Message-ID: <qRoeeADAqwV3OpGKc33c9vZBWCI55vVWI5FdB693ypE=.8232b087-3e04-4fea-9129-30849e0ba5a8@github.com>

On Thu, 15 Jan 2026 17:55:31 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> NamedGroup.SupportedGroups.namedGroups values are not being filtered against algorithm constraints, unlike other SSLParameters returned by SSLConfiguration#getSSLParameters() call. Those are the values being displayed to the user with "java -XshowSettings:security:tls" command.
>> 
>> Also making changes to avoid needless default group names lookup while we are touching this file.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comments

Marked as reviewed by hchao (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28397#pullrequestreview-3685456710

From hchao at openjdk.org  Wed Jan 21 05:55:55 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 21 Jan 2026 05:55:55 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints [v4]
In-Reply-To: <Xi3BCY2r9qaxOnOTtGAKPpWxNqnprrLkvPxs8FB7GDA=.8e705368-501d-4e20-b250-10da6834e2f7@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
 <SvUGi7_7e6pvwmVOec0MTv33yavtP2Ve3ixb7WanHnQ=.c3cfc626-657b-4076-ada1-3b5eae49418a@github.com>
 <O7mQex_5qoyhEEhmzGyX2NwU1RhTtqN6hQQjnICXAjY=.e8e707f7-2c5d-45cf-9ed8-61a191152c54@github.com>
 <Xi3BCY2r9qaxOnOTtGAKPpWxNqnprrLkvPxs8FB7GDA=.8e705368-501d-4e20-b250-10da6834e2f7@github.com>
Message-ID: <sVMk30ZKNGsC5qpEGWGuhfHXC8EQyftnobhosVOyyLw=.d575d9e3-9ead-460e-af0c-a9650ef5a064@github.com>

On Thu, 15 Jan 2026 17:43:19 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 780:
>> 
>>> 778:                 customizedGroups == null ?
>>> 779:                         null : Arrays.stream(customizedGroups)
>>> 780:                         .map(ng -> ng.name)
>> 
>> The filtering against algorithm constraints is not being done for customizedNames. Is it to preserve user?s selection and let constraints to be applied during handshake as before? It is different from defaultNames?s. Suggest to add some comments for it.
>
> Yes, that's correct. I figured we should display the user-passed groups as-is. Adding a comment.

Update looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28397#discussion_r2711070414

From ssahoo at openjdk.org  Wed Jan 21 06:06:57 2026
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 21 Jan 2026 06:06:57 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v6]
In-Reply-To: <xv-A-k6AdppP_rZKbqp0qzwyvPmVPwvEM9dG9VdeJjc=.fea025af-5c5c-4cfc-9499-4939e93dd14d@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <xv-A-k6AdppP_rZKbqp0qzwyvPmVPwvEM9dG9VdeJjc=.fea025af-5c5c-4cfc-9499-4939e93dd14d@github.com>
Message-ID: <JeSvOa1W-XAxkEl8K7EUjGgUHzjbIkiH6boSwjx69qc=.2e8ea430-b4bb-4400-a20b-5c65c5c98173@github.com>

On Tue, 20 Jan 2026 16:48:15 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Hi!
>> 
>> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
>> I would be very grateful for your comments and suggestions.
>> 
>> Thanks!
>> 
>> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc changes

src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java line 240:

> 238: 
> 239:         if (entry != null) {
> 240:             if (entry instanceof TrustedCertEntry) {

instanceof pattern matching can be used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2711082944

From duke at openjdk.org  Wed Jan 21 07:59:15 2026
From: duke at openjdk.org (duke)
Date: Wed, 21 Jan 2026 07:59:15 GMT
Subject: [jdk26] RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
Message-ID: <zFr4cvk6BsxliZi0Egh9zx6CZPPo9FeIKZy9eezvvr4=.c72d794b-9f9b-46bf-a306-2ff714717caf@github.com>

On Mon, 19 Jan 2026 08:33:02 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> This pull request is a clean backport of [JDK-8371559](https://bugs.openjdk.org/browse/JDK-8371559). 
> It is a test only change.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/29294#issuecomment-3776654630

From azeller at openjdk.org  Wed Jan 21 08:08:43 2026
From: azeller at openjdk.org (Arno Zeller)
Date: Wed, 21 Jan 2026 08:08:43 GMT
Subject: [jdk26] Integrated: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
In-Reply-To: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
References: <oKmJ7uJH9FcO8jWd2mFuXmcYgEFDH-ye5fh3grs8xJ0=.19be9ebb-98cd-4290-a8ad-07708c4e2a9b@github.com>
Message-ID: <F_FOBq_01Lfltn8anqIyE8ciVrEhwwsOzEyflJvcU-M=.3042b02a-1339-43e7-b640-0f2c44755087@github.com>

On Mon, 19 Jan 2026 08:33:02 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> This pull request is a clean backport of [JDK-8371559](https://bugs.openjdk.org/browse/JDK-8371559). 
> It is a test only change.

This pull request has now been integrated.

Changeset: bb9f0f06
Author:    Arno Zeller <azeller at openjdk.org>
Committer: Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb9f0f06825917e163195afb0c3973a62d35a38c
Stats:     59 lines in 1 file changed: 21 ins; 11 del; 27 mod

8371559: Intermittent timeouts in test javax/net/ssl/Stapling/HttpsUrlConnClient.java

Reviewed-by: myankelevich, clanger
Backport-of: af18fbd42d2a437dd35f33e557a8906ca0c3bd07

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

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

From ghan at openjdk.org  Wed Jan 21 08:39:52 2026
From: ghan at openjdk.org (Guanqiang Han)
Date: Wed, 21 Jan 2026 08:39:52 GMT
Subject: RFR: 8374516: -version asserts with
 "-XX:+UseAESCTRIntrinsics -XX:-UseAES":
 "need AES instructions and misaligned SSE support" in
 generate_counterMode_AESCrypt_Parallel()
Message-ID: <qa6IzAt1LzAzF9zOMtIIjGHY-c8Iqikre6fxlfA34Z8=.44fb722a-867e-432a-bf9d-8d819d136ebc@github.com>

Please review this change. Thanks!

**Description:**

VM crashes during startup on x86 when running with -XX:+UseAESCTRIntrinsics -XX:-UseAES. In this configuration, UseAESCTRIntrinsics may remain enabled while UseAES is explicitly disabled, and the VM generates AES-CTR stubs, hitting an assert(UseAES) in generate_counterMode_AESCrypt_Parallel().

**Fix:**

Update x86 flag initialization to enforce the dependency between UseAESCTRIntrinsics and UseAES. When UseAES is disabled, explicitly disable UseAESCTRIntrinsics (with a warning when it was set on the command line), aligning behavior with the existing UseAES/UseAESIntrinsics gating and avoiding stub generation with inconsistent flag states.

**Test:**

GHA

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

Commit messages:
 - fix 8374516

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

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

From coffeys at openjdk.org  Wed Jan 21 12:12:15 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 21 Jan 2026 12:12:15 GMT
Subject: RFR: 8375549: ConcurrentModificationException if
 jdk.crypto.disabledAlgorithms has multiple entries with known oid
In-Reply-To: <9RX9ppMiYrgBmp9W8Lwn9KdcGd9O6xQU2WhJQ-I0W3M=.9c831100-bb9b-479d-9994-7de269b093b6@github.com>
References: <9RX9ppMiYrgBmp9W8Lwn9KdcGd9O6xQU2WhJQ-I0W3M=.9c831100-bb9b-479d-9994-7de269b093b6@github.com>
Message-ID: <VH1pw5vpZTJAQkb8NwPtD88whVwUJncu02oEU4tasVs=.abbb2344-6662-4de3-a87d-65e0da69e2b2@github.com>

On Tue, 20 Jan 2026 22:59:54 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Inside the CryptoAlgorithmConstraints constructor, there is a loop looking up the known oid. Iterating over the "disabledServices" set and inserting the found oid(s) into it leads to ConcurrentModificationException when the set contains multiple entries. The proposed fix is to iterating over the array converted from the set which is also used for debugging output instead of the "disabledServices" set itself.
> 
> Thanks,
> Valerie

LGTM

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29335#pullrequestreview-3686877495

From duke at openjdk.org  Wed Jan 21 12:22:23 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 21 Jan 2026 12:22:23 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression can be simplified on
 aarch64
In-Reply-To: <Q_J9bZJ-0RBUNRI_9INN7XtiFvQkmiro9ex0UjJZ30E=.3196ecc9-6c2f-48f0-85e5-8da07176ce72@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <Q_J9bZJ-0RBUNRI_9INN7XtiFvQkmiro9ex0UjJZ30E=.3196ecc9-6c2f-48f0-85e5-8da07176ce72@github.com>
Message-ID: <cbUhOPjgcmbWVsqAdV-gH0wnHv8bLstsF97LL_BBIvY=.93b490ca-17cf-4eed-b84d-bb1dad1e2dc3@github.com>

On Mon, 12 Jan 2026 10:37:31 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.
>
> Changes look good. What testing have you run?

Thanks! @adinn would you be so kind as to /sponsor the integration?

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

PR Comment: https://git.openjdk.org/jdk/pull/29141#issuecomment-3777775558

From duke at openjdk.org  Wed Jan 21 12:22:24 2026
From: duke at openjdk.org (duke)
Date: Wed, 21 Jan 2026 12:22:24 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression can be simplified on
 aarch64 [v3]
In-Reply-To: <USCU_XBZpwk-x4wNEubmF6sg9VfBz1lA8PO1-2fIjZ8=.cb62b145-7b95-48bd-89c1-db408367b408@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <USCU_XBZpwk-x4wNEubmF6sg9VfBz1lA8PO1-2fIjZ8=.cb62b145-7b95-48bd-89c1-db408367b408@github.com>
Message-ID: <WHLYAqc9eHgwxXdcXUmsgbbiEOEHhEk6kDxXuiSg_-A=.0012d127-d315-4890-99af-8b3fa6d83d2d@github.com>

On Mon, 19 Jan 2026 14:01:56 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve comment

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

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

PR Comment: https://git.openjdk.org/jdk/pull/29141#issuecomment-3777794081

From adinn at openjdk.org  Wed Jan 21 13:39:51 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 21 Jan 2026 13:39:51 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression can be simplified on
 aarch64 [v3]
In-Reply-To: <USCU_XBZpwk-x4wNEubmF6sg9VfBz1lA8PO1-2fIjZ8=.cb62b145-7b95-48bd-89c1-db408367b408@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <USCU_XBZpwk-x4wNEubmF6sg9VfBz1lA8PO1-2fIjZ8=.cb62b145-7b95-48bd-89c1-db408367b408@github.com>
Message-ID: <FkgI3KedZ764qfn_w2b27kQcIIFSZWhD1NsqhOQQTdA=.2f2c504e-4b6c-4e4f-8bab-938cd9dee31b@github.com>

On Mon, 19 Jan 2026 14:01:56 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve comment

I believe this needs a second sign-off.

@theRealAph can you do the honours?

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

PR Comment: https://git.openjdk.org/jdk/pull/29141#issuecomment-3778177332

From myankelevich at openjdk.org  Wed Jan 21 13:58:00 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 21 Jan 2026 13:58:00 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v7]
In-Reply-To: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
Message-ID: <EwuVQ29oZESErQisYwbXCD6aF7ez3ZVuG70oSQZc-M0=.b1674457-2d8d-4d89-a435-3e592866858b@github.com>

> Hi!
> 
> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
> I would be very grateful for your comments and suggestions.
> 
> Thanks!
> 
> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)

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

  Doc changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29140/files
  - new: https://git.openjdk.org/jdk/pull/29140/files/a01ca622..befe9989

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

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

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

From abarashev at openjdk.org  Wed Jan 21 15:03:29 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 21 Jan 2026 15:03:29 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints [v6]
In-Reply-To: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
Message-ID: <kYSmhGL5FuDOS4ofMC_Bc-94i3KuaqaLLUiblRjNUxA=.b9b77881-11af-4458-9458-ba8ca1cb2f3a@github.com>

> NamedGroup.SupportedGroups.namedGroups values are not being filtered against algorithm constraints, unlike other SSLParameters returned by SSLConfiguration#getSSLParameters() call. Those are the values being displayed to the user with "java -XshowSettings:security:tls" command.
> 
> Also making changes to avoid needless default group names lookup while we are touching this file.

Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into JDK-8370885
   
   # Conflicts:
   #	src/java.base/share/classes/sun/security/ssl/NamedGroup.java
 - Update comments
 - Merge branch 'master' into JDK-8370885
   
   # Conflicts:
   #	src/java.base/share/classes/sun/security/ssl/NamedGroup.java
 - Update copyright year
 - Merge branch 'master' into JDK-8370885
 - Merge branch 'master' into JDK-8370885
   
   # Conflicts:
   #	src/java.base/share/classes/sun/security/ssl/NamedGroup.java
 - 8370885: Default namedGroups values are not being filtered against algorithm constraints

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

Changes: https://git.openjdk.org/jdk/pull/28397/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28397&range=05
  Stats: 233 lines in 2 files changed: 159 ins; 44 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/28397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28397/head:pull/28397

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

From abarashev at openjdk.org  Wed Jan 21 15:07:05 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 21 Jan 2026 15:07:05 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints [v7]
In-Reply-To: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
Message-ID: <Pjr3WUCzlapr8nhnSalhXvNXVtbo7kzaS3XNph_iRaU=.0aff9384-b31d-41cd-ac92-fc64b96e1548@github.com>

> NamedGroup.SupportedGroups.namedGroups values are not being filtered against algorithm constraints, unlike other SSLParameters returned by SSLConfiguration#getSSLParameters() call. Those are the values being displayed to the user with "java -XshowSettings:security:tls" command.
> 
> Also making changes to avoid needless default group names lookup while we are touching this file.

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

  Test fix: add the Hybrid named group. Move the comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28397/files
  - new: https://git.openjdk.org/jdk/pull/28397/files/a6cc0ecb..47ff278f

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

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

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

From kfarrell at openjdk.org  Wed Jan 21 16:52:08 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Wed, 21 Jan 2026 16:52:08 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <tb2p5UScm2-tC7p6jEEmiRMJ1GSTAWfFocWDIvuIELQ=.b51a5809-0e92-4495-a556-79fd65c83864@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

This backport is now required for another fix, could we please get this reviewed/integreated and I will backport to the older releases? Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3779586006

From sshivang at openjdk.org  Wed Jan 21 17:03:23 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Wed, 21 Jan 2026 17:03:23 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <LPXWY0EsTQSPQjQNwh5DY9xCjj9EUcY52kGWgGWQgW8=.e225d2ea-a37c-4c1b-aef3-d18cf9724e04@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

I think now it should go in 26u?

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3779694290

From mullan at openjdk.org  Wed Jan 21 17:38:05 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 21 Jan 2026 17:38:05 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v3]
In-Reply-To: <SgSXm67_H3uwtwjLq_Vc89cJYq9EN3JTpdhGtxU10Z4=.ba224fd7-987d-43c1-8d3c-d673b45bd375@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
 <SgSXm67_H3uwtwjLq_Vc89cJYq9EN3JTpdhGtxU10Z4=.ba224fd7-987d-43c1-8d3c-d673b45bd375@github.com>
Message-ID: <6eTwVCfingRL8g3sj-GTFhwy9PoDfHmMn_n3vM1RbTs=.a43ee6f4-c301-4e09-8894-547ac340ab74@github.com>

On Tue, 20 Jan 2026 12:56:58 GMT, Roger Calnan <duke at openjdk.org> wrote:

>> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option
>
> Roger Calnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust anchors to have a "option" prefix to match the anchors in javac/javadoc.md

Copyright dates need to be updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/29258#issuecomment-3779965644

From dfuchs at openjdk.org  Wed Jan 21 18:46:03 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 21 Jan 2026 18:46:03 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <d1s45aDlcTye4sAV2kJHWtvfsoDFCIZuKDTHfXAoTZ0=.e21e82ad-dcf4-4ecc-ae6d-d106698b1937@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

Yes I would prefer to see it go to 26u.

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3780310809

From mcimadamore at openjdk.org  Wed Jan 21 19:02:10 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 21 Jan 2026 19:02:10 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <un--qP6HOPN7VyxKxZLIUwJbVHgZbqZ_dwQYYbdF004=.4dee79fb-20f2-47ef-8965-a1e01e0e30c5@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
 <uLtjpxSm_9oOJqhkyASoPG9Tz_rccTerc1v6uwf9yNo=.68ff8f24-a8e0-4b39-b124-b36ca7d07776@github.com>
 <Tf3g4VZ5xTQ5EkiugzVAL-9NUsmYtV0lxCz0FK5TB78=.01c55ced-599c-432d-afca-91d25c625939@github.com>
 <un--qP6HOPN7VyxKxZLIUwJbVHgZbqZ_dwQYYbdF004=.4dee79fb-20f2-47ef-8965-a1e01e0e30c5@github.com>
Message-ID: <BKAxFQOF2jFU1Ciwys3v_QX3FP6BNNTjBVdFYOo4Gvc=.6e63cb2c-8eb2-4bc7-95fb-7fe70c2f1c7d@github.com>

On Thu, 15 Jan 2026 23:07:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I don't have the expertise to confirm the correctness of that code change. @mcimadamore, are you comfortable to  include the patch for PPC64 as described in https://github.com/openjdk/jdk/pull/28931#discussion_r2662361633?
>
> For reference: hotspot uses the platform dependent constant `CCallingConventionRequiresIntsAsLongs`  for such issues. The value is `true` on PPC64 and s390 platforms (and SPARC in earlier JDK versions).

I believe the proposed patch to be reasonable given the limitations we already covered.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2713938064

From weijun at openjdk.org  Wed Jan 21 19:23:18 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 21 Jan 2026 19:23:18 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v9]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <UCEEkYIgcdU1sgsHoGcJ1VKn3a4bcmnlhtspj5_6s3I=.5242b6cc-d0f2-48cf-8814-9841faa72ab8@github.com>

> Rewrite the native calls with FFM.

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

  adding TheRealMDoerr's workaround

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/bf91106e..99604e06

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

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

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

From weijun at openjdk.org  Wed Jan 21 19:23:20 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 21 Jan 2026 19:23:20 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2]
In-Reply-To: <G1HpP1CVgjD-6dUfPU61Bj3FbScVg4pd_LZskbKdtvI=.dcbac94b-65aa-450d-8046-76e7a21b4664@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <qU5mvJSlw1yaIETHt9GNNjwvD1NHIV-UX5omiYHPvGA=.2c9e2dc9-f14f-4489-bcc9-5c19f007e67e@github.com>
 <G1HpP1CVgjD-6dUfPU61Bj3FbScVg4pd_LZskbKdtvI=.dcbac94b-65aa-450d-8046-76e7a21b4664@github.com>
Message-ID: <Yh8hK0WYmQOEBqJXDNeGjngi6aDYQho5ZHJn9L5kCRU=.90d0bc47-fdc7-4a8c-93f8-5fc002014281@github.com>

On Tue, 30 Dec 2025 23:00:31 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rewrite without jextract
>
> I've made some AIX experiments.

Hi @TheRealMDoerr, I've included your workaround. Please try it on your systems. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28931#issuecomment-3780725018

From mdoerr at openjdk.org  Wed Jan 21 19:23:21 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 Jan 2026 19:23:21 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5]
In-Reply-To: <BKAxFQOF2jFU1Ciwys3v_QX3FP6BNNTjBVdFYOo4Gvc=.6e63cb2c-8eb2-4bc7-95fb-7fe70c2f1c7d@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <L1_1LrqH4VA_RpsoY3qPeph3OYFPYQqyQ1RIafK7NMs=.3e3a569b-229a-4d57-9d80-629e99aa29b6@github.com>
 <M0pV1r0RTzKBuSYO7aB9MbSYmOW9iEA6kX9xq56Mch0=.7e98c697-536f-4f41-b7c8-5d2b77568a7e@github.com>
 <j93-14a3DaLRj6VNVvTsZM8aifHbCPGEMsdAzIldOs8=.78ea441e-6927-496b-ae6a-04c8692760ce@github.com>
 <llhqk5fQdM6aMJl2NU8OIvjukkO-YPmxJtvtq0qVWhk=.5b751024-26e0-41c3-ab99-68c475de66ac@github.com>
 <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com>
 <SOPWd5XCPtQJ_pMv9Mh6wBpJEO5c_L_hnUKPRkuXLSA=.b136913e-f4c3-4963-8958-b81447b9ed39@github.com>
 <GNmA2dCF_gTwdbIWFuhjxDNwezudbcZ6xs--Xr0a4nk=.a6c7068c-c045-4a65-887c-8d18a301f7ab@github.com>
 <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com>
 <txOVxNzs84Yzi7us6Mfsa5qCGDD4TKaRoCeyS8HAB6A=.f4cbd478-4231-4e10-a4e4-e2d97ea5fdf6@github.com>
 <JcIPyIKFV_TULuCKA4KOai7dtUOXpmsPMkN
 GApzbNVI=.fc17af48-7446-49e2-9ea7-25ee02b78513@github.com>
 <ICp8P3drsEE0wUkMZkSBA6l6ytgFsKF07w25fIk96UA=.f4b748a2-8960-47e0-88ac-1a7814beb7d0@github.com>
 <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com>
 <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com>
 <GFKfY2oRTFkx6oREn9vyWt6z4kZKjVeOObTQHSOwzyQ=.01405712-861b-45ca-a288-74d78634ef17@github.com>
 <c0LhwNEF-9txDUSvaFtT1PJNMrqZyafEq6gXq5eTYiE=.840fb221-e315-47bc-ac97-9b4b3cb2676b@github.com>
 <uLtjpxSm_9oOJqhkyASoPG9Tz_rccTerc1v6uwf9yNo=.68ff8f24-a8e0-4b39-b124-b36ca7d07776@github.com>
 <Tf3g4VZ5xTQ5EkiugzVAL-9NUsmYtV0lxCz0FK5TB78=.01c55ced-599c-432d-afca-91d25c625939@github.com>
 <un--qP6HOPN7VyxKxZLIUwJbVHgZbqZ_dwQYYbdF004=.4dee79fb-20f2-47ef-8965-a1e01e0e30c5@github.com>
 <BKAxFQOF2jFU1Ciwys3v_QX3FP6BNNTjBVdFYOo4Gvc=.6e63cb2c-8eb2-4bc7-95fb-7fe70c2f1c7d@github.com>
Message-ID: <f6A-D7YC82mfj80xSth99JvhOhvnSEptvzjgDaQp3EM=.e7e9f2d4-4c20-43a3-a336-11d025ad74d9@github.com>

On Wed, 21 Jan 2026 18:59:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> For reference: hotspot uses the platform dependent constant `CCallingConventionRequiresIntsAsLongs`  for such issues. The value is `true` on PPC64 and s390 platforms (and SPARC in earlier JDK versions).
>
> I believe the proposed patch to be reasonable given the limitations we already covered.

It would be nice to add a comment like:
We need to pass the uid as uint32_t which requires zero extension on some 64-bit platforms. JDK-8336664 is not yet available, so we extend it here for these platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714007305

From abarashev at openjdk.org  Wed Jan 21 19:24:17 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 21 Jan 2026 19:24:17 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v3]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <xt7nUl50aEDdGhu1hVfdERLdMLMoxsIXVIYKfwI-wR0=.509b0940-e218-4193-a825-eeb0a6a17430@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

 - Improve cache key checksum
 - Merge branch 'master' into JDK-8372526
 - Cache compressed local certificates
 - Merge branch 'master' into JDK-8372526
   
   # Conflicts:
   #	src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
 - Correct log message. Reformat file.
 - Update unit test
 - Merge branch 'master' into JDK-8372526
 - Add DefaultCertCompression unit test
 - Update copyright year and bug number plus some small changes
 - Revert SSLLogger changes
 - ... and 16 more: https://git.openjdk.org/jdk/compare/aaca0a2c...c859eb39

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

Changes: https://git.openjdk.org/jdk/pull/28682/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=02
  Stats: 1387 lines in 17 files changed: 1358 ins; 11 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

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

From mdoerr at openjdk.org  Wed Jan 21 19:25:10 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 Jan 2026 19:25:10 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v8]
In-Reply-To: <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com>
Message-ID: <rYzkfr_D0QYPxOZ2sa0znr0lmwv-leFnHuHn3UQAtiE=.748b6cfb-8dfb-45a1-ba9f-f37ab99c8900@github.com>

On Tue, 13 Jan 2026 21:17:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   new naming style; use VarHandle to access fields

Ah, you already added a comment referring to JDK-8336664. Looks good! Thanks a lot for taking care of it! We'll run tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/28931#issuecomment-3780744019

From weijun at openjdk.org  Wed Jan 21 19:39:49 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 21 Jan 2026 19:39:49 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>

> Rewrite the native calls with FFM.

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

  unnecessary initialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28931/files
  - new: https://git.openjdk.org/jdk/pull/28931/files/99604e06..0aec40c0

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

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

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

From hchao at openjdk.org  Wed Jan 21 20:31:10 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 21 Jan 2026 20:31:10 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints [v7]
In-Reply-To: <Pjr3WUCzlapr8nhnSalhXvNXVtbo7kzaS3XNph_iRaU=.0aff9384-b31d-41cd-ac92-fc64b96e1548@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
 <Pjr3WUCzlapr8nhnSalhXvNXVtbo7kzaS3XNph_iRaU=.0aff9384-b31d-41cd-ac92-fc64b96e1548@github.com>
Message-ID: <5pRXpaMT9a4bfIOT0pVRJMOgShErSyWaammJhnwo9HM=.4f13128a-5ae5-458e-aa93-86083bcf25fe@github.com>

On Wed, 21 Jan 2026 15:07:05 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> NamedGroup.SupportedGroups.namedGroups values are not being filtered against algorithm constraints, unlike other SSLParameters returned by SSLConfiguration#getSSLParameters() call. Those are the values being displayed to the user with "java -XshowSettings:security:tls" command.
>> 
>> Also making changes to avoid needless default group names lookup while we are touching this file.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix: add the Hybrid named group. Move the comment.

Marked as reviewed by hchao (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28397#pullrequestreview-3689274221

From mullan at openjdk.org  Wed Jan 21 20:31:11 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 21 Jan 2026 20:31:11 GMT
Subject: RFR: 8375549: ConcurrentModificationException if
 jdk.crypto.disabledAlgorithms has multiple entries with known oid
In-Reply-To: <9RX9ppMiYrgBmp9W8Lwn9KdcGd9O6xQU2WhJQ-I0W3M=.9c831100-bb9b-479d-9994-7de269b093b6@github.com>
References: <9RX9ppMiYrgBmp9W8Lwn9KdcGd9O6xQU2WhJQ-I0W3M=.9c831100-bb9b-479d-9994-7de269b093b6@github.com>
Message-ID: <WBkLjbL8C8uNa7cDYl8nQ_c_rz_zmka0JAjerR2sGy8=.307fa7bb-787a-4dae-921d-f6cca4926f8a@github.com>

On Tue, 20 Jan 2026 22:59:54 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Inside the CryptoAlgorithmConstraints constructor, there is a loop looking up the known oid. Iterating over the "disabledServices" set and inserting the found oid(s) into it leads to ConcurrentModificationException when the set contains multiple entries. The proposed fix is to iterating over the array converted from the set which is also used for debugging output instead of the "disabledServices" set itself.
> 
> Thanks,
> Valerie

test/jdk/javax/crypto/Cipher/TestDisabledWithOids.java line 33:

> 31:  */
> 32: import java.security.NoSuchAlgorithmException;
> 33: import java.security.Security;

Don't think you need this import.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29335#discussion_r2714227917

From mdoerr at openjdk.org  Wed Jan 21 20:32:14 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 Jan 2026 20:32:14 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
Message-ID: <Rd0PtNgjAakeqfR2MXWzjW7Haff4VL-0qC1vsE12_3Q=.941e3d47-8925-4412-b425-4423a51d342d@github.com>

On Wed, 21 Jan 2026 19:39:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unnecessary initialization

The test has passed on linux PPC64le and AIX. @offamitkumar: Do you want to run the test on s390?
I think it's good.
The JBS issue says "See if it's a better alternative of JNI." Is there any comparison or evaluation planned?

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 118:

> 116:             = LINKER.downcallHandle(SYMBOL_LOOKUP.findOrThrow(
> 117:                             OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
> 118:                     FunctionDescriptor.of(C_INT,

Indentation could be improved, here.

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

PR Review: https://git.openjdk.org/jdk/pull/28931#pullrequestreview-3689250234
PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714211087

From weijun at openjdk.org  Wed Jan 21 21:04:40 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 21 Jan 2026 21:04:40 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <Rd0PtNgjAakeqfR2MXWzjW7Haff4VL-0qC1vsE12_3Q=.941e3d47-8925-4412-b425-4423a51d342d@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
 <Rd0PtNgjAakeqfR2MXWzjW7Haff4VL-0qC1vsE12_3Q=.941e3d47-8925-4412-b425-4423a51d342d@github.com>
Message-ID: <14xLBqYrM9A7yRkPrXX2w23d3rBrjx02pZdwTzrte9Y=.aef64278-f25e-4c0c-a38e-de1f4b0b0e6e@github.com>

On Wed, 21 Jan 2026 20:23:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   unnecessary initialization
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 118:
> 
>> 116:             = LINKER.downcallHandle(SYMBOL_LOOKUP.findOrThrow(
>> 117:                             OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
>> 118:                     FunctionDescriptor.of(C_INT,
> 
> Indentation could be improved, here.

Do you have a suggestion? I intentionally indented based on argument nesting. `FunctionDescriptor.of(...` is the 2nd argument of `downcallHandle` so I indented one level (8 spaces) to the method. `OperatingSystem.isAix()...` is argument of `findOrThrow` and `calling_convention_requires_int_as_long...` etc are arguments of `FunctionDescriptor.of` and they are indented one level further. IntelliJ IDEA unindents the `FunctionDescriptor.of(...)` block but I don't think that's correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714326021

From weijun at openjdk.org  Wed Jan 21 21:13:58 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 21 Jan 2026 21:13:58 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <14xLBqYrM9A7yRkPrXX2w23d3rBrjx02pZdwTzrte9Y=.aef64278-f25e-4c0c-a38e-de1f4b0b0e6e@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
 <Rd0PtNgjAakeqfR2MXWzjW7Haff4VL-0qC1vsE12_3Q=.941e3d47-8925-4412-b425-4423a51d342d@github.com>
 <14xLBqYrM9A7yRkPrXX2w23d3rBrjx02pZdwTzrte9Y=.aef64278-f25e-4c0c-a38e-de1f4b0b0e6e@github.com>
Message-ID: <iqmJs8j886RTTMgrXLoLOqdgh5yDoskM0UkzKMtbGyw=.d23aaf74-2479-4c32-9e8b-96cccf9a06f7@github.com>

On Wed, 21 Jan 2026 21:01:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 118:
>> 
>>> 116:             = LINKER.downcallHandle(SYMBOL_LOOKUP.findOrThrow(
>>> 117:                             OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"),
>>> 118:                     FunctionDescriptor.of(C_INT,
>> 
>> Indentation could be improved, here.
>
> Do you have a suggestion? I intentionally indented based on argument nesting. `FunctionDescriptor.of(...` is the 2nd argument of `downcallHandle` so I indented one level (8 spaces) to the method. `OperatingSystem.isAix()...` is argument of `findOrThrow` and `calling_convention_requires_int_as_long...` etc are arguments of `FunctionDescriptor.of` and they are indented one level further. IntelliJ IDEA unindents the `FunctionDescriptor.of(...)` block but I think that's misleading.

As for whether it's a better alternative of JNI, FFM is usually considered at least as fast as JNI. In this case, on my Mac, the FFM version is much much faster. I guess the main reason is while the C code is quite small it calls back to Java object manipulation too much.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714356450

From hchao at openjdk.org  Wed Jan 21 21:20:02 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 21 Jan 2026 21:20:02 GMT
Subject: RFR: 8373408: SHA1withECDSA is not required for ECDHE and ECDSA
In-Reply-To: <i-iGO-kWjmBqfybfCYPiU0QBMw6FIj7ZnQNB3S6w2L0=.1631522d-62f3-4892-9d66-7955687b94f2@github.com>
References: <ZBDSdP8PhO2q3gjF10Xv8GKaWjxmwD5vO4p2ro_6qz4=.6e8e40fc-6087-41f1-8635-1239c755861f@github.com>
 <i-iGO-kWjmBqfybfCYPiU0QBMw6FIj7ZnQNB3S6w2L0=.1631522d-62f3-4892-9d66-7955687b94f2@github.com>
Message-ID: <zk8gi2tAjBAE-fWPkQNqmLPcBS6vQ06g3IBG91SwCVs=.154930b9-e175-4608-a4ca-d2c4c0bebfc4@github.com>

On Tue, 13 Jan 2026 10:59:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> SunJSSE should not probe SHA1withECDSA signature availably when determining if elliptic curve cryptography is available, as it is deprecated and not required for ECDHE and ECDSA signature schemes. This change removes SHA1withECDSA from the EC availability probe. TLS signature scheme availability is validated later during handshake negotiation.
>
> LGTM.
> 
> SHA1withECDSA (`SIGNATURE_ECDSA`) is required for ECDHE_ECDSA in TLS 1.1 and older. Starting with TLS 1.2, there are several hash algorithms available to choose from, and SHA1 is no longer required.

@djelinski @ascarpino Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/29184#issuecomment-3781207248

From mdoerr at openjdk.org  Wed Jan 21 21:32:11 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 Jan 2026 21:32:11 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
Message-ID: <7sNwX027pt2Pc7AHHZ9xBcTQe34A4UOAZwKGQZv1sZw=.a71ed3a2-d75d-4a2b-8f7b-7ebd8a5677a4@github.com>

On Wed, 21 Jan 2026 19:39:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unnecessary initialization

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28931#pullrequestreview-3689482675

From mdoerr at openjdk.org  Wed Jan 21 21:32:12 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 Jan 2026 21:32:12 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <iqmJs8j886RTTMgrXLoLOqdgh5yDoskM0UkzKMtbGyw=.d23aaf74-2479-4c32-9e8b-96cccf9a06f7@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
 <Rd0PtNgjAakeqfR2MXWzjW7Haff4VL-0qC1vsE12_3Q=.941e3d47-8925-4412-b425-4423a51d342d@github.com>
 <14xLBqYrM9A7yRkPrXX2w23d3rBrjx02pZdwTzrte9Y=.aef64278-f25e-4c0c-a38e-de1f4b0b0e6e@github.com>
 <iqmJs8j886RTTMgrXLoLOqdgh5yDoskM0UkzKMtbGyw=.d23aaf74-2479-4c32-9e8b-96cccf9a06f7@github.com>
Message-ID: <roADzDg--JnkPxUVHeq-hlkVHpjSL3fEkRCFYxcC4G8=.69a423b6-9ee5-49df-acb1-ef1e397464fe@github.com>

On Wed, 21 Jan 2026 21:11:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Do you have a suggestion? I intentionally indented based on argument nesting. `FunctionDescriptor.of(...` is the 2nd argument of `downcallHandle` so I indented one level (8 spaces) to the method. `OperatingSystem.isAix()...` is argument of `findOrThrow` and `calling_convention_requires_int_as_long...` etc are arguments of `FunctionDescriptor.of` and they are indented one level further. IntelliJ IDEA unindents the `FunctionDescriptor.of(...)` block but I think that's misleading.
>
> As for whether it's a better alternative of JNI, FFM is usually considered at least as fast as JNI. In this case, on my Mac, the FFM version is much much faster. I guess the main reason is while the C code is quite small it calls back to Java object manipulation too much.

> IntelliJ IDEA unindents the FunctionDescriptor.of(...) block but I think that's misleading.

That's what I thought.

Ok. Another advantage is that we don't need the .c file any more. If performance matters, we could still tune it by using the critical option. But I guess it's fast enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714401065

From hchao at openjdk.org  Wed Jan 21 21:46:59 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 21 Jan 2026 21:46:59 GMT
Subject: RFR: 8373408: SHA1withECDSA is not required for ECDHE and ECDSA
 [v2]
In-Reply-To: <ZBDSdP8PhO2q3gjF10Xv8GKaWjxmwD5vO4p2ro_6qz4=.6e8e40fc-6087-41f1-8635-1239c755861f@github.com>
References: <ZBDSdP8PhO2q3gjF10Xv8GKaWjxmwD5vO4p2ro_6qz4=.6e8e40fc-6087-41f1-8635-1239c755861f@github.com>
Message-ID: <AaDW6QJHLCne7onKRw4Bu0-SGTmbt5ozNi3_9KOWdMA=.fddb3840-3df3-41a6-ac65-f09cfb7ab598@github.com>

> SunJSSE should not probe SHA1withECDSA signature availably when determining if elliptic curve cryptography is available, as it is deprecated and not required for ECDHE and ECDSA signature schemes. This change removes SHA1withECDSA from the EC availability probe. TLS signature scheme availability is validated later during handshake negotiation.

Hai-May Chao 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
 - 8373408: SHA1withECDSA is not required for ECDHE and ECDSA

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29184/files
  - new: https://git.openjdk.org/jdk/pull/29184/files/1f449b34..661c1f6d

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

  Stats: 32061 lines in 627 files changed: 18317 ins; 6530 del; 7214 mod
  Patch: https://git.openjdk.org/jdk/pull/29184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29184/head:pull/29184

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

From duke at openjdk.org  Thu Jan 22 00:27:48 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 22 Jan 2026 00:27:48 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl
Message-ID: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>

Refactor sun.security.provider.X509Factory cache access to avoid coarse-grained locking and reduce contention during certificate/CRL interning and parsing.

As per request in [the PR](https://github.com/openjdk/jdk/pull/22616#issuecomment-2524971845), re-visit "the initialisation and locking in this area, e.g. addToCache is a static synchronized method so very coarse locking."

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

Commit messages:
 - 8345954: Revisit Class Initializers and Locking in X509TrustManagerImpl-switch back to existing helpers
 - 8345954: Revisit Class Initializers and Locking in X509TrustManagerImpl-minor cleanerup
 - Merge branch 'master' into 8345954
 - 8345954: Revisit Class Initializers and Locking in X509TrustManagerImpl

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

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

From ascarpino at openjdk.org  Thu Jan 22 00:58:40 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 22 Jan 2026 00:58:40 GMT
Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10]
In-Reply-To: <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
 <N5Nd5NgivZW-5RbX7q0vejpVssem8DGK2gEjtWcE1mk=.3329b2cb-e580-4a45-b6eb-d0d262617320@github.com>
Message-ID: <LB7K8sVYjox3LZ5K5lQOaSutPndTv4RiBRGV-S8Ijp0=.414a82ca-11a5-4b26-a6f9-14e48e6cd656@github.com>

On Wed, 21 Jan 2026 19:39:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Rewrite the native calls with FFM.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unnecessary initialization

Marked as reviewed by ascarpino (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28931#pullrequestreview-3690107628

From sshivang at openjdk.org  Thu Jan 22 03:35:24 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Thu, 22 Jan 2026 03:35:24 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <1sjspoLu_R0ZMvos2_mMIm5k36kAxH0NPbXRWbtpXDU=.86e2c8eb-2b8e-4d94-bfb8-68bf26bcd7a2@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

Ok I will quickly do this in 26u and ask for review. Closing this one.

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3782339473

From sshivang at openjdk.org  Thu Jan 22 03:35:24 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Thu, 22 Jan 2026 03:35:24 GMT
Subject: [jdk26] Withdrawn: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <Q4GMebawqxiQO_NlLyOMmocPK2Q0OwH_S-nEN7ODzWY=.c9ac2720-28df-426e-bd75-c4c4bb50deea@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

This pull request has been closed without being integrated.

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

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

From hchao at openjdk.org  Thu Jan 22 05:18:13 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 22 Jan 2026 05:18:13 GMT
Subject: RFR: 8328046: Need to keep leading zeros in TlsPremasterSecret of
 TLS1.3 DHKeyAgreement [v4]
In-Reply-To: <s0kEjUuUFTMBK-ONcxzRKXxKknk4Al9WdFVcI0DKEGM=.8b80ee2e-41cd-4648-bac8-15e204fbde7c@github.com>
References: <HFMfI-Mpd5KEUXNZ6qhyHs8UFRLDbZFBA1qvoWpQLqI=.c36c897d-6af8-4bc5-be99-fdcee492887d@github.com>
 <s0kEjUuUFTMBK-ONcxzRKXxKknk4Al9WdFVcI0DKEGM=.8b80ee2e-41cd-4648-bac8-15e204fbde7c@github.com>
Message-ID: <j8q6e-wqazLFHngTM3eVQJw-VV1zkP1GdryyKqwLioM=.73ef4628-1f1d-4875-b81c-819f8d062dab@github.com>

On Tue, 20 Jan 2026 20:34:19 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> TLS 1.3 changed the way it generates the FFDHE shared secret. In TLS 1.2, the leading zeroes in the shared secret were stripped, and in TLS 1.3 the leading zeroes are preserved.
>> 
>> Thanks to the recent work in [JDK-8189441](https://bugs.openjdk.org/browse/JDK-8189441), we now have a new algorithm name `Generic` that can be used to generate a shared secret with the leading zeroes preserved.
>> 
>> This PR changes the TLS 1.3 handshake to use the new algorithm name.
>> 
>> I didn't add any tests to verify the correctness of the handshake. This can be verified using tlsfuzzer, see JBS for details.
>> 
>> Tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into tls13-ffdhe
>  - Merge branch 'master' into tls13-ffdhe
>  - Revert PKCS11 changes
>  - Update copyright, add bug IDs
>  - Fix PKCS11 DH key derivation
>  - Keep leading zeroes in tls13

Marked as reviewed by hchao (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27343#pullrequestreview-3690624879

From hchao at openjdk.org  Thu Jan 22 05:24:12 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 22 Jan 2026 05:24:12 GMT
Subject: RFR: 8328046: Need to keep leading zeros in TlsPremasterSecret of
 TLS1.3 DHKeyAgreement [v4]
In-Reply-To: <s0kEjUuUFTMBK-ONcxzRKXxKknk4Al9WdFVcI0DKEGM=.8b80ee2e-41cd-4648-bac8-15e204fbde7c@github.com>
References: <HFMfI-Mpd5KEUXNZ6qhyHs8UFRLDbZFBA1qvoWpQLqI=.c36c897d-6af8-4bc5-be99-fdcee492887d@github.com>
 <s0kEjUuUFTMBK-ONcxzRKXxKknk4Al9WdFVcI0DKEGM=.8b80ee2e-41cd-4648-bac8-15e204fbde7c@github.com>
Message-ID: <wcFyCPgnjqgtz58HU_JCYuhqspQABKTOPl3sAbMyJFU=.bc28fe94-6eab-4d8b-a624-b5f90bd0b033@github.com>

On Tue, 20 Jan 2026 20:34:19 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> TLS 1.3 changed the way it generates the FFDHE shared secret. In TLS 1.2, the leading zeroes in the shared secret were stripped, and in TLS 1.3 the leading zeroes are preserved.
>> 
>> Thanks to the recent work in [JDK-8189441](https://bugs.openjdk.org/browse/JDK-8189441), we now have a new algorithm name `Generic` that can be used to generate a shared secret with the leading zeroes preserved.
>> 
>> This PR changes the TLS 1.3 handshake to use the new algorithm name.
>> 
>> I didn't add any tests to verify the correctness of the handshake. This can be verified using tlsfuzzer, see JBS for details.
>> 
>> Tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into tls13-ffdhe
>  - Merge branch 'master' into tls13-ffdhe
>  - Revert PKCS11 changes
>  - Update copyright, add bug IDs
>  - Fix PKCS11 DH key derivation
>  - Keep leading zeroes in tls13

nit: copyright year

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

PR Review: https://git.openjdk.org/jdk/pull/27343#pullrequestreview-3690636159

From clanger at openjdk.org  Thu Jan 22 09:43:13 2026
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 22 Jan 2026 09:43:13 GMT
Subject: RFR: 8375684: Avoid leak in KeystoreImpl.m when using
 CFArrayCreateMutable
In-Reply-To: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
References: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
Message-ID: <-7Bj__zDI_x-VwMsETGTdd08C4-zt12uLDtCjVpLSBA=.806bfd2a-c2cb-4d05-ba41-d1c828190698@github.com>

On Tue, 20 Jan 2026 16:47:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In KeystoreImpl.m we use CFArrayCreateMutable, but we do not always CFRelease the resources we created.
> This should be adjusted.
> 
> See
> https://developer.apple.com/documentation/corefoundation/cfarraycreatemutable(_:_:_:)
> 
> return value is  
> A new mutable array, or NULL if there was a problem creating the object. Ownership follows the [The Create Rule](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/20001148-103029).

Looks correct.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29326#pullrequestreview-3691520668

From weijun at openjdk.org  Thu Jan 22 12:06:21 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 22 Jan 2026 12:06:21 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl
In-Reply-To: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
Message-ID: <dTKV1ToChI6rATC34DQrkqojKMJy1_Si50yUjJJYnP0=.ba8f3b0b-fd7b-4c51-aefc-779b43ceec90@github.com>

On Tue, 13 Jan 2026 04:14:22 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> Refactor sun.security.provider.X509Factory cache access to avoid coarse-grained locking and reduce contention during certificate/CRL interning and parsing.
> 
> As per request in [the PR](https://github.com/openjdk/jdk/pull/22616#issuecomment-2524971845), re-visit "the initialisation and locking in this area, e.g. addToCache is a static synchronized method so very coarse locking."

Some comments.

src/java.base/share/classes/sun/security/provider/X509Factory.java line 94:

> 92:             synchronized (certCache) {
> 93:                 certCache.clear();
> 94:             }

This is just for debugging. Maybe not worth any protection.

src/java.base/share/classes/sun/security/provider/X509Factory.java line 183:

> 181:         X509CertImpl newC = isImpl ? (X509CertImpl) c : new X509CertImpl(encoding);
> 182:         byte[] enc = isImpl ? encoding : newC.getEncodedInternal();
> 183:         return addToCache(certCache, enc, newC);

Is this better than the old code? `isImpl` was only checked once.

src/java.base/share/classes/sun/security/provider/X509Factory.java line 230:

> 228:      * Add the X509CertImpl or X509CRLImpl to the cache.
> 229:      */
> 230:     private static <V> V addToCache(Cache<Object, V> cache, byte[] encoding, V value) {

Now that you added double check inside this method to ensure no cache, does it make sense to rename the method to be something like `addIfNotPresent`?

src/java.base/share/classes/sun/security/provider/X509Factory.java line 245:

> 243:     }
> 244: 
> 245: 

Newline?

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

PR Review: https://git.openjdk.org/jdk/pull/29181#pullrequestreview-3692030795
PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2716545800
PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2716567416
PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2716621763
PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2716550443

From weijun at openjdk.org  Thu Jan 22 12:19:07 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 22 Jan 2026 12:19:07 GMT
Subject: Integrated: 8277489: Rewrite JAAS UnixLoginModule with FFM
In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com>
Message-ID: <sSAJoOldLPU2fDE9jz-RiUv1DbEFJqVxYZ06xOnOVgE=.89873aed-4e70-4aeb-906b-22007c0bf731@github.com>

On Fri, 19 Dec 2025 17:56:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Rewrite the native calls with FFM.

This pull request has now been integrated.

Changeset: eda15aa1
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eda15aa19c36142984edaa08850132ca6ae7a369
Stats:     355 lines in 6 files changed: 190 ins; 135 del; 30 mod

8277489: Rewrite JAAS UnixLoginModule with FFM

Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: mdoerr, ascarpino, erikj

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

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

From mbaesken at openjdk.org  Thu Jan 22 12:31:42 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jan 2026 12:31:42 GMT
Subject: RFR: 8375684: Avoid leak in KeystoreImpl.m when using
 CFArrayCreateMutable
In-Reply-To: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
References: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
Message-ID: <om60lVZtJ3D4QkcTBHeaOaQS935_KVXP6jcLWEqdfdQ=.9afe539d-8d49-445c-9687-f2ed3cd2a202@github.com>

On Tue, 20 Jan 2026 16:47:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In KeystoreImpl.m we use CFArrayCreateMutable, but we do not always CFRelease the resources we created.
> This should be adjusted.
> 
> See
> https://developer.apple.com/documentation/corefoundation/cfarraycreatemutable(_:_:_:)
> 
> return value is  
> A new mutable array, or NULL if there was a problem creating the object. Ownership follows the [The Create Rule](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/20001148-103029).

Thanks for the review !

When looking at the same file, seems privateKeyRef from

SecKeyRef privateKeyRef;
err = SecIdentityCopyPrivateKey(theIdentity, &privateKeyRef);

https://github.com/openjdk/jdk/blob/5ba91fed345b078a67ad6bead1d8893bd9289f58/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m#L343

needs to be CFReleased too according to
https://developer.apple.com/documentation/security/secidentitycopyprivatekey(_:_:)


should I add this here or in a separate  PR ?

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

PR Comment: https://git.openjdk.org/jdk/pull/29326#issuecomment-3784135239

From dfuchs at openjdk.org  Thu Jan 22 12:38:15 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 22 Jan 2026 12:38:15 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v3]
In-Reply-To: <xt7nUl50aEDdGhu1hVfdERLdMLMoxsIXVIYKfwI-wR0=.509b0940-e218-4193-a825-eeb0a6a17430@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <xt7nUl50aEDdGhu1hVfdERLdMLMoxsIXVIYKfwI-wR0=.509b0940-e218-4193-a825-eeb0a6a17430@github.com>
Message-ID: <VublKY2XK48iwP0tzvpzK6O3Ej1VBmJ9u6Q0_IpXy5w=.e9f130a1-2af3-4881-ad28-7cfcaefde6f7@github.com>

On Wed, 21 Jan 2026 19:24:17 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Improve cache key checksum
>  - Merge branch 'master' into JDK-8372526
>  - Cache compressed local certificates
>  - Merge branch 'master' into JDK-8372526
>    
>    # Conflicts:
>    #	src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
>  - Correct log message. Reformat file.
>  - Update unit test
>  - Merge branch 'master' into JDK-8372526
>  - Add DefaultCertCompression unit test
>  - Update copyright year and bug number plus some small changes
>  - Revert SSLLogger changes
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/aaca0a2c...c859eb39

test/jdk/javax/net/ssl/HttpsURLConnection/HttpsCompressedCert.java line 32:

> 30: import java.net.http.HttpRequest;
> 31: import java.net.http.HttpResponse;
> 32: import javax.net.ssl.SSLParameters;

Since this test is not using HttpsURLConnection but the new HttpClient it would be better to bring it to `test/jdk/java/net/httpclient`

test/jdk/javax/net/ssl/HttpsURLConnection/HttpsCompressedCert.java line 58:

> 56:                         new URI("https://www.google.com/"))
> 57:                 .GET()
> 58:                 .build();

Maybe this should be a manual test since it's accessing a host on the public internet.
How difficult would it be to have a test that uses the jdk.net HttpServer instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2716718955
PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2716722820

From mdonovan at openjdk.org  Thu Jan 22 12:45:43 2026
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 22 Jan 2026 12:45:43 GMT
Subject: RFR: 8374001: sun/security/ skip without Exceptions [v2]
In-Reply-To: <9UiHxDfiSJwrgZHG1vlJnjwiLZsRFuWiVxeYDvsmqlU=.8dbcfb68-bd31-4345-9fc4-7cc2aee1d395@github.com>
References: <P1xMe3z5wtoG1l84Iu2IJNH-B2sUVchQ46SFYiOThPs=.18e8a2fe-dc84-45a7-98b0-f4568ca949e9@github.com>
 <9UiHxDfiSJwrgZHG1vlJnjwiLZsRFuWiVxeYDvsmqlU=.8dbcfb68-bd31-4345-9fc4-7cc2aee1d395@github.com>
Message-ID: <2wpzUHBeQEN5OnIwOXtfb-GiL8ynC1wDWl5dSH8Jz-U=.ce7d2c0c-1b85-4203-8572-6b0addecdcf2@github.com>

On Wed, 7 Jan 2026 11:22:54 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Pr cleaning up the tests left after the previous PRs.
>> 
>> * test/jdk/sun/security/util/Resources/Usages.java
>> * test/jdk/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java
>> * test/jdk/sun/security/krb5/config/ConfPlusProp.java
>> * test/jdk/sun/security/krb5/auto/ReplayCacheTestProc.java
>
> Mikhail Yankelevich 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:
> 
>  - updating to latest master and copyrights
>  - Merge branch 'master' into JDK-8374001
>  - JDK-8374001: sun/security/ skip without Exceptions

LGTM, one minor suggestion. You can take it or leave it.

test/jdk/sun/security/krb5/config/ConfPlusProp.java line 44:

> 42:                 System.getenv("LOGONSERVER") != null) {
> 43:             throw new SkippedException(
> 44:                     "Looks like a Windows machine in a domain.");

maybe change the message to "Test cannot run in a domain."?

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

PR Review: https://git.openjdk.org/jdk/pull/28898#pullrequestreview-3692262362
PR Review Comment: https://git.openjdk.org/jdk/pull/28898#discussion_r2716752770

From myankelevich at openjdk.org  Thu Jan 22 13:12:29 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 22 Jan 2026 13:12:29 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v8]
In-Reply-To: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
Message-ID: <zjupGHc6cSsSqCX2CgTKQrgoCUguX4zMCFedFr-dYTI=.22a01de0-a122-4e28-856a-8e0493db4a1c@github.com>

> Hi!
> 
> This is my proposal to transfer `KeyStore` and `KeyStoreSpi` with internal implementations to use `Instance`s instead of `Date`s. 
> I would be very grateful for your comments and suggestions.
> 
> Thanks!
> 
> P.S. this is related to [JDK-8350953](https://bugs.openjdk.org/browse/JDK-8350953)

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

  patter matching comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29140/files
  - new: https://git.openjdk.org/jdk/pull/29140/files/befe9989..8a5341ab

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

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

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

From myankelevich at openjdk.org  Thu Jan 22 13:12:32 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 22 Jan 2026 13:12:32 GMT
Subject: RFR: 8374808: Add new methods to KeyStore and KeyStoreSpi that
 return the creation date as an Instant instead of Date [v6]
In-Reply-To: <JeSvOa1W-XAxkEl8K7EUjGgUHzjbIkiH6boSwjx69qc=.2e8ea430-b4bb-4400-a20b-5c65c5c98173@github.com>
References: <umQgOXgNggyg2JGmpwuqZNCR8-Aa_RAiEJaOZwoCvCc=.e2bbe2c9-ef1c-4085-a909-a1aa07d473aa@github.com>
 <xv-A-k6AdppP_rZKbqp0qzwyvPmVPwvEM9dG9VdeJjc=.fea025af-5c5c-4cfc-9499-4939e93dd14d@github.com>
 <JeSvOa1W-XAxkEl8K7EUjGgUHzjbIkiH6boSwjx69qc=.2e8ea430-b4bb-4400-a20b-5c65c5c98173@github.com>
Message-ID: <R4EyOJjIuTvUhmwRDGPAz940Dhupu6m5Ie5_dEIab9E=.c720e759-844e-48ef-943e-dfc6d2c6779b@github.com>

On Wed, 21 Jan 2026 05:58:17 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc changes
>
> src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java line 240:
> 
>> 238: 
>> 239:         if (entry != null) {
>> 240:             if (entry instanceof TrustedCertEntry) {
> 
> instanceof pattern matching can be used.

Not sure if it is useful here to be honest, but updated anyway

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29140#discussion_r2716850587

From abarashev at openjdk.org  Thu Jan 22 13:14:52 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 22 Jan 2026 13:14:52 GMT
Subject: Integrated: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints
In-Reply-To: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
Message-ID: <EP9ZP6DVUcVy6hCobhtJ_1H4Wn4zsmqy719ZPsE60YU=.831f2d84-1066-4ebb-9467-a2905baf1e1e@github.com>

On Wed, 19 Nov 2025 17:26:25 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> NamedGroup.SupportedGroups.namedGroups values are not being filtered against algorithm constraints, unlike other SSLParameters returned by SSLConfiguration#getSSLParameters() call. Those are the values being displayed to the user with "java -XshowSettings:security:tls" command.
> 
> Also making changes to avoid needless default group names lookup while we are touching this file.

This pull request has now been integrated.

Changeset: 025041ba
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/025041ba04f3ae3a149b9d57d0dde4afaef37f4c
Stats:     234 lines in 2 files changed: 160 ins; 44 del; 30 mod

8370885: Default namedGroups values are not being filtered against algorithm constraints

Reviewed-by: hchao

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

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

From abarashev at openjdk.org  Thu Jan 22 16:20:33 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 22 Jan 2026 16:20:33 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v4]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <7xzWKZ7pSQgNGkw52uy-y-MrEpd_h3Rwv9aZlo-qCCQ=.90f237c6-8a1f-452f-a5f3-46f9420d38f0@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Use CRC32C checksum instead of Adler32 to reduce the chance of collision

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/c859eb39..7dad5f1b

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

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

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

From hchao at openjdk.org  Thu Jan 22 17:44:52 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 22 Jan 2026 17:44:52 GMT
Subject: Integrated: 8373408: SHA1withECDSA is not required for ECDHE and ECDSA
In-Reply-To: <ZBDSdP8PhO2q3gjF10Xv8GKaWjxmwD5vO4p2ro_6qz4=.6e8e40fc-6087-41f1-8635-1239c755861f@github.com>
References: <ZBDSdP8PhO2q3gjF10Xv8GKaWjxmwD5vO4p2ro_6qz4=.6e8e40fc-6087-41f1-8635-1239c755861f@github.com>
Message-ID: <yyjeEOnnDtUe_1cjFieElAXGA4MhoItD2694_ZGQ5pY=.5df36d19-f7ab-45bf-b4eb-9defbf9b13bb@github.com>

On Tue, 13 Jan 2026 07:47:15 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> SunJSSE should not probe SHA1withECDSA signature availably when determining if elliptic curve cryptography is available, as it is deprecated and not required for ECDHE and ECDSA signature schemes. This change removes SHA1withECDSA from the EC availability probe. TLS signature scheme availability is validated later during handshake negotiation.

This pull request has now been integrated.

Changeset: 96a2649e
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96a2649e29b8b4ff9b65b2314d430bc7637c5c61
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8373408: SHA1withECDSA is not required for ECDHE and ECDSA

Reviewed-by: djelinski, ascarpino

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

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

From djelinski at openjdk.org  Thu Jan 22 18:52:21 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jan 2026 18:52:21 GMT
Subject: RFR: 8328046: Need to keep leading zeros in TlsPremasterSecret of
 TLS1.3 DHKeyAgreement [v5]
In-Reply-To: <HFMfI-Mpd5KEUXNZ6qhyHs8UFRLDbZFBA1qvoWpQLqI=.c36c897d-6af8-4bc5-be99-fdcee492887d@github.com>
References: <HFMfI-Mpd5KEUXNZ6qhyHs8UFRLDbZFBA1qvoWpQLqI=.c36c897d-6af8-4bc5-be99-fdcee492887d@github.com>
Message-ID: <p0StbDTfGC0rCvv_zCIxTLDELLPws8zehjnsuHAQUi8=.fa9164fc-4aa7-4ae3-94d9-6432cc5c42a3@github.com>

> TLS 1.3 changed the way it generates the FFDHE shared secret. In TLS 1.2, the leading zeroes in the shared secret were stripped, and in TLS 1.3 the leading zeroes are preserved.
> 
> Thanks to the recent work in [JDK-8189441](https://bugs.openjdk.org/browse/JDK-8189441), we now have a new algorithm name `Generic` that can be used to generate a shared secret with the leading zeroes preserved.
> 
> This PR changes the TLS 1.3 handshake to use the new algorithm name.
> 
> I didn't add any tests to verify the correctness of the handshake. This can be verified using tlsfuzzer, see JBS for details.
> 
> Tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27343/files
  - new: https://git.openjdk.org/jdk/pull/27343/files/e13078d9..4e4b0532

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

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

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

From hchao at openjdk.org  Thu Jan 22 19:05:59 2026
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 22 Jan 2026 19:05:59 GMT
Subject: RFR: 8328046: Need to keep leading zeros in TlsPremasterSecret of
 TLS1.3 DHKeyAgreement [v5]
In-Reply-To: <p0StbDTfGC0rCvv_zCIxTLDELLPws8zehjnsuHAQUi8=.fa9164fc-4aa7-4ae3-94d9-6432cc5c42a3@github.com>
References: <HFMfI-Mpd5KEUXNZ6qhyHs8UFRLDbZFBA1qvoWpQLqI=.c36c897d-6af8-4bc5-be99-fdcee492887d@github.com>
 <p0StbDTfGC0rCvv_zCIxTLDELLPws8zehjnsuHAQUi8=.fa9164fc-4aa7-4ae3-94d9-6432cc5c42a3@github.com>
Message-ID: <Au-mduzt_DA2KNWHvFuoT-l-zX-R24Uw7qjVJGbP32g=.05049fac-746a-4cee-bd92-966a7cb9c1d6@github.com>

On Thu, 22 Jan 2026 18:52:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> TLS 1.3 changed the way it generates the FFDHE shared secret. In TLS 1.2, the leading zeroes in the shared secret were stripped, and in TLS 1.3 the leading zeroes are preserved.
>> 
>> Thanks to the recent work in [JDK-8189441](https://bugs.openjdk.org/browse/JDK-8189441), we now have a new algorithm name `Generic` that can be used to generate a shared secret with the leading zeroes preserved.
>> 
>> This PR changes the TLS 1.3 handshake to use the new algorithm name.
>> 
>> I didn't add any tests to verify the correctness of the handshake. This can be verified using tlsfuzzer, see JBS for details.
>> 
>> Tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Looks good. Thanks.

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

Marked as reviewed by hchao (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27343#pullrequestreview-3694051055

From djelinski at openjdk.org  Thu Jan 22 19:06:00 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jan 2026 19:06:00 GMT
Subject: RFR: 8328046: Need to keep leading zeros in TlsPremasterSecret of
 TLS1.3 DHKeyAgreement [v5]
In-Reply-To: <Au-mduzt_DA2KNWHvFuoT-l-zX-R24Uw7qjVJGbP32g=.05049fac-746a-4cee-bd92-966a7cb9c1d6@github.com>
References: <HFMfI-Mpd5KEUXNZ6qhyHs8UFRLDbZFBA1qvoWpQLqI=.c36c897d-6af8-4bc5-be99-fdcee492887d@github.com>
 <p0StbDTfGC0rCvv_zCIxTLDELLPws8zehjnsuHAQUi8=.fa9164fc-4aa7-4ae3-94d9-6432cc5c42a3@github.com>
 <Au-mduzt_DA2KNWHvFuoT-l-zX-R24Uw7qjVJGbP32g=.05049fac-746a-4cee-bd92-966a7cb9c1d6@github.com>
Message-ID: <VLY6DFDz-lFmtXknjNjp7ACuwRihkrB7T5-KFEZ0RM0=.97417ae1-4846-43e7-8b1a-b5afb7aa460b@github.com>

On Thu, 22 Jan 2026 19:00:53 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright
>
> Looks good. Thanks.

Thanks @haimaychao for the re-review!

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

PR Comment: https://git.openjdk.org/jdk/pull/27343#issuecomment-3786171540

From mullan at openjdk.org  Thu Jan 22 20:41:57 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 22 Jan 2026 20:41:57 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v4]
In-Reply-To: <SsqcFUEplYv6T9rqb1-9wE7K7ANRTYyJuab6lS9H5JM=.64eb3edf-3711-480b-a69f-0c1484018120@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <SsqcFUEplYv6T9rqb1-9wE7K7ANRTYyJuab6lS9H5JM=.64eb3edf-3711-480b-a69f-0c1484018120@github.com>
Message-ID: <IltpbQr6-7MVtoHHKjiePl8POxjbr0uZsVd2spga0CA=.425de191-c60d-4a69-91f9-3b9bbbeaefa4@github.com>

On Tue, 10 Jun 2025 14:41:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded when a new key pair is generated or when `KeyFactory::translateKey` is called.
>> 
>> By default, the choice is "seed".
>> 
>> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is calculated from the input if it's seed only.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into 8347938
>  - KeyChoices class
>  - allow expanded to be null
>  - merge
>  - Merge
>  - safer privKeyToPubKey; updated desciptions for the properties; adding braces to if blocks
>  - the fix

src/java.base/share/classes/sun/security/util/KeyChoices.java line 46:

> 44:  *       }
> 45:  * </pre>
> 46:  * This class supports reading, writing, and convert between them.

s/convert/converting/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2237859524

From mullan at openjdk.org  Thu Jan 22 20:41:52 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 22 Jan 2026 20:41:52 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v10]
In-Reply-To: <7GibXbpYksp4f8ltqrU5CfPzApSKW6zgI0IJfSvEZh0=.b0b6c420-5d25-4b99-b595-3088430f969b@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <7GibXbpYksp4f8ltqrU5CfPzApSKW6zgI0IJfSvEZh0=.b0b6c420-5d25-4b99-b595-3088430f969b@github.com>
Message-ID: <d7NRIW39zUVX1JGsZ8n9M3zWZMdaP-EOd-qnudut2nc=.70afb0a9-65bb-48d5-8682-3e59533e06a5@github.com>

On Wed, 14 Jan 2026 14:25:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded when a new key pair is generated or when `KeyFactory::translateKey` is called.
>> 
>> By default, the choice is "seed".
>> 
>> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is calculated from the input if it's seed only.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into 8347938
>  - one RFC; some java.security word changes
>  - fixed merge error
>  - merge
>  - merge
>  - Ben comment
>  - combine security properties description; remove one test
>  - Merge branch 'master' into 8347938
>  - KeyChoices class
>  - allow expanded to be null
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/20bd178b...dfbcaa09

Sending you a couple of minor comments for now. Going to take me a little while longer to get through this review.

src/java.base/share/conf/security/java.security line 1662:

> 1660: # PKCS #8 encoding format for newly created ML-KEM and ML-DSA private keys
> 1661: #
> 1662: # draft-ietf-lamps-kyber-certificates-11 and RFC 9881 define three possible formats for a private key:

This line looks a bit longer than 80 chars.

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

PR Review: https://git.openjdk.org/jdk/pull/24969#pullrequestreview-3064612877
PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2716858331

From abarashev at openjdk.org  Thu Jan 22 21:22:19 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 22 Jan 2026 21:22:19 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v5]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <t5S0D-cD60SSAlNQC9WsBK0RWkVQC4obNbCg6OIo5s8=.840c1424-197e-4681-b9ef-94b9fb0b7695@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Move HttpsCompressedCert test to test/jdk/java/net/httpclient and make it manual

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/7dad5f1b..b53a5fca

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

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

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

From abarashev at openjdk.org  Thu Jan 22 21:25:54 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 22 Jan 2026 21:25:54 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v3]
In-Reply-To: <VublKY2XK48iwP0tzvpzK6O3Ej1VBmJ9u6Q0_IpXy5w=.e9f130a1-2af3-4881-ad28-7cfcaefde6f7@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <xt7nUl50aEDdGhu1hVfdERLdMLMoxsIXVIYKfwI-wR0=.509b0940-e218-4193-a825-eeb0a6a17430@github.com>
 <VublKY2XK48iwP0tzvpzK6O3Ej1VBmJ9u6Q0_IpXy5w=.e9f130a1-2af3-4881-ad28-7cfcaefde6f7@github.com>
Message-ID: <jTnbHt-qo_5er7PRFhHE_Wtt9HxCm55FtYPmZNfV0Nk=.2b2b7afa-aa02-4acd-9e51-4b25929b4678@github.com>

On Thu, 22 Jan 2026 12:33:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Improve cache key checksum
>>  - Merge branch 'master' into JDK-8372526
>>  - Cache compressed local certificates
>>  - Merge branch 'master' into JDK-8372526
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
>>  - Correct log message. Reformat file.
>>  - Update unit test
>>  - Merge branch 'master' into JDK-8372526
>>  - Add DefaultCertCompression unit test
>>  - Update copyright year and bug number plus some small changes
>>  - Revert SSLLogger changes
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/aaca0a2c...c859eb39
>
> test/jdk/java/net/httpclient/HttpsCompressedCert.java line 32:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Since this test is not using HttpsURLConnection but the new HttpClient it would be better to bring it to `test/jdk/java/net/httpclient`

Indeed, moved it to `test/jdk/java/net/httpclient`, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2718684416

From abarashev at openjdk.org  Thu Jan 22 21:30:10 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 22 Jan 2026 21:30:10 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v3]
In-Reply-To: <VublKY2XK48iwP0tzvpzK6O3Ej1VBmJ9u6Q0_IpXy5w=.e9f130a1-2af3-4881-ad28-7cfcaefde6f7@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <xt7nUl50aEDdGhu1hVfdERLdMLMoxsIXVIYKfwI-wR0=.509b0940-e218-4193-a825-eeb0a6a17430@github.com>
 <VublKY2XK48iwP0tzvpzK6O3Ej1VBmJ9u6Q0_IpXy5w=.e9f130a1-2af3-4881-ad28-7cfcaefde6f7@github.com>
Message-ID: <odMLhlpTATP9ddLWSFrpQ5oglsROYTkvaDUlQyxqRS4=.0c113cf8-6fa3-4392-af92-3264f09706ef@github.com>

On Thu, 22 Jan 2026 12:33:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Improve cache key checksum
>>  - Merge branch 'master' into JDK-8372526
>>  - Cache compressed local certificates
>>  - Merge branch 'master' into JDK-8372526
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
>>  - Correct log message. Reformat file.
>>  - Update unit test
>>  - Merge branch 'master' into JDK-8372526
>>  - Add DefaultCertCompression unit test
>>  - Update copyright year and bug number plus some small changes
>>  - Revert SSLLogger changes
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/aaca0a2c...c859eb39
>
> test/jdk/javax/net/ssl/HttpsURLConnection/HttpsCompressedCert.java line 58:
> 
>> 56:                         new URI("https://www.google.com/"))
>> 57:                 .GET()
>> 58:                 .build();
> 
> Maybe this should be a manual test since it's accessing a host on the public internet.
> How difficult would it be to have a test that uses the jdk.net HttpServer instead?

I made it manual, thanks! I'll work on `HttpServer` test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2718696868

From duke at openjdk.org  Thu Jan 22 21:45:36 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 22 Jan 2026 21:45:36 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays [v5]
In-Reply-To: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
Message-ID: <0fhR-jmXGNfkqXDhpysfOXl0fTmHnVXAzupT5IoI37E=.f459aea6-4ca8-455b-953a-ec97ef5a013e@github.com>

> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.

Koushik Muthukrishnan Thirupattur has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - 8370688: Updated the documentation to describe the behavior using @implSpec
 - Merge branch 'master' into 8370688
 - 8370688: Addressed review comments-removed this method in the return label
 - 8370688: Addressed review comments-moved the sentence to return label
 - 8370688: Addressed review comments - add explicit note similar to SSLParameters
 - 8370688: Addressed review comments
 - 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28615/files
  - new: https://git.openjdk.org/jdk/pull/28615/files/cc77e339..548af3e6

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

  Stats: 117807 lines in 3863 files changed: 67264 ins; 24612 del; 25931 mod
  Patch: https://git.openjdk.org/jdk/pull/28615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28615/head:pull/28615

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

From djelinski at openjdk.org  Thu Jan 22 21:51:45 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jan 2026 21:51:45 GMT
Subject: Integrated: 8328046: Need to keep leading zeros in TlsPremasterSecret
 of TLS1.3 DHKeyAgreement
In-Reply-To: <HFMfI-Mpd5KEUXNZ6qhyHs8UFRLDbZFBA1qvoWpQLqI=.c36c897d-6af8-4bc5-be99-fdcee492887d@github.com>
References: <HFMfI-Mpd5KEUXNZ6qhyHs8UFRLDbZFBA1qvoWpQLqI=.c36c897d-6af8-4bc5-be99-fdcee492887d@github.com>
Message-ID: <VgyufcCjd8XIFsySftkF7YEDR2sSg8FodaR_xZC3oY0=.48554d0a-f334-4c91-9a6d-fd88690a7710@github.com>

On Wed, 17 Sep 2025 12:15:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> TLS 1.3 changed the way it generates the FFDHE shared secret. In TLS 1.2, the leading zeroes in the shared secret were stripped, and in TLS 1.3 the leading zeroes are preserved.
> 
> Thanks to the recent work in [JDK-8189441](https://bugs.openjdk.org/browse/JDK-8189441), we now have a new algorithm name `Generic` that can be used to generate a shared secret with the leading zeroes preserved.
> 
> This PR changes the TLS 1.3 handshake to use the new algorithm name.
> 
> I didn't add any tests to verify the correctness of the handshake. This can be verified using tlsfuzzer, see JBS for details.
> 
> Tier1-3 tests continue to pass.

This pull request has now been integrated.

Changeset: 25d2b52a
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25d2b52ab97d116024872e567c1c1ffd814616d4
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8328046: Need to keep leading zeros in TlsPremasterSecret of TLS1.3 DHKeyAgreement

Reviewed-by: hchao

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

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

From duke at openjdk.org  Thu Jan 22 21:54:35 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 22 Jan 2026 21:54:35 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays [v6]
In-Reply-To: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
Message-ID: <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com>

> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8370688: Updated the documentation to describe the behavior using @implSpec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28615/files
  - new: https://git.openjdk.org/jdk/pull/28615/files/548af3e6..753154a3

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

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

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

From duke at openjdk.org  Thu Jan 22 23:51:42 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 22 Jan 2026 23:51:42 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v2]
In-Reply-To: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
Message-ID: <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>

> Refactor sun.security.provider.X509Factory cache access to avoid coarse-grained locking and reduce contention during certificate/CRL interning and parsing.
> 
> As per request in [the PR](https://github.com/openjdk/jdk/pull/22616#issuecomment-2524971845), re-visit "the initialisation and locking in this area, e.g. addToCache is a static synchronized method so very coarse locking."

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8345954: Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29181/files
  - new: https://git.openjdk.org/jdk/pull/29181/files/ef780e2c..bf2ccdab

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

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

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

From duke at openjdk.org  Thu Jan 22 23:51:43 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 22 Jan 2026 23:51:43 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v2]
In-Reply-To: <dTKV1ToChI6rATC34DQrkqojKMJy1_Si50yUjJJYnP0=.ba8f3b0b-fd7b-4c51-aefc-779b43ceec90@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <dTKV1ToChI6rATC34DQrkqojKMJy1_Si50yUjJJYnP0=.ba8f3b0b-fd7b-4c51-aefc-779b43ceec90@github.com>
Message-ID: <T6OeAmtyjPbcBg5aqwy5qS9MkuCxFCEn6A5EdmRPMIo=.cd92b4f1-ae3c-43f3-9acd-60b15ab0e2f3@github.com>

On Thu, 22 Jan 2026 11:46:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8345954: Addressing review comments
>
> src/java.base/share/classes/sun/security/provider/X509Factory.java line 183:
> 
>> 181:         X509CertImpl newC = isImpl ? (X509CertImpl) c : new X509CertImpl(encoding);
>> 182:         byte[] enc = isImpl ? encoding : newC.getEncodedInternal();
>> 183:         return addToCache(certCache, enc, newC);
> 
> Is this better than the old code? `isImpl` was only checked once.

Makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2719068938

From valeriep at openjdk.org  Fri Jan 23 00:57:01 2026
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 23 Jan 2026 00:57:01 GMT
Subject: RFR: 8375549: ConcurrentModificationException if
 jdk.crypto.disabledAlgorithms has multiple entries with known oid [v2]
In-Reply-To: <9RX9ppMiYrgBmp9W8Lwn9KdcGd9O6xQU2WhJQ-I0W3M=.9c831100-bb9b-479d-9994-7de269b093b6@github.com>
References: <9RX9ppMiYrgBmp9W8Lwn9KdcGd9O6xQU2WhJQ-I0W3M=.9c831100-bb9b-479d-9994-7de269b093b6@github.com>
Message-ID: <rI3-GSG8pWW4qmbX32hKYJt_zomSS-9XfJX3OqoPEBQ=.05536cca-8f3e-46a1-868f-c57163974b25@github.com>

> Inside the CryptoAlgorithmConstraints constructor, there is a loop looking up the known oid. Iterating over the "disabledServices" set and inserting the found oid(s) into it leads to ConcurrentModificationException when the set contains multiple entries. The proposed fix is to iterating over the array converted from the set which is also used for debugging output instead of the "disabledServices" set itself.
> 
> Thanks,
> Valerie

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

  Removed an unused import from test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29335/files
  - new: https://git.openjdk.org/jdk/pull/29335/files/2032d24b..ce3fb4fa

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

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

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

From abarashev at openjdk.org  Fri Jan 23 03:33:52 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 23 Jan 2026 03:33:52 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v6]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <nAZwEBGOjjuzpDS-22fH9dZj1Mfup-ESeB-4MJjwzJ8=.29f59844-4fac-4b40-9785-e8f576482d14@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

 - Add COMPRESSED_CERTIFICATE to the QUIC list of expected TLS messages
 - Add back the library directive

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/b53a5fca..ef0a8f04

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

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

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

From mbaesken at openjdk.org  Fri Jan 23 09:07:53 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 23 Jan 2026 09:07:53 GMT
Subject: RFR: 8375684: Avoid leak in KeystoreImpl.m when using
 CFArrayCreateMutable
In-Reply-To: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
References: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
Message-ID: <96c8AhZO2eSs4t-28qf4CdiRZIfsV5wB2nDHYqC3JzM=.ff40fd59-3a81-4c40-897b-e6933485de2b@github.com>

On Tue, 20 Jan 2026 16:47:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In KeystoreImpl.m we use CFArrayCreateMutable, but we do not always CFRelease the resources we created.
> This should be adjusted.
> 
> See
> https://developer.apple.com/documentation/corefoundation/cfarraycreatemutable(_:_:_:)
> 
> return value is  
> A new mutable array, or NULL if there was a problem creating the object. Ownership follows the [The Create Rule](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/20001148-103029).

Seems
SecKeychainCopyDefault
needs a CFRelease too .
See   https://developer.apple.com/documentation/security/seckeychaincopydefault(_:)  .

But I do not see one here afterwards
https://github.com/openjdk/jdk/blob/fa20391e73102a5d6a5b0a760d95a4225c673e04/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m#L769

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

PR Comment: https://git.openjdk.org/jdk/pull/29326#issuecomment-3789169638

From mbaesken at openjdk.org  Fri Jan 23 09:21:30 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 23 Jan 2026 09:21:30 GMT
Subject: RFR: 8375684: Avoid leak in KeystoreImpl.m when using
 CFArrayCreateMutable
In-Reply-To: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
References: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
Message-ID: <jDlXHu96ZfF6wrRMBzR3TA06ZdkW7-uuvaUDbFArQOs=.0dc5ca5c-2749-4243-85fd-f7c76bc82ee1@github.com>

On Tue, 20 Jan 2026 16:47:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In KeystoreImpl.m we use CFArrayCreateMutable, but we do not always CFRelease the resources we created.
> This should be adjusted.
> 
> See
> https://developer.apple.com/documentation/corefoundation/cfarraycreatemutable(_:_:_:)
> 
> return value is  
> A new mutable array, or NULL if there was a problem creating the object. Ownership follows the [The Create Rule](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/20001148-103029).

@wangweij , could you please comment on the potential function usages that miss CFRelease ?
Should I address the other too in this PR or better in another one  ?

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

PR Comment: https://git.openjdk.org/jdk/pull/29326#issuecomment-3789233374

From jpai at openjdk.org  Fri Jan 23 09:32:30 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 Jan 2026 09:32:30 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v6]
In-Reply-To: <nAZwEBGOjjuzpDS-22fH9dZj1Mfup-ESeB-4MJjwzJ8=.29f59844-4fac-4b40-9785-e8f576482d14@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <nAZwEBGOjjuzpDS-22fH9dZj1Mfup-ESeB-4MJjwzJ8=.29f59844-4fac-4b40-9785-e8f576482d14@github.com>
Message-ID: <6cs-_wTI-PO4suA-EQSfzgqBbCwohpLzMGeY7I46IMA=.1d919135-157c-4c43-8b75-61db7ac6a6dd@github.com>

On Fri, 23 Jan 2026 03:33:52 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add COMPRESSED_CERTIFICATE to the QUIC list of expected TLS messages
>  - Add back the library directive

src/java.base/share/classes/sun/security/ssl/CompressionAlgorithm.java line 98:

> 96: 
> 97:         Map<Integer, Function<byte[], byte[]>> inflaters =
> 98:                 new LinkedHashMap<>(config.certInflaters.size());

Hello Artur, is this intentionally using the constructor which takes a `initialCapacity` or was it meant to be the number of expected mappings? If it's the latter, then there's `LinkedHashMap.newLinkedHashMap()` method https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/LinkedHashMap.html#newLinkedHashMap(int) which takes the expected number of mappings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2720415224

From vyazici at openjdk.org  Fri Jan 23 13:50:39 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 23 Jan 2026 13:50:39 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <ILLRs0p4F_EwS1Qxnn-VCMaNpOG8qp-S06b8pWzuRfQ=.8ae1f46e-60d2-4747-bafb-96e64270caef@github.com>

On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

I'd like to provide some help for reviewers:

1. [JDK-8361842] (integrated in 655dc516c22) implemented changes for `java.lang.StringCoding`
2. [JDK-8374210] (integrated in 7e18de137c3) reported regressions against JDK-8361842, and used as the BACKOUT issue.
3. [JDK-8374582] (this PR) is the REDO of JDK-8361842, plus the fix for regressions reported in JDK-8374210

That is, this PR starts with 3c466d372b7 (i.e, the revert of 7e18de137c3), and continues with the fix, which is **the interesting part, and that can be viewed by diff'ing 3c466d372b7...ff22857609d**. (ff22857609d is the last commit as of date.)

[JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
[JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210
[JDK-8374582]: https://bugs.openjdk.org/browse/JDK-8374582

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

PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3790314570

From mullan at openjdk.org  Fri Jan 23 14:13:47 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 23 Jan 2026 14:13:47 GMT
Subject: RFR: 8375549: ConcurrentModificationException if
 jdk.crypto.disabledAlgorithms has multiple entries with known oid [v2]
In-Reply-To: <rI3-GSG8pWW4qmbX32hKYJt_zomSS-9XfJX3OqoPEBQ=.05536cca-8f3e-46a1-868f-c57163974b25@github.com>
References: <9RX9ppMiYrgBmp9W8Lwn9KdcGd9O6xQU2WhJQ-I0W3M=.9c831100-bb9b-479d-9994-7de269b093b6@github.com>
 <rI3-GSG8pWW4qmbX32hKYJt_zomSS-9XfJX3OqoPEBQ=.05536cca-8f3e-46a1-868f-c57163974b25@github.com>
Message-ID: <obsfoZ0PqP5122RPdXp8jqghkUjgMV4I6YzW3Z5-LfQ=.ca2b5b91-8c39-4799-85be-b26021ef7d71@github.com>

On Fri, 23 Jan 2026 00:57:01 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Inside the CryptoAlgorithmConstraints constructor, there is a loop looking up the known oid. Iterating over the "disabledServices" set and inserting the found oid(s) into it leads to ConcurrentModificationException when the set contains multiple entries. The proposed fix is to iterating over the array converted from the set which is also used for debugging output instead of the "disabledServices" set itself.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed an unused import from test.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29335#pullrequestreview-3697697634

From mullan at openjdk.org  Fri Jan 23 14:21:37 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 23 Jan 2026 14:21:37 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays [v6]
In-Reply-To: <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
 <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com>
Message-ID: <YB_ei3o3uGsuH1Y-OmRZPG0eWIXTB7RFbfpf-3P8AMQ=.5b1712b6-40ee-4de8-a7d7-383f203a999d@github.com>

On Thu, 22 Jan 2026 21:54:35 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8370688: Updated the documentation to describe the behavior using @implSpec

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28615#pullrequestreview-3697740377

From mullan at openjdk.org  Fri Jan 23 14:23:49 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 23 Jan 2026 14:23:49 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v10]
In-Reply-To: <7GibXbpYksp4f8ltqrU5CfPzApSKW6zgI0IJfSvEZh0=.b0b6c420-5d25-4b99-b595-3088430f969b@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <7GibXbpYksp4f8ltqrU5CfPzApSKW6zgI0IJfSvEZh0=.b0b6c420-5d25-4b99-b595-3088430f969b@github.com>
Message-ID: <yD5J9eaSpXFtVvBZ0HmFQ-MhN_oFNqqPeGi7eKTyzN8=.439564dd-5113-46b1-96d2-f91a1ecb3010@github.com>

On Wed, 14 Jan 2026 14:25:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded when a new key pair is generated or when `KeyFactory::translateKey` is called.
>> 
>> By default, the choice is "seed".
>> 
>> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is calculated from the input if it's seed only.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into 8347938
>  - one RFC; some java.security word changes
>  - fixed merge error
>  - merge
>  - merge
>  - Ben comment
>  - combine security properties description; remove one test
>  - Merge branch 'master' into 8347938
>  - KeyChoices class
>  - allow expanded to be null
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/20bd178b...dfbcaa09

test/jdk/sun/security/provider/named/NamedKeys.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8347938 8347941

Remove 8347941, it is a dup of 8347938.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2721330629

From weijun at openjdk.org  Fri Jan 23 14:45:08 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 23 Jan 2026 14:45:08 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v11]
In-Reply-To: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
Message-ID: <lpHIcDRmHLIUnisarrbiRRDzyZy9Lec6LoqZhh_1-HI=.ff8c5701-27f5-4698-a13c-23e32c0b04f9@github.com>

> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded when a new key pair is generated or when `KeyFactory::translateKey` is called.
> 
> By default, the choice is "seed".
> 
> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is calculated from the input if it's seed only.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge from master
 - Merge branch 'master' into 8347938
 - one RFC; some java.security word changes
 - fixed merge error
 - merge
 - merge
 - Ben comment
 - combine security properties description; remove one test
 - Merge branch 'master' into 8347938
 - KeyChoices class
 - ... and 5 more: https://git.openjdk.org/jdk/compare/6f6966b2...3ffc5362

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

Changes: https://git.openjdk.org/jdk/pull/24969/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24969&range=10
  Stats: 2458 lines in 24 files changed: 1699 ins; 548 del; 211 mod
  Patch: https://git.openjdk.org/jdk/pull/24969.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24969/head:pull/24969

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

From weijun at openjdk.org  Fri Jan 23 14:45:14 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 23 Jan 2026 14:45:14 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v10]
In-Reply-To: <d7NRIW39zUVX1JGsZ8n9M3zWZMdaP-EOd-qnudut2nc=.70afb0a9-65bb-48d5-8682-3e59533e06a5@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <7GibXbpYksp4f8ltqrU5CfPzApSKW6zgI0IJfSvEZh0=.b0b6c420-5d25-4b99-b595-3088430f969b@github.com>
 <d7NRIW39zUVX1JGsZ8n9M3zWZMdaP-EOd-qnudut2nc=.70afb0a9-65bb-48d5-8682-3e59533e06a5@github.com>
Message-ID: <JReYXBuoiZBgcWSMHiEes9u2wZx6g-jGCuvIjw41kLc=.b4cefae0-1ede-4f23-9062-c5e2e0689388@github.com>

On Thu, 22 Jan 2026 13:11:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' into 8347938
>>  - one RFC; some java.security word changes
>>  - fixed merge error
>>  - merge
>>  - merge
>>  - Ben comment
>>  - combine security properties description; remove one test
>>  - Merge branch 'master' into 8347938
>>  - KeyChoices class
>>  - allow expanded to be null
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/20bd178b...dfbcaa09
>
> src/java.base/share/conf/security/java.security line 1662:
> 
>> 1660: # PKCS #8 encoding format for newly created ML-KEM and ML-DSA private keys
>> 1661: #
>> 1662: # draft-ietf-lamps-kyber-certificates-11 and RFC 9881 define three possible formats for a private key:
> 
> This line looks a bit longer than 80 chars.

Oh, I intentionally did it so when the I-D becomes an RFC, the line is not too long and not too short.

I can make it short now and rearrange the lines later.

> test/jdk/sun/security/provider/named/NamedKeys.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 8347938 8347941
> 
> Remove 8347941, it is a dup of 8347938.

Good catch. I'll remove all mentioning of it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2721482610
PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2721486906

From weijun at openjdk.org  Fri Jan 23 14:49:12 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 23 Jan 2026 14:49:12 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v12]
In-Reply-To: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
Message-ID: <c9pcA-G-P_63a9ICfLwNe3iodcQiFJNX40K0MtsIZCI=.ce04424e-7233-4dd7-af2e-0a4f1e230f59@github.com>

> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded when a new key pair is generated or when `KeyFactory::translateKey` is called.
> 
> By default, the choice is "seed".
> 
> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is calculated from the input if it's seed only.

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

  grammar; no more 8347941

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24969/files
  - new: https://git.openjdk.org/jdk/pull/24969/files/3ffc5362..91894fc6

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

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

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

From abarashev at openjdk.org  Fri Jan 23 15:24:29 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 23 Jan 2026 15:24:29 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v6]
In-Reply-To: <6cs-_wTI-PO4suA-EQSfzgqBbCwohpLzMGeY7I46IMA=.1d919135-157c-4c43-8b75-61db7ac6a6dd@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <nAZwEBGOjjuzpDS-22fH9dZj1Mfup-ESeB-4MJjwzJ8=.29f59844-4fac-4b40-9785-e8f576482d14@github.com>
 <6cs-_wTI-PO4suA-EQSfzgqBbCwohpLzMGeY7I46IMA=.1d919135-157c-4c43-8b75-61db7ac6a6dd@github.com>
Message-ID: <nkAALZ2iFmmlHCOppaPFbk8PVEoneJE85RS6f5dOgJc=.b63aa3d7-4667-4e3e-a7e6-b8fa620d083f@github.com>

On Fri, 23 Jan 2026 09:29:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add COMPRESSED_CERTIFICATE to the QUIC list of expected TLS messages
>>  - Add back the library directive
>
> src/java.base/share/classes/sun/security/ssl/CompressionAlgorithm.java line 98:
> 
>> 96: 
>> 97:         Map<Integer, Function<byte[], byte[]>> inflaters =
>> 98:                 new LinkedHashMap<>(config.certInflaters.size());
> 
> Hello Artur, is this intentionally using the constructor which takes a `initialCapacity` or was it meant to be the number of expected mappings? If it's the latter, then there's `LinkedHashMap.newLinkedHashMap()` method https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/LinkedHashMap.html#newLinkedHashMap(int) which takes the expected number of mappings.

That's basically the max possible size of that map. Currently it can be either 1 or 0. Thanks for pointing out this new method. I'll make a change so we avoid unnecessary reallocation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2721665798

From myankelevich at openjdk.org  Fri Jan 23 15:39:45 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 23 Jan 2026 15:39:45 GMT
Subject: RFR: 8376218: Improve KeyUtil::getKeySize coverage
Message-ID: <iDqq-efhgIW0YoYIV1_Sc3ziPaZPQLqFVWVoLZHFM84=.9e0f3ff7-6d65-4c32-9d26-f3180e3d6c84@github.com>

Improving `public static final int getKeySize(AlgorithmParameters parameters)` coverage

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

Commit messages:
 - JDK-8376218: Improve KeyUtil::getKeySize coverage

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

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

From myankelevich at openjdk.org  Fri Jan 23 16:31:58 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 23 Jan 2026 16:31:58 GMT
Subject: RFR: 8376218: Improve KeyUtil::getKeySize coverage [v2]
In-Reply-To: <iDqq-efhgIW0YoYIV1_Sc3ziPaZPQLqFVWVoLZHFM84=.9e0f3ff7-6d65-4c32-9d26-f3180e3d6c84@github.com>
References: <iDqq-efhgIW0YoYIV1_Sc3ziPaZPQLqFVWVoLZHFM84=.9e0f3ff7-6d65-4c32-9d26-f3180e3d6c84@github.com>
Message-ID: <o5yZf1O9cfFE_fLkQvftoGm53SIOj4m7igkMwge2Ka8=.4e204274-1be2-471d-9dd2-542b68375fea@github.com>

> Improving `public static final int getKeySize(AlgorithmParameters parameters)` coverage

Mikhail Yankelevich 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:

  JDK-8376218: Improve KeyUtil::getKeySize coverage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29389/files
  - new: https://git.openjdk.org/jdk/pull/29389/files/b18b815b..f50afc73

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

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

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

From julian.reschke at gmx.de  Fri Jan 23 17:18:46 2026
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 23 Jan 2026 18:18:46 +0100
Subject: removal of AccessControlException vs javax.jcr
Message-ID: <b4005b8c-f368-4ba0-b0c5-b7f0ca1fc614@gmx.de>

Dear JDK security experts!

I'm mailing as member of the org.apache.jackrabbit PMC and former member 
of the JSR 283 EG...

The removal of AccessControlException would break the javax.jcr API 
which - AFAIU - is completely frozen.

See

https://developer.adobe.com/experience-manager/reference-materials/spec/javax.jcr/javadocs/jcr-2.0/javax/jcr/Session.html#checkPermission(java.lang.String,java.lang.String)

Is there anything we can/should do right now?

Best regards, Julian

From abarashev at openjdk.org  Fri Jan 23 17:24:02 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 23 Jan 2026 17:24:02 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v7]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <1fvgSgXKXRZotuRbDAJm0SGdiy2vDboEatjbJXmI6g8=.aa3845b4-9d05-4a5d-b75a-335c4ad21e8f@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Use newLinkedHashMap to avoid unnecessary reallocation. Remove redundant "handshake" check point from logging.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/ef0a8f04..c0fd9b86

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

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

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

From sean.mullan at oracle.com  Fri Jan 23 18:00:08 2026
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 23 Jan 2026 13:00:08 -0500
Subject: removal of AccessControlException vs javax.jcr
In-Reply-To: <b4005b8c-f368-4ba0-b0c5-b7f0ca1fc614@gmx.de>
References: <b4005b8c-f368-4ba0-b0c5-b7f0ca1fc614@gmx.de>
Message-ID: <83192500-5ccd-4515-a32c-60848e1ab01e@oracle.com>

It hasn't been removed yet, but the plan is to eventually remove it. Why 
is it frozen? Depending on a library or project that isn't active or 
cannot be adapted seems a bit concerning.

--Sean

On 1/23/26 12:18 PM, Julian Reschke wrote:
> Dear JDK security experts!
> 
> I'm mailing as member of the org.apache.jackrabbit PMC and former member 
> of the JSR 283 EG...
> 
> The removal of AccessControlException would break the javax.jcr API 
> which - AFAIU - is completely frozen.
> 
> See
> 
> https://developer.adobe.com/experience-manager/reference-materials/spec/ 
> javax.jcr/javadocs/jcr-2.0/javax/jcr/ 
> Session.html#checkPermission(java.lang.String,java.lang.String)
> 
> Is there anything we can/should do right now?
> 
> Best regards, Julian


From weijun at openjdk.org  Fri Jan 23 18:44:33 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 23 Jan 2026 18:44:33 GMT
Subject: RFR: 8375684: Avoid leak in KeystoreImpl.m when using
 CFArrayCreateMutable
In-Reply-To: <jDlXHu96ZfF6wrRMBzR3TA06ZdkW7-uuvaUDbFArQOs=.0dc5ca5c-2749-4243-85fd-f7c76bc82ee1@github.com>
References: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
 <jDlXHu96ZfF6wrRMBzR3TA06ZdkW7-uuvaUDbFArQOs=.0dc5ca5c-2749-4243-85fd-f7c76bc82ee1@github.com>
Message-ID: <Z-sgGVoo0rHCyhfGxLmHcKZHQDgK0xNb-C-yE9bcs3E=.9522932c-71db-41af-8fcf-697416c24de4@github.com>

On Fri, 23 Jan 2026 09:18:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> @wangweij , could you please comment on the potential function usages that miss CFRelease ? Should I address the others too in this PR or better in another one ?

Yes, seems all of them should be released. Have you tried `getInstance("KeychainStore")` again and again and see if there is any memory leak?

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

PR Comment: https://git.openjdk.org/jdk/pull/29326#issuecomment-3791742350

From julian.reschke at gmx.de  Fri Jan 23 19:00:42 2026
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 23 Jan 2026 20:00:42 +0100
Subject: removal of AccessControlException vs javax.jcr
In-Reply-To: <83192500-5ccd-4515-a32c-60848e1ab01e@oracle.com>
References: <b4005b8c-f368-4ba0-b0c5-b7f0ca1fc614@gmx.de>
 <83192500-5ccd-4515-a32c-60848e1ab01e@oracle.com>
Message-ID: <7b0cfee5-b87c-43ab-9ad8-2636684e2282@gmx.de>

Am 23.01.2026 um 19:00 schrieb Sean Mullan:
> It hasn't been removed yet, but the plan is to eventually remove it. Why 
> is it frozen? Depending on a library or project that isn't active or 
> cannot be adapted seems a bit concerning.
> ...

It's a Javax API. The only way to change/revise/update it would be a new 
JSR xxx Expert Group, unless I'm missing something.

Best regards, Julian




From valeriep at openjdk.org  Fri Jan 23 19:49:31 2026
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 23 Jan 2026 19:49:31 GMT
Subject: Integrated: 8375549: ConcurrentModificationException if
 jdk.crypto.disabledAlgorithms has multiple entries with known oid
In-Reply-To: <9RX9ppMiYrgBmp9W8Lwn9KdcGd9O6xQU2WhJQ-I0W3M=.9c831100-bb9b-479d-9994-7de269b093b6@github.com>
References: <9RX9ppMiYrgBmp9W8Lwn9KdcGd9O6xQU2WhJQ-I0W3M=.9c831100-bb9b-479d-9994-7de269b093b6@github.com>
Message-ID: <HWIsvCooFXW-HTofZLIAnJxevCqocdL7u-LEN5-oe9k=.281dc080-525c-43bf-ab57-1ccf3d1dbcf9@github.com>

On Tue, 20 Jan 2026 22:59:54 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Inside the CryptoAlgorithmConstraints constructor, there is a loop looking up the known oid. Iterating over the "disabledServices" set and inserting the found oid(s) into it leads to ConcurrentModificationException when the set contains multiple entries. The proposed fix is to iterating over the array converted from the set which is also used for debugging output instead of the "disabledServices" set itself.
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: e5512404
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e55124041e0181ca14ed95dc5f94d404b7900029
Stats:     52 lines in 2 files changed: 49 ins; 0 del; 3 mod

8375549: ConcurrentModificationException if jdk.crypto.disabledAlgorithms has multiple entries with known oid

Reviewed-by: mullan, coffeys

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

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

From jpai at openjdk.org  Sat Jan 24 01:25:25 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 24 Jan 2026 01:25:25 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays [v6]
In-Reply-To: <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
 <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com>
Message-ID: <SocqCBUgh-p6P2s4XmdhhYJD1vS4v6-s6VTRVP0j-cs=.c103695d-15d8-429c-a95c-4c8e0bd3d28a@github.com>

On Thu, 22 Jan 2026 21:54:35 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8370688: Updated the documentation to describe the behavior using @implSpec

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28615#pullrequestreview-3700349807

From alan.bateman at oracle.com  Sat Jan 24 08:44:52 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sat, 24 Jan 2026 08:44:52 +0000
Subject: removal of AccessControlException vs javax.jcr
In-Reply-To: <7b0cfee5-b87c-43ab-9ad8-2636684e2282@gmx.de>
References: <b4005b8c-f368-4ba0-b0c5-b7f0ca1fc614@gmx.de>
 <83192500-5ccd-4515-a32c-60848e1ab01e@oracle.com>
 <7b0cfee5-b87c-43ab-9ad8-2636684e2282@gmx.de>
Message-ID: <386baba1-6c16-4f1d-9c99-d323f53f2d0e@oracle.com>



On 23/01/2026 19:00, Julian Reschke wrote:
> Am 23.01.2026 um 19:00 schrieb Sean Mullan:
>> It hasn't been removed yet, but the plan is to eventually remove it. 
>> Why is it frozen? Depending on a library or project that isn't active 
>> or cannot be adapted seems a bit concerning.
>> ...
>
> It's a Javax API. The only way to change/revise/update it would be a 
> new JSR xxx Expert Group, unless I'm missing something.

I don't know anything about this Content Repository API but I agree with 
Sean that it is a bit concerning to be dependent on something that might 
no longer be maintained. I see the last update to the API was 2009 but I 
can't tell if this is one of these APIs with multiple implementations 
maintained by different projects. Do you know if anyone has been 
maintaining an implementation has tested it on JDK 7 or newer? As the 
API was developed in the JCP then it may be that it needs a maintenance 
JSR to update. This assumes of course that it is still relevant and 
intended to work with modern JDK releases.

-Alan

From julian.reschke at gmx.de  Sat Jan 24 09:53:17 2026
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat, 24 Jan 2026 10:53:17 +0100
Subject: removal of AccessControlException vs javax.jcr
In-Reply-To: <386baba1-6c16-4f1d-9c99-d323f53f2d0e@oracle.com>
References: <b4005b8c-f368-4ba0-b0c5-b7f0ca1fc614@gmx.de>
 <83192500-5ccd-4515-a32c-60848e1ab01e@oracle.com>
 <7b0cfee5-b87c-43ab-9ad8-2636684e2282@gmx.de>
 <386baba1-6c16-4f1d-9c99-d323f53f2d0e@oracle.com>
Message-ID: <2bc137f1-27dc-4b93-8f0a-8a116c5c0e4c@gmx.de>

Am 24.01.2026 um 09:44 schrieb Alan Bateman:
> 
> 
> On 23/01/2026 19:00, Julian Reschke wrote:
>> Am 23.01.2026 um 19:00 schrieb Sean Mullan:
>>> It hasn't been removed yet, but the plan is to eventually remove it. 
>>> Why is it frozen? Depending on a library or project that isn't active 
>>> or cannot be adapted seems a bit concerning.
>>> ...
>>
>> It's a Javax API. The only way to change/revise/update it would be a 
>> new JSR xxx Expert Group, unless I'm missing something.
> 
> I don't know anything about this Content Repository API but I agree with 
> Sean that it is a bit concerning to be dependent on something that might 
> no longer be maintained. I see the last update to the API was 2009 but I 

Well. It mainly wasn't updated because there was no urge.

> can't tell if this is one of these APIs with multiple implementations 
> maintained by different projects. Do you know if anyone has been 

There are two implementations in Apache space. Jackrabbit is the 
reference implementation. Oak is a re-implementation (complete). These 
are used in other Apache projects (like Sling), and in commercial 
projects such as Magnolia or Adobe AEM (used by many Fortune 500 
companies). ((Excuse the marketing spin; I'm an Adobe contractor but 
still mostly developing in Open Source space)). There are also 
*implementations* elsewhere but I don't know whether they are still in use.

It's also used (or was used) in Oracle's DB products; see 
<https://www.orafaq.com/wiki/JCR>. See also 
<https://en.wikipedia.org/wiki/Content_repository_API_for_Java#Available_implementations>.

Note <https://www.linkedin.com/in/eric-sedlar-160752/> was EG member, 
you may want to talk to him.

So the API in itself is not a big success story, but it has a huge 
number of deployments.

> maintaining an implementation has tested it on JDK 7 or newer? As the 

It is maintained and happily compiling and running on JDK 25 
(https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk-java25/ 
- ignore test flakiness),

> API was developed in the JCP then it may be that it needs a maintenance 
> JSR to update. This assumes of course that it is still relevant and 
> intended to work with modern JDK releases.

Starting a new EG is quite an expensive thing when the only issue at 
hand is a deprecated Exception in a method signature.

Best regards, Julian

PS: Sean, you may remember: many years ago you delayed a part of the 
java.security removal to help "us" (Apache) to transition away (again, 
it was an issue of use in method signatures). Thanks for that.

From duke at openjdk.org  Sat Jan 24 16:14:48 2026
From: duke at openjdk.org (Roger Calnan)
Date: Sat, 24 Jan 2026 16:14:48 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v4]
In-Reply-To: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
Message-ID: <b28cquRT_0PQ_G7KwcgprtZZCcBCU8DmKdCf-6Ir300=.73b97b99-9f77-46f6-82f3-33f17ff5d087@github.com>

> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option

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

  implemented suggestion by weijun to distinguish between the flags that are documented as commands vs. options

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29258/files
  - new: https://git.openjdk.org/jdk/pull/29258/files/872ae076..52433bc5

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

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

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

From duke at openjdk.org  Sat Jan 24 19:58:26 2026
From: duke at openjdk.org (Roger Calnan)
Date: Sat, 24 Jan 2026 19:58:26 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v5]
In-Reply-To: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
Message-ID: <kdWK7U_TB7IgYvt6zrzx-zVUFqP1S7eeb7YI7GuBIPk=.bfcdbd79-812c-454f-9c9e-2ced18ee004f@github.com>

> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option

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

  update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29258/files
  - new: https://git.openjdk.org/jdk/pull/29258/files/52433bc5..a4083a66

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

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

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

From weijun at openjdk.org  Sun Jan 25 01:18:54 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 25 Jan 2026 01:18:54 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v4]
In-Reply-To: <b28cquRT_0PQ_G7KwcgprtZZCcBCU8DmKdCf-6Ir300=.73b97b99-9f77-46f6-82f3-33f17ff5d087@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
 <b28cquRT_0PQ_G7KwcgprtZZCcBCU8DmKdCf-6Ir300=.73b97b99-9f77-46f6-82f3-33f17ff5d087@github.com>
Message-ID: <I3FUMOEgOetbNdIaGx3jSEz9AWBUWBDjnCSS4ActYNw=.fa1c6c15-b62b-49b3-aff2-79ee2d72317e@github.com>

On Sat, 24 Jan 2026 16:14:48 GMT, Roger Calnan <duke at openjdk.org> wrote:

>> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option
>
> Roger Calnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implemented suggestion by weijun to distinguish between the flags that are documented as commands vs. options

src/java.security.jgss/windows/man/kinit.md line 1:

> 1: ---

I suggest revert all anchor names in `kinit.md` to be `option`. There are no real command here.

src/java.security.jgss/windows/man/klist.md line 1:

> 1: ---

Same with `kinit.md`. There are only options in `klist.md`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29258#discussion_r2724752625
PR Review Comment: https://git.openjdk.org/jdk/pull/29258#discussion_r2724752845

From bperez at openjdk.org  Mon Jan 26 04:25:44 2026
From: bperez at openjdk.org (Ben Perez)
Date: Mon, 26 Jan 2026 04:25:44 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v4]
In-Reply-To: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
Message-ID: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com>

> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method

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

  Added conditionalAssign() intrinsic, changed mult intrinsic to use hybrid neon/gpr approach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27946/files
  - new: https://git.openjdk.org/jdk/pull/27946/files/ee2f01ac..3cadf6cf

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

  Stats: 948 lines in 1 file changed: 614 ins; 35 del; 299 mod
  Patch: https://git.openjdk.org/jdk/pull/27946.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27946/head:pull/27946

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

From myankelevich at openjdk.org  Mon Jan 26 11:12:03 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 26 Jan 2026 11:12:03 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v2]
In-Reply-To: <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
Message-ID: <w_PEiqdhwGbPjctTdGFYIjTllgCXmWiHnRGUJvFRQWU=.8d558167-8f1d-4684-9214-96bb00d30ed7@github.com>

On Thu, 22 Jan 2026 23:51:42 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Refactor sun.security.provider.X509Factory cache access to avoid coarse-grained locking and reduce contention during certificate/CRL interning and parsing.
>> 
>> As per request in [the PR](https://github.com/openjdk/jdk/pull/22616#issuecomment-2524971845), re-visit "the initialisation and locking in this area, e.g. addToCache is a static synchronized method so very coarse locking."
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345954: Addressing review comments

Looks fine to me, just one minor question

src/java.base/share/classes/sun/security/provider/X509Factory.java line 188:

> 186:             enc = newC.getEncodedInternal();
> 187:         }
> 188:         return addIfNotPresent(certCache, enc, newC);

Nit: what do you think about moving this logic inside of the `addIfNotPresent` and just pass an option if it is an impl? 

        X509CertImpl newC;
        byte[] enc;
        if (isImpl) {
            newC = (X509CertImpl) c;
            enc = encoding;
        } else {
            newC = new X509CertImpl(encoding);
            enc = newC.getEncodedInternal();
        }
        return addIfNotPresent(certCache, enc, newC);


I think this might be a bit easier to follow then. But I don't really mind if you leave it this way either

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

PR Review: https://git.openjdk.org/jdk/pull/29181#pullrequestreview-3705573013
PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2727198948

From mbaesken at openjdk.org  Mon Jan 26 11:38:18 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 26 Jan 2026 11:38:18 GMT
Subject: RFR: 8375684: Avoid leak in KeystoreImpl.m when using
 CFArrayCreateMutable
In-Reply-To: <Z-sgGVoo0rHCyhfGxLmHcKZHQDgK0xNb-C-yE9bcs3E=.9522932c-71db-41af-8fcf-697416c24de4@github.com>
References: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
 <jDlXHu96ZfF6wrRMBzR3TA06ZdkW7-uuvaUDbFArQOs=.0dc5ca5c-2749-4243-85fd-f7c76bc82ee1@github.com>
 <Z-sgGVoo0rHCyhfGxLmHcKZHQDgK0xNb-C-yE9bcs3E=.9522932c-71db-41af-8fcf-697416c24de4@github.com>
Message-ID: <TPiN0BNDP5rta7peZicJ_AsZfUGnSf2UHl8jYnzHHes=.b18f1237-a6e2-4f33-a052-fa8054d2f371@github.com>

On Fri, 23 Jan 2026 18:41:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> > @wangweij , could you please comment on the potential function usages that miss CFRelease ? Should I address the others too in this PR or better in another one ?
> 
> Yes, seems all of them should be released. Have you tried `getInstance("KeychainStore")` again and again and see if there is any memory leak?

No , I just looked at the coding (plus used some tool).
Are there e.g. some good jtreg tests I should use to get more info about the leaks ?

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

PR Comment: https://git.openjdk.org/jdk/pull/29326#issuecomment-3799123427

From mbaesken at openjdk.org  Mon Jan 26 11:38:20 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 26 Jan 2026 11:38:20 GMT
Subject: RFR: 8375684: Avoid leak in KeystoreImpl.m when using
 CFArrayCreateMutable
In-Reply-To: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
References: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
Message-ID: <xkDRO27w11_kXW-zjNgirFXO5nfii2JoxXG-4hDe_lg=.cf178ecf-c89e-4aa8-8e5a-0463b98d0958@github.com>

On Tue, 20 Jan 2026 16:47:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In KeystoreImpl.m we use CFArrayCreateMutable, but we do not always CFRelease the resources we created.
> This should be adjusted.
> 
> See
> https://developer.apple.com/documentation/corefoundation/cfarraycreatemutable(_:_:_:)
> 
> return value is  
> A new mutable array, or NULL if there was a problem creating the object. Ownership follows the [The Create Rule](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/20001148-103029).

Btw.  I now integrate this one and continue with the other issues in another PR .

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

PR Comment: https://git.openjdk.org/jdk/pull/29326#issuecomment-3799126917

From mbaesken at openjdk.org  Mon Jan 26 11:41:39 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 26 Jan 2026 11:41:39 GMT
Subject: Integrated: 8375684: Avoid leak in KeystoreImpl.m when using
 CFArrayCreateMutable
In-Reply-To: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
References: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
Message-ID: <2WOYCirwa1pPhaRLaDBsxslIiJPFVRMWagU97AJqLdk=.edda36fe-0ef2-4074-9fc4-d10df8dd32b6@github.com>

On Tue, 20 Jan 2026 16:47:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In KeystoreImpl.m we use CFArrayCreateMutable, but we do not always CFRelease the resources we created.
> This should be adjusted.
> 
> See
> https://developer.apple.com/documentation/corefoundation/cfarraycreatemutable(_:_:_:)
> 
> return value is  
> A new mutable array, or NULL if there was a problem creating the object. Ownership follows the [The Create Rule](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/20001148-103029).

This pull request has now been integrated.

Changeset: 0f1b96a5
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f1b96a50a3a79fd699bf34121df8451ffa37b8f
Stats:     14 lines in 1 file changed: 10 ins; 1 del; 3 mod

8375684: Avoid leak in KeystoreImpl.m when using CFArrayCreateMutable

Reviewed-by: clanger

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

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

From myankelevich at openjdk.org  Mon Jan 26 12:07:55 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 26 Jan 2026 12:07:55 GMT
Subject: RFR: 8374001: sun/security/ skip without Exceptions [v3]
In-Reply-To: <P1xMe3z5wtoG1l84Iu2IJNH-B2sUVchQ46SFYiOThPs=.18e8a2fe-dc84-45a7-98b0-f4568ca949e9@github.com>
References: <P1xMe3z5wtoG1l84Iu2IJNH-B2sUVchQ46SFYiOThPs=.18e8a2fe-dc84-45a7-98b0-f4568ca949e9@github.com>
Message-ID: <3NQoUAbD1DGb8yG0smG9vlsbY2DkJhWwhOO9YwT_xK4=.e9c6165e-384b-4ab7-ab66-dde17fe206aa@github.com>

> Pr cleaning up the tests left after the previous PRs.
> 
> * test/jdk/sun/security/util/Resources/Usages.java
> * test/jdk/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java
> * test/jdk/sun/security/krb5/config/ConfPlusProp.java
> * test/jdk/sun/security/krb5/auto/ReplayCacheTestProc.java

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

  Updated message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28898/files
  - new: https://git.openjdk.org/jdk/pull/28898/files/6284930a..6794469f

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

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

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

From myankelevich at openjdk.org  Mon Jan 26 12:07:59 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 26 Jan 2026 12:07:59 GMT
Subject: RFR: 8374001: sun/security/ skip without Exceptions [v2]
In-Reply-To: <2wpzUHBeQEN5OnIwOXtfb-GiL8ynC1wDWl5dSH8Jz-U=.ce7d2c0c-1b85-4203-8572-6b0addecdcf2@github.com>
References: <P1xMe3z5wtoG1l84Iu2IJNH-B2sUVchQ46SFYiOThPs=.18e8a2fe-dc84-45a7-98b0-f4568ca949e9@github.com>
 <9UiHxDfiSJwrgZHG1vlJnjwiLZsRFuWiVxeYDvsmqlU=.8dbcfb68-bd31-4345-9fc4-7cc2aee1d395@github.com>
 <2wpzUHBeQEN5OnIwOXtfb-GiL8ynC1wDWl5dSH8Jz-U=.ce7d2c0c-1b85-4203-8572-6b0addecdcf2@github.com>
Message-ID: <dlaWo6NeSoJ6xScQk-OWfu-lnyv-IsUZI8Jv645O4gU=.9e60f493-05ce-45c7-940d-c0e3f390a74b@github.com>

On Thu, 22 Jan 2026 12:41:31 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Mikhail Yankelevich 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:
>> 
>>  - updating to latest master and copyrights
>>  - Merge branch 'master' into JDK-8374001
>>  - JDK-8374001: sun/security/ skip without Exceptions
>
> test/jdk/sun/security/krb5/config/ConfPlusProp.java line 44:
> 
>> 42:                 System.getenv("LOGONSERVER") != null) {
>> 43:             throw new SkippedException(
>> 44:                     "Looks like a Windows machine in a domain.");
> 
> maybe change the message to "Test cannot run in a domain."?

Yes, I believe this sounds better, thanks. Updated in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28898#discussion_r2727348620

From adinn at openjdk.org  Mon Jan 26 13:42:28 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 26 Jan 2026 13:42:28 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v4]
In-Reply-To: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com>
Message-ID: <PmILsPF4cMa5N_u5dToH7OkWoJl3XSxWtt7-_6Ybevw=.42ce2dbb-670e-472e-a70f-bffc467f7377@github.com>

On Mon, 26 Jan 2026 04:25:44 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method and `IntegerPolynomial.conditionalAssign()`. Since 64-bit multiplication is not supported on Neon and manually performing this operation with 32-bit limbs is slower than with GPRs, a hybrid neon/gpr approach is used. Neon instructions are used to compute intermediate values used in the last two iterations of the main "loop", while the GPRs compute the first few iterations. At the method level this improves performance by ~9% and at the API level roughly 5%. 
>> 
>> Performance no intrinsic:
>> 
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    8  2427.562 ? 24.923  ops/s
>> PolynomialP256Bench.benchMultiply          false  thrpt    8  1757.495 ? 41.805  ops/s
>> PolynomialP256Bench.benchSquare             true  thrpt    8  2435.202 ? 20.822  ops/s
>> PolynomialP256Bench.benchSquare            false  thrpt    8  2420.390 ? 33.594  ops/s
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   8439.881 ?  29.838  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   7990.614 ?  30.998  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   2677.737 ?   8.400  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   2619.297 ?   9.737  ops/s
>> 
>> Benchmark                                         (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.EC.generateSecret                      ECDH          256              EC              thrpt   40  1905.369 ?  3.745  ops/s
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1903.997 ? 4.092  ops/s
>> 
>> 
>> Performance with intrinsic
>> 
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    8  2676.599 ? 24.722  ops/s
>> PolynomialP256Bench.benchMultiply          false  thrpt    8  1770.589 ?  2.584  op...
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added conditionalAssign() intrinsic, changed mult intrinsic to use hybrid neon/gpr approach

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7282:

> 7280:     __ mov(mul_ptr, sp);
> 7281: 
> 7282:     __ umullv(A[0], __ T2D, b_lows, __ T2S, a_vals, __ S, 0);

I notice that this 4 line insn pattern recurs several times. You might consider defining a macro generator method to generate these sequences i.e.

vs_umullv(VSeq<4> vs, FloatRegister bs, FloatRegister as, int lane_lo) {
    __ umullv(vs[0], __ T2D, bs, __ T2S, as, __S, lane_lo);
    __ umull2v(vs[1], __ T2D, bs, __ T4S. as, __S, lane_lo);
    __ umullv(vs[2], __ T2D, bs, __T2S, as, __S, lane_lo + 2);
    __ umull2v(vs[3], __ T2D, bs, __T4S, as, __S, lane_lo + 2);
}

So, in this case you would call

  vs_umullv(A, b_lows, a_vals, 0);

and in other cases you can simply vary which arguments you provide for `vs`, `as`, `bs` and `lane_lo`.

I'm suggesting that because the various cross multiplies generated by this macro-method appear to implement a specific subsequence of the mont mul computation (similar to what is done in e.g. the kyber code). So, this generator method abstraction should also abstract that a clear step in any pseudo-code algorithm you provide and ought therefore to make clear that (also make clear /how/) the generated code implements that algorithm. If you can provide such a pseudo-code algorithm then we might even be able come up with a better name for the generator method (e.g. montmul_uproduct or something else that reflects what is happening here).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2727648074

From adinn at openjdk.org  Mon Jan 26 13:55:39 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 26 Jan 2026 13:55:39 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v4]
In-Reply-To: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com>
Message-ID: <9BNJyY7gZJtYmMduwlUp1seCnrCamkEpiVrKNKEHYhI=.a37c9472-1469-4e88-bada-128627110e57@github.com>

On Mon, 26 Jan 2026 04:25:44 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method and `IntegerPolynomial.conditionalAssign()`. Since 64-bit multiplication is not supported on Neon and manually performing this operation with 32-bit limbs is slower than with GPRs, a hybrid neon/gpr approach is used. Neon instructions are used to compute intermediate values used in the last two iterations of the main "loop", while the GPRs compute the first few iterations. At the method level this improves performance by ~9% and at the API level roughly 5%. 
>> 
>> Performance no intrinsic:
>> 
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    8  2427.562 ? 24.923  ops/s
>> PolynomialP256Bench.benchMultiply          false  thrpt    8  1757.495 ? 41.805  ops/s
>> PolynomialP256Bench.benchSquare             true  thrpt    8  2435.202 ? 20.822  ops/s
>> PolynomialP256Bench.benchSquare            false  thrpt    8  2420.390 ? 33.594  ops/s
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   8439.881 ?  29.838  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   7990.614 ?  30.998  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   2677.737 ?   8.400  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   2619.297 ?   9.737  ops/s
>> 
>> Benchmark                                         (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.EC.generateSecret                      ECDH          256              EC              thrpt   40  1905.369 ?  3.745  ops/s
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1903.997 ? 4.092  ops/s
>> 
>> 
>> Performance with intrinsic
>> 
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    8  2676.599 ? 24.722  ops/s
>> PolynomialP256Bench.benchMultiply          false  thrpt    8  1770.589 ?  2.584  op...
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added conditionalAssign() intrinsic, changed mult intrinsic to use hybrid neon/gpr approach

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7933:

> 7931:       __ ldr(b9, Address(bLimbs, 64));
> 7932:       __ ldr(b10, Address(bLimbs, 72));
> 7933: 

You could use the existing macro generator method `vs_ldpq` to plant these load instructions

    vs_ldpq(a_vec, aLimbs);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2727688196

From adinn at openjdk.org  Mon Jan 26 13:55:40 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 26 Jan 2026 13:55:40 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v4]
In-Reply-To: <9BNJyY7gZJtYmMduwlUp1seCnrCamkEpiVrKNKEHYhI=.a37c9472-1469-4e88-bada-128627110e57@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com>
 <9BNJyY7gZJtYmMduwlUp1seCnrCamkEpiVrKNKEHYhI=.a37c9472-1469-4e88-bada-128627110e57@github.com>
Message-ID: <sgV6ZGvIxVyF96qrsQB3ZYa1UGxs0QPBqk6XSm1UZ14=.29508e06-425f-4e8e-a99e-bd432597745c@github.com>

On Mon, 26 Jan 2026 13:49:52 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added conditionalAssign() intrinsic, changed mult intrinsic to use hybrid neon/gpr approach
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7933:
> 
>> 7931:       __ ldr(b9, Address(bLimbs, 64));
>> 7932:       __ ldr(b10, Address(bLimbs, 72));
>> 7933: 
> 
> You could use the existing macro generator method `vs_ldpq` to plant these load instructions
> 
>     vs_ldpq(a_vec, aLimbs);

Alternatively, if you need to fold in a fixed initial offset plus a suitable step then use `vs_ldpq_indexed`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2727698642

From adinn at openjdk.org  Mon Jan 26 14:01:33 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 26 Jan 2026 14:01:33 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v4]
In-Reply-To: <sgV6ZGvIxVyF96qrsQB3ZYa1UGxs0QPBqk6XSm1UZ14=.29508e06-425f-4e8e-a99e-bd432597745c@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com>
 <9BNJyY7gZJtYmMduwlUp1seCnrCamkEpiVrKNKEHYhI=.a37c9472-1469-4e88-bada-128627110e57@github.com>
 <sgV6ZGvIxVyF96qrsQB3ZYa1UGxs0QPBqk6XSm1UZ14=.29508e06-425f-4e8e-a99e-bd432597745c@github.com>
Message-ID: <q8lwiNDJRX0q7MllqZz8NJoLupsJHBroSDwF21Rcwrk=.95731fab-ad59-4ff7-9841-c974e6ac61a3@github.com>

On Mon, 26 Jan 2026 13:52:58 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7933:
>> 
>>> 7931:       __ ldr(b9, Address(bLimbs, 64));
>>> 7932:       __ ldr(b10, Address(bLimbs, 72));
>>> 7933: 
>> 
>> You could use the existing macro generator method `vs_ldpq` to plant these load instructions
>> 
>>     vs_ldpq(a_vec, aLimbs);
>
> Alternatively, if you need to fold in a fixed initial offset plus a suitable step then use `vs_ldpq_indexed`

n.b. Note that you can use `vs_even(a_vec)` and `vs_odd(a_vec)` to select vector subsequences `a_vec[0]` and `a_vec[2]` or `a_vec[1]` and `a_vec[3]` respectively. Likewise, there is `vs_front` and `vs_back` to select the first and second halves of the vector sequence.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2727712970

From adinn at openjdk.org  Mon Jan 26 14:01:37 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 26 Jan 2026 14:01:37 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v4]
In-Reply-To: <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <1pWEujfd2cR7cqahubA6lbBgtTfnX00oGLzR9tr1AOw=.9c3fa260-6c98-480d-aec8-82ebf8c63129@github.com>
Message-ID: <_sGnMq8gOMBI_7zccUovqLRS-kCEWvtGnsPNQ76S2QI=.c8b20bec-694b-4b51-a240-626b2c099d0a@github.com>

On Mon, 26 Jan 2026 04:25:44 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method and `IntegerPolynomial.conditionalAssign()`. Since 64-bit multiplication is not supported on Neon and manually performing this operation with 32-bit limbs is slower than with GPRs, a hybrid neon/gpr approach is used. Neon instructions are used to compute intermediate values used in the last two iterations of the main "loop", while the GPRs compute the first few iterations. At the method level this improves performance by ~9% and at the API level roughly 5%. 
>> 
>> Performance no intrinsic:
>> 
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    8  2427.562 ? 24.923  ops/s
>> PolynomialP256Bench.benchMultiply          false  thrpt    8  1757.495 ? 41.805  ops/s
>> PolynomialP256Bench.benchSquare             true  thrpt    8  2435.202 ? 20.822  ops/s
>> PolynomialP256Bench.benchSquare            false  thrpt    8  2420.390 ? 33.594  ops/s
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   8439.881 ?  29.838  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   7990.614 ?  30.998  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   2677.737 ?   8.400  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   2619.297 ?   9.737  ops/s
>> 
>> Benchmark                                         (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> KeyAgreementBench.EC.generateSecret                      ECDH          256              EC              thrpt   40  1905.369 ?  3.745  ops/s
>> 
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1903.997 ? 4.092  ops/s
>> 
>> 
>> Performance with intrinsic
>> 
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    8  2676.599 ? 24.722  ops/s
>> PolynomialP256Bench.benchMultiply          false  thrpt    8  1770.589 ?  2.584  op...
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added conditionalAssign() intrinsic, changed mult intrinsic to use hybrid neon/gpr approach

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7957:

> 7955: 
> 7956:       vs_eor(a_vec, a_vec, b_vec);
> 7957: 

Likewise there are `vs_stpq` and `vs_stqp_indexed` that you can use here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2727717489

From weijun at openjdk.org  Mon Jan 26 15:03:44 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 26 Jan 2026 15:03:44 GMT
Subject: RFR: 8375684: Avoid leak in KeystoreImpl.m when using
 CFArrayCreateMutable
In-Reply-To: <Z-sgGVoo0rHCyhfGxLmHcKZHQDgK0xNb-C-yE9bcs3E=.9522932c-71db-41af-8fcf-697416c24de4@github.com>
References: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
 <jDlXHu96ZfF6wrRMBzR3TA06ZdkW7-uuvaUDbFArQOs=.0dc5ca5c-2749-4243-85fd-f7c76bc82ee1@github.com>
 <Z-sgGVoo0rHCyhfGxLmHcKZHQDgK0xNb-C-yE9bcs3E=.9522932c-71db-41af-8fcf-697416c24de4@github.com>
Message-ID: <rfw9C5zgYur7tBTOR0K6JOBf4HVTHdSGIQJd-Z1fYIE=.93494e87-9dff-4098-9e85-2fb55f6fb7fd@github.com>

On Fri, 23 Jan 2026 18:41:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> @wangweij , could you please comment on the potential function usages that miss CFRelease ?
>> Should I address the others too in this PR or better in another one  ?
>
>> @wangweij , could you please comment on the potential function usages that miss CFRelease ? Should I address the others too in this PR or better in another one ?
> 
> Yes, seems all of them should be released. Have you tried `getInstance("KeychainStore")` again and again and see if there is any memory leak?

> > > @wangweij , could you please comment on the potential function usages that miss CFRelease ? Should I address the others too in this PR or better in another one ?
> > 
> > 
> > Yes, seems all of them should be released. Have you tried `getInstance("KeychainStore")` again and again and see if there is any memory leak?
> 
> No , I just looked at the coding (plus used some tool). Are there e.g. some good jtreg tests I should use to get more info about the leaks ?

I only find one automatic test related to macOS keystores: `java/security/KeyStore/CheckMacOSKeyChainTrust.java`. The other one -- `sun/security/tools/keytool/ListKeyChainStore.java` -- is manual.

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

PR Comment: https://git.openjdk.org/jdk/pull/29326#issuecomment-3800028752

From mbaesken at openjdk.org  Mon Jan 26 15:15:06 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 26 Jan 2026 15:15:06 GMT
Subject: RFR: 8375684: Avoid leak in KeystoreImpl.m when using
 CFArrayCreateMutable
In-Reply-To: <rfw9C5zgYur7tBTOR0K6JOBf4HVTHdSGIQJd-Z1fYIE=.93494e87-9dff-4098-9e85-2fb55f6fb7fd@github.com>
References: <AMBrQGcRgD4VszCZjFOHvEiLw89zqJYnxlLdS_JLwPU=.37f59844-5dcf-403c-bab5-f43cbcc2d3b0@github.com>
 <jDlXHu96ZfF6wrRMBzR3TA06ZdkW7-uuvaUDbFArQOs=.0dc5ca5c-2749-4243-85fd-f7c76bc82ee1@github.com>
 <Z-sgGVoo0rHCyhfGxLmHcKZHQDgK0xNb-C-yE9bcs3E=.9522932c-71db-41af-8fcf-697416c24de4@github.com>
 <rfw9C5zgYur7tBTOR0K6JOBf4HVTHdSGIQJd-Z1fYIE=.93494e87-9dff-4098-9e85-2fb55f6fb7fd@github.com>
Message-ID: <yVlan_9wZHI3ztpkj2dwg6Bkn-b5BUlSQIj_nqbmkgo=.5c6449f1-cb74-430d-a1fb-2225b313b695@github.com>

On Mon, 26 Jan 2026 14:58:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I only find one automatic test related to macOS keystores: java/security/KeyStore/CheckMacOSKeyChainTrust.java. The other one -- sun/security/tools/keytool/ListKeyChainStore.java -- is manual.

Thanks !
Looks like we have some CFRelease calls as well coming from the Java layer, from  Java_apple_security_KeychainStore__1releaseKeychainItemRef .

https://github.com/openjdk/jdk/blob/61b722d59a799ba943476a03be3a1c7649aa0c27/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m#L877-L882

So those need to be considered too .

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

PR Comment: https://git.openjdk.org/jdk/pull/29326#issuecomment-3800091243

From mdonovan at openjdk.org  Mon Jan 26 16:44:44 2026
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 26 Jan 2026 16:44:44 GMT
Subject: RFR: 8376218: Improve KeyUtil::getKeySize coverage [v2]
In-Reply-To: <o5yZf1O9cfFE_fLkQvftoGm53SIOj4m7igkMwge2Ka8=.4e204274-1be2-471d-9dd2-542b68375fea@github.com>
References: <iDqq-efhgIW0YoYIV1_Sc3ziPaZPQLqFVWVoLZHFM84=.9e0f3ff7-6d65-4c32-9d26-f3180e3d6c84@github.com>
 <o5yZf1O9cfFE_fLkQvftoGm53SIOj4m7igkMwge2Ka8=.4e204274-1be2-471d-9dd2-542b68375fea@github.com>
Message-ID: <8_yjDCd_ZdO6qVwTvlqxpKNUio7n65l7r7rmcwc6gu4=.7af216dc-c68c-41d9-90d7-3ec93b043f79@github.com>

On Fri, 23 Jan 2026 16:31:58 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Improving `public static final int getKeySize(AlgorithmParameters parameters)` coverage
>
> Mikhail Yankelevich 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:
> 
>   JDK-8376218: Improve KeyUtil::getKeySize coverage

test/jdk/sun/security/util/KeyUtilTests.java line 58:

> 56: 
> 57:     @Test
> 58:     public void testProvidersAdded() {

Is this just a sanity check?

test/jdk/sun/security/util/KeyUtilTests.java line 84:

> 82:         params.init(ecPrivateKey.getParams());
> 83: 
> 84:         int keySizeResult = KeyUtil.getKeySize(params);

If the `CustomSunEC` provider uses all of the same Service classes as SunEC, what exactly is this test exercising? Seems like it's duplicating `testGetKeySizeSunEc`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29389#discussion_r2728117398
PR Review Comment: https://git.openjdk.org/jdk/pull/29389#discussion_r2728366347

From abarashev at openjdk.org  Mon Jan 26 17:43:16 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 26 Jan 2026 17:43:16 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v8]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <H1_Cmuze7aXkmSKJfG5fsgFVfMTKoC0rlekNA313gP4=.2ca4e35b-e986-4c04-8738-e038022ad882@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Move caching to CompressedCertificate. Add caching unit tests. Update benchmark test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/c0fd9b86..4f99f4fb

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

  Stats: 378 lines in 5 files changed: 322 ins; 25 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

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

From abarashev at openjdk.org  Mon Jan 26 22:41:29 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 26 Jan 2026 22:41:29 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v9]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <1n7cM37Rd8vlEbxnZzaQhyxHveEQ5jeqNJKzwqYipTk=.299583c9-8c2c-4119-ad19-f9ec56a7173e@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Allocate 24 bits for input size in cache key. Add unit tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/4f99f4fb..358840fc

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

  Stats: 197 lines in 5 files changed: 147 ins; 31 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

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

From duke at openjdk.org  Tue Jan 27 05:48:16 2026
From: duke at openjdk.org (duke)
Date: Tue, 27 Jan 2026 05:48:16 GMT
Subject: Withdrawn: 8371688: Unexpected behavior for
 jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites system properties
In-Reply-To: <KqGL6cc_Kwq18AWnxul--q7AInEKVtKRMv5xggbKcVw=.7276c340-c470-474c-8124-6e570725084f@github.com>
References: <KqGL6cc_Kwq18AWnxul--q7AInEKVtKRMv5xggbKcVw=.7276c340-c470-474c-8124-6e570725084f@github.com>
Message-ID: <N_0EQOcZlOhF_XCGNOMs5q7qwxUg12rk8s3VAf4bXmU=.81c4211e-e682-486b-b131-09c2aabe16bf@github.com>

On Tue, 25 Nov 2025 19:25:36 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> The jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites system properties allow a custom set of cipher suites to be used for the default JDK SSLContext. If such properties specify cipher suites not supported by the JDK, then the JDK falls back to using the default cipher suite list (as if no property was specified). This seems like unexpected behavior.

This pull request has been closed without being integrated.

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

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

From chagedorn at openjdk.org  Tue Jan 27 09:33:02 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 27 Jan 2026 09:33:02 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <Pz0pq_L2Pa3Bq9RWksAGkPCT7_Tk0kWNm_MSZCUMQ_s=.c2f9c052-ab37-4a43-a217-a89fea80dd10@github.com>

On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Overall, the fix idea with `Opaque` nodes looks good to me!

src/hotspot/share/opto/library_call.hpp line 161:

> 159:   Node* generate_negative_guard(Node* index, RegionNode* region,
> 160:                                 // resulting CastII of index:
> 161:                                 Node* *pos_index = nullptr,

Suggestion:

                                Node** pos_index = nullptr,

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

PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3710064929
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2731064422

From chagedorn at openjdk.org  Tue Jan 27 09:33:03 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 27 Jan 2026 09:33:03 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <sn2GOc4tdoyMYCNjYB4yg9k31OCYDhvJYlugbmN34l8=.d6e02dd6-f8ab-442f-a0f2-ee87bfd4464f@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
 <Jb0WcdejyobjlQaehsAQ0xIcMZoojkfDASIFQMgiKh0=.3450989a-44c1-4037-bf36-86ce665882e7@github.com>
 <sn2GOc4tdoyMYCNjYB4yg9k31OCYDhvJYlugbmN34l8=.d6e02dd6-f8ab-442f-a0f2-ee87bfd4464f@github.com>
Message-ID: <p_72oa29MDb8NTKDxNtYxINXAqP6uItH0uUL4NJLsCM=.274c3609-b2a0-4dac-8b72-4e1ba881fc01@github.com>

On Tue, 20 Jan 2026 09:06:27 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. ?
>
> Fair enough ? I was just curious.

I was about to ask the same question. It seems like both `OpaqueNotNullNode` and `OpaqueGuardNode` behave the same apart from eventually folding to a false or true constant. They might have slightly different reasons for adding them but AFAIU, they are both intended to keep control and data in sync. Apart from duplicating most of the logic and comments, an additional challenge with having both nodes is that we need to special case both nodes at various points in the code which makes it more complex and raises the question if we could really observe them both or not (would not be a problem when only having one node type).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2731057975

From myankelevich at openjdk.org  Tue Jan 27 10:49:14 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 27 Jan 2026 10:49:14 GMT
Subject: RFR: 8376218: Improve KeyUtil::getKeySize coverage [v2]
In-Reply-To: <8_yjDCd_ZdO6qVwTvlqxpKNUio7n65l7r7rmcwc6gu4=.7af216dc-c68c-41d9-90d7-3ec93b043f79@github.com>
References: <iDqq-efhgIW0YoYIV1_Sc3ziPaZPQLqFVWVoLZHFM84=.9e0f3ff7-6d65-4c32-9d26-f3180e3d6c84@github.com>
 <o5yZf1O9cfFE_fLkQvftoGm53SIOj4m7igkMwge2Ka8=.4e204274-1be2-471d-9dd2-542b68375fea@github.com>
 <8_yjDCd_ZdO6qVwTvlqxpKNUio7n65l7r7rmcwc6gu4=.7af216dc-c68c-41d9-90d7-3ec93b043f79@github.com>
Message-ID: <m0LekDYrF5q4f5SLJF2WZ_QjcYk6NiaYrznoYKg2u5w=.fa08d05b-7c01-4b45-9e75-909d8ebe15a3@github.com>

On Mon, 26 Jan 2026 15:38:42 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Mikhail Yankelevich 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:
>> 
>>   JDK-8376218: Improve KeyUtil::getKeySize coverage
>
> test/jdk/sun/security/util/KeyUtilTests.java line 58:
> 
>> 56: 
>> 57:     @Test
>> 58:     public void testProvidersAdded() {
> 
> Is this just a sanity check?

Yep, to make sure the provider is added correctly

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29389#discussion_r2731399899

From myankelevich at openjdk.org  Tue Jan 27 10:53:13 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 27 Jan 2026 10:53:13 GMT
Subject: RFR: 8376218: Improve KeyUtil::getKeySize coverage [v2]
In-Reply-To: <8_yjDCd_ZdO6qVwTvlqxpKNUio7n65l7r7rmcwc6gu4=.7af216dc-c68c-41d9-90d7-3ec93b043f79@github.com>
References: <iDqq-efhgIW0YoYIV1_Sc3ziPaZPQLqFVWVoLZHFM84=.9e0f3ff7-6d65-4c32-9d26-f3180e3d6c84@github.com>
 <o5yZf1O9cfFE_fLkQvftoGm53SIOj4m7igkMwge2Ka8=.4e204274-1be2-471d-9dd2-542b68375fea@github.com>
 <8_yjDCd_ZdO6qVwTvlqxpKNUio7n65l7r7rmcwc6gu4=.7af216dc-c68c-41d9-90d7-3ec93b043f79@github.com>
Message-ID: <1XbujPb5MThipyb_qYpV9V4NOZED-qlMBJg-eJ46KCk=.c7d33a58-4591-4f4d-bd5d-c143298bee98@github.com>

On Mon, 26 Jan 2026 16:41:44 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Mikhail Yankelevich 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:
>> 
>>   JDK-8376218: Improve KeyUtil::getKeySize coverage
>
> test/jdk/sun/security/util/KeyUtilTests.java line 84:
> 
>> 82:         params.init(ecPrivateKey.getParams());
>> 83: 
>> 84:         int keySizeResult = KeyUtil.getKeySize(params);
> 
> If the `CustomSunEC` provider uses all of the same Service classes as SunEC, what exactly is this test exercising? Seems like it's duplicating `testGetKeySizeSunEc`

It tests [this](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/KeyUtil.java#L137-L165) block specifically. We already test SunEC, but EC which is not SunEC is not covered at all hence this test. 

  public static final int getKeySize(AlgorithmParameters parameters) {

        switch (parameters.getAlgorithm()) {
            case "EC":
                // ECKeySizeParameterSpec is SunEC internal only
                if (parameters.getProvider().getName().equals("SunEC")) {
                    try {
                        ECKeySizeParameterSpec ps = parameters.getParameterSpec(
                            ECKeySizeParameterSpec.class);
                        if (ps != null) {
                            return ps.getKeySize();
                        }
                    } catch (InvalidParameterSpecException ipse) {
                        // ignore
                    }
                }

                try {
                    ECParameterSpec ps = parameters.getParameterSpec(
                            ECParameterSpec.class);
                    if (ps != null) {
                        return ps.getOrder().bitLength();
                    }
                } catch (InvalidParameterSpecException ipse) {
                    // ignore
                }

                // Note: the ECGenParameterSpec case should be covered by the
                // ECParameterSpec case above.
                // See ECUtil.getECParameterSpec(String).

                break;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29389#discussion_r2731417895

From coffeys at openjdk.org  Tue Jan 27 11:44:06 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 27 Jan 2026 11:44:06 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v26]
In-Reply-To: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
Message-ID: <xhLHqZx2wotlAV7ps5ipOCKNi-LQhbu3B5ojs5EK50w=.54b66b88-dd2e-46c0-96bf-91eb73b9fd2c@github.com>

> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago.
> 
> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. 
> 
> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options :
> 
> 
>         System.err.println("help           print the help messages");
>         System.err.println("expand         expand debugging information");
>         System.err.println();
>         System.err.println("all            turn on all debugging");
>         System.err.println("ssl            turn on ssl debugging");
>         System.err.println();
>         System.err.println("The following can be used with ssl:");
>         System.err.println("\trecord       enable per-record tracing");
>         System.err.println("\thandshake    print each handshake message");
>         System.err.println("\tkeygen       print key generation data");
>         System.err.println("\tsession      print session activity");
>         System.err.println("\tdefaultctx   print default SSL initialization");
>         System.err.println("\tsslctx       print SSLContext tracing");
>         System.err.println("\tsessioncache print session cache tracing");
>         System.err.println("\tkeymanager   print key manager tracing");
>         System.err.println("\ttrustmanager print trust manager tracing");
>         System.err.println("\tpluggability print pluggability tracing");
>         System.err.println();
>         System.err.println("\thandshake debugging can be widened with:");
>         System.err.println("\tdata         hex dump of each handshake message");
>         System.err.println("\tverbose      verbose handshake message printing");
>         System.err.println();
>         System.err.println("\trecord debugging can be widened with:");
>         System.err.println("\tplaintext    hex dump of record plaintext");
>         System.err.println("\tpacket       print raw SSL/TLS packets");
> 
> 
> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. 
> 
> the output has changed slightly with respect to that  - less verbose
> 
> e.g. old style:
> 
> 
> javax.net.ssl|DEBUG|10|main|2024-04-12 15:47:24.302 GMT|SSLSocketOut...

Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:

 - correct NamedGroup.java merge
 - Merge branch 'master' into 8044609-ssl
 - fix up test bug ID
 - fix up files post merge
 - Merge branch 'master' into 8044609-ssl
 - prep for isOn() merge
 - Merge branch 'master' into 8044609-ssl
 - Merge branch 'master' into 8044609-ssl
 - Merge branch 'master' into 8044609-ssl
 - Incorporate review comments from Brad
 - ... and 38 more: https://git.openjdk.org/jdk/compare/c69275dd...6b5c692c

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

Changes: https://git.openjdk.org/jdk/pull/18764/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=25
  Stats: 1297 lines in 83 files changed: 460 ins; 69 del; 768 mod
  Patch: https://git.openjdk.org/jdk/pull/18764.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18764/head:pull/18764

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

From mdonovan at openjdk.org  Tue Jan 27 14:41:33 2026
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 27 Jan 2026 14:41:33 GMT
Subject: RFR: 8376218: Improve KeyUtil::getKeySize coverage [v2]
In-Reply-To: <1XbujPb5MThipyb_qYpV9V4NOZED-qlMBJg-eJ46KCk=.c7d33a58-4591-4f4d-bd5d-c143298bee98@github.com>
References: <iDqq-efhgIW0YoYIV1_Sc3ziPaZPQLqFVWVoLZHFM84=.9e0f3ff7-6d65-4c32-9d26-f3180e3d6c84@github.com>
 <o5yZf1O9cfFE_fLkQvftoGm53SIOj4m7igkMwge2Ka8=.4e204274-1be2-471d-9dd2-542b68375fea@github.com>
 <8_yjDCd_ZdO6qVwTvlqxpKNUio7n65l7r7rmcwc6gu4=.7af216dc-c68c-41d9-90d7-3ec93b043f79@github.com>
 <1XbujPb5MThipyb_qYpV9V4NOZED-qlMBJg-eJ46KCk=.c7d33a58-4591-4f4d-bd5d-c143298bee98@github.com>
Message-ID: <UA7Y3CBJTPxmrvNTSMwl4MqjTDdF_S2doKMvslmPTCo=.c37ee208-87bb-4cd2-997d-4565525043f2@github.com>

On Tue, 27 Jan 2026 10:50:58 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> test/jdk/sun/security/util/KeyUtilTests.java line 84:
>> 
>>> 82:         params.init(ecPrivateKey.getParams());
>>> 83: 
>>> 84:         int keySizeResult = KeyUtil.getKeySize(params);
>> 
>> If the `CustomSunEC` provider uses all of the same Service classes as SunEC, what exactly is this test exercising? Seems like it's duplicating `testGetKeySizeSunEc`
>
> It tests [this](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/KeyUtil.java#L137-L165) block specifically. We already test SunEC, but EC which is not SunEC is not covered at all hence this test. 
> 
>   public static final int getKeySize(AlgorithmParameters parameters) {
> 
>         switch (parameters.getAlgorithm()) {
>             case "EC":
>                 // ECKeySizeParameterSpec is SunEC internal only
>                 if (parameters.getProvider().getName().equals("SunEC")) {
>                     try {
>                         ECKeySizeParameterSpec ps = parameters.getParameterSpec(
>                             ECKeySizeParameterSpec.class);
>                         if (ps != null) {
>                             return ps.getKeySize();
>                         }
>                     } catch (InvalidParameterSpecException ipse) {
>                         // ignore
>                     }
>                 }
> 
>                 try {
>                     ECParameterSpec ps = parameters.getParameterSpec(
>                             ECParameterSpec.class);
>                     if (ps != null) {
>                         return ps.getOrder().bitLength();
>                     }
>                 } catch (InvalidParameterSpecException ipse) {
>                     // ignore
>                 }
> 
>                 // Note: the ECGenParameterSpec case should be covered by the
>                 // ECParameterSpec case above.
>                 // See ECUtil.getECParameterSpec(String).
> 
>                 break;

that makes sense, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29389#discussion_r2732340217

From dfenacci at openjdk.org  Tue Jan 27 16:22:52 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 27 Jan 2026 16:22:52 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v2]
In-Reply-To: <p_72oa29MDb8NTKDxNtYxINXAqP6uItH0uUL4NJLsCM=.274c3609-b2a0-4dac-8b72-4e1ba881fc01@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com>
 <Jb0WcdejyobjlQaehsAQ0xIcMZoojkfDASIFQMgiKh0=.3450989a-44c1-4037-bf36-86ce665882e7@github.com>
 <sn2GOc4tdoyMYCNjYB4yg9k31OCYDhvJYlugbmN34l8=.d6e02dd6-f8ab-442f-a0f2-ee87bfd4464f@github.com>
 <p_72oa29MDb8NTKDxNtYxINXAqP6uItH0uUL4NJLsCM=.274c3609-b2a0-4dac-8b72-4e1ba881fc01@github.com>
Message-ID: <Ol4UunnyjJ2breqdwRf2AO5chwcD88rAMMjRf07s47U=.45feee45-a7e5-4798-a77e-1aa7ce039ac1@github.com>

On Tue, 27 Jan 2026 09:24:34 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Fair enough ? I was just curious.
>
> I was about to ask the same question. It seems like both `OpaqueNotNullNode` and `OpaqueGuardNode` behave the same apart from eventually folding to a false or true constant. They might have slightly different reasons for adding them but AFAIU, they are both intended to keep control and data in sync. Apart from duplicating most of the logic and comments, an additional challenge with having both nodes is that we need to special case both nodes at various points in the code which makes it more complex and raises the question if we could really observe them both or not (would not be a problem when only having one node type).

Thanks for reviewing @chhagedorn.

> special case both nodes at various points

Good point. I guess better have only one after all. Changed. (I called it `OpaqueCheck` for lack of a better idea)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2732811990

From dfenacci at openjdk.org  Tue Jan 27 16:22:52 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 27 Jan 2026 16:22:52 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v2]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <Oq2vN6wGYB6q2wbKB2oNqwXhOR2FeypoT_G5qq07AX0=.818ff2d9-6a4e-4b53-882b-6fd0c00721c4@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

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

 - JDK-8374852: fix macro expansion for OpaqueCheck
 - JDK-8374852: use only one opaque node

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/ff228576..b79738c3

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

  Stats: 95 lines in 15 files changed: 11 ins; 42 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/29164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164

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

From dfenacci at openjdk.org  Tue Jan 27 16:26:19 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 27 Jan 2026 16:26:19 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v3]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <VrYWdFIyIZfOKeKx9hZBFriAo34PIGOqPOd6FfHEKZs=.576a9a1e-feed-4fad-975b-69c6294cc145@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

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

  JDK-8374852: fix star layout
  
  Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/b79738c3..0ef73ef9

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

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

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

From jvernee at openjdk.org  Tue Jan 27 16:57:35 2026
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 27 Jan 2026 16:57:35 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
Message-ID: <Mg3vPu8exFTKO4FiJAudoCLbAU27lxZk_iUWmSrlY9w=.273cdbaf-0c19-4b27-b7df-5c583f732988@github.com>

On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> MemorySegments allocated from shared Arena from
> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
> 
> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
> 
> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
> 
> After:
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
> |    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |...

Sorry this is taking a while to review. I have been swamped since the start of the year. I want to give this patch the time it deserves, but that also means it's not possible to squeeze in the review between other things

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3806333930

From xuelei at openjdk.org  Tue Jan 27 16:57:43 2026
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 27 Jan 2026 16:57:43 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v9]
In-Reply-To: <1n7cM37Rd8vlEbxnZzaQhyxHveEQ5jeqNJKzwqYipTk=.299583c9-8c2c-4119-ad19-f9ec56a7173e@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <1n7cM37Rd8vlEbxnZzaQhyxHveEQ5jeqNJKzwqYipTk=.299583c9-8c2c-4119-ad19-f9ec56a7173e@github.com>
Message-ID: <POSv-RUqpERiVlfaGtotSgK1XeszOIyfD617E6pHWKc=.b8829e93-3346-42e0-87e5-a0b83d9f43a5@github.com>

On Mon, 26 Jan 2026 22:41:29 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allocate 24 bits for input size in cache key. Add unit tests.

Changes requested by xuelei (Reviewer).

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 982:

> 980:             boolean enableCertificateCompression) {
> 981:         this.enableCertificateCompression = enableCertificateCompression;
> 982:     }

Is there a plan to support brotli compression algorithm in OpenJDK?  It is the only supported algorithm in browser Chrome.

If there is a need to support more than one compression algorithms in the future, it might be better to provide an option to customize the algorithms selection, including preferences.  The flexibility could provide better interoperability if a vendor does not support compression algorithm properly.

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

PR Review: https://git.openjdk.org/jdk/pull/28682#pullrequestreview-3712350928
PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2732956812

From abarashev at openjdk.org  Tue Jan 27 17:27:43 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 27 Jan 2026 17:27:43 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v9]
In-Reply-To: <POSv-RUqpERiVlfaGtotSgK1XeszOIyfD617E6pHWKc=.b8829e93-3346-42e0-87e5-a0b83d9f43a5@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <1n7cM37Rd8vlEbxnZzaQhyxHveEQ5jeqNJKzwqYipTk=.299583c9-8c2c-4119-ad19-f9ec56a7173e@github.com>
 <POSv-RUqpERiVlfaGtotSgK1XeszOIyfD617E6pHWKc=.b8829e93-3346-42e0-87e5-a0b83d9f43a5@github.com>
Message-ID: <k7wMtNwusu5--8vfdjMTwC0rQIqIoXUtT3UXkg20LwE=.caba1a91-89dc-4839-be22-58e5e18c4c5c@github.com>

On Tue, 27 Jan 2026 16:54:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Allocate 24 bits for input size in cache key. Add unit tests.
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 982:
> 
>> 980:             boolean enableCertificateCompression) {
>> 981:         this.enableCertificateCompression = enableCertificateCompression;
>> 982:     }
> 
> Is there a plan to support brotli compression algorithm in OpenJDK?  It is the only supported algorithm in browser Chrome.
> 
> If there is a need to support more than one compression algorithms in the future, it might be better to provide an option to customize the algorithms selection, including preferences.  The flexibility could provide better interoperability if a vendor does not support compression algorithm properly.

Yes, strangely Chrome supports only brotli although I didn't see any difference in compression ration between zlib and brotli when manually testing certificate compression. We may add support for more algorithms in the future, but for now it's zlib only.
Generally speaking, it's the certificate's metadata that is being compressed, the keys are high-entropy data difficult to compress. PQC certificates don?t compress well, most likely because of lower metadata to keys ratio.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2733079369

From duke at openjdk.org  Tue Jan 27 19:45:53 2026
From: duke at openjdk.org (Roger Calnan)
Date: Tue, 27 Jan 2026 19:45:53 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v6]
In-Reply-To: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
Message-ID: <QGCYmpqFvnMBKHiTqKgfzO7t3StgzYsgArWsQhVEFzQ=.b4b7b48e-e33f-4bed-b21d-e53b0a6abf1c@github.com>

> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option

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

  backed out changes to command- anchor names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29258/files
  - new: https://git.openjdk.org/jdk/pull/29258/files/a4083a66..9dca215c

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

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

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

From duke at openjdk.org  Tue Jan 27 19:45:57 2026
From: duke at openjdk.org (Roger Calnan)
Date: Tue, 27 Jan 2026 19:45:57 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v4]
In-Reply-To: <I3FUMOEgOetbNdIaGx3jSEz9AWBUWBDjnCSS4ActYNw=.fa1c6c15-b62b-49b3-aff2-79ee2d72317e@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
 <b28cquRT_0PQ_G7KwcgprtZZCcBCU8DmKdCf-6Ir300=.73b97b99-9f77-46f6-82f3-33f17ff5d087@github.com>
 <I3FUMOEgOetbNdIaGx3jSEz9AWBUWBDjnCSS4ActYNw=.fa1c6c15-b62b-49b3-aff2-79ee2d72317e@github.com>
Message-ID: <ToM-c1WPGzvyrj2v98uVIW1iwdGo7OlBKnj7r6oFFpE=.9218742e-33e3-4c76-b71f-f6883f87d1c6@github.com>

On Sun, 25 Jan 2026 01:13:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Roger Calnan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   implemented suggestion by weijun to distinguish between the flags that are documented as commands vs. options
>
> src/java.security.jgss/windows/man/kinit.md line 1:
> 
>> 1: ---
> 
> I suggest revert all anchor names in `kinit.md` to be `option`. There are no real command here.

done

> src/java.security.jgss/windows/man/klist.md line 1:
> 
>> 1: ---
> 
> Same with `kinit.md`. There are only options in `klist.md`.

changed back

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29258#discussion_r2733553027
PR Review Comment: https://git.openjdk.org/jdk/pull/29258#discussion_r2733553751

From duke at openjdk.org  Tue Jan 27 21:50:55 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Tue, 27 Jan 2026 21:50:55 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v2]
In-Reply-To: <w_PEiqdhwGbPjctTdGFYIjTllgCXmWiHnRGUJvFRQWU=.8d558167-8f1d-4684-9214-96bb00d30ed7@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
 <w_PEiqdhwGbPjctTdGFYIjTllgCXmWiHnRGUJvFRQWU=.8d558167-8f1d-4684-9214-96bb00d30ed7@github.com>
Message-ID: <Um-dPhx03Ur484ts5ab9iSSIuAkfEs5LBlzScrbqPZw=.4ffea032-ab61-4097-8f47-19ae2e0195c7@github.com>

On Mon, 26 Jan 2026 11:08:10 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8345954: Addressing review comments
>
> src/java.base/share/classes/sun/security/provider/X509Factory.java line 188:
> 
>> 186:             enc = newC.getEncodedInternal();
>> 187:         }
>> 188:         return addIfNotPresent(certCache, enc, newC);
> 
> Nit: what do you think about moving this logic inside of the `addIfNotPresent` and just pass an option if it is an impl? 
> 
>         X509CertImpl newC;
>         byte[] enc;
>         if (isImpl) {
>             newC = (X509CertImpl) c;
>             enc = encoding;
>         } else {
>             newC = new X509CertImpl(encoding);
>             enc = newC.getEncodedInternal();
>         }
>         return addIfNotPresent(certCache, enc, newC);
> 
> 
> I think this might be a bit easier to follow then. But I don't really mind if you leave it this way either

Good suggestion. But I am thinking to keep addIfNotPresent() as a generic cache helper without specific construction logic inside.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2733956670

From weijun at openjdk.org  Wed Jan 28 02:27:24 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 28 Jan 2026 02:27:24 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v6]
In-Reply-To: <QGCYmpqFvnMBKHiTqKgfzO7t3StgzYsgArWsQhVEFzQ=.b4b7b48e-e33f-4bed-b21d-e53b0a6abf1c@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
 <QGCYmpqFvnMBKHiTqKgfzO7t3StgzYsgArWsQhVEFzQ=.b4b7b48e-e33f-4bed-b21d-e53b0a6abf1c@github.com>
Message-ID: <DB9UATPU8O6GbWbjNj9Fl1O6VjbBAcXElRFHkYo6ukM=.c0c897d0-5ed0-4a45-867c-cce479066099@github.com>

On Tue, 27 Jan 2026 19:45:53 GMT, Roger Calnan <duke at openjdk.org> wrote:

>> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option
>
> Roger Calnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   backed out changes to command- anchor names

LGTM!

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29258#pullrequestreview-3714300449

From duke at openjdk.org  Wed Jan 28 03:25:29 2026
From: duke at openjdk.org (duke)
Date: Wed, 28 Jan 2026 03:25:29 GMT
Subject: RFR: 8375325: add anchors to the options in the security man pages
 [v6]
In-Reply-To: <QGCYmpqFvnMBKHiTqKgfzO7t3StgzYsgArWsQhVEFzQ=.b4b7b48e-e33f-4bed-b21d-e53b0a6abf1c@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
 <QGCYmpqFvnMBKHiTqKgfzO7t3StgzYsgArWsQhVEFzQ=.b4b7b48e-e33f-4bed-b21d-e53b0a6abf1c@github.com>
Message-ID: <6ivT5VFMICu6kKX-1WOH_-lrA-nzChAgTCQMZpMHB88=.b57dd738-b058-4ddd-a44d-9173aec71f6d@github.com>

On Tue, 27 Jan 2026 19:45:53 GMT, Roger Calnan <duke at openjdk.org> wrote:

>> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option
>
> Roger Calnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   backed out changes to command- anchor names

@calnan 
Your change (at version 9dca215c3eba5cf19e9275f8c44fe65f427d6232) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/29258#issuecomment-3808739748

From wetmore at openjdk.org  Wed Jan 28 06:34:27 2026
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 28 Jan 2026 06:34:27 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v26]
In-Reply-To: <xhLHqZx2wotlAV7ps5ipOCKNi-LQhbu3B5ojs5EK50w=.54b66b88-dd2e-46c0-96bf-91eb73b9fd2c@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
 <xhLHqZx2wotlAV7ps5ipOCKNi-LQhbu3B5ojs5EK50w=.54b66b88-dd2e-46c0-96bf-91eb73b9fd2c@github.com>
Message-ID: <KoNRySQEhqft-pQl3F_Q0V_Y3I8vJNH_PwYXgxSW_6U=.6ae1fcff-38af-40ed-9088-dabec373b79b@github.com>

On Tue, 27 Jan 2026 11:44:06 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago.
>> 
>> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. 
>> 
>> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options :
>> 
>> 
>>         System.err.println("help           print the help messages");
>>         System.err.println("expand         expand debugging information");
>>         System.err.println();
>>         System.err.println("all            turn on all debugging");
>>         System.err.println("ssl            turn on ssl debugging");
>>         System.err.println();
>>         System.err.println("The following can be used with ssl:");
>>         System.err.println("\trecord       enable per-record tracing");
>>         System.err.println("\thandshake    print each handshake message");
>>         System.err.println("\tkeygen       print key generation data");
>>         System.err.println("\tsession      print session activity");
>>         System.err.println("\tdefaultctx   print default SSL initialization");
>>         System.err.println("\tsslctx       print SSLContext tracing");
>>         System.err.println("\tsessioncache print session cache tracing");
>>         System.err.println("\tkeymanager   print key manager tracing");
>>         System.err.println("\ttrustmanager print trust manager tracing");
>>         System.err.println("\tpluggability print pluggability tracing");
>>         System.err.println();
>>         System.err.println("\thandshake debugging can be widened with:");
>>         System.err.println("\tdata         hex dump of each handshake message");
>>         System.err.println("\tverbose      verbose handshake message printing");
>>         System.err.println();
>>         System.err.println("\trecord debugging can be widened with:");
>>         System.err.println("\tplaintext    hex dump of record plaintext");
>>         System.err.println("\tpacket       print raw SSL/TLS packets");
>> 
>> 
>> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. 
>> 
>> the output has changed slightly with respect to that  - less verbose
>> 
>> e.g. old...
>
> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:
> 
>  - correct NamedGroup.java merge
>  - Merge branch 'master' into 8044609-ssl
>  - fix up test bug ID
>  - fix up files post merge
>  - Merge branch 'master' into 8044609-ssl
>  - prep for isOn() merge
>  - Merge branch 'master' into 8044609-ssl
>  - Merge branch 'master' into 8044609-ssl
>  - Merge branch 'master' into 8044609-ssl
>  - Incorporate review comments from Brad
>  - ... and 38 more: https://git.openjdk.org/jdk/compare/c69275dd...6b5c692c

Nothing major.  We did most of the heavy lifting last year.  Without looking at the calls sites yet, I like how the enum turned out.  I am looking forward to seeing how the enums actually fit.  

Just a few nits+requested comments.

I've hit the `SSLLogger.java` code pretty hard, now off to the other 500+ call sites.  ;)  

I'm going to check the Levels and the categories and see if we can make them more consistent, with ears towards: 

[JDK-8338702](https://bugs.openjdk.org/browse/JDK-8338702)
[JDK-8344158](https://bugs.openjdk.org/browse/JDK-8344158)

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 52:

> 50: /**
> 51:  * Implementation of SSL logger.
> 52:  *

If you feel up to it, you could add  `<p>` where needed.

Also, lines 298, 302, and 308.

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 58:

> 56:  * and applications can customize and configure the logger or use external
> 57:  * logging mechanisms.  If the system property "javax.net.debug" is defined
> 58:  * and non-empty, a private debug logger implemented in this class is used.

add something like...

the private debug logger in this class simply outputs to `System.err`.

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 62:

> 60: public final class SSLLogger implements System.Logger {
> 61:     private static final System.Logger logger;
> 62:     // high level boolean to track whether "all" or "ssl" option

Minor nit:  
This makes it sounds like the boolean state `true` might be `all` and `false` is `ssl`.

Suggest maybe "to track whether logging is active (i.e. all/ssl)."

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 105:

> 103:                     if (Opt.HANDSHAKE.on && p.contains("verbose")) {
> 104:                         Opt.HANDSHAKE_VERBOSE.on = true;
> 105:                     }

Not absolutely needed given the options currently defined, but you could `replaceFirst()` on these 3 as well.  

Your call.

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 130:

> 128:                 }
> 129:             }
> 130:             // javax.net.debug would be misconfigured property with respect

Nit:  add extra line.

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 149:

> 147:         return logging;
> 148:     }
> 149:     /**

Nit:  add a line.

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 157:

> 155:     }
> 156: 
> 157:     public static void severe(String msg, Object... params) {

Since we're down here, these don't really need to be `public`.  Package-private  is fine.

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 237:

> 235:         System.err.printf("%nAdding valid filter options to \"ssl\" will log" +
> 236:                 " messages to include%njust those filtered categories.%n");
> 237:         System.err.printf("%nIf \"ssl\" is specified by itself," +

Maybe reverse 235 and 237.  ssl by itself, then ssl+filter?  I've gone back/forth on this quite a bit.  Do you have a preference?

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 296:

> 294:         return level != Level.OFF;
> 295:     }
> 296:     /**

Nit:  add a line.

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 311:

> 309:      * Enabling subcomponents fine-tunes (filters) debug output.
> 310:      */
> 311:     public enum Opt {

Does this need to be public?

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 465:

> 463:                         formatParameters(parameters) :
> 464:                         Utilities.indent(formatParameters(parameters)))
> 465:                 };

Why did the indent get changed?

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 490:

> 488:                     isFirst = false;
> 489:                 } else {
> 490:                     builder.append(",\n");

Why did this get changed from `LINE_SEP` to `\n`.  All of the other line separators in this file are still `LINE_SEP`.

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 494:

> 492: 
> 493:                 if (parameter instanceof Throwable) {
> 494:                     builder.append(formatThrowable((Throwable)parameter));

Nit:  from the Java Coding conventions, Section 8.2:

    Casts should be followed by a blank. Examples:
        myMethod((byte) aNum, (Object) x);
        myFunc((int) (cp + 5), ((int) (i + 3))

I don't have a strong preference here.  

If you do revert back, there are several places that got changed here.

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

PR Review: https://git.openjdk.org/jdk/pull/18764#pullrequestreview-3713815602
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734229865
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734137947
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734242861
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734786277
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734786894
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734896804
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734793448
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734912268
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734915243
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734920494
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734926518
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734982921
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2734985908

From chagedorn at openjdk.org  Wed Jan 28 08:23:31 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 28 Jan 2026 08:23:31 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v3]
In-Reply-To: <VrYWdFIyIZfOKeKx9hZBFriAo34PIGOqPOd6FfHEKZs=.576a9a1e-feed-4fad-975b-69c6294cc145@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <VrYWdFIyIZfOKeKx9hZBFriAo34PIGOqPOd6FfHEKZs=.576a9a1e-feed-4fad-975b-69c6294cc145@github.com>
Message-ID: <UkcVqNuDaxfS276NoZJ6PNCpvWD-w0OfLcXEWXZH1zU=.3f3c2fcb-cbeb-4b7b-afdc-ec626eacffbb@github.com>

On Tue, 27 Jan 2026 16:26:19 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8374852: fix star layout
>   
>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

Thanks for unifying the two opaque nodes! I have some more comments.

src/hotspot/share/opto/macro.cpp line 2559:

> 2557: #else
> 2558:         bool is_positive = n->as_OpaqueCheck()->is_positive();
> 2559:         _igvn.replace_node(n, _igvn.intcon(is_positive?1:0));

Suggestion:

        _igvn.replace_node(n, _igvn.intcon(is_positive ? 1 : 0));

src/hotspot/share/opto/opaquenode.hpp line 146:

> 144: // builds, we keep the actual checks as additional verification code (i.e. removing OpaqueCheckNodes and use the
> 145: // BoolNode inputs instead).
> 146: class OpaqueCheckNode : public Node {

I've also thought about the name. `OpaqueCheck` is already a good indication what the node is about. Maybe we could go a step further and call it `OpaqueConstantBoolNode` to emphasize more that it is belonging to a `BoolNode` whose result we already know. What do you think?

Then we could also think about changing `_positive` to `_constant` (still can be a boolean to just pass true and false which seems more intuitive then passing in 1 and 0).

src/hotspot/share/opto/opaquenode.hpp line 148:

> 146: class OpaqueCheckNode : public Node {
> 147:  private:
> 148:   bool _positive;

Now that we define a field, we also need to override `size_of()` (see for example `OpaqueMultiversioningNode`).

src/hotspot/share/opto/opaquenode.hpp line 150:

> 148:   bool _positive;
> 149:  public:
> 150:   OpaqueCheckNode(Compile* C, Node* tst, bool positive) : Node(nullptr, tst), _positive(positive) {

`tst` is probably almost always a `BoolNode`. I'm wondering if it could also be a constant because we already folded the `BoolNode`? But then it's probably also useless to create the opaque node in the first place.

src/hotspot/share/opto/opaquenode.hpp line 159:

> 157:   virtual const Type* Value(PhaseGVN* phase) const;
> 158:   virtual const Type* bottom_type() const { return TypeInt::BOOL; }
> 159:   bool is_positive() { return _positive; }

When going with `_constant`, we could turn this into

int constant() const { return _constant ? 1 : 0; }

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

PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3715097474
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735306919
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735376625
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735315675
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735369034
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735392835

From ghan at openjdk.org  Wed Jan 28 11:09:09 2026
From: ghan at openjdk.org (Guanqiang Han)
Date: Wed, 28 Jan 2026 11:09:09 GMT
Subject: RFR: 8374516: -version asserts with
 "-XX:+UseAESCTRIntrinsics -XX:-UseAES":
 "need AES instructions and misaligned SSE support" in
 generate_counterMode_AESCrypt_Parallel()
In-Reply-To: <qa6IzAt1LzAzF9zOMtIIjGHY-c8Iqikre6fxlfA34Z8=.44fb722a-867e-432a-bf9d-8d819d136ebc@github.com>
References: <qa6IzAt1LzAzF9zOMtIIjGHY-c8Iqikre6fxlfA34Z8=.44fb722a-867e-432a-bf9d-8d819d136ebc@github.com>
Message-ID: <ibybvCJtdn0eG4wekWg5hV516UnTTzjVNNPDj_UKpM0=.7eb87b79-eb77-43b9-9424-2393444035a7@github.com>

On Wed, 21 Jan 2026 08:32:59 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> Please review this change. Thanks!
> 
> **Description:**
> 
> VM crashes during startup on x86 when running with -XX:+UseAESCTRIntrinsics -XX:-UseAES. In this configuration, UseAESCTRIntrinsics may remain enabled while UseAES is explicitly disabled, and the VM generates AES-CTR stubs, hitting an assert(UseAES) in generate_counterMode_AESCrypt_Parallel().
> 
> **Fix:**
> 
> Update x86 flag initialization to enforce the dependency between UseAESCTRIntrinsics and UseAES. When UseAES is disabled, explicitly disable UseAESCTRIntrinsics (with a warning when it was set on the command line), aligning behavior with the existing UseAES/UseAESIntrinsics gating and avoiding stub generation with inconsistent flag states.
> 
> **Test:**
> 
> GHA

Hi @vnkozlov and @ascarpino , Sorry for the ping ? could you please take a look at this PR when you have a moment?

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

PR Comment: https://git.openjdk.org/jdk/pull/29338#issuecomment-3810647933

From duke at openjdk.org  Wed Jan 28 14:22:09 2026
From: duke at openjdk.org (Roger Calnan)
Date: Wed, 28 Jan 2026 14:22:09 GMT
Subject: Integrated: 8375325: add anchors to the options in the security man
 pages
In-Reply-To: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
References: <dW2M0CLFBYCVXHMbfjSNCVXz889z6cqAr2tYzfwOtZM=.d182674f-7086-4f56-b4a3-4b788c0a0f1b@github.com>
Message-ID: <WaxxovyX14XTgSpD1fYz3xgqSY34724M7Ca0P485yj4=.bdc07f6c-c956-4730-a212-1a569416f939@github.com>

On Fri, 16 Jan 2026 00:46:48 GMT, Roger Calnan <duke at openjdk.org> wrote:

> adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option

This pull request has now been integrated.

Changeset: 8c86b1bb
Author:    Roger Calnan <roger.calnan at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c86b1bb1054b565cf23156d89ee8925a4e32597
Stats:     74 lines in 5 files changed: 0 ins; 0 del; 74 mod

8375325: add anchors to the options in the security man pages

Reviewed-by: weijun, hchao

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

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

From coffeys at openjdk.org  Wed Jan 28 14:41:01 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 28 Jan 2026 14:41:01 GMT
Subject: RFR: 8371333: Optimize static initialization of SSLContextImpl
 classes and improve logging [v5]
In-Reply-To: <TZF1SzuB8Pps8O10qrKtOXRrGWWyiGxSFqfZVjvUj0I=.4de2e8f8-bc38-49c7-96bc-8205118c7fc7@github.com>
References: <TZF1SzuB8Pps8O10qrKtOXRrGWWyiGxSFqfZVjvUj0I=.4de2e8f8-bc38-49c7-96bc-8205118c7fc7@github.com>
Message-ID: <5hQSO-KSbmN49F9W2OBY3XVCehR4eop5cLsuoI97WQ8=.1be44185-ac40-44a3-8e94-a1a4951cbe21@github.com>

> Introduce lazy static initialization logic to SSLContextImpl via use of the new LazyConstant API and improve logging output
> 
> As per JBS comments:
> 
> * Each subclass of AbstractTLSContext (TLSv10. TLSv11 etc) is being initialization at framework initialization time due to the getApplicableSupportedCipherSuites(..) calls made in static block. Such calls are unnecessary if the subclass isn't required. This is especially true for the default JDK configuration where TLSv10, TLSv11 protocols are disabled. I've moved logic to lazy initialization of these fields via LazyConstant
> 
> * The debug prints output never made clear what protocol version each cipher suite was being disabled for. Improved logging there
> * The debug prints never printed out the resulting set of enabled/allowed cipher suites
> 
> There's efficiency gain also in having one less call to the getApplicableEnabledCipherSuites method in the scenario where customized cipher suites are not in use.
> 
> example of new debug output:
> 
> 
> javax.net.ssl|TRACE|30|main|2025-11-26 14:31:31.997 GMT|SSLContextImpl.java:425|Ignore disabled cipher suites for protocols:[TLSv1.3, TLSv1.2]
> [TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384
> TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA
> TLS_RSA_WITH_AES_128_CBC_SHA]
> javax.net.ssl|TRACE|30|main|2025-11-26 14:31:31.997 GMT|SSLContextImpl.java:425|Available cipher suites for protocols:[TLSv1.3, TLSv1.2]
> [TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> TLS_ECDHE_E...

Sean Coffey 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 eight additional commits since the last revision:

 - Merge branch 'master' into 8371333-ssl-debug
 - Incorportate comments from Jamil
 - Merge branch 'master' into 8371333-ssl-debug
 - Merge branch 'master' into 8371333-ssl-debug
 - Move wrapText method to Utilities
 - Merge branch 'master' into 8371333-ssl-debug
 - use LINE_SEP
 - 8371333

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28511/files
  - new: https://git.openjdk.org/jdk/pull/28511/files/fdaa2a70..6faa83e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28511&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28511&range=03-04

  Stats: 57700 lines in 1123 files changed: 32862 ins; 10926 del; 13912 mod
  Patch: https://git.openjdk.org/jdk/pull/28511.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28511/head:pull/28511

PR: https://git.openjdk.org/jdk/pull/28511

From dfenacci at openjdk.org  Wed Jan 28 16:10:53 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 28 Jan 2026 16:10:53 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v4]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <fVjE2X-Nqf9wVrw6S2_Z6L8W732nJyBKeaZKeePFTGU=.b08e61af-3a98-407d-9933-66f8411ad18e@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Damon Fenacci has updated the pull request incrementally with five additional commits since the last revision:

 - JDK-8374582: fix indent
 - JDK-8374582: constant
 - JDK-8374582: add size_of
 - JDK-8374852: OpaqueCheck -> OpaqueConstantBool
 - JDK-8374852: fix number of OpaqueCheck nodes in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/0ef73ef9..a3690526

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=02-03

  Stats: 162 lines in 16 files changed: 60 ins; 60 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/29164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164

PR: https://git.openjdk.org/jdk/pull/29164

From dfenacci at openjdk.org  Wed Jan 28 16:10:57 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 28 Jan 2026 16:10:57 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v3]
In-Reply-To: <UkcVqNuDaxfS276NoZJ6PNCpvWD-w0OfLcXEWXZH1zU=.3f3c2fcb-cbeb-4b7b-afdc-ec626eacffbb@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <VrYWdFIyIZfOKeKx9hZBFriAo34PIGOqPOd6FfHEKZs=.576a9a1e-feed-4fad-975b-69c6294cc145@github.com>
 <UkcVqNuDaxfS276NoZJ6PNCpvWD-w0OfLcXEWXZH1zU=.3f3c2fcb-cbeb-4b7b-afdc-ec626eacffbb@github.com>
Message-ID: <v37o-d1AqannQfWbl4etGP5ieIpAg66YFzyECYATgBY=.70b8095e-ae47-4ad1-82ff-95ef36d0a98c@github.com>

On Wed, 28 Jan 2026 08:13:23 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8374852: fix star layout
>>   
>>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>
> src/hotspot/share/opto/opaquenode.hpp line 146:
> 
>> 144: // builds, we keep the actual checks as additional verification code (i.e. removing OpaqueCheckNodes and use the
>> 145: // BoolNode inputs instead).
>> 146: class OpaqueCheckNode : public Node {
> 
> I've also thought about the name. `OpaqueCheck` is already a good indication what the node is about. Maybe we could go a step further and call it `OpaqueConstantBoolNode` to emphasize more that it is belonging to a `BoolNode` whose result we already know. What do you think?
> 
> Then we could also think about changing `_positive` to `_constant` (still can be a boolean to just pass true and false which seems more intuitive then passing in 1 and 0).

I was still had a doubt about what to put first (`Constant` or `Bool`) but I think `ConstantBool` is actually more correct.

I suppose `_constant` is better than `_value` since we use it already ? 
Done.

> src/hotspot/share/opto/opaquenode.hpp line 148:
> 
>> 146: class OpaqueCheckNode : public Node {
>> 147:  private:
>> 148:   bool _positive;
> 
> Now that we define a field, we also need to override `size_of()` (see for example `OpaqueMultiversioningNode`).

Good to know. Thanks!

> src/hotspot/share/opto/opaquenode.hpp line 150:
> 
>> 148:   bool _positive;
>> 149:  public:
>> 150:   OpaqueCheckNode(Compile* C, Node* tst, bool positive) : Node(nullptr, tst), _positive(positive) {
> 
> `tst` is probably almost always a `BoolNode`. I'm wondering if it could also be a constant because we already folded the `BoolNode`? But then it's probably also useless to create the opaque node in the first place.

Hmmm... I find it hard to totally exclude a constant (e.g. if its inputs are constant...?). In that case we could skip all the opaque business (I guess in the few places where new `OpaqueConstantBool` nodes are created). On the other hand the opaque node should only really delay the folding... ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2737356877
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2737353309
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2737355777

From coffeys at openjdk.org  Wed Jan 28 16:23:07 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 28 Jan 2026 16:23:07 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v27]
In-Reply-To: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
Message-ID: <z6OcJwgF-hIMe8M7zrg4mCFlhiGG-tE2OH7zBF6GJVU=.8c4b111d-f018-4962-82f8-0495de2ba889@github.com>

> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago.
> 
> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. 
> 
> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options :
> 
> 
>         System.err.println("help           print the help messages");
>         System.err.println("expand         expand debugging information");
>         System.err.println();
>         System.err.println("all            turn on all debugging");
>         System.err.println("ssl            turn on ssl debugging");
>         System.err.println();
>         System.err.println("The following can be used with ssl:");
>         System.err.println("\trecord       enable per-record tracing");
>         System.err.println("\thandshake    print each handshake message");
>         System.err.println("\tkeygen       print key generation data");
>         System.err.println("\tsession      print session activity");
>         System.err.println("\tdefaultctx   print default SSL initialization");
>         System.err.println("\tsslctx       print SSLContext tracing");
>         System.err.println("\tsessioncache print session cache tracing");
>         System.err.println("\tkeymanager   print key manager tracing");
>         System.err.println("\ttrustmanager print trust manager tracing");
>         System.err.println("\tpluggability print pluggability tracing");
>         System.err.println();
>         System.err.println("\thandshake debugging can be widened with:");
>         System.err.println("\tdata         hex dump of each handshake message");
>         System.err.println("\tverbose      verbose handshake message printing");
>         System.err.println();
>         System.err.println("\trecord debugging can be widened with:");
>         System.err.println("\tplaintext    hex dump of record plaintext");
>         System.err.println("\tpacket       print raw SSL/TLS packets");
> 
> 
> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. 
> 
> the output has changed slightly with respect to that  - less verbose
> 
> e.g. old style:
> 
> 
> javax.net.ssl|DEBUG|10|main|2024-04-12 15:47:24.302 GMT|SSLSocketOut...

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Review comments from Brad

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18764/files
  - new: https://git.openjdk.org/jdk/pull/18764/files/6b5c692c..c36775d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=25-26

  Stats: 36 lines in 1 file changed: 5 ins; 4 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/18764.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18764/head:pull/18764

PR: https://git.openjdk.org/jdk/pull/18764

From coffeys at openjdk.org  Wed Jan 28 16:23:11 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 28 Jan 2026 16:23:11 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v26]
In-Reply-To: <xhLHqZx2wotlAV7ps5ipOCKNi-LQhbu3B5ojs5EK50w=.54b66b88-dd2e-46c0-96bf-91eb73b9fd2c@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
 <xhLHqZx2wotlAV7ps5ipOCKNi-LQhbu3B5ojs5EK50w=.54b66b88-dd2e-46c0-96bf-91eb73b9fd2c@github.com>
Message-ID: <HhgjYgRx0NhgX_D80e2cnLIvcrHYKSpdrFadLoUluH8=.b8778589-bdec-41b6-8e52-1d81e119ba56@github.com>

On Tue, 27 Jan 2026 11:44:06 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago.
>> 
>> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. 
>> 
>> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options :
>> 
>> 
>>         System.err.println("help           print the help messages");
>>         System.err.println("expand         expand debugging information");
>>         System.err.println();
>>         System.err.println("all            turn on all debugging");
>>         System.err.println("ssl            turn on ssl debugging");
>>         System.err.println();
>>         System.err.println("The following can be used with ssl:");
>>         System.err.println("\trecord       enable per-record tracing");
>>         System.err.println("\thandshake    print each handshake message");
>>         System.err.println("\tkeygen       print key generation data");
>>         System.err.println("\tsession      print session activity");
>>         System.err.println("\tdefaultctx   print default SSL initialization");
>>         System.err.println("\tsslctx       print SSLContext tracing");
>>         System.err.println("\tsessioncache print session cache tracing");
>>         System.err.println("\tkeymanager   print key manager tracing");
>>         System.err.println("\ttrustmanager print trust manager tracing");
>>         System.err.println("\tpluggability print pluggability tracing");
>>         System.err.println();
>>         System.err.println("\thandshake debugging can be widened with:");
>>         System.err.println("\tdata         hex dump of each handshake message");
>>         System.err.println("\tverbose      verbose handshake message printing");
>>         System.err.println();
>>         System.err.println("\trecord debugging can be widened with:");
>>         System.err.println("\tplaintext    hex dump of record plaintext");
>>         System.err.println("\tpacket       print raw SSL/TLS packets");
>> 
>> 
>> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. 
>> 
>> the output has changed slightly with respect to that  - less verbose
>> 
>> e.g. old...
>
> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:
> 
>  - correct NamedGroup.java merge
>  - Merge branch 'master' into 8044609-ssl
>  - fix up test bug ID
>  - fix up files post merge
>  - Merge branch 'master' into 8044609-ssl
>  - prep for isOn() merge
>  - Merge branch 'master' into 8044609-ssl
>  - Merge branch 'master' into 8044609-ssl
>  - Merge branch 'master' into 8044609-ssl
>  - Incorporate review comments from Brad
>  - ... and 38 more: https://git.openjdk.org/jdk/compare/c69275dd...6b5c692c

Thanks for the review comments to date Brad. I've fixed up most issues that you highlighted - left comments inline.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18764#pullrequestreview-3717613276

From coffeys at openjdk.org  Wed Jan 28 16:23:20 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 28 Jan 2026 16:23:20 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v26]
In-Reply-To: <KoNRySQEhqft-pQl3F_Q0V_Y3I8vJNH_PwYXgxSW_6U=.6ae1fcff-38af-40ed-9088-dabec373b79b@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
 <xhLHqZx2wotlAV7ps5ipOCKNi-LQhbu3B5ojs5EK50w=.54b66b88-dd2e-46c0-96bf-91eb73b9fd2c@github.com>
 <KoNRySQEhqft-pQl3F_Q0V_Y3I8vJNH_PwYXgxSW_6U=.6ae1fcff-38af-40ed-9088-dabec373b79b@github.com>
Message-ID: <XAnEj4gkM8cy71YbVtjQ5dMoa6iQf3jzDR3E1ABsufc=.2d59672f-e33b-4b35-88e1-3c40ccd4a66c@github.com>

On Tue, 27 Jan 2026 23:28:39 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:
>> 
>>  - correct NamedGroup.java merge
>>  - Merge branch 'master' into 8044609-ssl
>>  - fix up test bug ID
>>  - fix up files post merge
>>  - Merge branch 'master' into 8044609-ssl
>>  - prep for isOn() merge
>>  - Merge branch 'master' into 8044609-ssl
>>  - Merge branch 'master' into 8044609-ssl
>>  - Merge branch 'master' into 8044609-ssl
>>  - Incorporate review comments from Brad
>>  - ... and 38 more: https://git.openjdk.org/jdk/compare/c69275dd...6b5c692c
>
> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 62:
> 
>> 60: public final class SSLLogger implements System.Logger {
>> 61:     private static final System.Logger logger;
>> 62:     // high level boolean to track whether "all" or "ssl" option
> 
> Minor nit:  
> This makes it sounds like the boolean state `true` might be `all` and `false` is `ssl`.
> 
> Suggest maybe "to track whether logging is active (i.e. all/ssl)."

done

> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 105:
> 
>> 103:                     if (Opt.HANDSHAKE.on && p.contains("verbose")) {
>> 104:                         Opt.HANDSHAKE_VERBOSE.on = true;
>> 105:                     }
> 
> Not absolutely needed given the options currently defined, but you could `replaceFirst()` on these 3 as well.  
> 
> Your call.

thanks - I might leave this out for now. Unlikely we'll ever need such values to be removed.

> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 130:
> 
>> 128:                 }
>> 129:             }
>> 130:             // javax.net.debug would be misconfigured property with respect
> 
> Nit:  add extra line.

done

> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 149:
> 
>> 147:         return logging;
>> 148:     }
>> 149:     /**
> 
> Nit:  add a line.

done

> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 237:
> 
>> 235:         System.err.printf("%nAdding valid filter options to \"ssl\" will log" +
>> 236:                 " messages to include%njust those filtered categories.%n");
>> 237:         System.err.printf("%nIf \"ssl\" is specified by itself," +
> 
> Maybe reverse 235 and 237.  ssl by itself, then ssl+filter?  I've gone back/forth on this quite a bit.  Do you have a preference?

good point. I've swapped these around. I think it reads well now.

> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 296:
> 
>> 294:         return level != Level.OFF;
>> 295:     }
>> 296:     /**
> 
> Nit:  add a line.

done

> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 311:
> 
>> 309:      * Enabling subcomponents fine-tunes (filters) debug output.
>> 310:      */
>> 311:     public enum Opt {
> 
> Does this need to be public?

Looks like there's some usage of SSLLogger outside of sun.security.ssl

e.g. sun/security/util/DomainName.java

> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 465:
> 
>> 463:                         formatParameters(parameters) :
>> 464:                         Utilities.indent(formatParameters(parameters)))
>> 465:                 };
> 
> Why did the indent get changed?

not sure! I've reverted the indentation back

> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 490:
> 
>> 488:                     isFirst = false;
>> 489:                 } else {
>> 490:                     builder.append(",\n");
> 
> Why did this get changed from `LINE_SEP` to `\n`.  All of the other line separators in this file are still `LINE_SEP`.

this might have crept back in during a merge operation. Resolved.

> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 494:
> 
>> 492: 
>> 493:                 if (parameter instanceof Throwable) {
>> 494:                     builder.append(formatThrowable((Throwable)parameter));
> 
> Nit:  from the Java Coding conventions, Section 8.2:
> 
>     Casts should be followed by a blank. Examples:
>         myMethod((byte) aNum, (Object) x);
>         myFunc((int) (cp + 5), ((int) (i + 3))
> 
> I don't have a strong preference here.  
> 
> If you do revert back, there are several places that got changed here.

Thanks - I need to remember that coding convention. Seen different styles.
I've taken an extra step here and introduced instanceof pattern matching where possible. Cleans up the code some more.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2737388191
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2737392636
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2737392983
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2737393402
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2737395056
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2737395731
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2737398470
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2737400506
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2737402184
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2737405959

From dfenacci at openjdk.org  Wed Jan 28 16:23:21 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 28 Jan 2026 16:23:21 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v5]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <UVDT8Lsr8ZnIVyGdwaXI83U2QcsbyMeJvRg02OdVyww=.1658b087-d14d-4d16-996a-d18624d46176@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision:

 - JDK-8374582: fix comment layout
 - JDK-8374582: fix constructor argument name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/a3690526..bddec5b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=03-04

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/29164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164

PR: https://git.openjdk.org/jdk/pull/29164

From xuelei.f at gmail.com  Wed Jan 28 16:40:31 2026
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Wed, 28 Jan 2026 08:40:31 -0800
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v9]
In-Reply-To: <k7wMtNwusu5--8vfdjMTwC0rQIqIoXUtT3UXkg20LwE=.caba1a91-89dc-4839-be22-58e5e18c4c5c@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <1n7cM37Rd8vlEbxnZzaQhyxHveEQ5jeqNJKzwqYipTk=.299583c9-8c2c-4119-ad19-f9ec56a7173e@github.com>
 <POSv-RUqpERiVlfaGtotSgK1XeszOIyfD617E6pHWKc=.b8829e93-3346-42e0-87e5-a0b83d9f43a5@github.com>
 <k7wMtNwusu5--8vfdjMTwC0rQIqIoXUtT3UXkg20LwE=.caba1a91-89dc-4839-be22-58e5e18c4c5c@github.com>
Message-ID: <CAPJ=zzgOGmNafGz_P4syheqAxvbsxfSUstsQmGv85NY-c5pC=w@mail.gmail.com>

On Tue, Jan 27, 2026 at 9:27?AM Artur Barashev <abarashev at openjdk.org>
wrote:

> On Tue, 27 Jan 2026 16:54:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org>
> wrote:
>
> >> Artur Barashev has updated the pull request incrementally with one
> additional commit since the last revision:
> >>
> >>   Allocate 24 bits for input size in cache key. Add unit tests.
> >
> > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 982:
> >
> >> 980:             boolean enableCertificateCompression) {
> >> 981:         this.enableCertificateCompression =
> enableCertificateCompression;
> >> 982:     }
> >
> > Is there a plan to support brotli compression algorithm in OpenJDK?  It
> is the only supported algorithm in browser Chrome.
> >
> > If there is a need to support more than one compression algorithms in
> the future, it might be better to provide an option to customize the
> algorithms selection, including preferences.  The flexibility could provide
> better interoperability if a vendor does not support compression algorithm
> properly.
>
> Yes, strangely Chrome supports only brotli although I didn't see any
> difference in compression ration between zlib and brotli when manually
> testing certificate compression. We may add support for more algorithms in
> the future, but for now it's zlib only.


Once there is a need to support more algorithms, this API may not be
applicable for some cases especially when there are compatibility impact.
It might be good to consider the API to support multiple algorithms from
day zero.

Just my $0.02.

Thanks,
Xuelei


> Generally speaking, it's the certificate's metadata that is being
> compressed, the keys are high-entropy data difficult to compress. PQC
> certificates don?t compress well, most likely because of lower metadata to
> keys ratio.



>
> -------------
>
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/28682#discussion_r2733079369
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20260128/7e41c352/attachment.htm>

From xuelei.f at gmail.com  Wed Jan 28 16:53:15 2026
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Wed, 28 Jan 2026 08:53:15 -0800
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v9]
In-Reply-To: <CAPJ=zzgOGmNafGz_P4syheqAxvbsxfSUstsQmGv85NY-c5pC=w@mail.gmail.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <1n7cM37Rd8vlEbxnZzaQhyxHveEQ5jeqNJKzwqYipTk=.299583c9-8c2c-4119-ad19-f9ec56a7173e@github.com>
 <POSv-RUqpERiVlfaGtotSgK1XeszOIyfD617E6pHWKc=.b8829e93-3346-42e0-87e5-a0b83d9f43a5@github.com>
 <k7wMtNwusu5--8vfdjMTwC0rQIqIoXUtT3UXkg20LwE=.caba1a91-89dc-4839-be22-58e5e18c4c5c@github.com>
 <CAPJ=zzgOGmNafGz_P4syheqAxvbsxfSUstsQmGv85NY-c5pC=w@mail.gmail.com>
Message-ID: <CAPJ=zziYQkqZFBt9mnPfXBWL+GWL2AydLMCiHDntvomSoCmdLw@mail.gmail.com>

>
>> Yes, strangely Chrome supports only brotli although I didn't see any
>> difference in compression ration between zlib and brotli when manually
>> testing certificate compression.
>
>
Did you have a chance to compress certification path with multiple
certificates?  It is said Brotli has better ratio.

It is said decompression is fas for Brotli.  An entry may cache certificate
compression and thus decompression performance could play a role for the
algorithm selection in practice.

Xuelei



>>
>> -------------
>>
>> PR Review Comment:
>> https://git.openjdk.org/jdk/pull/28682#discussion_r2733079369
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20260128/82032b40/attachment.htm>

From abarashev at openjdk.org  Wed Jan 28 16:53:59 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 28 Jan 2026 16:53:59 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Force cache limit per compression algorithm

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/358840fc..b96442a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=08-09

  Stats: 17 lines in 2 files changed: 10 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

PR: https://git.openjdk.org/jdk/pull/28682

From abarashev at openjdk.org  Wed Jan 28 17:54:42 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 28 Jan 2026 17:54:42 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
Message-ID: <DafAw81Tvi_4p9zpQV1TqT98zQ1rBL6cNLzw7JoT1uk=.a8628088-2256-44d7-98b2-83e16f9c7369@github.com>

On Wed, 28 Jan 2026 16:53:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force cache limit per compression algorithm

> _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
> 
> > > Yes, strangely Chrome supports only brotli although I didn't see any
> > > difference in compression ration between zlib and brotli when manually
> > > testing certificate compression.
> 
> Did you have a chance to compress certification path with multiple certificates? It is said Brotli has better ratio.
> 
> It is said decompression is fas for Brotli. An entry may cache certificate compression and thus decompression performance could play a role for the algorithm selection in practice.
> 
> Xuelei
> 
> > 
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20260128/82032b40/attachment.htm>

- Yes, I tested 3-certificate "EC" and "ML-DSA" chains in DER format. There is no significant difference with default compression settings between gzip and brotli:
   -  1771  EC_chain.der
   -  1029  EC_chain.der.br
   -  1006  EC_chain.der.gz
   - 16992  ML-DSA_chain.der
   - 16487  ML-DSA_chain.der.br
   - 16555  ML-DSA_chain.der.gz
- Decompression is generally much faster than compression for any algorithm, so while brotli decompression is faster than ZLIB it's not going to be a major performance factor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28682#issuecomment-3812856696

From abarashev at openjdk.org  Wed Jan 28 18:00:57 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 28 Jan 2026 18:00:57 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
Message-ID: <sLa5fs-1hgDfzxSjJB3jBCSc-eQ1iAG3sSZh-GZlgTI=.e7e92fc9-0d6a-4cc2-a5d9-6b12307a9447@github.com>

On Wed, 28 Jan 2026 16:53:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force cache limit per compression algorithm

> _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
> 
> On Tue, Jan 27, 2026 at 9:27?AM Artur Barashev <abarashev at openjdk.org> wrote:
> 
> > On Tue, 27 Jan 2026 16:54:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org>
> > wrote:
> > > > Artur Barashev has updated the pull request incrementally with one
> > > > additional commit since the last revision:
> > > > Allocate 24 bits for input size in cache key. Add unit tests.
> > > 
> > > 
> > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 982:
> > > > 980:             boolean enableCertificateCompression) {
> > > > 981:         this.enableCertificateCompression =
> > > > enableCertificateCompression;
> > > > 982:     }
> > > 
> > > 
> > > Is there a plan to support brotli compression algorithm in OpenJDK?  It
> > > is the only supported algorithm in browser Chrome.
> > > If there is a need to support more than one compression algorithms in
> > > the future, it might be better to provide an option to customize the
> > > algorithms selection, including preferences.  The flexibility could provide
> > > better interoperability if a vendor does not support compression algorithm
> > > properly.
> > 
> > 
> > Yes, strangely Chrome supports only brotli although I didn't see any
> > difference in compression ration between zlib and brotli when manually
> > testing certificate compression. We may add support for more algorithms in
> > the future, but for now it's zlib only.
> 
> Once there is a need to support more algorithms, this API may not be applicable for some cases especially when there are compatibility impact. It might be good to consider the API to support multiple algorithms from day zero.
> 
> Just my $0.02.
> 
> Thanks, Xuelei
> 
> > Generally speaking, it's the certificate's metadata that is being
> > compressed, the keys are high-entropy data difficult to compress. PQC
> > certificates don?t compress well, most likely because of lower metadata to
> > keys ratio.
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20260128/7e41c352/attachment.htm>

I know original design had callback functions for custom deflators/inflators, but it was decided to support only internally implemented ZLIB for now. We may add callbacks at the later time if there is a demand for it. Current API only enables/disables the certificate compression overall, there shouldn't be any compatibly issues with future callback function mechanism if we decide to support it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28682#issuecomment-3812904883

From vyazici at openjdk.org  Wed Jan 28 19:06:27 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 28 Jan 2026 19:06:27 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v5]
In-Reply-To: <UVDT8Lsr8ZnIVyGdwaXI83U2QcsbyMeJvRg02OdVyww=.1658b087-d14d-4d16-996a-d18624d46176@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <UVDT8Lsr8ZnIVyGdwaXI83U2QcsbyMeJvRg02OdVyww=.1658b087-d14d-4d16-996a-d18624d46176@github.com>
Message-ID: <YRa29n3zMGoazIkezGYf1VazGU6gbLz548PG2bw9nrI=.42120acc-417e-44bc-870e-a148f1cb659c@github.com>

On Wed, 28 Jan 2026 16:23:21 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JDK-8374582: fix comment layout
>  - JDK-8374582: fix constructor argument name

Copyright years don't point to 2026 for the following touched files:


src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
src/hotspot/cpu/x86/macroAssembler_x86.cpp
src/hotspot/share/classfile/vmIntrinsics.hpp
src/hotspot/share/opto/classes.hpp
src/hotspot/share/opto/escape.cpp
src/hotspot/share/opto/library_call.cpp
src/hotspot/share/opto/library_call.hpp
src/hotspot/share/opto/loopTransform.cpp
src/hotspot/share/opto/loopopts.cpp
src/hotspot/share/opto/macro.cpp
src/hotspot/share/opto/node.hpp
src/hotspot/share/opto/opaquenode.cpp
src/hotspot/share/opto/opaquenode.hpp
src/hotspot/share/opto/split_if.cpp
src/java.base/share/classes/java/lang/String.java
src/java.base/share/classes/java/lang/StringCoding.java
src/java.base/share/classes/java/lang/System.java
src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
src/java.base/share/classes/sun/nio/cs/CESU_8.java
src/java.base/share/classes/sun/nio/cs/DoubleByte.java
src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java
src/java.base/share/classes/sun/nio/cs/SingleByte.java
src/java.base/share/classes/sun/nio/cs/US_ASCII.java
src/java.base/share/classes/sun/nio/cs/UTF_8.java
src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template
test/hotspot/jtreg/compiler/escapeAnalysis/TestCanReduceCheckUsersDifferentIfs.java
test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java
test/hotspot/jtreg/compiler/unsafe/OpaqueAccesses.java

-------------

PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3718529560

From abarashev at openjdk.org  Wed Jan 28 20:19:34 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 28 Jan 2026 20:19:34 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v2]
In-Reply-To: <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
Message-ID: <raPzDbE3eI1UTvXK8K3mZ8Dy5IDsSGtAITPyQO91U9c=.93bc0474-a455-4584-a5d0-3e227044a3b5@github.com>

On Thu, 22 Jan 2026 23:51:42 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Refactor sun.security.provider.X509Factory cache access to avoid coarse-grained locking and reduce contention during certificate/CRL interning and parsing.
>> 
>> As per request in [the PR](https://github.com/openjdk/jdk/pull/22616#issuecomment-2524971845), re-visit "the initialisation and locking in this area, e.g. addToCache is a static synchronized method so very coarse locking."
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345954: Addressing review comments

I wonder why we need to do any synchronization in `X509Factory` at all when `sun.security.util.MemoryCache` being used is internally synchronized and its documentation states that it's `safe for concurrent use by multiple threads`:
https://github.com/openjdk/jdk/blob/7efa3168b706c1d061c4ee65574427ef1f50fc7b/src/java.base/share/classes/sun/security/util/Cache.java#L267

I think we need to look closer into this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29181#issuecomment-3813708167

From wetmore at openjdk.org  Wed Jan 28 20:27:05 2026
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 28 Jan 2026 20:27:05 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v26]
In-Reply-To: <XAnEj4gkM8cy71YbVtjQ5dMoa6iQf3jzDR3E1ABsufc=.2d59672f-e33b-4b35-88e1-3c40ccd4a66c@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
 <xhLHqZx2wotlAV7ps5ipOCKNi-LQhbu3B5ojs5EK50w=.54b66b88-dd2e-46c0-96bf-91eb73b9fd2c@github.com>
 <KoNRySQEhqft-pQl3F_Q0V_Y3I8vJNH_PwYXgxSW_6U=.6ae1fcff-38af-40ed-9088-dabec373b79b@github.com>
 <XAnEj4gkM8cy71YbVtjQ5dMoa6iQf3jzDR3E1ABsufc=.2d59672f-e33b-4b35-88e1-3c40ccd4a66c@github.com>
Message-ID: <WzxaAg2JGeRakCntbzR5-7IbS_GOU0eBvN7niqmBOvc=.1c4afbba-c1ec-45a4-b1c2-10a4712bd2dc@github.com>

On Wed, 28 Jan 2026 16:11:52 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 105:
>> 
>>> 103:                     if (Opt.HANDSHAKE.on && p.contains("verbose")) {
>>> 104:                         Opt.HANDSHAKE_VERBOSE.on = true;
>>> 105:                     }
>> 
>> Not absolutely needed given the options currently defined, but you could `replaceFirst()` on these 3 as well.  
>> 
>> Your call.
>
> thanks - I might leave this out for now. Unlikely we'll ever need such values to be removed.

Ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2738459779

From wetmore at openjdk.org  Wed Jan 28 20:27:09 2026
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 28 Jan 2026 20:27:09 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v26]
In-Reply-To: <KoNRySQEhqft-pQl3F_Q0V_Y3I8vJNH_PwYXgxSW_6U=.6ae1fcff-38af-40ed-9088-dabec373b79b@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
 <xhLHqZx2wotlAV7ps5ipOCKNi-LQhbu3B5ojs5EK50w=.54b66b88-dd2e-46c0-96bf-91eb73b9fd2c@github.com>
 <KoNRySQEhqft-pQl3F_Q0V_Y3I8vJNH_PwYXgxSW_6U=.6ae1fcff-38af-40ed-9088-dabec373b79b@github.com>
Message-ID: <WQZTeIaHwofCo6RCt-6gKQ1U-3AwTYPGO9eZDvCxXac=.ab163d73-e0c6-438b-a119-d9907c8f7b33@github.com>

On Wed, 28 Jan 2026 04:22:28 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:
>> 
>>  - correct NamedGroup.java merge
>>  - Merge branch 'master' into 8044609-ssl
>>  - fix up test bug ID
>>  - fix up files post merge
>>  - Merge branch 'master' into 8044609-ssl
>>  - prep for isOn() merge
>>  - Merge branch 'master' into 8044609-ssl
>>  - Merge branch 'master' into 8044609-ssl
>>  - Merge branch 'master' into 8044609-ssl
>>  - Incorporate review comments from Brad
>>  - ... and 38 more: https://git.openjdk.org/jdk/compare/c69275dd...6b5c692c
>
> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 157:
> 
>> 155:     }
>> 156: 
>> 157:     public static void severe(String msg, Object... params) {
> 
> Since we're down here, these don't really need to be `public`.  Package-private  is fine.

I didn't see this comment (`isOn`/`severe`/`warning`/etc.) addressed?  They are still `public`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2738469785

From wetmore at openjdk.org  Wed Jan 28 20:34:08 2026
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 28 Jan 2026 20:34:08 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v26]
In-Reply-To: <WQZTeIaHwofCo6RCt-6gKQ1U-3AwTYPGO9eZDvCxXac=.ab163d73-e0c6-438b-a119-d9907c8f7b33@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
 <xhLHqZx2wotlAV7ps5ipOCKNi-LQhbu3B5ojs5EK50w=.54b66b88-dd2e-46c0-96bf-91eb73b9fd2c@github.com>
 <KoNRySQEhqft-pQl3F_Q0V_Y3I8vJNH_PwYXgxSW_6U=.6ae1fcff-38af-40ed-9088-dabec373b79b@github.com>
 <WQZTeIaHwofCo6RCt-6gKQ1U-3AwTYPGO9eZDvCxXac=.ab163d73-e0c6-438b-a119-d9907c8f7b33@github.com>
Message-ID: <gBlnFu2FlvOOcht3XhEYXT3QZzhhYoR9CvuWc_w3YLM=.b7a6705d-b6b1-4f35-a60f-eb745c7f9e87@github.com>

On Wed, 28 Jan 2026 20:23:46 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 157:
>> 
>>> 155:     }
>>> 156: 
>>> 157:     public static void severe(String msg, Object... params) {
>> 
>> Since we're down here, these don't really need to be `public`.  Package-private  is fine.
>
> I didn't see this comment (`isOn`/`severe`/`warning`/etc.) addressed?  They are still `public`.

Just found later comment about `sun/security/util/DomainName.java`, so these can stay public.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2738481515

From wetmore at openjdk.org  Wed Jan 28 20:34:11 2026
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 28 Jan 2026 20:34:11 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v26]
In-Reply-To: <XAnEj4gkM8cy71YbVtjQ5dMoa6iQf3jzDR3E1ABsufc=.2d59672f-e33b-4b35-88e1-3c40ccd4a66c@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
 <xhLHqZx2wotlAV7ps5ipOCKNi-LQhbu3B5ojs5EK50w=.54b66b88-dd2e-46c0-96bf-91eb73b9fd2c@github.com>
 <KoNRySQEhqft-pQl3F_Q0V_Y3I8vJNH_PwYXgxSW_6U=.6ae1fcff-38af-40ed-9088-dabec373b79b@github.com>
 <XAnEj4gkM8cy71YbVtjQ5dMoa6iQf3jzDR3E1ABsufc=.2d59672f-e33b-4b35-88e1-3c40ccd4a66c@github.com>
Message-ID: <SAzZ_cVMy9ObK_errZ_Kdj_nYO3cqKO7pAwDYsBCxBo=.0a3c4d93-6752-4c87-a4e8-c06956239559@github.com>

On Wed, 28 Jan 2026 16:13:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 311:
>> 
>>> 309:      * Enabling subcomponents fine-tunes (filters) debug output.
>>> 310:      */
>>> 311:     public enum Opt {
>> 
>> Does this need to be public?
>
> Looks like there's some usage of SSLLogger outside of sun.security.ssl
> 
> e.g. sun/security/util/DomainName.java

Ah, I didn't know there were any consumers outside the SSL code.

>> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 494:
>> 
>>> 492: 
>>> 493:                 if (parameter instanceof Throwable) {
>>> 494:                     builder.append(formatThrowable((Throwable)parameter));
>> 
>> Nit:  from the Java Coding conventions, Section 8.2:
>> 
>>     Casts should be followed by a blank. Examples:
>>         myMethod((byte) aNum, (Object) x);
>>         myFunc((int) (cp + 5), ((int) (i + 3))
>> 
>> I don't have a strong preference here.  
>> 
>> If you do revert back, there are several places that got changed here.
>
> Thanks - I need to remember that coding convention. Seen different styles.
> I've taken an extra step here and introduced instanceof pattern matching where possible. Cleans up the code some more.

That is one clean way to do it.  Doesn't backport well (11/8), but works well enough!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2738484618
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2738493926

From mullan at openjdk.org  Wed Jan 28 21:29:08 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 28 Jan 2026 21:29:08 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
Message-ID: <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>

On Wed, 28 Jan 2026 16:53:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force cache limit per compression algorithm

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 966:

> 964: 
> 965:     /**
> 966:      * Sets whether TLS certificate compression should be enabled.

I think we should also specify what this enables, the name of the extension. I would also add an @spec label with RFC 8879. Also consider adding a sentence or two (perhaps as an API note) that this signals to the peer that it supports compression and that both sides need to support the underlying extension and compression format in order for it to be actually used. 

Also, I would probably add an Implementation Note specifying that the SunJSSE provider only supports zlib compression, and that other JSSE providers may not support this method.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 979:

> 977:      * @since 27
> 978:      */
> 979:     public void setEnableCertificateCompression(

Need to specify the default value in the constructor.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 985:

> 983: 
> 984:     /**
> 985:      * Returns whether TLS certificate compression should be enabled

Missing period.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2738642563
PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2738595313
PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2738598539

From abarashev at openjdk.org  Thu Jan 29 02:14:51 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 02:14:51 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
 <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
Message-ID: <uApZ_GHW_dTqG_vKDuMNpIB33Y56_Qc0CGjp1ubooGU=.cc477e87-3d98-4424-af0e-afe848680ad9@github.com>

On Wed, 28 Jan 2026 21:02:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Force cache limit per compression algorithm
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 985:
> 
>> 983: 
>> 984:     /**
>> 985:      * Returns whether TLS certificate compression should be enabled
> 
> Missing period.

Done, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2739445115

From abarashev at openjdk.org  Thu Jan 29 02:19:38 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 02:19:38 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
 <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
Message-ID: <_rzv0U2YCmViu8Rg4SaZfqhr5THzV65DHD2w5oBbOag=.3094eaab-8967-4efa-8284-4dac174798b0@github.com>

On Wed, 28 Jan 2026 21:01:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Force cache limit per compression algorithm
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 979:
> 
>> 977:      * @since 27
>> 978:      */
>> 979:     public void setEnableCertificateCompression(
> 
> Need to specify the default value in the constructor.

The convention in `SSLParameters` is not to specify the default values: the rest of set methods in this file don't mention it. In our particular case the default value is the value of `jdk.tls.enableCertificateCompression` system property, and if such value is not set then it's `true`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2739453252

From abarashev at openjdk.org  Thu Jan 29 02:52:55 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 02:52:55 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v11]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <z0wPRFf8DgVZ1IRRhDggSrSckgwWQ0RPbsaMkpS3pwU=.ac82a54d-9a9d-4c9e-af7e-a53c5b11ecdd@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/b96442a9..2c911b0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=09-10

  Stats: 13 lines in 1 file changed: 10 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

PR: https://git.openjdk.org/jdk/pull/28682

From abarashev at openjdk.org  Thu Jan 29 02:52:58 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 02:52:58 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
 <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
Message-ID: <wa9NzhMhD0PylqkiPAc_L9_7s7Qi6QLlwm-Gi-8JCyw=.f7fee6b5-0e52-4bd0-a9b6-6bb997116e71@github.com>

On Wed, 28 Jan 2026 21:16:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Force cache limit per compression algorithm
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 966:
> 
>> 964: 
>> 965:     /**
>> 966:      * Sets whether TLS certificate compression should be enabled.
> 
> I think we should also specify what this enables, the name of the extension. I would also add an @spec label with RFC 8879. Also consider adding a sentence or two (perhaps as an API note) that this signals to the peer that it supports compression and that both sides need to support the underlying extension and compression format in order for it to be actually used. 
> 
> Also, I would probably add an Implementation Note specifying that the SunJSSE provider only supports zlib compression, and that other JSSE providers may not support this method.

Done, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2739563146

From dfenacci at openjdk.org  Thu Jan 29 07:32:12 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 29 Jan 2026 07:32:12 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v6]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <o9-z7YqT6dihVbU7KFHqpMELp8i75tvIJg6tY6J_c3E=.7121e5e7-4700-4ff9-afb8-b924095ed53b@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Damon Fenacci 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 31 additional commits since the last revision:

 - JDK-8374582: merge and update copyright year
 - Merge branch 'master' into JDK-8374582
 - Merge branch 'master' into JDK-8374582
 - JDK-8374582: fix comment layout
 - JDK-8374582: fix constructor argument name
 - JDK-8374582: fix indent
 - JDK-8374582: constant
 - JDK-8374582: add size_of
 - JDK-8374852: OpaqueCheck -> OpaqueConstantBool
 - JDK-8374852: fix number of OpaqueCheck nodes in test
 - ... and 21 more: https://git.openjdk.org/jdk/compare/7e545381...a587a269

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/bddec5b5..a587a269

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=04-05

  Stats: 61562 lines in 1281 files changed: 34520 ins; 12116 del; 14926 mod
  Patch: https://git.openjdk.org/jdk/pull/29164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164

PR: https://git.openjdk.org/jdk/pull/29164

From dfenacci at openjdk.org  Thu Jan 29 07:32:12 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 29 Jan 2026 07:32:12 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v5]
In-Reply-To: <YRa29n3zMGoazIkezGYf1VazGU6gbLz548PG2bw9nrI=.42120acc-417e-44bc-870e-a148f1cb659c@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <UVDT8Lsr8ZnIVyGdwaXI83U2QcsbyMeJvRg02OdVyww=.1658b087-d14d-4d16-996a-d18624d46176@github.com>
 <YRa29n3zMGoazIkezGYf1VazGU6gbLz548PG2bw9nrI=.42120acc-417e-44bc-870e-a148f1cb659c@github.com>
Message-ID: <XLX15oFt15qyXhrEfUtWBNrBh1VZJh4nTVpWcHmL6C4=.013eb1ee-8fc4-4bf5-a84c-2a6bde9d2717@github.com>

On Wed, 28 Jan 2026 19:03:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Copyright years don't point to 2026 for the following touched files:

Right! Fixed. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3815950950

From smonteith at openjdk.org  Thu Jan 29 09:03:47 2026
From: smonteith at openjdk.org (Stuart Monteith)
Date: Thu, 29 Jan 2026 09:03:47 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <Mg3vPu8exFTKO4FiJAudoCLbAU27lxZk_iUWmSrlY9w=.273cdbaf-0c19-4b27-b7df-5c583f732988@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <Mg3vPu8exFTKO4FiJAudoCLbAU27lxZk_iUWmSrlY9w=.273cdbaf-0c19-4b27-b7df-5c583f732988@github.com>
Message-ID: <5izV9DyV060gChX8G_D1BvaYq6AJ2u9abAH8HmSIMKU=.a903cdd2-ec1c-4d4d-8c87-6dac4a8e32a8@github.com>

On Tue, 27 Jan 2026 16:54:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Sorry this is taking a while to review. I have been swamped since the start of the year. I want to give this patch the time it deserves, but that also means it's not possible to squeeze in the review between other things

Thanke @JornVernee , appreciated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3816372109

From dfenacci at openjdk.org  Thu Jan 29 12:42:44 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 29 Jan 2026 12:42:44 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v7]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <y1_tSg2kFucxLE1zIBdVlAcKcIsqKPTgNoSBanfJNzI=.e1f3b33d-91ba-4af3-b5b4-a77f948520f7@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8374582: add flagless to test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/a587a269..083d5698

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=05-06

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164

PR: https://git.openjdk.org/jdk/pull/29164

From weijun at openjdk.org  Thu Jan 29 12:49:47 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Jan 2026 12:49:47 GMT
Subject: RFR: 8373018: Build OpenSSL 3.5.4 with ZLIB
In-Reply-To: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>
References: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>
Message-ID: <YJvSatW0yqbv3zLfPX4C-W36JyI3CcvzN0f24xedrRc=.b24e9eee-1d77-45d3-ba51-c3888471fd61@github.com>

On Tue, 20 Jan 2026 14:39:41 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This small PR updates the OpenSSL library version to 3.5.4

The title confused me a little, as if it is about building OpenSSL.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29323#issuecomment-3817474481

From duke at openjdk.org  Thu Jan 29 12:55:33 2026
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 29 Jan 2026 12:55:33 GMT
Subject: Integrated: 8374755: ML-KEM's 12-bit decompression can be simplified
 on aarch64
In-Reply-To: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
Message-ID: <tFxd_k2J0072uAiUuoY1CKivgr4JwF_68szJ3kq7uNA=.ace2ef72-12bc-4eda-ba1f-0f089a8cc643@github.com>

On Fri, 9 Jan 2026 14:41:07 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.

This pull request has now been integrated.

Changeset: 99119597
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99119597aa95c1139ae2259bed5ec885a7c01269
Stats:     91 lines in 2 files changed: 4 ins; 73 del; 14 mod

8374755: ML-KEM's 12-bit decompression can be simplified on aarch64

Reviewed-by: adinn

-------------

PR: https://git.openjdk.org/jdk/pull/29141

From mullan at openjdk.org  Thu Jan 29 13:30:41 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 29 Jan 2026 13:30:41 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <_rzv0U2YCmViu8Rg4SaZfqhr5THzV65DHD2w5oBbOag=.3094eaab-8967-4efa-8284-4dac174798b0@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
 <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
 <_rzv0U2YCmViu8Rg4SaZfqhr5THzV65DHD2w5oBbOag=.3094eaab-8967-4efa-8284-4dac174798b0@github.com>
Message-ID: <VUxcre337JywdXRtDUAhfiy4hd0A7e2o6Ygc5jH1XvY=.6661a731-1da2-4c49-987a-c84faff98bbf@github.com>

On Thu, 29 Jan 2026 02:17:02 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 979:
>> 
>>> 977:      * @since 27
>>> 978:      */
>>> 979:     public void setEnableCertificateCompression(
>> 
>> Need to specify the default value in the constructor.
>
> The convention in `SSLParameters` is not to specify the default values: the rest of set methods in this file don't mention it. In our particular case the default value is the value of `jdk.tls.enableCertificateCompression` system property, and if such value is not set then it's `true`

The defaults are listed in the SSLParameters ctor: https://download.java.net/java/early_access/jdk26/docs/api/java.base/javax/net/ssl/SSLParameters.html#%3Cinit%3E()

So I think the default for this new param should also be listed if the application is creating the `SSLParameters` and not the provider implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2741648461

From mdonovan at openjdk.org  Thu Jan 29 13:46:30 2026
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 29 Jan 2026 13:46:30 GMT
Subject: RFR: 8373018: Build OpenSSL 3.5.4 with ZLIB [v2]
In-Reply-To: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>
References: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>
Message-ID: <lxe_-HbDfPCUxs-6X2C1jCGwgJ9YujA-yLJ0pVK4Wy8=.8517300d-1dcd-4d7e-acfc-041c22db02cc@github.com>

> This small PR updates the OpenSSL library version to 3.5.4

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29323/files
  - new: https://git.openjdk.org/jdk/pull/29323/files/cf6060f1..c8d4f79b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29323&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29323&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29323/head:pull/29323

PR: https://git.openjdk.org/jdk/pull/29323

From mdonovan at openjdk.org  Thu Jan 29 13:51:10 2026
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 29 Jan 2026 13:51:10 GMT
Subject: RFR: 8373018: Build OpenSSL 3.5.4 with ZLIB
In-Reply-To: <YJvSatW0yqbv3zLfPX4C-W36JyI3CcvzN0f24xedrRc=.b24e9eee-1d77-45d3-ba51-c3888471fd61@github.com>
References: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>
 <YJvSatW0yqbv3zLfPX4C-W36JyI3CcvzN0f24xedrRc=.b24e9eee-1d77-45d3-ba51-c3888471fd61@github.com>
Message-ID: <mSfasuFOMlj69qlsPenuUTtXjWjqNRw1jwWji-rJnRE=.99abaafb-eb9d-4e4c-8fd2-6ad4b4006d59@github.com>

On Thu, 29 Jan 2026 12:47:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The title confused me a little, as if it is about building OpenSSL.

I updated the title.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29323#issuecomment-3817806443

From mdonovan at openjdk.org  Thu Jan 29 13:51:14 2026
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 29 Jan 2026 13:51:14 GMT
Subject: RFR: 8373018: Build OpenSSL 3.5.4 with ZLIB [v2]
In-Reply-To: <Od5Z6twLAyeO66QMXMcNlegwkzoNLSPeskerh8r_Iu8=.16619a8b-6c01-42cf-bda1-f890df9c6447@github.com>
References: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>
 <Od5Z6twLAyeO66QMXMcNlegwkzoNLSPeskerh8r_Iu8=.16619a8b-6c01-42cf-bda1-f890df9c6447@github.com>
Message-ID: <ehc9N4ESwKTA-cpn6J-TzVgcrlFtdPkr7dA-FJuTOnw=.b330b177-f571-4b0e-be37-2a2ef4116118@github.com>

On Tue, 20 Jan 2026 15:08:44 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright year
>
> test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Nit: copyright

Updated copyright year.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29323#discussion_r2741744974

From abarashev at openjdk.org  Thu Jan 29 13:57:57 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 13:57:57 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v12]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <B9Yj-v4kk_FfOCre_YSwTet5ErQUB3oqfdeDaADpgkc=.266a53af-663c-445b-8a9c-c45c1dddb822@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Use newSoftMemoryCache for LRU mechanism and EqualByteArray to avoid any chance of collision

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/2c911b0a..82d5d62f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=10-11

  Stats: 516 lines in 6 files changed: 213 ins; 291 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

PR: https://git.openjdk.org/jdk/pull/28682

From abarashev at openjdk.org  Thu Jan 29 13:58:18 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 13:58:18 GMT
Subject: RFR: 8373018: Build OpenSSL 3.5.4 with ZLIB [v2]
In-Reply-To: <lxe_-HbDfPCUxs-6X2C1jCGwgJ9YujA-yLJ0pVK4Wy8=.8517300d-1dcd-4d7e-acfc-041c22db02cc@github.com>
References: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>
 <lxe_-HbDfPCUxs-6X2C1jCGwgJ9YujA-yLJ0pVK4Wy8=.8517300d-1dcd-4d7e-acfc-041c22db02cc@github.com>
Message-ID: <c81t2_NaiFvhijRAOOYHeEMgp_ynVu6uBDWLG3NGGAM=.8b164484-ad5e-49e3-aec2-ad40af57e579@github.com>

On Thu, 29 Jan 2026 13:46:30 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This small PR updates the OpenSSL library version to 3.5.4
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

LGTM

-------------

Marked as reviewed by abarashev (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29323#pullrequestreview-3722890196

From adinn at openjdk.org  Thu Jan 29 14:33:52 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 29 Jan 2026 14:33:52 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression can be simplified on
 aarch64 [v3]
In-Reply-To: <USCU_XBZpwk-x4wNEubmF6sg9VfBz1lA8PO1-2fIjZ8=.cb62b145-7b95-48bd-89c1-db408367b408@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <USCU_XBZpwk-x4wNEubmF6sg9VfBz1lA8PO1-2fIjZ8=.cb62b145-7b95-48bd-89c1-db408367b408@github.com>
Message-ID: <Hi9QYkCz4TMQ9KygPweiHIXvphFZbvLNz8JEGRIzOtI=.9b388fbe-b15e-4fb5-85b4-36fb1e9fdacc@github.com>

On Mon, 19 Jan 2026 14:01:56 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve comment

@wangweij Thanks for sponsoring. While that probably counts implicitly as a review I think you are supposed to actually click the 'reviewed' button to acknowledge that you have reviewed the code.

n.b. Although the PR says only one review is required a Hotspot change actually needs two reviews with at least one (big R) 'Reviewer'.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29141#issuecomment-3818054364

From abarashev at openjdk.org  Thu Jan 29 14:38:19 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 14:38:19 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <VUxcre337JywdXRtDUAhfiy4hd0A7e2o6Ygc5jH1XvY=.6661a731-1da2-4c49-987a-c84faff98bbf@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
 <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
 <_rzv0U2YCmViu8Rg4SaZfqhr5THzV65DHD2w5oBbOag=.3094eaab-8967-4efa-8284-4dac174798b0@github.com>
 <VUxcre337JywdXRtDUAhfiy4hd0A7e2o6Ygc5jH1XvY=.6661a731-1da2-4c49-987a-c84faff98bbf@github.com>
Message-ID: <8toAKagwhzr9_aOXQ5U3Y8hPQLZ3nqW7pkQs9fK_mjI=.12315e81-d7a4-4953-b983-95c4670bdcfe@github.com>

On Thu, 29 Jan 2026 13:28:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> The convention in `SSLParameters` is not to specify the default values: the rest of set methods in this file don't mention it. In our particular case the default value is the value of `jdk.tls.enableCertificateCompression` system property, and if such value is not set then it's `true`
>
> The defaults are listed in the SSLParameters ctor: https://download.java.net/java/early_access/jdk26/docs/api/java.base/javax/net/ssl/SSLParameters.html#%3Cinit%3E()
> 
> So I think the default for this new param should also be listed if the application is creating the `SSLParameters` and not the provider implementation.

Oh, indeed! Good catch, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2741973089

From abarashev at openjdk.org  Thu Jan 29 14:46:05 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 14:46:05 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v13]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update javadoc: specify default value for enableCertificateCompression

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/82d5d62f..8b0261c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=11-12

  Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

PR: https://git.openjdk.org/jdk/pull/28682

From weijun at openjdk.org  Thu Jan 29 15:02:51 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Jan 2026 15:02:51 GMT
Subject: RFR: 8374755: ML-KEM's 12-bit decompression can be simplified on
 aarch64 [v3]
In-Reply-To: <USCU_XBZpwk-x4wNEubmF6sg9VfBz1lA8PO1-2fIjZ8=.cb62b145-7b95-48bd-89c1-db408367b408@github.com>
References: <2XkSKe1vGfj4EzcrRnkK99q8QjauNLaBgNPvMRJrhbQ=.ccee73f0-8cbf-4119-bdee-32c6784b25d1@github.com>
 <USCU_XBZpwk-x4wNEubmF6sg9VfBz1lA8PO1-2fIjZ8=.cb62b145-7b95-48bd-89c1-db408367b408@github.com>
Message-ID: <ntor8crDrryqzXMa_CqreLqBq3CVMsL06oK9LgB8oKk=.2dd49e31-8fe5-4eb9-b804-34348bc96212@github.com>

On Mon, 19 Jan 2026 14:01:56 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> The preconditions for the aarch64 and the AVX-512 intrinsic implementations of the implKyber12To16() method of com.sun.crypto.provider.ML_KEM are different and the AVX-512 one has stricter preconditions on the input, which was not recorded in the assert() before calling the function (although they were satisfied by all calling code). Now the assert() is corrected, and with these preconditions, the aarch64 implementation is simplified.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve comment

Didn't notice the reviewer count. Maybe the Skara bot hasn't enforced it. Otherwise, it should not add the `ready` and `sponsor` labels.

I typed `/sponsor` mainly because I trust Ferenc' code and reviews from you and Shawn. I don't think a sponsor has to review the code change themselves.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29141#issuecomment-3818252537

From weijun at openjdk.org  Thu Jan 29 15:05:50 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Jan 2026 15:05:50 GMT
Subject: RFR: 8373018: Build OpenSSL 3.5.4 with ZLIB [v2]
In-Reply-To: <lxe_-HbDfPCUxs-6X2C1jCGwgJ9YujA-yLJ0pVK4Wy8=.8517300d-1dcd-4d7e-acfc-041c22db02cc@github.com>
References: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>
 <lxe_-HbDfPCUxs-6X2C1jCGwgJ9YujA-yLJ0pVK4Wy8=.8517300d-1dcd-4d7e-acfc-041c22db02cc@github.com>
Message-ID: <0qYT14ORrYEEgENRV2sZ3nlS4ZwKB7r5Tza31QUC33s=.13b9c58c-47a0-4dce-9860-51b19e636a54@github.com>

On Thu, 29 Jan 2026 13:46:30 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This small PR updates the OpenSSL library version to 3.5.4
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

Approved, but you need to update the title of the PR too.

-------------

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29323#pullrequestreview-3723287182

From dfuchs at openjdk.org  Thu Jan 29 15:40:25 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Jan 2026 15:40:25 GMT
Subject: RFR: 8376031: HttpsURLConnection.getServerCertificates() throws
 "java.lang.IllegalStateException: connection not yet open" for the HEAD method
Message-ID: <dR0upqPEpJY5DoqLkFAgvOrQY5K8by_G-pG-PdG0Uvo=.a9036e97-4409-4839-81bb-c5d6f45a5b9f@github.com>

The issue here is that `HttpURLConnection` is automatically disconnected (`HttpClient` is set to `null`, `connected` is set to `false`) when a response with no response body bytes is received. This happens before a fake empty body input stream is returned to the user. That behaviour also occurs with any method for which `content-length: 0` is returned (GET, POST, custom, anything), and with any status code (204, 304) for which there is no body.

In this case, the proposed fix is to store the `SSLSession` in the `AbstractDelegateHttpsURLConnection` subclass until such a time where `disconnect()` is explicitely closed. Information pertaining to SSL, such as server certificates, can be extracted from the saved `SSLSession`.

-------------

Commit messages:
 - 8376031: HttpsURLConnection.getServerCertificates() throws "java.lang.IllegalStateException: connection not yet open" for the HEAD method

Changes: https://git.openjdk.org/jdk/pull/29489/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29489&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376031
  Stats: 481 lines in 4 files changed: 388 ins; 79 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/29489.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29489/head:pull/29489

PR: https://git.openjdk.org/jdk/pull/29489

From mdonovan at openjdk.org  Thu Jan 29 16:47:14 2026
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 29 Jan 2026 16:47:14 GMT
Subject: Integrated: 8373018: Update OpenSSL version to 3.5.4
In-Reply-To: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>
References: <VULRXuQ5gX7SwL7GRXmIAhSYI2wrexFP8YLDJED1Ims=.7c252c5e-318a-47b0-bff7-c8cae8c335f0@github.com>
Message-ID: <7uskSgS9c9vNGwD-IQeIFl7Suvo1eJX4UkvJk3A6oVc=.76bac8a0-2fd2-41fa-b217-b0424a00a61a@github.com>

On Tue, 20 Jan 2026 14:39:41 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This small PR updates the OpenSSL library version to 3.5.4

This pull request has now been integrated.

Changeset: 847b5166
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/847b5166ea6322f9ff3effa62ed6d1e73a8b1122
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8373018: Update OpenSSL version to 3.5.4

Reviewed-by: abarashev, weijun

-------------

PR: https://git.openjdk.org/jdk/pull/29323

From xuelei at openjdk.org  Thu Jan 29 17:17:42 2026
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 29 Jan 2026 17:17:42 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v13]
In-Reply-To: <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>
Message-ID: <Ag1zV75rDv2o_pyZR_B4LFplmVfibBbrSXNCpMZmuTk=.1d45afbd-a37b-4114-8b02-f6779452c2a8@github.com>

On Thu, 29 Jan 2026 14:46:05 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update javadoc: specify default value for enableCertificateCompression

src/java.base/share/classes/sun/security/ssl/CompressedCertificate.java line 148:

> 146:         // the deflated certificate data in a memory cache statically and avoid
> 147:         // compressing local certificates repeatedly for every handshake.
> 148:         private static final Cache<CompCertCacheKey, byte[]> CACHE =

I was just wondering about the multiple tenant systems, where one JVM may be used by multiple users with different key and certificates.  The system may run many weeks, and the tenants sign on and off, new and old tenants come in and out.  Will this CACHE keep the record for each key-cert for each tenant?  Could it be a potential problem?  Does it sound like a direction to cache the compressed certificate in where the certificate come from, for example key manager instance or SSLContext instance?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2742697277

From abarashev at openjdk.org  Thu Jan 29 18:17:49 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 18:17:49 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v13]
In-Reply-To: <Ag1zV75rDv2o_pyZR_B4LFplmVfibBbrSXNCpMZmuTk=.1d45afbd-a37b-4114-8b02-f6779452c2a8@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>
 <Ag1zV75rDv2o_pyZR_B4LFplmVfibBbrSXNCpMZmuTk=.1d45afbd-a37b-4114-8b02-f6779452c2a8@github.com>
Message-ID: <KqBPy_GpoXAcWuMOvtAomVx-Y2rZV7NVceSY7gvR6-0=.371b2bcf-1f61-4074-9982-c534b3a2c108@github.com>

On Thu, 29 Jan 2026 17:15:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update javadoc: specify default value for enableCertificateCompression
>
> src/java.base/share/classes/sun/security/ssl/CompressedCertificate.java line 148:
> 
>> 146:         // the deflated certificate data in a memory cache statically and avoid
>> 147:         // compressing local certificates repeatedly for every handshake.
>> 148:         private static final Cache<CompCertCacheKey, byte[]> CACHE =
> 
> I was just wondering about the multiple tenant systems, where one JVM may be used by multiple users with different key and certificates.  The system may run many weeks, and the tenants sign on and off, new and old tenants come in and out.  Will this CACHE keep the record for each key-cert for each tenant?  Could it be a potential problem?  Does it sound like a direction to cache the compressed certificate in where the certificate come from, for example key manager instance or SSLContext instance, without using static field?

Yes, I'm actually currently thinking whether to attach this cache to SSLContext instance or not. Not sure about it. This cache implementation has LRU mechanism, so it will simply keep the last 12 compressed certs in memory which should be fine for most scenarios. It's also an easier to maintain code where we have all the pieces in a single file. Currently we have only session caches attached to SSLContext and quite a few static caches like this one in JSSE code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2742923390

From mullan at openjdk.org  Thu Jan 29 19:53:41 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 29 Jan 2026 19:53:41 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v12]
In-Reply-To: <c9pcA-G-P_63a9ICfLwNe3iodcQiFJNX40K0MtsIZCI=.ce04424e-7233-4dd7-af2e-0a4f1e230f59@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <c9pcA-G-P_63a9ICfLwNe3iodcQiFJNX40K0MtsIZCI=.ce04424e-7233-4dd7-af2e-0a4f1e230f59@github.com>
Message-ID: <ykULcDTapaUBh37b7L-RXnyLA_ibaLRpVzXANbjqoT8=.b8e8f84a-0090-46fb-a3c9-5092c7aa489d@github.com>

On Fri, 23 Jan 2026 14:49:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest [draft-ietf-lamps-kyber-certificates-11](https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-11) and [RFC 9881](https://datatracker.ietf.org/doc/rfc9881/). New security/system properties are introduced to determine which CHOICE a private key is encoded when a new key pair is generated or when `KeyFactory::translateKey` is called.
>> 
>> By default, the choice is "seed".
>> 
>> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS8 key, the expanded format is calculated from the input if it's seed only.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   grammar; no more 8347941

src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java line 68:

> 66: ///
> 67: /// A `NamedPKCS8Key`, when created, must include `expanded` if required, its
> 68: /// `privKeyMaterial` must have already been validated for internal consistency.

I don't understand this sentence - maybe should be two sentences?

src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java line 192:

> 190:     }
> 191: 
> 192:     /// Expands from encoding format to expanded format.

Add `@FunctionalInterface`?

src/java.base/share/classes/sun/security/provider/NamedKeyFactory.java line 245:

> 243:     @Override
> 244:     protected Key engineTranslateKey(Key key) throws InvalidKeyException {
> 245:         // The base toNamedKey only make sure key is translated into a NamedKey.

s/make/makes/

test/jdk/sun/security/provider/pqc/PrivateKeyEncodings.java line 1:

> 1: /*

Is this test skipped if it cannot download the drafts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2743063487
PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2743082475
PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2742340332
PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2743249691

From abarashev at openjdk.org  Thu Jan 29 19:56:09 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 19:56:09 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v2]
In-Reply-To: <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
Message-ID: <K99btN4KRSKU56FEELtXkx5pHpuChrZaZC0M7dxTuCc=.9de3dad2-9609-4931-82e1-10dac13e57ea@github.com>

On Thu, 22 Jan 2026 23:51:42 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Refactor sun.security.provider.X509Factory cache access to avoid coarse-grained locking and reduce contention during certificate/CRL interning and parsing.
>> 
>> As per request in [the PR](https://github.com/openjdk/jdk/pull/22616#issuecomment-2524971845), re-visit "the initialisation and locking in this area, e.g. addToCache is a static synchronized method so very coarse locking."
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345954: Addressing review comments

src/java.base/share/classes/sun/security/provider/X509Factory.java line 118:

> 116:         X509CertImpl newCert = new X509CertImpl(encoding);
> 117:         byte[] enc = newCert.getEncodedInternal();
> 118:         return addIfNotPresent(certCache, enc, newCert);

Same: Why we call `addIfNotPresent` if we already checked above that it's not present?

src/java.base/share/classes/sun/security/provider/X509Factory.java line 234:

> 232:      */
> 233:     private static <V> V getFromCache(Cache<Object, V> cache, byte[] encoding) {
> 234:         synchronized (cache) {

This `synchronized` is redundant. This cache's `get` method is already synchronized.

src/java.base/share/classes/sun/security/provider/X509Factory.java line 242:

> 240:      * Add the X509CertImpl or X509CRLImpl to the cache.
> 241:      */
> 242:     private static <V> V addIfNotPresent(Cache<Object, V> cache, byte[] encoding, V value) {

Why do we need this method? How is it different from simply calling `put` if both current cache value and possibly-present-in-the-cache value are identical?

src/java.base/share/classes/sun/security/provider/X509Factory.java line 413:

> 411:                 // Build outside lock
> 412:                 X509CRLImpl crl = new X509CRLImpl(encoding);
> 413:                 byte[] enc = crl.getEncodedInternal();

How `enc` is different from  `encoding`? Isn't they the same?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2743262746
PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2743236443
PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2743243270
PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2743253752

From abarashev at openjdk.org  Thu Jan 29 19:59:20 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 19:59:20 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v2]
In-Reply-To: <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
Message-ID: <xcu-9Y6uPYdeUDofnyGCM90dSCmrMQ0RQR4scLgdcjk=.83a91ee8-73c6-4714-bd7a-ebf68e94faac@github.com>

On Thu, 22 Jan 2026 23:51:42 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Refactor sun.security.provider.X509Factory cache access to avoid coarse-grained locking and reduce contention during certificate/CRL interning and parsing.
>> 
>> As per request in [the PR](https://github.com/openjdk/jdk/pull/22616#issuecomment-2524971845), re-visit "the initialisation and locking in this area, e.g. addToCache is a static synchronized method so very coarse locking."
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345954: Addressing review comments

src/java.base/share/classes/sun/security/provider/X509Factory.java line 414:

> 412:                 X509CRLImpl crl = new X509CRLImpl(encoding);
> 413:                 byte[] enc = crl.getEncodedInternal();
> 414:                 return addIfNotPresent(crlCache, enc, crl);

Why we call `addIfNotPresent` if we already checked above that it's not present?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2743279133

From weijun at openjdk.org  Thu Jan 29 20:48:08 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Jan 2026 20:48:08 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v12]
In-Reply-To: <ykULcDTapaUBh37b7L-RXnyLA_ibaLRpVzXANbjqoT8=.b8e8f84a-0090-46fb-a3c9-5092c7aa489d@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <c9pcA-G-P_63a9ICfLwNe3iodcQiFJNX40K0MtsIZCI=.ce04424e-7233-4dd7-af2e-0a4f1e230f59@github.com>
 <ykULcDTapaUBh37b7L-RXnyLA_ibaLRpVzXANbjqoT8=.b8e8f84a-0090-46fb-a3c9-5092c7aa489d@github.com>
Message-ID: <xgWZ8-nL4h8LoiEsaOMCf2OEx2c7SLuPwOcwQawm0m4=.7313b5be-14b5-4edd-a58e-99011fd84215@github.com>

On Thu, 29 Jan 2026 18:56:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   grammar; no more 8347941
>
> src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java line 68:
> 
>> 66: ///
>> 67: /// A `NamedPKCS8Key`, when created, must include `expanded` if required, its
>> 68: /// `privKeyMaterial` must have already been validated for internal consistency.
> 
> I don't understand this sentence - maybe should be two sentences?

I can break it into 2 sentences. Basically, it means after this key has been created, the `expanded` and `privKeyMaterial` fields have already been checked for consistency so users don't need to check anymore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2743466739

From weijun at openjdk.org  Thu Jan 29 20:57:28 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Jan 2026 20:57:28 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v12]
In-Reply-To: <ykULcDTapaUBh37b7L-RXnyLA_ibaLRpVzXANbjqoT8=.b8e8f84a-0090-46fb-a3c9-5092c7aa489d@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <c9pcA-G-P_63a9ICfLwNe3iodcQiFJNX40K0MtsIZCI=.ce04424e-7233-4dd7-af2e-0a4f1e230f59@github.com>
 <ykULcDTapaUBh37b7L-RXnyLA_ibaLRpVzXANbjqoT8=.b8e8f84a-0090-46fb-a3c9-5092c7aa489d@github.com>
Message-ID: <RnoaU3j4pJft59bVvxVwo35SUCNiH_p85G7F8xn2wH0=.58604ebd-6604-48b4-83d9-7a6e0449904d@github.com>

On Thu, 29 Jan 2026 19:49:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   grammar; no more 8347941
>
> test/jdk/sun/security/provider/pqc/PrivateKeyEncodings.java line 1:
> 
>> 1: /*
> 
> Is this test skipped if it cannot download the drafts?

Yes. The `RepositoryFileReader` class describes alternative ways to read from a local or remote repo.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2743513683

From weijun at openjdk.org  Thu Jan 29 21:14:05 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Jan 2026 21:14:05 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v12]
In-Reply-To: <xgWZ8-nL4h8LoiEsaOMCf2OEx2c7SLuPwOcwQawm0m4=.7313b5be-14b5-4edd-a58e-99011fd84215@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <c9pcA-G-P_63a9ICfLwNe3iodcQiFJNX40K0MtsIZCI=.ce04424e-7233-4dd7-af2e-0a4f1e230f59@github.com>
 <ykULcDTapaUBh37b7L-RXnyLA_ibaLRpVzXANbjqoT8=.b8e8f84a-0090-46fb-a3c9-5092c7aa489d@github.com>
 <xgWZ8-nL4h8LoiEsaOMCf2OEx2c7SLuPwOcwQawm0m4=.7313b5be-14b5-4edd-a58e-99011fd84215@github.com>
Message-ID: <dgab3_kQ0YzvFfCyTfbV8AaAVWCfmXjWNF8m48FvYtQ=.7499bb91-ebf0-4534-a2ce-4bab88e651af@github.com>

On Thu, 29 Jan 2026 20:45:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java line 68:
>> 
>>> 66: ///
>>> 67: /// A `NamedPKCS8Key`, when created, must include `expanded` if required, its
>>> 68: /// `privKeyMaterial` must have already been validated for internal consistency.
>> 
>> I don't understand this sentence - maybe should be two sentences?
>
> I can break it into 2 sentences. Basically, it means after this key has been created, the `expanded` and `privKeyMaterial` fields have already been checked for consistency so users don't need to check anymore.

How about this?

/// If the `expanded` field is required by the algorithm, it is either
/// [calculated from the PKCS #8 encoding][#NamedPKCS8Key(String, byte[], Expander)],
/// or [provided directly][#NamedPKCS8Key(String, String, byte[], byte[])].
/// In the latter case, the caller must ensure the consistency of the `encoded`
/// and `expanded` arguments. For example, seed and expanded key should match.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2743564211

From weijun at openjdk.org  Thu Jan 29 21:38:49 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Jan 2026 21:38:49 GMT
Subject: RFR: 8368692: Restrict Password::readPassword from reading from
 System.in
Message-ID: <Vg4j8_TewPvuilBi9UvIsYOaZND5GDfHm7szbGeUFo4=.a8f21c3e-2dcf-4bea-869a-bca39f7a1837@github.com>

A new security/system property added to determine whether Java can read password from `System.in` if a console is not available.

-------------

Commit messages:
 - the change

Changes: https://git.openjdk.org/jdk/pull/29490/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29490&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368692
  Stats: 100 lines in 3 files changed: 100 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29490/head:pull/29490

PR: https://git.openjdk.org/jdk/pull/29490

From weijun at openjdk.org  Thu Jan 29 21:38:50 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Jan 2026 21:38:50 GMT
Subject: RFR: 8368692: Restrict Password::readPassword from reading from
 System.in
In-Reply-To: <Vg4j8_TewPvuilBi9UvIsYOaZND5GDfHm7szbGeUFo4=.a8f21c3e-2dcf-4bea-869a-bca39f7a1837@github.com>
References: <Vg4j8_TewPvuilBi9UvIsYOaZND5GDfHm7szbGeUFo4=.a8f21c3e-2dcf-4bea-869a-bca39f7a1837@github.com>
Message-ID: <zYN09AZ_5lWLybrD5t57Ea4RSv8NJ_vEqjyZ28-Aj2w=.40d85749-af6d-4fba-a91a-d576ec97782e@github.com>

On Thu, 29 Jan 2026 16:08:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> A new security/system property added to determine whether Java can read password from `System.in` if a console is not available.

@naotoj @stuart-marks This is the first step to migrate away from reading password from `System.in`. Please take a look. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29490#issuecomment-3818664786

From naoto at openjdk.org  Thu Jan 29 21:38:53 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jan 2026 21:38:53 GMT
Subject: RFR: 8368692: Restrict Password::readPassword from reading from
 System.in
In-Reply-To: <Vg4j8_TewPvuilBi9UvIsYOaZND5GDfHm7szbGeUFo4=.a8f21c3e-2dcf-4bea-869a-bca39f7a1837@github.com>
References: <Vg4j8_TewPvuilBi9UvIsYOaZND5GDfHm7szbGeUFo4=.a8f21c3e-2dcf-4bea-869a-bca39f7a1837@github.com>
Message-ID: <1X8oAg5q_PQVtXn3JhpzBqaIe-WrzAGozDmrXnsRfmY=.a175a0bb-6762-459a-bc20-303d60eac092@github.com>

On Thu, 29 Jan 2026 16:08:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> A new security/system property added to determine whether Java can read password from `System.in` if a console is not available.

src/java.base/share/classes/sun/security/util/Password.java line 75:

> 73:                 } else if (in == System.in && !ALLOW_STDIN) {
> 74:                     throw new UnsupportedOperationException("Console not available." +
> 75:                             " Reading passwords from System.in is disallowed.");

Although I understand the meaning of this error, it might be a bit cryptic to the user. Using the term "password input from non-interactive terminal" or something along the lines might be easier.

Anyway, this "else if" clause can be merged with the following "else if", as "in == System.in" is repeated.

src/java.base/share/conf/security/java.security line 1716:

> 1714: # This security property determines whether passwords can be read from the
> 1715: # standard input stream when a console is not available. The value can be
> 1716: # "true" or "false". The default value is "true". This default may change in

Maybe better to mention the case where the property is set to neither `true` nor `false`

src/java.base/share/conf/security/java.security line 1729:

> 1727: # environment variable or a file.
> 1728: #
> 1729: #jdk.security.password.allowSystemIn = true

Should this be uncommented? Otherwise the default value is `null`

test/jdk/sun/security/tools/keytool/AllowSystemIn.java line 29:

> 27:  * @summary Restrict Password::readPassword from reading from System.in
> 28:  * @library /test/lib
> 29:  * @run main AllowSystemIn succeed

Adding tests to check the system property value (should either be `true` or `false`) would be helpful, as well as setting it to a bogus one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29490#discussion_r2743434622
PR Review Comment: https://git.openjdk.org/jdk/pull/29490#discussion_r2743466889
PR Review Comment: https://git.openjdk.org/jdk/pull/29490#discussion_r2743477998
PR Review Comment: https://git.openjdk.org/jdk/pull/29490#discussion_r2743501379

From weijun at openjdk.org  Thu Jan 29 21:38:54 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Jan 2026 21:38:54 GMT
Subject: RFR: 8368692: Restrict Password::readPassword from reading from
 System.in
In-Reply-To: <1X8oAg5q_PQVtXn3JhpzBqaIe-WrzAGozDmrXnsRfmY=.a175a0bb-6762-459a-bc20-303d60eac092@github.com>
References: <Vg4j8_TewPvuilBi9UvIsYOaZND5GDfHm7szbGeUFo4=.a8f21c3e-2dcf-4bea-869a-bca39f7a1837@github.com>
 <1X8oAg5q_PQVtXn3JhpzBqaIe-WrzAGozDmrXnsRfmY=.a175a0bb-6762-459a-bc20-303d60eac092@github.com>
Message-ID: <-xjObyh-KIpbTCiYar4abTOetFuXM8ZtAQRvjTAWChQ=.d5738780-897e-4435-a514-6019f92b86ea@github.com>

On Thu, 29 Jan 2026 20:38:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A new security/system property added to determine whether Java can read password from `System.in` if a console is not available.
>
> src/java.base/share/classes/sun/security/util/Password.java line 75:
> 
>> 73:                 } else if (in == System.in && !ALLOW_STDIN) {
>> 74:                     throw new UnsupportedOperationException("Console not available." +
>> 75:                             " Reading passwords from System.in is disallowed.");
> 
> Although I understand the meaning of this error, it might be a bit cryptic to the user. Using the term "password input from non-interactive terminal" or something along the lines might be easier.
> 
> Anyway, this "else if" clause can be merged with the following "else if", as "in == System.in" is repeated.

Can we just say "from standard input"? I'm not sure "non-interactive terminal" is precise. And yes, I can put another level of `if` there.

> src/java.base/share/conf/security/java.security line 1729:
> 
>> 1727: # environment variable or a file.
>> 1728: #
>> 1729: #jdk.security.password.allowSystemIn = true
> 
> Should this be uncommented? Otherwise the default value is `null`

This is our usual pattern in `java.security`. By commenting out the line, the property read is null but internally treated as "true".

> test/jdk/sun/security/tools/keytool/AllowSystemIn.java line 29:
> 
>> 27:  * @summary Restrict Password::readPassword from reading from System.in
>> 28:  * @library /test/lib
>> 29:  * @run main AllowSystemIn succeed
> 
> Adding tests to check the system property value (should either be `true` or `false`) would be helpful, as well as setting it to a bogus one.

I can add a bogus value but in a lot of cases the behavior is undefined. It could fail early or at called time. Anyway, this is an implementation detail and I can always adjust the test later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29490#discussion_r2743645058
PR Review Comment: https://git.openjdk.org/jdk/pull/29490#discussion_r2743649789
PR Review Comment: https://git.openjdk.org/jdk/pull/29490#discussion_r2743654112

From weijun at openjdk.org  Thu Jan 29 21:58:53 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Jan 2026 21:58:53 GMT
Subject: RFR: 8368692: Restrict Password::readPassword from reading from
 System.in [v2]
In-Reply-To: <Vg4j8_TewPvuilBi9UvIsYOaZND5GDfHm7szbGeUFo4=.a8f21c3e-2dcf-4bea-869a-bca39f7a1837@github.com>
References: <Vg4j8_TewPvuilBi9UvIsYOaZND5GDfHm7szbGeUFo4=.a8f21c3e-2dcf-4bea-869a-bca39f7a1837@github.com>
Message-ID: <DYZN9wuC_LrRpDWWbn7tz0LhHNxYidYGmAtE-JvVUvY=.e68262bd-9e5d-4c24-8f78-22c52d85ff0b@github.com>

> A new security/system property added to determine whether Java can read password from `System.in` if a console is not available.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  adressing Naoto's comments; check invalid property value

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29490/files
  - new: https://git.openjdk.org/jdk/pull/29490/files/8467453c..f01166a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29490&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29490&range=00-01

  Stats: 43 lines in 3 files changed: 17 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/29490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29490/head:pull/29490

PR: https://git.openjdk.org/jdk/pull/29490

From naoto at openjdk.org  Thu Jan 29 22:18:40 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jan 2026 22:18:40 GMT
Subject: RFR: 8368692: Restrict Password::readPassword from reading from
 System.in [v2]
In-Reply-To: <-xjObyh-KIpbTCiYar4abTOetFuXM8ZtAQRvjTAWChQ=.d5738780-897e-4435-a514-6019f92b86ea@github.com>
References: <Vg4j8_TewPvuilBi9UvIsYOaZND5GDfHm7szbGeUFo4=.a8f21c3e-2dcf-4bea-869a-bca39f7a1837@github.com>
 <1X8oAg5q_PQVtXn3JhpzBqaIe-WrzAGozDmrXnsRfmY=.a175a0bb-6762-459a-bc20-303d60eac092@github.com>
 <-xjObyh-KIpbTCiYar4abTOetFuXM8ZtAQRvjTAWChQ=.d5738780-897e-4435-a514-6019f92b86ea@github.com>
Message-ID: <0u0ivwya1zNRp94OA3HOhplPBCy_GmfoOmU6BmNfQww=.ee4c5e07-2093-4984-8fd5-56277ee5d28c@github.com>

On Thu, 29 Jan 2026 21:33:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 1729:
>> 
>>> 1727: # environment variable or a file.
>>> 1728: #
>>> 1729: #jdk.security.password.allowSystemIn = true
>> 
>> Should this be uncommented? Otherwise the default value is `null`
>
> This is our usual pattern in `java.security`. By commenting out the line, the property read is null but internally treated as "true".

I was under the impression that 

System.getProperty("jdk.security.password.allowSystemIn")

would return `true`, as it reads "The default *value* is "true"".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29490#discussion_r2743773545

From weijun at openjdk.org  Thu Jan 29 22:30:54 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Jan 2026 22:30:54 GMT
Subject: RFR: 8368692: Restrict Password::readPassword from reading from
 System.in [v2]
In-Reply-To: <0u0ivwya1zNRp94OA3HOhplPBCy_GmfoOmU6BmNfQww=.ee4c5e07-2093-4984-8fd5-56277ee5d28c@github.com>
References: <Vg4j8_TewPvuilBi9UvIsYOaZND5GDfHm7szbGeUFo4=.a8f21c3e-2dcf-4bea-869a-bca39f7a1837@github.com>
 <1X8oAg5q_PQVtXn3JhpzBqaIe-WrzAGozDmrXnsRfmY=.a175a0bb-6762-459a-bc20-303d60eac092@github.com>
 <-xjObyh-KIpbTCiYar4abTOetFuXM8ZtAQRvjTAWChQ=.d5738780-897e-4435-a514-6019f92b86ea@github.com>
 <0u0ivwya1zNRp94OA3HOhplPBCy_GmfoOmU6BmNfQww=.ee4c5e07-2093-4984-8fd5-56277ee5d28c@github.com>
Message-ID: <OTPAO0eChDk3rPy7hn7Fl4igqRHdVPRUPuJ6oLXKllY=.44f899c7-8168-48fb-a20f-f5cd091716e0@github.com>

On Thu, 29 Jan 2026 22:14:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is our usual pattern in `java.security`. By commenting out the line, the property read is null but internally treated as "true".
>
> I was under the impression that 
> 
> System.getProperty("jdk.security.password.allowSystemIn")
> 
> would return `true`, as it reads "The default *value* is "true"".

Yes, you can understand this way, but if you look at other properties in `java.security`, you can see many of them commented out but the spec above describes a default. So when we say "default", it's not about the exact value returned by `getProperty` but how we treat this property even if it's not set anywhere.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29490#discussion_r2743805594

From duke at openjdk.org  Thu Jan 29 22:48:23 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 29 Jan 2026 22:48:23 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v3]
In-Reply-To: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
Message-ID: <VYGK2WSNj4g-KTwnvmfFW9AqsP-dDGEYkLgkAj2uOZ4=.59ca932f-c7ce-4453-af56-4c6414d8740a@github.com>

> Refactor sun.security.provider.X509Factory cache access to avoid coarse-grained locking and reduce contention during certificate/CRL interning and parsing.
> 
> As per request in [the PR](https://github.com/openjdk/jdk/pull/22616#issuecomment-2524971845), re-visit "the initialisation and locking in this area, e.g. addToCache is a static synchronized method so very coarse locking."

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8345954: Removing synchronization on getfromcache

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29181/files
  - new: https://git.openjdk.org/jdk/pull/29181/files/bf2ccdab..8fd1f70d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29181&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29181&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29181.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29181/head:pull/29181

PR: https://git.openjdk.org/jdk/pull/29181

From duke at openjdk.org  Thu Jan 29 22:52:59 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 29 Jan 2026 22:52:59 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v2]
In-Reply-To: <raPzDbE3eI1UTvXK8K3mZ8Dy5IDsSGtAITPyQO91U9c=.93bc0474-a455-4584-a5d0-3e227044a3b5@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
 <raPzDbE3eI1UTvXK8K3mZ8Dy5IDsSGtAITPyQO91U9c=.93bc0474-a455-4584-a5d0-3e227044a3b5@github.com>
Message-ID: <w9gCv7DZJImy-xab9kDtBiD_fSer1WkMwIQjjoa1eAg=.15ea6562-0aec-4226-9c12-ef07eeb14232@github.com>

On Wed, 28 Jan 2026 20:16:35 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> I wonder why we need to do any synchronization in `X509Factory` at all when `sun.security.util.MemoryCache` being used is internally synchronized and its documentation states that it's `safe for concurrent use by multiple threads`:
> 
> https://github.com/openjdk/jdk/blob/7efa3168b706c1d061c4ee65574427ef1f50fc7b/src/java.base/share/classes/sun/security/util/Cache.java#L267
> 
> I think we need to look closer into this.

I think MemoryCache is synchronized for individual get/put/clear, but we still need to synchronize inside addIfNotPresent() because it?s a compound check-then-put and needs atomicity to preserve interning semantics.

> src/java.base/share/classes/sun/security/provider/X509Factory.java line 234:
> 
>> 232:      */
>> 233:     private static <V> V getFromCache(Cache<Object, V> cache, byte[] encoding) {
>> 234:         synchronized (cache) {
> 
> This `synchronized` is redundant. This cache's `get` method is already synchronized.

I had this because synchronizing in getFromCache() makes our locking policy explicit and keeps the access pattern consistent with addIfNotPresent(). But I am okay with removing it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29181#issuecomment-3820814229
PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2743863462

From duke at openjdk.org  Thu Jan 29 23:07:00 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 29 Jan 2026 23:07:00 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v2]
In-Reply-To: <K99btN4KRSKU56FEELtXkx5pHpuChrZaZC0M7dxTuCc=.9de3dad2-9609-4931-82e1-10dac13e57ea@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
 <K99btN4KRSKU56FEELtXkx5pHpuChrZaZC0M7dxTuCc=.9de3dad2-9609-4931-82e1-10dac13e57ea@github.com>
Message-ID: <BTLlEAt6imYyDqRUbdgwW5SBjj4MFa-h3VBeFSQjGz8=.ed7ad174-c71e-48c6-9a5f-208cfeca922c@github.com>

On Thu, 29 Jan 2026 19:47:56 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8345954: Addressing review comments
>
> src/java.base/share/classes/sun/security/provider/X509Factory.java line 242:
> 
>> 240:      * Add the X509CertImpl or X509CRLImpl to the cache.
>> 241:      */
>> 242:     private static <V> V addIfNotPresent(Cache<Object, V> cache, byte[] encoding, V value) {
> 
> Why do we need this method? How is it different from simply calling `put` if both current cache value and possibly-present-in-the-cache value are identical?

I think `put() `can overwrite an entry if two threads race. `addIfNotPresent()` makes the intent explicit: use the already-cached instance if present, otherwise add. That keeps interning correct and avoids unnecessary duplicate objects.

> src/java.base/share/classes/sun/security/provider/X509Factory.java line 413:
> 
>> 411:                 // Build outside lock
>> 412:                 X509CRLImpl crl = new X509CRLImpl(encoding);
>> 413:                 byte[] enc = crl.getEncodedInternal();
> 
> How `enc` is different from  `encoding`? Aren't they the same?

They might be same sometimes but they are not guaranteed to be. `enc` is the canonical encoding produced by the parsed object (`getEncodedInternal()`), which we use as the cache key to normalize equivalent inputs and avoid duplicate cache entries.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2743894042
PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2743895804

From duke at openjdk.org  Thu Jan 29 23:15:05 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 29 Jan 2026 23:15:05 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v2]
In-Reply-To: <K99btN4KRSKU56FEELtXkx5pHpuChrZaZC0M7dxTuCc=.9de3dad2-9609-4931-82e1-10dac13e57ea@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
 <K99btN4KRSKU56FEELtXkx5pHpuChrZaZC0M7dxTuCc=.9de3dad2-9609-4931-82e1-10dac13e57ea@github.com>
Message-ID: <ufqO4cRni-GsEtJmWoo4U3nagLsJkvRlfgHEZq20arM=.b883935e-71e2-4d24-abd8-a4abd11a6e6c@github.com>

On Thu, 29 Jan 2026 19:53:05 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8345954: Addressing review comments
>
> src/java.base/share/classes/sun/security/provider/X509Factory.java line 118:
> 
>> 116:         X509CertImpl newCert = new X509CertImpl(encoding);
>> 117:         byte[] enc = newCert.getEncodedInternal();
>> 118:         return addIfNotPresent(certCache, enc, newCert);
> 
> Same: Why we call `addIfNotPresent` if we already checked above that it's not present?

I think we still need `addIfNotPresent` because the earlier `getFromCache()` and the put are not atomic and can race with other threads. `addIfNotPresent` performs the check-then-put under one lock and returns the already-cached instance if another thread won the race. Also, the cache key for insertion is the canonical enc, which may differ from the raw encoding used for the initial lookup, so we might still need this.

> src/java.base/share/classes/sun/security/provider/X509Factory.java line 414:
> 
>> 412:                 X509CRLImpl crl = new X509CRLImpl(encoding);
>> 413:                 byte[] enc = crl.getEncodedInternal();
>> 414:                 return addIfNotPresent(crlCache, enc, crl);
> 
> Why we call `addIfNotPresent` if we already checked above that it's not present?

Same as above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2743912878
PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2743914237

From abarashev at openjdk.org  Fri Jan 30 00:47:09 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 30 Jan 2026 00:47:09 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v2]
In-Reply-To: <ufqO4cRni-GsEtJmWoo4U3nagLsJkvRlfgHEZq20arM=.b883935e-71e2-4d24-abd8-a4abd11a6e6c@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
 <K99btN4KRSKU56FEELtXkx5pHpuChrZaZC0M7dxTuCc=.9de3dad2-9609-4931-82e1-10dac13e57ea@github.com>
 <ufqO4cRni-GsEtJmWoo4U3nagLsJkvRlfgHEZq20arM=.b883935e-71e2-4d24-abd8-a4abd11a6e6c@github.com>
Message-ID: <GuCpk2VWiDfE5pE6x4X6pMwCU3q8AtG2JF_Ej_INAgE=.87f15db5-65b3-441a-93aa-4b47d7e356bc@github.com>

On Thu, 29 Jan 2026 23:12:22 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/X509Factory.java line 118:
>> 
>>> 116:         X509CertImpl newCert = new X509CertImpl(encoding);
>>> 117:         byte[] enc = newCert.getEncodedInternal();
>>> 118:         return addIfNotPresent(certCache, enc, newCert);
>> 
>> Same: Why we call `addIfNotPresent` if we already checked above that it's not present?
>
> I think we still need `addIfNotPresent` because the earlier `getFromCache()` and the put are not atomic and can race with other threads. `addIfNotPresent` performs the check-then-put under one lock and returns the already-cached instance if another thread won the race. Also, the cache key for insertion is the canonical enc, which may differ from the raw encoding used for the initial lookup, so we might still need this.

But we can simply call `addIfNotPresent` without `getFromCache`, right? I mean we don't need to perform 2 `get` operations in the row.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2744136098

From abarashev at openjdk.org  Fri Jan 30 01:13:34 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 30 Jan 2026 01:13:34 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v3]
In-Reply-To: <VYGK2WSNj4g-KTwnvmfFW9AqsP-dDGEYkLgkAj2uOZ4=.59ca932f-c7ce-4453-af56-4c6414d8740a@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <VYGK2WSNj4g-KTwnvmfFW9AqsP-dDGEYkLgkAj2uOZ4=.59ca932f-c7ce-4453-af56-4c6414d8740a@github.com>
Message-ID: <LkW4wRTElk5SQieXvHLJQw7-Fz8VeBZgrZQLi7POis0=.db674d8d-645b-4300-8f20-0fc19fa7c015@github.com>

On Thu, 29 Jan 2026 22:48:23 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Refactor sun.security.provider.X509Factory cache access to avoid coarse-grained locking and reduce contention during certificate/CRL interning and parsing.
>> 
>> As per request in [the PR](https://github.com/openjdk/jdk/pull/22616#issuecomment-2524971845), re-visit "the initialisation and locking in this area, e.g. addToCache is a static synchronized method so very coarse locking."
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345954: Removing synchronization on getfromcache

Not sure about this change: we used to synchronize static methods and now we synchronize static caches with pretty much the same coarse class-level locking. We should consider removing any synchronization from this class because we don't remove or modify any values from those caches, we only insert values. So even if there is a race condition then we'll just insert the same value twice. Would it be possible to insert 2 different values for the same key in this class? It doesn't seem so. FYI: those caches already synchronized internally for `get` and `put` operations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29181#issuecomment-3821231819

From abarashev at openjdk.org  Fri Jan 30 01:59:10 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 30 Jan 2026 01:59:10 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v14]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <7CXUTIVrF6uQSUav5jVkDnLQe5ZpzMSW1wJzAaVp5i4=.352169f7-883d-486a-9f13-a6b50fb5f898@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Increase cache size to be on the safe side

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/8b0261c1..6b23c05f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=12-13

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

PR: https://git.openjdk.org/jdk/pull/28682

From duke at openjdk.org  Fri Jan 30 05:49:13 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Fri, 30 Jan 2026 05:49:13 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v3]
In-Reply-To: <LkW4wRTElk5SQieXvHLJQw7-Fz8VeBZgrZQLi7POis0=.db674d8d-645b-4300-8f20-0fc19fa7c015@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <VYGK2WSNj4g-KTwnvmfFW9AqsP-dDGEYkLgkAj2uOZ4=.59ca932f-c7ce-4453-af56-4c6414d8740a@github.com>
 <LkW4wRTElk5SQieXvHLJQw7-Fz8VeBZgrZQLi7POis0=.db674d8d-645b-4300-8f20-0fc19fa7c015@github.com>
Message-ID: <ZOBVYvVKosLQXNEGOPtje1zu2Lubgpnl4LqnDKNAal0=.725b10e9-d100-4f0d-9bcf-df6311e4b346@github.com>

On Fri, 30 Jan 2026 01:10:41 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> So even if there is a race condition then we'll just insert the same value twice. Would it be possible to insert 2 different values for the same key in this class? It doesn't seem so.

Thanks for the detailed comment. You?re right that this won?t corrupt the cache and that the objects are semantically equivalent. The issue I see isn?t correctness of the cache, but interning/canonicalization semantics.

I think it could be possible for two values to be inserted for the same logical key: if two threads concurrently miss on `get()`, they can both construct separate `X509CertImpl/X509CRLImpl` instances and then both call `put()`. The cache remains valid, but different callers may observe different object instances for the same certificate/CRL. That breaks the intent of `intern()` as documented (returning a canonical cached instance) and can introduce avoidable object churn.

The addIfNotPresent() helper keeps the ?check-then-insert and return existing? behavior atomic at this layer, without relying on assumptions about the cache implementation. I would be happy to revisit if we agree interning semantics are not required here. Let me know.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29181#issuecomment-3821970071

From duke at openjdk.org  Fri Jan 30 05:56:15 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Fri, 30 Jan 2026 05:56:15 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v2]
In-Reply-To: <GuCpk2VWiDfE5pE6x4X6pMwCU3q8AtG2JF_Ej_INAgE=.87f15db5-65b3-441a-93aa-4b47d7e356bc@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <d0lfXG0GBpHtuuTLFLiNix2ymQrOS3APhPui-8Y3m88=.7297ac84-9514-4a82-bad4-138433c95b5b@github.com>
 <K99btN4KRSKU56FEELtXkx5pHpuChrZaZC0M7dxTuCc=.9de3dad2-9609-4931-82e1-10dac13e57ea@github.com>
 <ufqO4cRni-GsEtJmWoo4U3nagLsJkvRlfgHEZq20arM=.b883935e-71e2-4d24-abd8-a4abd11a6e6c@github.com>
 <GuCpk2VWiDfE5pE6x4X6pMwCU3q8AtG2JF_Ej_INAgE=.87f15db5-65b3-441a-93aa-4b47d7e356bc@github.com>
Message-ID: <06GWiAXJs75sEqTBJLw9WxWqkHN6IUPm82bz-nEHUeM=.44b474f2-9f26-4e6c-a375-ca6ccd125be7@github.com>

On Fri, 30 Jan 2026 00:44:15 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> I think we still need `addIfNotPresent` because the earlier `getFromCache()` and the put are not atomic and can race with other threads. `addIfNotPresent` performs the check-then-put under one lock and returns the already-cached instance if another thread won the race. Also, the cache key for insertion is the canonical enc, which may differ from the raw encoding used for the initial lookup, so we might still need this.
>
> But we can simply call `addIfNotPresent` without `getFromCache`, right? I mean we don't need to perform 2 `get` operations in the row.

Good point. Yes, we could call `addIfNotPresent()` directly and drop the initial `getFromCache()`.
I kept the fast-path `getFromCache()` so cache hits don?t have to enter the synchronized block in `addIfNotPresent()`; the ?two gets? we worry about here only happens on misses.
Also, we still need addIfNotPresent() after the first check because the miss path is racy and we want the ?check-then-insert and return existing? behavior to be atomic, and to converge on the canonical enc key.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29181#discussion_r2744751740

From chagedorn at openjdk.org  Fri Jan 30 10:47:17 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 30 Jan 2026 10:47:17 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v7]
In-Reply-To: <y1_tSg2kFucxLE1zIBdVlAcKcIsqKPTgNoSBanfJNzI=.e1f3b33d-91ba-4af3-b5b4-a77f948520f7@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <y1_tSg2kFucxLE1zIBdVlAcKcIsqKPTgNoSBanfJNzI=.e1f3b33d-91ba-4af3-b5b4-a77f948520f7@github.com>
Message-ID: <K0y8_ePOPY1HjkjWcM1Fg8t-yhljHI_h1Qt25M3HOQ0=.9d7f61ab-5011-4c63-8ac7-593b6bbbb0af@github.com>

On Thu, 29 Jan 2026 12:42:44 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8374582: add flagless to test

src/hotspot/share/opto/library_call.cpp line 894:

> 892: 
> 893: inline Node* LibraryCallKit::generate_negative_guard(Node* index, RegionNode* region,
> 894:                                                      Node* *pos_index, bool is_opaque) {

Suggestion:

                                                     Node** pos_index, bool is_opaque) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2745638291

From chagedorn at openjdk.org  Fri Jan 30 10:47:19 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 30 Jan 2026 10:47:19 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v3]
In-Reply-To: <v37o-d1AqannQfWbl4etGP5ieIpAg66YFzyECYATgBY=.70b8095e-ae47-4ad1-82ff-95ef36d0a98c@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <VrYWdFIyIZfOKeKx9hZBFriAo34PIGOqPOd6FfHEKZs=.576a9a1e-feed-4fad-975b-69c6294cc145@github.com>
 <UkcVqNuDaxfS276NoZJ6PNCpvWD-w0OfLcXEWXZH1zU=.3f3c2fcb-cbeb-4b7b-afdc-ec626eacffbb@github.com>
 <v37o-d1AqannQfWbl4etGP5ieIpAg66YFzyECYATgBY=.70b8095e-ae47-4ad1-82ff-95ef36d0a98c@github.com>
Message-ID: <qAgw17uyYg8a3YP6IrSEzgQc1zN8rxjThQGGFYlWWlI=.9c983e56-8166-4128-b9c9-6f8ed900ce56@github.com>

On Wed, 28 Jan 2026 16:02:56 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> src/hotspot/share/opto/opaquenode.hpp line 150:
>> 
>>> 148:   bool _positive;
>>> 149:  public:
>>> 150:   OpaqueCheckNode(Compile* C, Node* tst, bool positive) : Node(nullptr, tst), _positive(positive) {
>> 
>> `tst` is probably almost always a `BoolNode`. I'm wondering if it could also be a constant because we already folded the `BoolNode`? But then it's probably also useless to create the opaque node in the first place.
>
> Hmmm... I find it hard to totally exclude a constant (e.g. if its inputs are constant...?). In that case we could skip all the opaque business (I guess in the few places where new `OpaqueConstantBool` nodes are created). On the other hand the opaque node should only really delay the folding... ?

I think folding is fine since we implement `Value()` to take the input's `Value()`. My understanding is that we insert an additional check that is actually not needed because we already checked it in Java code. So, it should be true at that point but C2 does not know that. We still insert the check in order to make sure to also fold control away if data is dying. Once we know that data will not die anymore, we can remove the useless check again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2745545348

From abarashev at openjdk.org  Fri Jan 30 13:43:55 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 30 Jan 2026 13:43:55 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v3]
In-Reply-To: <ZOBVYvVKosLQXNEGOPtje1zu2Lubgpnl4LqnDKNAal0=.725b10e9-d100-4f0d-9bcf-df6311e4b346@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <VYGK2WSNj4g-KTwnvmfFW9AqsP-dDGEYkLgkAj2uOZ4=.59ca932f-c7ce-4453-af56-4c6414d8740a@github.com>
 <LkW4wRTElk5SQieXvHLJQw7-Fz8VeBZgrZQLi7POis0=.db674d8d-645b-4300-8f20-0fc19fa7c015@github.com>
 <ZOBVYvVKosLQXNEGOPtje1zu2Lubgpnl4LqnDKNAal0=.725b10e9-d100-4f0d-9bcf-df6311e4b346@github.com>
Message-ID: <7BCEiZiKXu53Y0W0zYp_RZcOoiomJv6-jhb7t1j6Dw8=.5a699988-5811-4f65-b325-8695aa6a4e7e@github.com>

On Fri, 30 Jan 2026 05:46:32 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> > So even if there is a race condition then we'll just insert the same value twice. Would it be possible to insert 2 different values for the same key in this class? It doesn't seem so.
> 
> Thanks for the detailed comment. You?re right that this won?t corrupt the cache and that the objects are semantically equivalent. The issue I see isn?t correctness of the cache, but interning/canonicalization semantics.
> 
> I think it could be possible for two values to be inserted for the same logical key: if two threads concurrently miss on `get()`, they can both construct separate `X509CertImpl/X509CRLImpl` instances and then both call `put()`. The cache remains valid, but different callers may observe different object instances for the same certificate/CRL. That breaks the intent of `intern()` as documented (returning a canonical cached instance) and can introduce avoidable object churn.
> 
> The addIfNotPresent() helper keeps the ?check-then-insert and return existing? behavior atomic at this layer, without relying on assumptions about the cache implementation. I would be happy to revisit if we agree interning semantics are not required here. Let me know.

I see your point, but since this is `SoftMemoryCache` there is no guarantee it will always return the same exact object for the same key anyhow. The callers of `intern` method can't rely on that. SoftReferences are automatically cleared by the garbage collector in response to memory demand, then the new object will be re-inserted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29181#issuecomment-3823820517

From weijun at openjdk.org  Fri Jan 30 13:53:56 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 30 Jan 2026 13:53:56 GMT
Subject: RFR: 8368692: Restrict Password::readPassword from reading from
 System.in [v3]
In-Reply-To: <Vg4j8_TewPvuilBi9UvIsYOaZND5GDfHm7szbGeUFo4=.a8f21c3e-2dcf-4bea-869a-bca39f7a1837@github.com>
References: <Vg4j8_TewPvuilBi9UvIsYOaZND5GDfHm7szbGeUFo4=.a8f21c3e-2dcf-4bea-869a-bca39f7a1837@github.com>
Message-ID: <Twdg_2Vq3_AlC99F5gPhvTtCN8LfxXFWy6cxCQbaZbM=.5391ca47-b749-4912-b70b-536731ea71a5@github.com>

> A new security/system property added to determine whether Java can read password from `System.in` if a console is not available.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  more descriptive exception message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29490/files
  - new: https://git.openjdk.org/jdk/pull/29490/files/f01166a8..9e8dc773

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29490&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29490&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29490/head:pull/29490

PR: https://git.openjdk.org/jdk/pull/29490

From dfenacci at openjdk.org  Fri Jan 30 13:56:01 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 30 Jan 2026 13:56:01 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <ruhbSt_5vfLBYmPoZN6_GkdXbS3oxDKsvtvR1hDInZk=.69425870-3c7f-4ec0-a06f-a43e5cae4900@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8374582: fix star layout
  
  Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/083d5698..c5390e4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164

PR: https://git.openjdk.org/jdk/pull/29164

From weijun at openjdk.org  Fri Jan 30 14:09:10 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 30 Jan 2026 14:09:10 GMT
Subject: RFR: 8374001: sun/security/ skip without Exceptions [v3]
In-Reply-To: <3NQoUAbD1DGb8yG0smG9vlsbY2DkJhWwhOO9YwT_xK4=.e9c6165e-384b-4ab7-ab66-dde17fe206aa@github.com>
References: <P1xMe3z5wtoG1l84Iu2IJNH-B2sUVchQ46SFYiOThPs=.18e8a2fe-dc84-45a7-98b0-f4568ca949e9@github.com>
 <3NQoUAbD1DGb8yG0smG9vlsbY2DkJhWwhOO9YwT_xK4=.e9c6165e-384b-4ab7-ab66-dde17fe206aa@github.com>
Message-ID: <-TciB3fuBE0VEJfKyKeqvAnR6dTXbCONIZ1k_NGqaBY=.893c425c-4bd4-40e3-a905-5458b549e02e@github.com>

On Mon, 26 Jan 2026 12:07:55 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Pr cleaning up the tests left after the previous PRs.
>> 
>> * test/jdk/sun/security/util/Resources/Usages.java
>> * test/jdk/sun/security/ssl/CertPathRestrictions/TLSRestrictions.java
>> * test/jdk/sun/security/krb5/config/ConfPlusProp.java
>> * test/jdk/sun/security/krb5/auto/ReplayCacheTestProc.java
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated message

test/jdk/sun/security/krb5/config/ConfPlusProp.java line 44:

> 42:                 System.getenv("LOGONSERVER") != null) {
> 43:             throw new SkippedException(
> 44:                     "Test cannot run in a domain.");

This is not a problem at all. No `SkippedException` is needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28898#discussion_r2746483819

From duke at openjdk.org  Fri Jan 30 15:27:53 2026
From: duke at openjdk.org (Brett Okken)
Date: Fri, 30 Jan 2026 15:27:53 GMT
Subject: RFR: 8376031: HttpsURLConnection.getServerCertificates() throws
 "java.lang.IllegalStateException: connection not yet open" for the HEAD method
In-Reply-To: <dR0upqPEpJY5DoqLkFAgvOrQY5K8by_G-pG-PdG0Uvo=.a9036e97-4409-4839-81bb-c5d6f45a5b9f@github.com>
References: <dR0upqPEpJY5DoqLkFAgvOrQY5K8by_G-pG-PdG0Uvo=.a9036e97-4409-4839-81bb-c5d6f45a5b9f@github.com>
Message-ID: <7Hd_5rWqKTqFPX9qF5e4oLRydMelUQsJ3s8CQ6AJczQ=.b068bbe6-820f-4ff4-932f-83686bf12870@github.com>

On Thu, 29 Jan 2026 15:32:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The issue here is that `HttpURLConnection` is automatically disconnected (`HttpClient` is set to `null`, `connected` is set to `false`) when a response with no response body bytes is received. This happens before a fake empty body input stream is returned to the user. That behaviour also occurs with any method for which `content-length: 0` is returned (GET, POST, custom, anything), and with any status code (204, 304) for which there is no body.
> 
> In this case, the proposed fix is to store the `SSLSession` in the `AbstractDelegateHttpsURLConnection` subclass until such a time where `disconnect()` is explicitely closed. Information pertaining to SSL, such as server certificates, can be extracted from the saved `SSLSession`.

I am not an official reviewer, but changes look good to me.
The "snapshot" build passes the reproducer posted with the issue.

-------------

Marked as reviewed by bokken at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/29489#pullrequestreview-3728939814

From dfuchs at openjdk.org  Fri Jan 30 15:34:03 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Jan 2026 15:34:03 GMT
Subject: RFR: 8376031: HttpsURLConnection.getServerCertificates() throws
 "java.lang.IllegalStateException: connection not yet open" for the HEAD method
In-Reply-To: <dR0upqPEpJY5DoqLkFAgvOrQY5K8by_G-pG-PdG0Uvo=.a9036e97-4409-4839-81bb-c5d6f45a5b9f@github.com>
References: <dR0upqPEpJY5DoqLkFAgvOrQY5K8by_G-pG-PdG0Uvo=.a9036e97-4409-4839-81bb-c5d6f45a5b9f@github.com>
Message-ID: <ueyhHaAlpKszhuQcjqed8sfgfKF6geHHPn23E5MecHc=.249585ac-e32d-4e6b-b883-c9aac5a021fb@github.com>

On Thu, 29 Jan 2026 15:32:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The issue here is that `HttpURLConnection` is automatically disconnected (`HttpClient` is set to `null`, `connected` is set to `false`) when a response with no response body bytes is received. This happens before a fake empty body input stream is returned to the user. That behaviour also occurs with any method for which `content-length: 0` is returned (GET, POST, custom, anything), and with any status code (204, 304) for which there is no body.
> 
> In this case, the proposed fix is to store the `SSLSession` in the `AbstractDelegateHttpsURLConnection` subclass until such a time where `disconnect()` is explicitely closed. Information pertaining to SSL, such as server certificates, can be extracted from the saved `SSLSession`.

Thank you Brett! Much appreciated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29489#issuecomment-3824329058

From weijun at openjdk.org  Fri Jan 30 15:55:17 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 30 Jan 2026 15:55:17 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v13]
In-Reply-To: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
Message-ID: <PHAwqVuUX1sLHtjFTQzYd7Yw3HbdztSgfY9OTabusL8=.9972b0e1-39f6-4383-9318-ab14dc1bf051@github.com>

> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest [draft-ietf-lamps-kyber-certificates-11](https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-11) and [RFC 9881](https://datatracker.ietf.org/doc/rfc9881/). New security/system properties are introduced to determine which CHOICE a private key is encoded when a new key pair is generated or when `KeyFactory::translateKey` is called.
> 
> By default, the choice is "seed".
> 
> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS8 key, the expanded format is calculated from the input if it's seed only.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  address Sean's comments; more test cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24969/files
  - new: https://git.openjdk.org/jdk/pull/24969/files/91894fc6..205eb344

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24969&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24969&range=11-12

  Stats: 67 lines in 4 files changed: 51 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24969.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24969/head:pull/24969

PR: https://git.openjdk.org/jdk/pull/24969

From myankelevich at openjdk.org  Fri Jan 30 16:32:08 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 30 Jan 2026 16:32:08 GMT
Subject: RFR: 8374001: sun/security/ skip without Exceptions [v3]
In-Reply-To: <-TciB3fuBE0VEJfKyKeqvAnR6dTXbCONIZ1k_NGqaBY=.893c425c-4bd4-40e3-a905-5458b549e02e@github.com>
References: <P1xMe3z5wtoG1l84Iu2IJNH-B2sUVchQ46SFYiOThPs=.18e8a2fe-dc84-45a7-98b0-f4568ca949e9@github.com>
 <3NQoUAbD1DGb8yG0smG9vlsbY2DkJhWwhOO9YwT_xK4=.e9c6165e-384b-4ab7-ab66-dde17fe206aa@github.com>
 <-TciB3fuBE0VEJfKyKeqvAnR6dTXbCONIZ1k_NGqaBY=.893c425c-4bd4-40e3-a905-5458b549e02e@github.com>
Message-ID: <dadc7kT2zV0CbODKcpao_UUMCuJSHH-vn9refEfASGo=.fc7e76d8-4447-43b1-8944-a1c7065717f7@github.com>

On Fri, 30 Jan 2026 14:06:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated message
>
> test/jdk/sun/security/krb5/config/ConfPlusProp.java line 44:
> 
>> 42:                 System.getenv("LOGONSERVER") != null) {
>> 43:             throw new SkippedException(
>> 44:                     "Test cannot run in a domain.");
> 
> This is not a problem at all. No `SkippedException` is needed.

This still skips the whole test so I believe this should throw a SkippedException. Alternatively I thought to require os not being Windows. What would you prefer to do?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28898#discussion_r2747057188

From xuelei at openjdk.org  Fri Jan 30 17:37:08 2026
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 30 Jan 2026 17:37:08 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v13]
In-Reply-To: <KqBPy_GpoXAcWuMOvtAomVx-Y2rZV7NVceSY7gvR6-0=.371b2bcf-1f61-4074-9982-c534b3a2c108@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>
 <Ag1zV75rDv2o_pyZR_B4LFplmVfibBbrSXNCpMZmuTk=.1d45afbd-a37b-4114-8b02-f6779452c2a8@github.com>
 <KqBPy_GpoXAcWuMOvtAomVx-Y2rZV7NVceSY7gvR6-0=.371b2bcf-1f61-4074-9982-c534b3a2c108@github.com>
Message-ID: <uDEn8dr5KZLPtyh3Sl0y6d8ASDfMQnGZwb4Gy-OSrvQ=.5eac767c-e8a7-4c6f-b151-77acb469b631@github.com>

On Thu, 29 Jan 2026 18:15:07 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/CompressedCertificate.java line 148:
>> 
>>> 146:         // the deflated certificate data in a memory cache statically and avoid
>>> 147:         // compressing local certificates repeatedly for every handshake.
>>> 148:         private static final Cache<CompCertCacheKey, byte[]> CACHE =
>> 
>> I was just wondering about the multiple tenant systems, where one JVM may be used by multiple users with different key and certificates.  The system may run many weeks, and the tenants sign on and off, new and old tenants come in and out.  Will this CACHE keep the record for each key-cert for each tenant?  Could it be a potential problem?  Does it sound like a direction to cache the compressed certificate in where the certificate come from, for example key manager instance or SSLContext instance, without using static field?
>
> Yes, I'm actually currently thinking whether to attach this cache to SSLContext instance or not. Not sure about it. This cache implementation has LRU mechanism, so it will simply keep the last 12 compressed certs in memory which should be fine for most scenarios. It's also an easier to maintain code where we have all the pieces in a single file. Currently we have only session caches attached to SSLContext and quite a few static caches like this one in JSSE code.

I had a quick search of the existing cache.  There are some global cache for default security parameters and configuration.  For example, default trust anchor, default context and default managers.   I think it is fine as default one always use the same configuration and can be shared.

The compressed certificate cache looks different, as it is not for default key/cert configuration.  Basically, the identity certificate is a property of key manager. It may be safer to manage the cache in key manager level instances.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2747291754

From abarashev at openjdk.org  Fri Jan 30 18:16:08 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 30 Jan 2026 18:16:08 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v13]
In-Reply-To: <uDEn8dr5KZLPtyh3Sl0y6d8ASDfMQnGZwb4Gy-OSrvQ=.5eac767c-e8a7-4c6f-b151-77acb469b631@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>
 <Ag1zV75rDv2o_pyZR_B4LFplmVfibBbrSXNCpMZmuTk=.1d45afbd-a37b-4114-8b02-f6779452c2a8@github.com>
 <KqBPy_GpoXAcWuMOvtAomVx-Y2rZV7NVceSY7gvR6-0=.371b2bcf-1f61-4074-9982-c534b3a2c108@github.com>
 <uDEn8dr5KZLPtyh3Sl0y6d8ASDfMQnGZwb4Gy-OSrvQ=.5eac767c-e8a7-4c6f-b151-77acb469b631@github.com>
Message-ID: <BSiZLYb9AvpYpzDFckUcigX62Q_nGO_k1ygGRIAVoeI=.e13ae5df-93cf-4343-885f-00201438e740@github.com>

On Fri, 30 Jan 2026 17:33:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Yes, I'm actually currently thinking whether to attach this cache to SSLContext instance or not. Not sure about it. This cache implementation has LRU mechanism, so it will simply keep the last 12 compressed certs in memory which should be fine for most scenarios. It's also an easier to maintain code where we have all the pieces in a single file. Currently we have only session caches attached to SSLContext and quite a few static caches like this one in JSSE code.
>
> I had a quick search of the existing cache.  There are some global cache for default security parameters and configuration.  For example, default trust anchor, default context and default managers.   I think it is fine as default one always use the same configuration and can be shared.
> 
> The compressed certificate cache looks different, as it is not for default key/cert configuration.  Basically, the identity certificate is a property of key manager. It may be safer to manage the cache in key manager level instances.

Yes, good point, it is different, I've done similar research. I'll look closer into this, thanks! Some problems I can see with this approach though:

-  Such caching won't work with a 3rd party `X509ExtendedKeyManager` implementations.
- `CertificateMessage` is not just a single certificate, it's the list of certificate entries plus certificate_request_context. Logically such cache doesn't belong to a KeyManager.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2747427885

From xuelei at openjdk.org  Fri Jan 30 19:41:49 2026
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 30 Jan 2026 19:41:49 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v13]
In-Reply-To: <BSiZLYb9AvpYpzDFckUcigX62Q_nGO_k1ygGRIAVoeI=.e13ae5df-93cf-4343-885f-00201438e740@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>
 <Ag1zV75rDv2o_pyZR_B4LFplmVfibBbrSXNCpMZmuTk=.1d45afbd-a37b-4114-8b02-f6779452c2a8@github.com>
 <KqBPy_GpoXAcWuMOvtAomVx-Y2rZV7NVceSY7gvR6-0=.371b2bcf-1f61-4074-9982-c534b3a2c108@github.com>
 <uDEn8dr5KZLPtyh3Sl0y6d8ASDfMQnGZwb4Gy-OSrvQ=.5eac767c-e8a7-4c6f-b151-77acb469b631@github.com>
 <BSiZLYb9AvpYpzDFckUcigX62Q_nGO_k1ygGRIAVoeI=.e13ae5df-93cf-4343-885f-00201438e740@github.com>
Message-ID: <sp1YClqkeK454SE1GYDn2jTq1nxaxGbmLkZOljhCcK0=.e8e5ffc0-a01e-4196-b32b-a4dd13926df2@github.com>

On Fri, 30 Jan 2026 18:13:15 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> I had a quick search of the existing cache.  There are some global cache for default security parameters and configuration.  For example, default trust anchor, default context and default managers.   I think it is fine as default one always use the same configuration and can be shared.
>> 
>> The compressed certificate cache looks different, as it is not for default key/cert configuration.  Basically, the identity certificate is a property of key manager. It may be safer to manage the cache in key manager level instances.
>
> Yes, good point, it is different, I've done similar research. I'll look closer into this, thanks! Some problems I can see with this approach though:
> 
> -  Such caching won't work with a 3rd party `X509ExtendedKeyManager` implementations.
> - `CertificateMessage` is not just a single certificate, it's the list of certificate entries plus certificate_request_context. Logically such cache doesn't belong to a KeyManager.

Yes, a tricky case.  Thank you @artur-oracle for considering this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2747699841

From myankelevich at openjdk.org  Fri Jan 30 20:15:41 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 30 Jan 2026 20:15:41 GMT
Subject: RFR: 8365883: Fix P11Cipher to throw BadPaddingException for PKCS11
 CKR_ENCRYPTED_DATA_INVALID error
Message-ID: <3URZ0BG1QZWecGI4nVsYG59PCRKmSt2SMJr4bVy39a8=.100d6442-5e63-43ac-8107-ca93589aa0fb@github.com>

Underlying issue: if provider returns `PKCS11Exception: CKR_ENCRYPTED_DATA_INVALID` instead of BadPaddingException - `java.security.ProviderException: doFinal()` is thrown

-------------

Commit messages:
 - JDK-8365883: Handle CKR_ENCRYPTED_DATA_INVALID for AES, DES and DES3 for providers correctly

Changes: https://git.openjdk.org/jdk/pull/29503/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29503&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365883
  Stats: 28 lines in 2 files changed: 17 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/29503.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29503/head:pull/29503

PR: https://git.openjdk.org/jdk/pull/29503

From mullan at openjdk.org  Fri Jan 30 20:57:01 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 30 Jan 2026 20:57:01 GMT
Subject: RFR: 8347938: Add Support for the Latest ML-KEM and ML-DSA Private
 Key Encodings [v12]
In-Reply-To: <dgab3_kQ0YzvFfCyTfbV8AaAVWCfmXjWNF8m48FvYtQ=.7499bb91-ebf0-4534-a2ce-4bab88e651af@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <c9pcA-G-P_63a9ICfLwNe3iodcQiFJNX40K0MtsIZCI=.ce04424e-7233-4dd7-af2e-0a4f1e230f59@github.com>
 <ykULcDTapaUBh37b7L-RXnyLA_ibaLRpVzXANbjqoT8=.b8e8f84a-0090-46fb-a3c9-5092c7aa489d@github.com>
 <xgWZ8-nL4h8LoiEsaOMCf2OEx2c7SLuPwOcwQawm0m4=.7313b5be-14b5-4edd-a58e-99011fd84215@github.com>
 <dgab3_kQ0YzvFfCyTfbV8AaAVWCfmXjWNF8m48FvYtQ=.7499bb91-ebf0-4534-a2ce-4bab88e651af@github.com>
Message-ID: <wyFemGSHb3FY21Ht2_JVKFDwF2zSC4ilLJHiXCtgO0k=.2a830593-0360-4c39-afb3-559de6db7df7@github.com>

On Thu, 29 Jan 2026 21:11:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I can break it into 2 sentences. Basically, it means after this key has been created, the `expanded` and `privKeyMaterial` fields have already been checked for consistency so users don't need to check anymore.
>
> How about this?
> 
> /// If the `expanded` field is required by the algorithm, it is either
> /// [calculated from the PKCS #8 encoding][#NamedPKCS8Key(String, byte[], Expander)],
> /// or [provided directly][#internalCreate(String, String, byte[], byte[])].
> /// In the latter case, the caller must ensure the consistency of the `encoded`
> /// and `expanded` arguments. For example, seed and expanded key should match.

Ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2747952449

From duke at openjdk.org  Fri Jan 30 22:30:45 2026
From: duke at openjdk.org (duke)
Date: Fri, 30 Jan 2026 22:30:45 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays [v6]
In-Reply-To: <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
 <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com>
Message-ID: <mrz3UvOF4ITmbpOHuZfJN7Ya98dvdVn9YW35REkJ9-k=.697c1498-b596-4d72-bb16-8c48212eb774@github.com>

On Thu, 22 Jan 2026 21:54:35 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8370688: Updated the documentation to describe the behavior using @implSpec

@koushikthirupattur 
Your change (at version 753154a393ee8c168d7552bae13a8a79f5ff67cc) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3826096708

From valeriep at openjdk.org  Sat Jan 31 00:05:03 2026
From: valeriep at openjdk.org (Valerie Peng)
Date: Sat, 31 Jan 2026 00:05:03 GMT
Subject: RFR: 8365883: Fix P11Cipher to throw BadPaddingException for
 PKCS11 CKR_ENCRYPTED_DATA_INVALID error
In-Reply-To: <3URZ0BG1QZWecGI4nVsYG59PCRKmSt2SMJr4bVy39a8=.100d6442-5e63-43ac-8107-ca93589aa0fb@github.com>
References: <3URZ0BG1QZWecGI4nVsYG59PCRKmSt2SMJr4bVy39a8=.100d6442-5e63-43ac-8107-ca93589aa0fb@github.com>
Message-ID: <haZyDWhSOGU8OuHCx54yVcGmb9frwj2Ka3BXozNlhv8=.a9995c32-540a-4ce3-ab16-64ac2e9f5982@github.com>

On Fri, 30 Jan 2026 10:57:23 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Underlying issue: if provider returns `PKCS11Exception: CKR_ENCRYPTED_DATA_INVALID` instead of BadPaddingException - `java.security.ProviderException: doFinal()` is thrown

test/jdk/sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java line 73:

> 71:         // Checking for SunJCE first
> 72:         System.out.println("Checking SunJCE provider");
> 73:         doTest(Security.getProvider("SunJCE"));

I am not too sure if this is really needed as this is the test for PKCS11 provider. If you really want to keep this, how about adding a static String variable whose value is `System.getProperty("test.provider.name", "SunJCE")`? This way it's consistent with line 90 inside the `doTest()` method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29503#discussion_r2748491998

From valeriep at openjdk.org  Sat Jan 31 00:11:23 2026
From: valeriep at openjdk.org (Valerie Peng)
Date: Sat, 31 Jan 2026 00:11:23 GMT
Subject: RFR: 8365883: Fix P11Cipher to throw BadPaddingException for
 PKCS11 CKR_ENCRYPTED_DATA_INVALID error
In-Reply-To: <3URZ0BG1QZWecGI4nVsYG59PCRKmSt2SMJr4bVy39a8=.100d6442-5e63-43ac-8107-ca93589aa0fb@github.com>
References: <3URZ0BG1QZWecGI4nVsYG59PCRKmSt2SMJr4bVy39a8=.100d6442-5e63-43ac-8107-ca93589aa0fb@github.com>
Message-ID: <yFyOORXwTm_QRSXSyl2Og07XOjcEXFfjv3BSsV1SXFQ=.54cd3ef8-b6ff-4d9b-b7fe-1166923a126a@github.com>

On Fri, 30 Jan 2026 10:57:23 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Underlying issue: if provider returns `PKCS11Exception: CKR_ENCRYPTED_DATA_INVALID` instead of BadPaddingException - `java.security.ProviderException: doFinal()` is thrown

test/jdk/sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java line 107:

> 105:                             c2.doFinal(cipherText, 0, cipherText.length - 2);
> 106:                         } catch (IllegalBlockSizeException ibe) {
> 107:                             // expected

Can we also add a `System.out.println("Expected IBSE thrown");` for information sake? Same goes for the other expected exception block on line 119.

test/jdk/sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java line 127:

> 125:                 } catch (NoSuchAlgorithmException nsae) {
> 126:                     System.out.println("Skipping unsupported algorithm: " +
> 127:                                        nsae);

nit: why so much indent?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29503#discussion_r2748505729
PR Review Comment: https://git.openjdk.org/jdk/pull/29503#discussion_r2748513559

From duke at openjdk.org  Sat Jan 31 01:02:26 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sat, 31 Jan 2026 01:02:26 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v3]
In-Reply-To: <VYGK2WSNj4g-KTwnvmfFW9AqsP-dDGEYkLgkAj2uOZ4=.59ca932f-c7ce-4453-af56-4c6414d8740a@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <VYGK2WSNj4g-KTwnvmfFW9AqsP-dDGEYkLgkAj2uOZ4=.59ca932f-c7ce-4453-af56-4c6414d8740a@github.com>
Message-ID: <3dJXyUlf41nV0VUnlu8-HNOhWZS346uAavA4neC9E8E=.630f6e00-262b-45ba-9d14-4b55a683ed4f@github.com>

On Thu, 29 Jan 2026 22:48:23 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Refactor sun.security.provider.X509Factory cache access to avoid coarse-grained locking and reduce contention during certificate/CRL interning and parsing.
>> 
>> As per request in [the PR](https://github.com/openjdk/jdk/pull/22616#issuecomment-2524971845), re-visit "the initialisation and locking in this area, e.g. addToCache is a static synchronized method so very coarse locking."
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345954: Removing synchronization on getfromcache

> Thanks for the detailed comment. You?re right that this won?t corrupt the cache and that the objects are semantically equivalent. The issue I see isn?t correctness of the cache, but interning/canonicalization semantics.
> 
> I think it could be possible for two values to be inserted for the same logical key: if two threads concurrently miss on `get()`, they can both construct separate `X509CertImpl/X509CRLImpl` instances and then both call `put()`. The cache remains valid, but different callers may observe different object instances for the same certificate/CRL. That breaks the intent of `intern()` as documented (returning a canonical cached instance) and can introduce avoidable object churn.
> 
> The addIfNotPresent() helper keeps the ?check-then-insert and return existing? behavior atomic at this layer, without relying on assumptions about the cache implementation. I would be happy to revisit if we agree interning semantics are not required here. Let me know.



> > > So even if there is a race condition then we'll just insert the same value twice. Would it be possible to insert 2 different values for the same key in this class? It doesn't seem so.
> > 
> > 
> > Thanks for the detailed comment. You?re right that this won?t corrupt the cache and that the objects are semantically equivalent. The issue I see isn?t correctness of the cache, but interning/canonicalization semantics.
> > I think it could be possible for two values to be inserted for the same logical key: if two threads concurrently miss on `get()`, they can both construct separate `X509CertImpl/X509CRLImpl` instances and then both call `put()`. The cache remains valid, but different callers may observe different object instances for the same certificate/CRL. That breaks the intent of `intern()` as documented (returning a canonical cached instance) and can introduce avoidable object churn.
> > The addIfNotPresent() helper keeps the ?check-then-insert and return existing? behavior atomic at this layer, without relying on assumptions about the cache implementation. I would be happy to revisit if we agree interning semantics are not required here. Let me know.
> 
> I see your point, but since this is `SoftMemoryCache` there is no guarantee it will always return the same exact object for the same key anyhow. The callers of `intern` method can't rely on that. SoftReferences are automatically cleared by the garbage collector in response to memory demand, then the new object will be re-inserted.

Thanks for the clarification - I agree that using a SoftMemoryCache means we can?t guarantee identity stability across time, since entries may be cleared and rebuilt under memory pressure. 

That said, I think the interning semantics are still meaningful and useful while an entry is present. The intent of intern() in X509Factory (as documented) is to return a canonical cached instance when possible. Without an atomic ?return existing or insert? step, concurrent callers can still observe different object instances for the same certificate/CRL even when the cache is populated, which weakens the documented intent of the api and can introduce avoidable allocation.

The soft cache limits how long canonicalization can persist, but it doesn?t remove the value of ensuring convergence among concurrent callers while the entry exists. addIfNotPresent() is meant to preserve that best-effort interning behavior in line with the API intent.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29181#issuecomment-3826952211

From wetmore at openjdk.org  Sat Jan 31 01:48:28 2026
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 31 Jan 2026 01:48:28 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v27]
In-Reply-To: <z6OcJwgF-hIMe8M7zrg4mCFlhiGG-tE2OH7zBF6GJVU=.8c4b111d-f018-4962-82f8-0495de2ba889@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
 <z6OcJwgF-hIMe8M7zrg4mCFlhiGG-tE2OH7zBF6GJVU=.8c4b111d-f018-4962-82f8-0495de2ba889@github.com>
Message-ID: <NSzgME-IFGUMlD5caNWWoQOEDcTAAO56jAdr5QrBCrI=.25fbcc36-57d2-4505-92f5-ea1484a1ea99@github.com>

On Wed, 28 Jan 2026 16:23:07 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago.
>> 
>> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. 
>> 
>> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options :
>> 
>> 
>>         System.err.println("help           print the help messages");
>>         System.err.println("expand         expand debugging information");
>>         System.err.println();
>>         System.err.println("all            turn on all debugging");
>>         System.err.println("ssl            turn on ssl debugging");
>>         System.err.println();
>>         System.err.println("The following can be used with ssl:");
>>         System.err.println("\trecord       enable per-record tracing");
>>         System.err.println("\thandshake    print each handshake message");
>>         System.err.println("\tkeygen       print key generation data");
>>         System.err.println("\tsession      print session activity");
>>         System.err.println("\tdefaultctx   print default SSL initialization");
>>         System.err.println("\tsslctx       print SSLContext tracing");
>>         System.err.println("\tsessioncache print session cache tracing");
>>         System.err.println("\tkeymanager   print key manager tracing");
>>         System.err.println("\ttrustmanager print trust manager tracing");
>>         System.err.println("\tpluggability print pluggability tracing");
>>         System.err.println();
>>         System.err.println("\thandshake debugging can be widened with:");
>>         System.err.println("\tdata         hex dump of each handshake message");
>>         System.err.println("\tverbose      verbose handshake message printing");
>>         System.err.println();
>>         System.err.println("\trecord debugging can be widened with:");
>>         System.err.println("\tplaintext    hex dump of record plaintext");
>>         System.err.println("\tpacket       print raw SSL/TLS packets");
>> 
>> 
>> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. 
>> 
>> the output has changed slightly with respect to that  - less verbose
>> 
>> e.g. old...
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments from Brad

As discussed, I've been looking mainly at the conversion in the call sites.  We'll address the `Levels` and `SSLLogger.Opt.*` categories issues later.

- [JDK-8344158](https://bugs.openjdk.org/browse/JDK-8344158) category consistency, and
- [JDK-8338702](https://bugs.openjdk.org/browse/JDK-8338702) System.Logger doesn't output most JSSE debug messages

One mismerge, I think.  Please check carefully.

Just have the `DebugPropertyValuesTest.java` to review, otherwise, looks pretty good.

src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 1026:

> 1024:                             ka, hc.negotiatedProtocol) != null
> 1025:                             || SSLLogger.logWarning(SSLLogger.Opt.HANDSHAKE,
> 1026:                                     "Unable to produce CertificateVerify for key algorithm: " + ka))

Nitty nit nit:  might as well take care of the <80 here too.  Esp line1021.  ;)    

Had to vertically scroll just to see the line in side-by-side.  Thanks!

There were a few others where things got a bit long (e.g. `SessionTicketExtension`, `SSLCipher`), and noticed a couple really egregious existing ones.  I'll probably take care of them when I get to the category bug.

(P.S.  Thank you for doing that in `CertificateRequest.java`!)

src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java line 847:

> 845:                 if (fragmentData.remaining() < 32) {
> 846:                     if (SSLLogger.isOn() &&
> 847:                             SSLLogger.isOn(SSLLogger.Opt.RECORD)) {

I think this looks right.

The consistency followup will look at this closer.  There's several things I think may need changing.

src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java line 1648:

> 1646:             for (RecordFragment fragment : bufferedFragments) {
> 1647:                 if (fragment.contentType == ContentType.CHANGE_CIPHER_SPEC.id) {
> 1648:                     if (hasFin) {

This appears to be another merge issue from a recent changeset (October).  8367059 removed the `if (hasFin)` check.  

Please check this one closely.  Here's the changeset ID.
436dc687ba2ead1662a4e0125cea0966fac825e5

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 212:

> 210:         System.err.println();
> 211:         System.err.println("The following filters can be used with ssl:");
> 212:         System.err.printf("    %-14s %s%n", "defaultctx",

Minor nit for visibility:  

Add an extra blank line between 211/212.    Between `can be used with ssl:` and `defaultctx...`

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 236:

> 234:         System.err.printf("    %-14s %s%n", "trustmanager",
> 235:                 "print trust manager tracing");
> 236:         System.err.printf("%nIf \"ssl\" is specified by itself," +

There's now an extra `%n` on this line.  Maybe move to the new last line?

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 239:

> 237:                 " all non-widening filters are enabled.%n%n");
> 238:         System.err.printf("%nAdding valid filter options to \"ssl\" will log" +
> 239:                 " messages to include%njust those filtered categories.%n");

So the intended behavior is the following:  

If we have code like this:

> if (SSLLogger.isOn() && SSLLogger.isOn(SSLLogger.Opt.SSL)) {

then setting `javax.net.debug=ssl` or `ssl,trustmanager`, it will always output this logging statement.  

But if we have code like this:

> if (SSLLogger.isOn() && SSLLogger.isOn(SSLLogger.Opt.TRUSTMANAGER)) {

then `javax.net.debug=ssl` will output this (because only `ssl` was enabled), but `javax.net.debug=ssl,keymanager` will not.  That's because `keymanager` is a valid name, thus only the `SSL` and `KEYMANAGER` options will print).  

So we need to make sure that everything `SSL` and non-`SSL` is categorized correctly, which will be the focus of [JDK-8344158](https://bugs.openjdk.org/browse/JDK-8344158).

The wording here needs a slight update, and I'm not quite sure how to word this.  Ideas?  :) 

    Adding valid filter options to ssl will output the high-level SSL/TLS debug 
    messages, plus only those messages in the specified categories.

test/jdk/sun/security/ssl/SSLEngineImpl/SSLEngineKeyLimit.java line 114:

> 112:                     " -Dtest.src=" + System.getProperty("test.src") +
> 113:                             " -Dtest.jdk=" + System.getProperty("test.jdk") +
> 114:                             " -Djavax.net.debug=ssl" +

I'm assuming that changing from `ssl,handshake` to just `ssl` is ok?  I didn't actually check.  I notice this in several tests.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18764#pullrequestreview-3719123589
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2748407425
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2748433796
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2748449980
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2747982555
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2738705046
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2738583278
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2748660217

From abarashev at openjdk.org  Sat Jan 31 17:16:07 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Sat, 31 Jan 2026 17:16:07 GMT
Subject: RFR: 8345954: Revisit Class Initializers and Locking in
 X509TrustManagerImpl [v3]
In-Reply-To: <3dJXyUlf41nV0VUnlu8-HNOhWZS346uAavA4neC9E8E=.630f6e00-262b-45ba-9d14-4b55a683ed4f@github.com>
References: <0wPVnxt2Y3q0JeHJg9T1grjNkxrr0AVq6hYB3ZZLxpw=.209b0dda-8804-42c3-949b-b6536f7e480e@github.com>
 <VYGK2WSNj4g-KTwnvmfFW9AqsP-dDGEYkLgkAj2uOZ4=.59ca932f-c7ce-4453-af56-4c6414d8740a@github.com>
 <3dJXyUlf41nV0VUnlu8-HNOhWZS346uAavA4neC9E8E=.630f6e00-262b-45ba-9d14-4b55a683ed4f@github.com>
Message-ID: <JFWftYh0mEsordxIpKoYdL4M67nsI05WKrJKzjCzAdU=.1737b46a-a061-4c73-bfe6-84ba1d00e8c6@github.com>

On Sat, 31 Jan 2026 00:59:22 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> > Thanks for the detailed comment. You?re right that this won?t corrupt the cache and that the objects are semantically equivalent. The issue I see isn?t correctness of the cache, but interning/canonicalization semantics.
> > I think it could be possible for two values to be inserted for the same logical key: if two threads concurrently miss on `get()`, they can both construct separate `X509CertImpl/X509CRLImpl` instances and then both call `put()`. The cache remains valid, but different callers may observe different object instances for the same certificate/CRL. That breaks the intent of `intern()` as documented (returning a canonical cached instance) and can introduce avoidable object churn.
> > The addIfNotPresent() helper keeps the ?check-then-insert and return existing? behavior atomic at this layer, without relying on assumptions about the cache implementation. I would be happy to revisit if we agree interning semantics are not required here. Let me know.
> 
> > > > So even if there is a race condition then we'll just insert the same value twice. Would it be possible to insert 2 different values for the same key in this class? It doesn't seem so.
> > > 
> > > 
> > > Thanks for the detailed comment. You?re right that this won?t corrupt the cache and that the objects are semantically equivalent. The issue I see isn?t correctness of the cache, but interning/canonicalization semantics.
> > > I think it could be possible for two values to be inserted for the same logical key: if two threads concurrently miss on `get()`, they can both construct separate `X509CertImpl/X509CRLImpl` instances and then both call `put()`. The cache remains valid, but different callers may observe different object instances for the same certificate/CRL. That breaks the intent of `intern()` as documented (returning a canonical cached instance) and can introduce avoidable object churn.
> > > The addIfNotPresent() helper keeps the ?check-then-insert and return existing? behavior atomic at this layer, without relying on assumptions about the cache implementation. I would be happy to revisit if we agree interning semantics are not required here. Let me know.
> > 
> > 
> > I see your point, but since this is `SoftMemoryCache` there is no guarantee it will always return the same exact object for the same key anyhow. The callers of `intern` method can't rely on that. SoftReferences are automatically cleared by the garbage collector in response to memory demand, then the new object will be re-inserted.
> 
> Thanks for the clarification - I agree that using a SoftMemoryCache means we can?t guarantee identity stability across time, since entries may be cleared and rebuilt under memory pressure.
> 
> That said, I think the interning semantics are still meaningful and useful while an entry is present. The intent of intern() in X509Factory (as documented) is to return a canonical cached instance when possible. Without an atomic ?return existing or insert? step, concurrent callers can still observe different object instances for the same certificate/CRL even when the cache is populated, which weakens the documented intent of the api and can introduce avoidable allocation.
> 
> The soft cache limits how long canonicalization can persist, but it doesn?t remove the value of ensuring convergence among concurrent callers while the entry exists. addIfNotPresent() is meant to preserve that best-effort interning behavior in line with the API intent.

I can't find anything like `The intent of intern() in X509Factory (as documented) is to return a canonical cached instance when possible.` in `intern` method's javadoc. Is there some other documentation? If we assume that there is indeed such requirement, then we should replace soft cache with a hard cache implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29181#issuecomment-3828855729