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