From myankelevich at openjdk.org  Mon Nov  3 10:49:13 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 3 Nov 2025 10:49:13 GMT
Subject: RFR: 8323999: KeyAgreement cannot be initiated again after a
 failed initialization
In-Reply-To: <Bg5Ko12jUKCaotOkF04mwV512OvQM8qNsMEIWFnQI0w=.c1d6d9a3-1e97-4f75-914c-5ae11deacd56@github.com>
References: <Bg5Ko12jUKCaotOkF04mwV512OvQM8qNsMEIWFnQI0w=.c1d6d9a3-1e97-4f75-914c-5ae11deacd56@github.com>
Message-ID: <KNmindRLlqQ8WirwsPax-3y_sjrzDA5dTCGAsFtXqac=.593f55c5-72f0-4268-b212-a9aa0b5b28ca@github.com>

On Mon, 27 Oct 2025 16:23:14 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates KeyAgreement to re-initialize the `serviceIterator` field when chooseProvider() is called and serviceIterator.hasNext() returns false. This can happen if KeyAgreement object has been initialized with an invalid key and then initialized with a valid key. (See accompanying test.)

src/java.base/share/classes/javax/crypto/KeyAgreement.java line 377:

> 375: 
> 376:             if (!serviceIterator.hasNext()) {
> 377:                 serviceIterator = GetInstance.getServices("KeyAgreement", algorithm);

Wouldn't it cause a change in behaviour of this method unnecessarily? It seems to me it might be a bit better to do this in the `init` methods calling `chooseProvider`. What do you think?

test/jdk/java/security/KeyAgreement/KeyAgreementReinit.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @run main KeyAgreementReinit

Minor: Could you please add a summary here and `@bugid`, as this is a product issue.

Also, `@run` doesn't seem to be doing anything here.

test/jdk/java/security/KeyAgreement/KeyAgreementReinit.java line 63:

> 61:         }
> 62: 
> 63: 

Nit: double new lines and a new line in the end of the file :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28004#discussion_r2486049211
PR Review Comment: https://git.openjdk.org/jdk/pull/28004#discussion_r2486036655
PR Review Comment: https://git.openjdk.org/jdk/pull/28004#discussion_r2486038277

From mdonovan at openjdk.org  Mon Nov  3 13:16:16 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 3 Nov 2025 13:16:16 GMT
Subject: RFR: 8323999: KeyAgreement cannot be initiated again after a
 failed initialization [v2]
In-Reply-To: <Bg5Ko12jUKCaotOkF04mwV512OvQM8qNsMEIWFnQI0w=.c1d6d9a3-1e97-4f75-914c-5ae11deacd56@github.com>
References: <Bg5Ko12jUKCaotOkF04mwV512OvQM8qNsMEIWFnQI0w=.c1d6d9a3-1e97-4f75-914c-5ae11deacd56@github.com>
Message-ID: <ngR7vx6PGPaRS31hmYwxqmfgIObIaW6oHH9QVpZjdCE=.07dc22d2-dfc5-49bd-97e6-c6231e2a75c7@github.com>

> This PR updates KeyAgreement to re-initialize the `serviceIterator` field when chooseProvider() is called and serviceIterator.hasNext() returns false. This can happen if KeyAgreement object has been initialized with an invalid key and then initialized with a valid key. (See accompanying test.)

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  fixed whitespace and @test block

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28004/files
  - new: https://git.openjdk.org/jdk/pull/28004/files/d6556fab..2a5ff125

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

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

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

From mdonovan at openjdk.org  Mon Nov  3 13:16:18 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 3 Nov 2025 13:16:18 GMT
Subject: RFR: 8323999: KeyAgreement cannot be initiated again after a
 failed initialization [v2]
In-Reply-To: <KNmindRLlqQ8WirwsPax-3y_sjrzDA5dTCGAsFtXqac=.593f55c5-72f0-4268-b212-a9aa0b5b28ca@github.com>
References: <Bg5Ko12jUKCaotOkF04mwV512OvQM8qNsMEIWFnQI0w=.c1d6d9a3-1e97-4f75-914c-5ae11deacd56@github.com>
 <KNmindRLlqQ8WirwsPax-3y_sjrzDA5dTCGAsFtXqac=.593f55c5-72f0-4268-b212-a9aa0b5b28ca@github.com>
Message-ID: <R4JiQ0WE6znVB6EJAxWQrim0uzLVlOoG3M3u2lf3fO8=.01cab533-48a3-45d4-889f-e61202140017@github.com>

On Mon, 3 Nov 2025 10:46:22 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed whitespace and @test block
>
> src/java.base/share/classes/javax/crypto/KeyAgreement.java line 377:
> 
>> 375: 
>> 376:             if (!serviceIterator.hasNext()) {
>> 377:                 serviceIterator = GetInstance.getServices("KeyAgreement", algorithm);
> 
> Wouldn't it cause a change in behaviour of this method unnecessarily? It seems to me it might be a bit better to do this in the `init` methods calling `chooseProvider`. What do you think?

I don't understand what you mean about changing the behavior of the method. The behavior has to change somewhere, doesn't it?

I don't like the idea of moving this to the init() method because the code would have to be duplicated in two places and the init methods don't currently have any knowledge of how providers are chosen. it's unlikely but if the chooseProvider() implementation is changed that could force an unnecessary change to the init() methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28004#discussion_r2486448798

From myankelevich at openjdk.org  Mon Nov  3 13:26:50 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 3 Nov 2025 13:26:50 GMT
Subject: RFR: 8323999: KeyAgreement cannot be initiated again after a
 failed initialization [v2]
In-Reply-To: <R4JiQ0WE6znVB6EJAxWQrim0uzLVlOoG3M3u2lf3fO8=.01cab533-48a3-45d4-889f-e61202140017@github.com>
References: <Bg5Ko12jUKCaotOkF04mwV512OvQM8qNsMEIWFnQI0w=.c1d6d9a3-1e97-4f75-914c-5ae11deacd56@github.com>
 <KNmindRLlqQ8WirwsPax-3y_sjrzDA5dTCGAsFtXqac=.593f55c5-72f0-4268-b212-a9aa0b5b28ca@github.com>
 <R4JiQ0WE6znVB6EJAxWQrim0uzLVlOoG3M3u2lf3fO8=.01cab533-48a3-45d4-889f-e61202140017@github.com>
Message-ID: <OQvIMMKmTWxo5YPmUxh0scKKQCNj7Gh6kTCXjqIDveU=.50e6d328-4f75-4fc9-a6e3-75865d16277e@github.com>

On Mon, 3 Nov 2025 13:13:34 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/KeyAgreement.java line 377:
>> 
>>> 375: 
>>> 376:             if (!serviceIterator.hasNext()) {
>>> 377:                 serviceIterator = GetInstance.getServices("KeyAgreement", algorithm);
>> 
>> Wouldn't it cause a change in behaviour of this method unnecessarily? It seems to me it might be a bit better to do this in the `init` methods calling `chooseProvider`. What do you think?
>
> I don't understand what you mean about changing the behavior of the method. The behavior has to change somewhere, doesn't it?
> 
> I don't like the idea of moving this to the init() method because the code would have to be duplicated in two places and the init methods don't currently have any knowledge of how providers are chosen. it's unlikely but if the chooseProvider() implementation is changed that could force an unnecessary change to the init() methods.

I was thinking more about why is it done in `chooseProvider`, this makes the method name inaccurate, as now you're initialising in the method itself. 

Actually, after looking at it the second time, I can see that the method already calls another `init` method and this is a bit confusing to me. It seems to me that it would be more appropriate to move both initialisations to a private helper method, call them from both `init`s and have `chooseProvider` only to choose provider. 

I'm fine if you prefer to keep it as it is to minimise changes, but I still think it would be beneficial in the end.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28004#discussion_r2486479928

From erikj at openjdk.org  Mon Nov  3 14:17:15 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 3 Nov 2025 14:17:15 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v9]
In-Reply-To: <V-BNOBiMS7EhU2yfL0NQNJdGu590cpvEST7UBQ-MFz0=.941bae9c-cefd-43c3-bf82-fadaa82d2b02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <V-BNOBiMS7EhU2yfL0NQNJdGu590cpvEST7UBQ-MFz0=.941bae9c-cefd-43c3-bf82-fadaa82d2b02@github.com>
Message-ID: <5uVrChmuvWYTVm5OgP-PoYFS-Sg3YkEVaUB8q9lIMqE=.8eab6e42-19e3-4a0d-bb62-d16c362ed670@github.com>

On Fri, 31 Oct 2025 22:48:53 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor doc/comment clean-ups

>From a build point of view this is definitely starting to look better. I would like to get input from a reviewer in the component team at this point to comment on the validity of the change before I spend more time reviewing the build aspects.

make/autoconf/lib-krb5.m4 line 47:

> 45:     KRB5_FOUND=no
> 46: 
> 47:     if test "x${with_krb5}" != "x" && test "x${with_krb5}" != "xyes" && test "x${with_krb5}" != "xauto"; then

I think you missed the case where `${with_krb5}` is `no`.

make/autoconf/lib-krb5.m4 line 132:

> 130:         AC_MSG_RESULT([$KRB5_FOUND])
> 131:       else
> 132:         PKG_CHECK_MODULES(KRB5, krb5, [KRB5_FOUND=yes], [KRB5_FOUND=no])

In lib-freetype.m4 we first check if `PKG_CONFIG` has a value before trying to use it. We also print a result because it seems PKG_CHECK_MODULES is quiet. I tried your patch here and configure doesn't produce any output in this case, so I think we should print something.

make/modules/java.security.jgss/Lib.gmk line 101:

> 99: 
> 100:   ifeq ($(call isTargetOs, linux), true)
> 101:     ifeq ($(ENABLE_LIBLINUXKRB5), true)

Suggestion:

    ifeq ($(ENABLE_LIBKRB5_LINUX), true)

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

PR Review: https://git.openjdk.org/jdk/pull/28075#pullrequestreview-3411106519
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2486542040
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2486621470
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2486550921

From duke at openjdk.org  Mon Nov  3 14:22:56 2025
From: duke at openjdk.org (Neha Joshi)
Date: Mon, 3 Nov 2025 14:22:56 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
Message-ID: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>

This PR contain changes to handle skipped exception for below test cases.

-> test/jdk/java/security/cert/CertStore/NoLDAP.java
-> test/jdk/java/security/Provider/NewInstance.java


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

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

Commit messages:
 - JDK-8370942 : Updated error message
 - JDK-8370942 : Updated the copyright
 - JDK-8370942 : Code added for handling the skip case with SkipException.

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

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

From duke at openjdk.org  Mon Nov  3 14:33:23 2025
From: duke at openjdk.org (Neha Joshi)
Date: Mon, 3 Nov 2025 14:33:23 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v2]
In-Reply-To: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
Message-ID: <5IsxmCNVgHKivTdwTJj9-0-vjkRVRRQj3SpVIhxRkwU=.e769138d-1578-46ba-a110-a8bcc4a38182@github.com>

> This PR contain changes to handle skipped exception for below test cases.
> 
> -> test/jdk/java/security/cert/CertStore/NoLDAP.java
> -> test/jdk/java/security/Provider/NewInstance.java
> 
> 
> https://bugs.openjdk.org/browse/JDK-8370942

Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8370942 : Updated error message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28112/files
  - new: https://git.openjdk.org/jdk/pull/28112/files/2b53281f..e522feb6

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

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

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

From abarashev at openjdk.org  Mon Nov  3 15:08:12 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 3 Nov 2025 15:08:12 GMT
Subject: Integrated: 8366364: Return enabled signature schemes with
 SSLConfiguration#getSSLParameters() call
In-Reply-To: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
Message-ID: <Z09aWVX_QTPaemDGuAzIo1eG2XLwTaTLBf2UH7INC6I=.0f729068-fdbc-430e-814f-fe412b9945a7@github.com>

On Thu, 23 Oct 2025 21:54:24 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
> Also enhancing "java -XshowSettings:security:tls" option to show the enabled signature schemes.

This pull request has now been integrated.

Changeset: 02a72174
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/02a7217491755e25f3ae7ff3924f85e26698720d
Stats:     237 lines in 8 files changed: 193 ins; 28 del; 16 mod

8366364: Return enabled signature schemes with SSLConfiguration#getSSLParameters() call

Reviewed-by: mullan

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

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

From myankelevich at openjdk.org  Mon Nov  3 15:54:34 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 3 Nov 2025 15:54:34 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v2]
In-Reply-To: <5IsxmCNVgHKivTdwTJj9-0-vjkRVRRQj3SpVIhxRkwU=.e769138d-1578-46ba-a110-a8bcc4a38182@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
 <5IsxmCNVgHKivTdwTJj9-0-vjkRVRRQj3SpVIhxRkwU=.e769138d-1578-46ba-a110-a8bcc4a38182@github.com>
Message-ID: <xTRoT2QKHIjdP1eRs2cM1IZ7V8XWIcxnKvP0qsbWk0k=.67e6b745-3593-4347-94d4-4a398fb649fb@github.com>

On Mon, 3 Nov 2025 14:33:23 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> This PR contain changes to handle skipped exception for below test cases.
>> 
>> -> test/jdk/java/security/cert/CertStore/NoLDAP.java
>> -> test/jdk/java/security/Provider/NewInstance.java
>> 
>> 
>> https://bugs.openjdk.org/browse/JDK-8370942
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8370942 : Updated error message

Changes requested by myankelevich (Committer).

test/jdk/java/security/Provider/NewInstance.java line 30:

> 28:             JDK JGSS Mechanisms
> 29:  * @library /test/lib ../..
> 30:  * @run main/othervm NewInstance

same as R28 and R29 in NoLDAP.java

test/jdk/java/security/Provider/NewInstance.java line 54:

> 52:             if (p.getName().equals("SunPCSC")) {
> 53:                 skippedProvider = "SunPCSC";
> 54:                 System.err.println("Skip test :: A smartcard might not be installed.");

This case I'd either take SunPCSC from the `Security.getProviders()` (save them to the list, take this out and traverse over it. This way you don't need to put this always skipped message. 

For SunPCSC, if you think it is needed at all, create a separate `@test` which will take the same providers list and run only if there is `SunPCSC` present and only with it. This way you can have it skipped/failed/passed if it needs to be. 

What do you think?

test/jdk/java/security/Provider/NewInstance.java line 78:

> 76:         }
> 77:         //Check if tests were skipped.
> 78:         if (skippedProvider.isEmpty()) {

I think you're checking if the string is empty when you could make an exact comparison. But I think this might be gone if you implement the suggestion at line 53 anyway :)

test/jdk/java/security/cert/CertStore/NoLDAP.java line 28:

> 26:  * @summary Sanity check that NoSuchAlgorithmException is thrown when requesting
> 27:  *   a CertStore of type "LDAP" and LDAP is not available.
> 28:  * @library /test/lib ../..

```sugest 
 * @library /test/lib
``` 

There is no need to import 2 directories up, this just adds to the build time

test/jdk/java/security/cert/CertStore/NoLDAP.java line 29:

> 27:  *   a CertStore of type "LDAP" and LDAP is not available.
> 28:  * @library /test/lib ../..
> 29:  * @run main/othervm NoLDAP

As you're not changing any env properties here, there is no need for othervm. 
`@run main NoLDAP` should be sufficient. But you don't need it at all, as `@run main NoLDAP` is there by default, it makes no difference at all.

test/jdk/java/security/cert/CertStore/NoLDAP.java line 44:

> 42:             throw new SkippedException("Test skipped :: LDAP is present");
> 43:         } catch (ClassNotFoundException ignore) {
> 44:             System.err.println("Class not found exception" + ignore.getMessage());

I'd state that this is expected, otherwise it's a bit confusing. What do you think?

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

PR Review: https://git.openjdk.org/jdk/pull/28112#pullrequestreview-3411626081
PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2486936366
PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2486974595
PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2486974940
PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2486941358
PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2486934199
PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2486948001

From duke at openjdk.org  Mon Nov  3 16:21:19 2025
From: duke at openjdk.org (Neha Joshi)
Date: Mon, 3 Nov 2025 16:21:19 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v2]
In-Reply-To: <xTRoT2QKHIjdP1eRs2cM1IZ7V8XWIcxnKvP0qsbWk0k=.67e6b745-3593-4347-94d4-4a398fb649fb@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
 <5IsxmCNVgHKivTdwTJj9-0-vjkRVRRQj3SpVIhxRkwU=.e769138d-1578-46ba-a110-a8bcc4a38182@github.com>
 <xTRoT2QKHIjdP1eRs2cM1IZ7V8XWIcxnKvP0qsbWk0k=.67e6b745-3593-4347-94d4-4a398fb649fb@github.com>
Message-ID: <6YRfl1CD4w2WhdHi3oZo9TzTp1vwfLtjGkTt9zXYoqA=.9e61e020-b7b3-48b6-ae91-866705e56cd8@github.com>

On Mon, 3 Nov 2025 15:39:35 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8370942 : Updated error message
>
> test/jdk/java/security/Provider/NewInstance.java line 30:
> 
>> 28:             JDK JGSS Mechanisms
>> 29:  * @library /test/lib ../..
>> 30:  * @run main/othervm NewInstance
> 
> same as R28 and R29 in NoLDAP.java

Sure

> test/jdk/java/security/Provider/NewInstance.java line 54:
> 
>> 52:             if (p.getName().equals("SunPCSC")) {
>> 53:                 skippedProvider = "SunPCSC";
>> 54:                 System.err.println("Skip test :: A smartcard might not be installed.");
> 
> This case I'd either take SunPCSC from the `Security.getProviders()` (save them to the list, take this out and traverse over it. This way you don't need to put this always skipped message. 
> 
> For SunPCSC, if you think it is needed at all, create a separate `@test` which will take the same providers list and run only if there is `SunPCSC` present and only with it. This way you can have it skipped/failed/passed if it needs to be. 
> 
> What do you think?

Yeah! if the skip case is required only for SunPCSC , then having a diff test case for that should be a better option.

> test/jdk/java/security/cert/CertStore/NoLDAP.java line 29:
> 
>> 27:  *   a CertStore of type "LDAP" and LDAP is not available.
>> 28:  * @library /test/lib ../..
>> 29:  * @run main/othervm NoLDAP
> 
> As you're not changing any env properties here, there is no need for othervm. 
> `@run main NoLDAP` should be sufficient. But you don't need it at all, as `@run main NoLDAP` is there by default, it makes no difference at all.

Sure will update this.

> test/jdk/java/security/cert/CertStore/NoLDAP.java line 44:
> 
>> 42:             throw new SkippedException("Test skipped :: LDAP is present");
>> 43:         } catch (ClassNotFoundException ignore) {
>> 44:             System.err.println("Class not found exception" + ignore.getMessage());
> 
> I'd state that this is expected, otherwise it's a bit confusing. What do you think?

We should never silently ignore exceptions so , it better to log it for making it easier to detect and fix problems.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2487078648
PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2487064234
PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2487077517
PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2487076043

From myankelevich at openjdk.org  Mon Nov  3 16:25:31 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 3 Nov 2025 16:25:31 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v2]
In-Reply-To: <6YRfl1CD4w2WhdHi3oZo9TzTp1vwfLtjGkTt9zXYoqA=.9e61e020-b7b3-48b6-ae91-866705e56cd8@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
 <5IsxmCNVgHKivTdwTJj9-0-vjkRVRRQj3SpVIhxRkwU=.e769138d-1578-46ba-a110-a8bcc4a38182@github.com>
 <xTRoT2QKHIjdP1eRs2cM1IZ7V8XWIcxnKvP0qsbWk0k=.67e6b745-3593-4347-94d4-4a398fb649fb@github.com>
 <6YRfl1CD4w2WhdHi3oZo9TzTp1vwfLtjGkTt9zXYoqA=.9e61e020-b7b3-48b6-ae91-866705e56cd8@github.com>
Message-ID: <VwUsc8DETOZXShUZ27z5Zsh4nJldSDspKr8e7eAWEbc=.763e4553-2a8f-4988-ac85-af7286c1089a@github.com>

On Mon, 3 Nov 2025 16:17:59 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> test/jdk/java/security/cert/CertStore/NoLDAP.java line 44:
>> 
>>> 42:             throw new SkippedException("Test skipped :: LDAP is present");
>>> 43:         } catch (ClassNotFoundException ignore) {
>>> 44:             System.err.println("Class not found exception" + ignore.getMessage());
>> 
>> I'd state that this is expected, otherwise it's a bit confusing. What do you think?
>
> We should never silently ignore exceptions so , it better to log it for making it easier to detect and fix problems.

This is expected behaviour, the test shouldn't run without it, so if you add exception logging for expected step it may be confusing. All I propose is to change the log to something like this
Suggestion:

            System.err.println("Expected: class not found exception " + ignore.getMessage());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2487090038

From duke at openjdk.org  Mon Nov  3 16:34:35 2025
From: duke at openjdk.org (Neha Joshi)
Date: Mon, 3 Nov 2025 16:34:35 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v3]
In-Reply-To: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
Message-ID: <GbQbuMFORAntzmE4740nLUxXqQ-Be-gb2K2HiUgcJhQ=.6099b373-9f45-4ff9-b510-abf82ca6b11f@github.com>

> This PR contain changes to handle skipped exception for below test cases.
> 
> -> test/jdk/java/security/cert/CertStore/NoLDAP.java
> -> test/jdk/java/security/Provider/NewInstance.java
> 
> 
> https://bugs.openjdk.org/browse/JDK-8370942

Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8370942 : Reveiw comment fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28112/files
  - new: https://git.openjdk.org/jdk/pull/28112/files/e522feb6..d4a2993a

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

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

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

From duke at openjdk.org  Mon Nov  3 16:49:44 2025
From: duke at openjdk.org (Neha Joshi)
Date: Mon, 3 Nov 2025 16:49:44 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v4]
In-Reply-To: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
Message-ID: <KkrhsJcJyovla3nSSY7f9yjvkfD6PSYYy9D1zBDQs6E=.c8b84ecc-55f8-4712-a5e5-29d525ccdbc8@github.com>

> This PR contain changes to handle skipped exception for below test cases.
> 
> -> test/jdk/java/security/cert/CertStore/NoLDAP.java
> -> test/jdk/java/security/Provider/NewInstance.java
> 
> 
> https://bugs.openjdk.org/browse/JDK-8370942

Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8370942 : Reveiw comment fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28112/files
  - new: https://git.openjdk.org/jdk/pull/28112/files/d4a2993a..53725a54

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

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

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

From duke at openjdk.org  Mon Nov  3 16:49:46 2025
From: duke at openjdk.org (Neha Joshi)
Date: Mon, 3 Nov 2025 16:49:46 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v2]
In-Reply-To: <VwUsc8DETOZXShUZ27z5Zsh4nJldSDspKr8e7eAWEbc=.763e4553-2a8f-4988-ac85-af7286c1089a@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
 <5IsxmCNVgHKivTdwTJj9-0-vjkRVRRQj3SpVIhxRkwU=.e769138d-1578-46ba-a110-a8bcc4a38182@github.com>
 <xTRoT2QKHIjdP1eRs2cM1IZ7V8XWIcxnKvP0qsbWk0k=.67e6b745-3593-4347-94d4-4a398fb649fb@github.com>
 <6YRfl1CD4w2WhdHi3oZo9TzTp1vwfLtjGkTt9zXYoqA=.9e61e020-b7b3-48b6-ae91-866705e56cd8@github.com>
 <VwUsc8DETOZXShUZ27z5Zsh4nJldSDspKr8e7eAWEbc=.763e4553-2a8f-4988-ac85-af7286c1089a@github.com>
Message-ID: <6SUKKklnDuaYbgocVKPiTXvwfkoZTAD5WESRVVRjhQo=.85c0c6eb-4867-47c1-95c2-e7a2c89aaf4d@github.com>

On Mon, 3 Nov 2025 16:22:19 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> We should never silently ignore exceptions so , it better to log it for making it easier to detect and fix problems.
>
> This is expected behaviour, the test shouldn't run without it, so if you add exception logging for expected step it may be confusing. All I propose is to change the log to something like this
> Suggestion:
> 
>             System.err.println("Expected: class not found exception " + ignore.getMessage());

Sounds good , will update the log.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2487163904

From jlahoda at openjdk.org  Mon Nov  3 17:06:36 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 3 Nov 2025 17:06:36 GMT
Subject: RFR: 5038439: Warning message for literal shift amounts outside
 the canonical domain
In-Reply-To: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
Message-ID: <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>

On Thu, 4 Sep 2025 15:22:57 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored.
> 
> This can create a trap for the unwary, as in this example:
> 
> public long readLongBigEndian(byte[] buf, int offset) {
>     return ((buf[offset + 0] & 0xff) << 56)   // BUG HERE
>          | ((buf[offset + 1] & 0xff) << 48)   // BUG HERE
>          | ((buf[offset + 2] & 0xff) << 40)   // BUG HERE
>          | ((buf[offset + 3] & 0xff) << 32)   // BUG HERE
>          | ((buf[offset + 4] & 0xff) << 24)
>          | ((buf[offset + 5] & 0xff) << 16)
>          | ((buf[offset + 6] & 0xff) << 8)
>          | ((buf[offset + 7] & 0xff);
> }
> 
> This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`.

I think overall seems sensible - some questions/nits inline.

make/jdk/src/classes/build/tools/intpoly/FieldGen.java line 631:

> 629:                 + (params.getBitsPerLimb() - 1) + ";");
> 630:         if (params.getBitsPerLimb() * params.getNumLimbs() != params.getPower()) {
> 631:             result.appendLine("@SuppressWarnings(\"lossy-conversions\")");

Do you know what is the specific problematic code generated here?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4055:

> 4053:             int maximumShift;
> 4054:             switch (((OperatorSymbol)operator).opcode) {
> 4055:             case ByteCodes.ishl:

Nit: use "modernized" switch - multiple case labels and `->`?

test/langtools/tools/javac/lint/ShiftOutOfRange.java line 14:

> 12: 
> 13:         // These should generate warnings
> 14:         a = a << (byte)-1;

Looking at the patch, I am not completely convinced disallowing `-1` is beneficial. On one hand, it looks weird. On the other hand, it makes some sense (as far as I can tell, it is universal for both `int` and `long`). And, unlike `128`, it is not clearly wrong. I am not sure if it wouldn't be better to simply permit `-1` as a special case.

I see there are `<< -5` in the microbenchmark tests, but I think I am less inclined to accommodate negative values other than `-1`, as the semantics of those is much more cryptic, for me at least.

Please let me know what you think.

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

PR Review: https://git.openjdk.org/jdk/pull/27102#pullrequestreview-3411950069
PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487162366
PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487161036
PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487176078

From duke at openjdk.org  Mon Nov  3 18:02:40 2025
From: duke at openjdk.org (duke)
Date: Mon, 3 Nov 2025 18:02:40 GMT
Subject: RFR: 8365069: Refactor tests to use PEM API (Phase 1) [v2]
In-Reply-To: <i3Taxyyib8yXlhpNIWA96sHLRJp0yvwaDMqm4q-_0EA=.8ee1a188-953b-4063-b70b-f85533ee3bc8@github.com>
References: <DsqvWZPzfHTHzZcUBlyHs6txGU41R38xovx3ZLsl2zM=.9752f9e0-1c05-4d4b-9b2e-3c4cd6e9b6a5@github.com>
 <i3Taxyyib8yXlhpNIWA96sHLRJp0yvwaDMqm4q-_0EA=.8ee1a188-953b-4063-b70b-f85533ee3bc8@github.com>
Message-ID: <BQH8lZfUVjemIoHEPDoxTecCap8L_qWvgbl0TqhzmXY=.7e6e31b6-9367-42ee-be63-da8068a14a0f@github.com>

On Wed, 29 Oct 2025 20:54:56 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The following tests have been identified as candidates for phase 1 of this change.
>> 2. test/jdk/javax/net/ssl/TLSCommon/TLSTest.java
>> 3. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java
>> 4. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilderWithMD5.java
>> 5. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java
>> 9. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java
>> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/PKIXExtendedTM.java
>> 11. test/jdk/sun/security/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java
>> 13. test/jdk/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java
>> 16. test/jdk/java/security/cert/CertPathBuilder/selfIssued/DisableRevocation.java
>> 17. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevel.java
>> 18. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevelRevoked.java
>> 20. test/jdk/java/security/KeyStore/PKCS12/WriteP12Test.java
>> 21. test/jdk/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java
>> 22. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithRID.java
>> 23. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithUnexpectedRID.java
>> 24. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithoutRID.java
>> 25. test/jdk/java/security/cert/CertPathValidator/trustAnchor/ValWithAnchorByName.java
>> 30. test/jdk/java/security/KeyStore/TestKeyStoreBasic.java
>
> Koushik Muthukrishnan Thirupattur has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8365069: Addressing review comments
>  - Merge branch 'master' into 8365069
>  - 8365069: Refactor tests to use PEM API (Phase 1)
>  - 8365069: Refactor tests to use PEM API (Phase 1)
>  - 8365069: Refactor tests to use PEM API (Phase 1)

@koushikthirupattur 
Your change (at version 9c958e51c7598e0a45b70a3610e730eb345db59a) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27267#issuecomment-3481823472

From rgiulietti at openjdk.org  Mon Nov  3 18:12:13 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 3 Nov 2025 18:12:13 GMT
Subject: RFR: 5038439: Warning message for literal shift amounts outside
 the canonical domain
In-Reply-To: <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
 <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>
Message-ID: <n0S7kzJSUFsFD2Hcjbv2nRCAKgyIv_fu_5kEi0gFiRY=.a14c970d-dfe6-44de-aaf4-b656b4267d55@github.com>

On Mon, 3 Nov 2025 16:47:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored.
>> 
>> This can create a trap for the unwary, as in this example:
>> 
>> public long readLongBigEndian(byte[] buf, int offset) {
>>     return ((buf[offset + 0] & 0xff) << 56)   // BUG HERE
>>          | ((buf[offset + 1] & 0xff) << 48)   // BUG HERE
>>          | ((buf[offset + 2] & 0xff) << 40)   // BUG HERE
>>          | ((buf[offset + 3] & 0xff) << 32)   // BUG HERE
>>          | ((buf[offset + 4] & 0xff) << 24)
>>          | ((buf[offset + 5] & 0xff) << 16)
>>          | ((buf[offset + 6] & 0xff) << 8)
>>          | ((buf[offset + 7] & 0xff);
>> }
>> 
>> This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`.
>
> test/langtools/tools/javac/lint/ShiftOutOfRange.java line 14:
> 
>> 12: 
>> 13:         // These should generate warnings
>> 14:         a = a << (byte)-1;
> 
> Looking at the patch, I am not completely convinced disallowing `-1` is beneficial. On one hand, it looks weird. On the other hand, it makes some sense (as far as I can tell, it is universal for both `int` and `long`). And, unlike `128`, it is not clearly wrong. I am not sure if it wouldn't be better to simply permit `-1` as a special case.
> 
> I see there are `<< -5` in the microbenchmark tests, but I think I am less inclined to accommodate negative values other than `-1`, as the semantics of those is much more cryptic, for me at least.
> 
> Please let me know what you think.

One way to read `v << -n` is: "Shift out everything to the left, except for the `n` least significant bits".
Analogously for `v >>> -n`: "Shift out everything to the right, except for the `n` most significant bits".

To rotate `v` by `n` bits to the left, for example, one can write `v << n | v >>> -n` (regardless of the width of `v`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487416183

From acobbs at openjdk.org  Mon Nov  3 18:36:33 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 3 Nov 2025 18:36:33 GMT
Subject: RFR: 5038439: Warning message for literal shift amounts outside
 the canonical domain [v2]
In-Reply-To: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
Message-ID: <rPvEyWXtBAqBsnyea0B0iaX_Z7a3OsftT4vxxaKtVlA=.94566266-84ea-40ac-abea-2e6b470a15ff@github.com>

> When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored.
> 
> This can create a trap for the unwary, as in this example:
> 
> public long readLongBigEndian(byte[] buf, int offset) {
>     return ((buf[offset + 0] & 0xff) << 56)   // BUG HERE
>          | ((buf[offset + 1] & 0xff) << 48)   // BUG HERE
>          | ((buf[offset + 2] & 0xff) << 40)   // BUG HERE
>          | ((buf[offset + 3] & 0xff) << 32)   // BUG HERE
>          | ((buf[offset + 4] & 0xff) << 24)
>          | ((buf[offset + 5] & 0xff) << 16)
>          | ((buf[offset + 6] & 0xff) << 8)
>          | ((buf[offset + 7] & 0xff);
> }
> 
> This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into JDK-5038439 to fix conflict.
 - Address review comment (combine switch cases).
 - Merge branch 'master' into JDK-5038439 to fix conflict.
 - Add "long" as a supported message parameter type.
 - Use "bit(s)" instead of "bits" where value could be 1.
 - Merge branch 'master' into JDK-5038439
 - Sprinkle more variety into the regression test.
 - Minor diff cleanup.
 - Update "lossy-conversions" description in compiler module Javadoc.
 - Warn for bit shifts using an out-of-range shift amount.

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

Changes: https://git.openjdk.org/jdk/pull/27102/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27102&range=01
  Stats: 181 lines in 13 files changed: 173 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27102.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27102/head:pull/27102

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

From acobbs at openjdk.org  Mon Nov  3 18:36:35 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 3 Nov 2025 18:36:35 GMT
Subject: RFR: 5038439: Warning message for literal shift amounts outside
 the canonical domain [v2]
In-Reply-To: <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
 <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>
Message-ID: <0D_jgs9w47rAKwt5Udla_7C1bfb7Moc14-Fr4RsTq64=.27341088-069f-4208-817e-7391e1348a54@github.com>

On Mon, 3 Nov 2025 16:44:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge branch 'master' into JDK-5038439 to fix conflict.
>>  - Address review comment (combine switch cases).
>>  - Merge branch 'master' into JDK-5038439 to fix conflict.
>>  - Add "long" as a supported message parameter type.
>>  - Use "bit(s)" instead of "bits" where value could be 1.
>>  - Merge branch 'master' into JDK-5038439
>>  - Sprinkle more variety into the regression test.
>>  - Minor diff cleanup.
>>  - Update "lossy-conversions" description in compiler module Javadoc.
>>  - Warn for bit shifts using an out-of-range shift amount.
>
> make/jdk/src/classes/build/tools/intpoly/FieldGen.java line 631:
> 
>> 629:                 + (params.getBitsPerLimb() - 1) + ";");
>> 630:         if (params.getBitsPerLimb() * params.getNumLimbs() != params.getPower()) {
>> 631:             result.appendLine("@SuppressWarnings(\"lossy-conversions\")");
> 
> Do you know what is the specific problematic code generated here?

Actually this goes away after merging int the latest master. It was fixed independently by JDK-8368301.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4055:
> 
>> 4053:             int maximumShift;
>> 4054:             switch (((OperatorSymbol)operator).opcode) {
>> 4055:             case ByteCodes.ishl:
> 
> Nit: use "modernized" switch - multiple case labels and `->`?

We can combined the labels, but since we're setting _two_ values we can't use the `->` syntax. Fixed in 8044632727d.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487476213
PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487476095

From acobbs at openjdk.org  Mon Nov  3 18:36:37 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 3 Nov 2025 18:36:37 GMT
Subject: RFR: 5038439: Warning message for literal shift amounts outside
 the canonical domain [v2]
In-Reply-To: <n0S7kzJSUFsFD2Hcjbv2nRCAKgyIv_fu_5kEi0gFiRY=.a14c970d-dfe6-44de-aaf4-b656b4267d55@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
 <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>
 <n0S7kzJSUFsFD2Hcjbv2nRCAKgyIv_fu_5kEi0gFiRY=.a14c970d-dfe6-44de-aaf4-b656b4267d55@github.com>
Message-ID: <nO1fo0YWP7DtcEliG7OwWB9PGTaq-EBm2lJMytOKgBs=.3abe305d-632a-4e14-a121-c8deebdf4ba9@github.com>

On Mon, 3 Nov 2025 18:09:01 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> test/langtools/tools/javac/lint/ShiftOutOfRange.java line 14:
>> 
>>> 12: 
>>> 13:         // These should generate warnings
>>> 14:         a = a << (byte)-1;
>> 
>> Looking at the patch, I am not completely convinced disallowing `-1` is beneficial. On one hand, it looks weird. On the other hand, it makes some sense (as far as I can tell, it is universal for both `int` and `long`). And, unlike `128`, it is not clearly wrong. I am not sure if it wouldn't be better to simply permit `-1` as a special case.
>> 
>> I see there are `<< -5` in the microbenchmark tests, but I think I am less inclined to accommodate negative values other than `-1`, as the semantics of those is much more cryptic, for me at least.
>> 
>> Please let me know what you think.
>
> One way to read `v << -n` is: "Shift out everything to the left, except for the `n` least significant bits".
> Analogously for `v >>> -n`: "Shift out everything to the right, except for the `n` most significant bits".
> 
> To rotate `v` by `n` bits to the left, for example, one can write `v << n | v >>> -n` (regardless of the width of `v`)

Hmm, obviously this is a judgement call and I'm curious what others think.

My opinion is that I still think there should be a warning for shifts of -1.

I mean, maybe to a _real_ hacker, then of course `foo << -1` makes perfect sense because it's just stating the "obvious" which is "shift the low order bit into the high order position and set all the other bits to zero", right?? :)

I just don't think the average Java programmer automatically understands that.

Yes, it's an idiom or "handy trick", but if hasn't attained the status of being universally recognized then it doesn't deserve a special exception.

On the other hand, excluding -1 from the warning would be less disruptive (at least, to the real hackers out there), and that has its own merits. So I don't have a super strong opinion about it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487476314

From hgreule at openjdk.org  Mon Nov  3 18:36:39 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 3 Nov 2025 18:36:39 GMT
Subject: RFR: 5038439: Warning message for literal shift amounts outside
 the canonical domain [v2]
In-Reply-To: <rPvEyWXtBAqBsnyea0B0iaX_Z7a3OsftT4vxxaKtVlA=.94566266-84ea-40ac-abea-2e6b470a15ff@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
 <rPvEyWXtBAqBsnyea0B0iaX_Z7a3OsftT4vxxaKtVlA=.94566266-84ea-40ac-abea-2e6b470a15ff@github.com>
Message-ID: <05yTbGH4d3Remac9l0EN0P6Li94CmDTyXvalkwb5vhI=.1a640f2e-df85-4add-88a9-e6613cfe3f4c@github.com>

On Mon, 3 Nov 2025 18:32:57 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored.
>> 
>> This can create a trap for the unwary, as in this example:
>> 
>> public long readLongBigEndian(byte[] buf, int offset) {
>>     return ((buf[offset + 0] & 0xff) << 56)   // BUG HERE
>>          | ((buf[offset + 1] & 0xff) << 48)   // BUG HERE
>>          | ((buf[offset + 2] & 0xff) << 40)   // BUG HERE
>>          | ((buf[offset + 3] & 0xff) << 32)   // BUG HERE
>>          | ((buf[offset + 4] & 0xff) << 24)
>>          | ((buf[offset + 5] & 0xff) << 16)
>>          | ((buf[offset + 6] & 0xff) << 8)
>>          | ((buf[offset + 7] & 0xff);
>> }
>> 
>> This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into JDK-5038439 to fix conflict.
>  - Address review comment (combine switch cases).
>  - Merge branch 'master' into JDK-5038439 to fix conflict.
>  - Add "long" as a supported message parameter type.
>  - Use "bit(s)" instead of "bits" where value could be 1.
>  - Merge branch 'master' into JDK-5038439
>  - Sprinkle more variety into the regression test.
>  - Minor diff cleanup.
>  - Update "lossy-conversions" description in compiler module Javadoc.
>  - Warn for bit shifts using an out-of-range shift amount.

test/langtools/tools/javac/lint/ShiftOutOfRange.java line 18:

> 16:         a = a >>> (short)-1;
> 17:         a <<= -1;
> 18:         a >>= -1L;          // also generates "implicit cast from long to int in compound assignment is possibly lossy"

I'm a bit surprised by the additional warning here. The shift still operates on int, not long; i.e., unary promotion is performed for each argument rather than binary promotion https://docs.oracle.com/javase/specs/jls/se25/html/jls-15.html#jls-15.19

Should this be fixed (separately, obviously)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487472103

From duke at openjdk.org  Mon Nov  3 18:50:38 2025
From: duke at openjdk.org (Nick Hall)
Date: Mon, 3 Nov 2025 18:50:38 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality
In-Reply-To: <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
Message-ID: <8Usem4e_ob2t8vNthfAQ91duUt2eVCToYUttekAau-o=.b9cc0f2b-38b4-410d-a59a-c6b82a5b9679@github.com>

On Thu, 30 Oct 2025 22:55:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Is there a particular reason for build.sh in the tests or are you just not familiar with how native test code gets automatically compiled by the makefiles based on file naming conventions? In short, any file `lib*.c[pp]` will get compiled into a native library (and exe*.c[pp] into an executable). You can define any special flags or platform include/exclude in `make/test/JtregNativeJdk.gmk`.

Thanks for these @erikj79, no idea how I managed to miss at least one of those...!  All addressed in latest commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3481997569

From duke at openjdk.org  Mon Nov  3 18:50:37 2025
From: duke at openjdk.org (Nick Hall)
Date: Mon, 3 Nov 2025 18:50:37 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v10]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Nick Hall has updated the pull request incrementally with one additional commit since the last revision:

  Address second set of @erikj79's build comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/47968fe7..8c8288a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=08-09

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

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

From acobbs at openjdk.org  Mon Nov  3 18:56:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 3 Nov 2025 18:56:27 GMT
Subject: RFR: 5038439: Warning message for literal shift amounts outside
 the canonical domain [v2]
In-Reply-To: <05yTbGH4d3Remac9l0EN0P6Li94CmDTyXvalkwb5vhI=.1a640f2e-df85-4add-88a9-e6613cfe3f4c@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
 <rPvEyWXtBAqBsnyea0B0iaX_Z7a3OsftT4vxxaKtVlA=.94566266-84ea-40ac-abea-2e6b470a15ff@github.com>
 <05yTbGH4d3Remac9l0EN0P6Li94CmDTyXvalkwb5vhI=.1a640f2e-df85-4add-88a9-e6613cfe3f4c@github.com>
Message-ID: <jSqJ-aHRJ9vxqzkPfdmgTtXwh0EH51WYKg5I6wbh2tE=.da612e30-1305-4a88-9ef1-a1a5b961452b@github.com>

On Mon, 3 Nov 2025 18:30:22 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge branch 'master' into JDK-5038439 to fix conflict.
>>  - Address review comment (combine switch cases).
>>  - Merge branch 'master' into JDK-5038439 to fix conflict.
>>  - Add "long" as a supported message parameter type.
>>  - Use "bit(s)" instead of "bits" where value could be 1.
>>  - Merge branch 'master' into JDK-5038439
>>  - Sprinkle more variety into the regression test.
>>  - Minor diff cleanup.
>>  - Update "lossy-conversions" description in compiler module Javadoc.
>>  - Warn for bit shifts using an out-of-range shift amount.
>
> test/langtools/tools/javac/lint/ShiftOutOfRange.java line 18:
> 
>> 16:         a = a >>> (short)-1;
>> 17:         a <<= -1;
>> 18:         a >>= -1L;          // also generates "implicit cast from long to int in compound assignment is possibly lossy"
> 
> I'm a bit surprised by the additional warning here. The shift still operates on int, not long; i.e., unary promotion is performed for each argument rather than binary promotion https://docs.oracle.com/javase/specs/jls/se25/html/jls-15.html#jls-15.19
> 
> Should this be fixed (separately, obviously)?

I agree, this is a separate compiler glitch.

I've created [JDK-8371162](https://bugs.openjdk.org/browse/JDK-8371162).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487531814

From duke at openjdk.org  Mon Nov  3 21:03:43 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Mon, 3 Nov 2025 21:03:43 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v13]
In-Reply-To: <xSFJKTO7f9E8RzpwWRuUZWL0MEBSZlAfL7XQLG9vXoQ=.0615c53c-f29c-442c-9b53-2f99f25fe80c@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <xSFJKTO7f9E8RzpwWRuUZWL0MEBSZlAfL7XQLG9vXoQ=.0615c53c-f29c-442c-9b53-2f99f25fe80c@github.com>
Message-ID: <awtLr4-zb2zr3TYxuso-YqUYYzZyHnIibAyRnn1tSGw=.fdecab52-3f09-4618-9064-11eacfbc2c07@github.com>

On Fri, 31 Oct 2025 21:57:56 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request 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 25 additional commits since the last revision:
> 
>  - mistakes
>  - Merge branch 'master' into pem26
>  - minor doc updates, fix some bugs, PEM set to 26
>  - more docs, remove runtimeexception
>  - EKPI has a lot of @link's
>  - docs
>  - more doc updates and zeroing
>  - fix non-pbe
>  - doc updates, zeroing, fix unencrypted keypair encoding, exception mods
>  - updates
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/3a0a96e1...0d95043c

LGTM!

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

Marked as reviewed by koushikthirupattur at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/27147#pullrequestreview-3412915195

From weijun at openjdk.org  Mon Nov  3 21:18:52 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 3 Nov 2025 21:18:52 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v13]
In-Reply-To: <xSFJKTO7f9E8RzpwWRuUZWL0MEBSZlAfL7XQLG9vXoQ=.0615c53c-f29c-442c-9b53-2f99f25fe80c@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <xSFJKTO7f9E8RzpwWRuUZWL0MEBSZlAfL7XQLG9vXoQ=.0615c53c-f29c-442c-9b53-2f99f25fe80c@github.com>
Message-ID: <3UO7SRA4zGxJ0QekgBj0R4pSFzza5Bcso0NV5KCwLWE=.edc58188-a5e8-466d-8ebf-09a8fbde0801@github.com>

On Fri, 31 Oct 2025 21:57:56 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request 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 25 additional commits since the last revision:
> 
>  - mistakes
>  - Merge branch 'master' into pem26
>  - minor doc updates, fix some bugs, PEM set to 26
>  - more docs, remove runtimeexception
>  - EKPI has a lot of @link's
>  - docs
>  - more doc updates and zeroing
>  - fix non-pbe
>  - doc updates, zeroing, fix unencrypted keypair encoding, exception mods
>  - updates
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/72fb3ba2...0d95043c

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27147#pullrequestreview-3412962978

From syan at openjdk.org  Tue Nov  4 02:10:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Nov 2025 02:10:03 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v4]
In-Reply-To: <KkrhsJcJyovla3nSSY7f9yjvkfD6PSYYy9D1zBDQs6E=.c8b84ecc-55f8-4712-a5e5-29d525ccdbc8@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
 <KkrhsJcJyovla3nSSY7f9yjvkfD6PSYYy9D1zBDQs6E=.c8b84ecc-55f8-4712-a5e5-29d525ccdbc8@github.com>
Message-ID: <pfDucIyggcflY3pIowPBtLhOdGkzOgFzz5jng_jIzt0=.500c0719-569a-4e03-a954-4d11a0c787cc@github.com>

On Mon, 3 Nov 2025 16:49:44 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> This PR contain changes to handle skipped exception for below test cases.
>> 
>> -> test/jdk/java/security/cert/CertStore/NoLDAP.java
>> -> test/jdk/java/security/Provider/NewInstance.java
>> 
>> 
>> https://bugs.openjdk.org/browse/JDK-8370942
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8370942 : Reveiw comment fixes.

test/jdk/java/security/cert/CertStore/NoLDAP.java line 39:

> 37:         try {
> 38:             Class.forName("javax.naming.ldap.LdapName");
> 39:             System.out.println("LDAP is present, test skipped");

Maybe we can add a new line to throw a Exception when the expected ClassNotFoundException do not seen.


throw new RuntimeException("The expexted ClassNotFoundException was not observed.");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2488405050

From sean at msgilligan.com  Tue Nov  4 02:19:41 2025
From: sean at msgilligan.com (Sean Gilligan)
Date: Mon, 3 Nov 2025 18:19:41 -0800
Subject: Stanford talk Nov 4th, new secp256k1 implementation using
 libsecp256k1 via Java FFM (or Bouncy Castle)
Message-ID: <edaea325-304a-4349-beb0-3bc888d76e80@msgilligan.com>

Hi all,

Andreas Schildbach and I are working on a new Open Source Java library 
for ECC on the secp256k1 curve: secp256k1-jdk [1].

Tuesday Nov 4th, Dan Boneh will be hosting and I will be presenting and 
demonstrating the secp256k1-jdk API at Stanford. The event is San 
Francisco BitDevs Socratic Seminar 64 [2]. More info and RSVP is here:

https://www.meetup.com/sf-bitcoin-devs/events/311604247/

One of the goals of the talk is to evangelize modern Java (especially 
FFM) -- so it would be great if some other Java folks could attend.

secp256k1-jdk defines an opinionated Java API based upon the 
libsecp256k1 'C' library and two implementations using the Java 
ServiceLoader mechanism. The API provides both Ecdsa and Schnorr 
signing/verification, ECDH, and other cryptography primitives. The first 
implementation uses Java FFM ("Panama") to wrap the well-regarded 
libsecp256k1 [3] library and includes Schnorr Signature signing and 
verification. The second implementation uses the pure-Java Bouncy Castle 
[4] library and implements the other functions but not Schnorr (yet.) 
The API currently requires Java 9 but the libsecp256k1/FFM 
implementation requires Java 25.

A Java Cryptography Architecture provider is not on the current roadmap, 
but could happen someday if there is interest and contribution.

We plan on doing a round of integration testing with Sparrow Wallet 
(JavaFX) [5] and bitcoinj [6] (which is used in the Android app "Bitcoin 
Wallet") in the next few months.

I welcome any and all feedback: please email me or open an issue or PR 
on GitHub.

Regards,

Sean Gilligan


[1] secp256k1-jdk: https://github.com/bitcoinj/secp256k1-jdk

[2] SF BitDevs Socratic Seminar 64: https://sfbitcoindevs.org/socratic-64

[3] libsecp256k1: https://github.com/bitcoin-core/secp256k1

[4] Bouncy Castle: https://www.bouncycastle.org

[5] Sparrow Wallet: https://github.com/sparrowwallet/sparrow

[6] bitcoinj: https://github.com/bitcoinj/bitcoinj







From myankelevich at openjdk.org  Tue Nov  4 08:37:48 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 4 Nov 2025 08:37:48 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v4]
In-Reply-To: <pfDucIyggcflY3pIowPBtLhOdGkzOgFzz5jng_jIzt0=.500c0719-569a-4e03-a954-4d11a0c787cc@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
 <KkrhsJcJyovla3nSSY7f9yjvkfD6PSYYy9D1zBDQs6E=.c8b84ecc-55f8-4712-a5e5-29d525ccdbc8@github.com>
 <pfDucIyggcflY3pIowPBtLhOdGkzOgFzz5jng_jIzt0=.500c0719-569a-4e03-a954-4d11a0c787cc@github.com>
Message-ID: <CzzmhGqq95J5JksmFIHa14x2U-PhcoyxyI8kBXClGsI=.35834105-f1ce-402e-af6c-65536977d41a@github.com>

On Tue, 4 Nov 2025 02:07:51 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8370942 : Reveiw comment fixes.
>
> test/jdk/java/security/cert/CertStore/NoLDAP.java line 39:
> 
>> 37:         try {
>> 38:             Class.forName("javax.naming.ldap.LdapName");
>> 39:             System.out.println("LDAP is present, test skipped");
> 
> Maybe we can add a new line to throw a Exception when the expected ClassNotFoundException do not seen.
> 
> 
> throw new RuntimeException("The expexted ClassNotFoundException was not observed.");

I'm not sure this would work tbh. This is an optional setting and failing the test due to the machine being setup for other tests may just introduce the noise from a false negative result.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2489244707

From vyazici at openjdk.org  Tue Nov  4 11:00:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 11:00:30 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
Message-ID: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>

`java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.

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

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

Commit messages:
 - Deprecate `Socket::setPerformancePreferences` and friends for removal

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

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

From weijun at openjdk.org  Tue Nov  4 13:17:48 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 4 Nov 2025 13:17:48 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v5]
In-Reply-To: <D7QJxWfcbUtaejqDNBn3chJAOXlJFpwVXtO0vdTYu2s=.81fbc86b-5236-4714-9b6c-e1a2b5917069@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
 <D7QJxWfcbUtaejqDNBn3chJAOXlJFpwVXtO0vdTYu2s=.81fbc86b-5236-4714-9b6c-e1a2b5917069@github.com>
Message-ID: <oir4Fo8fMlxCQYSceh3tJ04_DtFuTm0QEOaXD1wOOuQ=.e9f4e194-a1d3-49cb-87dc-ac2712491211@github.com>

On Tue, 17 Jun 2025 13:56:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new method `getNistCategory` to get the NIST security category.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   switch to if

Code change not addressing the problem in dug description. Will withdraw.

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

PR Comment: https://git.openjdk.org/jdk/pull/25642#issuecomment-3485957835

From jpai at openjdk.org  Tue Nov  4 13:50:21 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Nov 2025 13:50:21 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
In-Reply-To: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
Message-ID: <iAgN-E1GT697P-DU_Rl2G2rkoehYzZ7seX7eB88rTco=.6ddf7a7b-7d12-4bdd-b690-c8f339df0f15@github.com>

On Tue, 4 Nov 2025 10:53:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
> 
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28129#pullrequestreview-3416562326

From alanb at openjdk.org  Tue Nov  4 13:58:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Nov 2025 13:58:46 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
In-Reply-To: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
Message-ID: <cceeQg1Sxyma2netm_p0KiPT8KqPw07spEK2TDBjnk8=.39e1c74d-17d7-469b-979f-3b1293b4bbeb@github.com>

On Tue, 4 Nov 2025 10:53:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
> 
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

src/java.base/share/classes/java/net/ServerSocket.java line 951:

> 949:      * @since 1.5
> 950:      */
> 951:     @Deprecated(since = "26", forRemoval = true)

Are you planning to add a `@deprecated` comment to these methods?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28129#discussion_r2490619726

From duke at openjdk.org  Tue Nov  4 14:22:15 2025
From: duke at openjdk.org (Neha Joshi)
Date: Tue, 4 Nov 2025 14:22:15 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v5]
In-Reply-To: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
Message-ID: <QuRPUcYl9VTlg2PloiOdJktVBMbpDPwFMXclOk-RSf0=.bd649102-137c-4318-8dea-7a50457a8122@github.com>

> This PR contain changes to handle skipped exception for below test cases.
> 
> -> test/jdk/java/security/cert/CertStore/NoLDAP.java
> -> test/jdk/java/security/Provider/NewInstance.java
> 
> 
> https://bugs.openjdk.org/browse/JDK-8370942

Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8370942 : Remove the skip provider from the list.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28112/files
  - new: https://git.openjdk.org/jdk/pull/28112/files/53725a54..fc3ae067

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

  Stats: 20 lines in 1 file changed: 6 ins; 11 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28112/head:pull/28112

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

From myankelevich at openjdk.org  Tue Nov  4 15:23:40 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 4 Nov 2025 15:23:40 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v5]
In-Reply-To: <QuRPUcYl9VTlg2PloiOdJktVBMbpDPwFMXclOk-RSf0=.bd649102-137c-4318-8dea-7a50457a8122@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
 <QuRPUcYl9VTlg2PloiOdJktVBMbpDPwFMXclOk-RSf0=.bd649102-137c-4318-8dea-7a50457a8122@github.com>
Message-ID: <z5yxGmi6aIXpmWyRDk0Z0Mw3s-sL5ocDhsCxz-UCFHg=.cec07b7b-c32c-4c0a-ac6e-764baf0c8883@github.com>

On Tue, 4 Nov 2025 14:22:15 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> This PR contain changes to handle skipped exception for below test cases.
>> 
>> -> test/jdk/java/security/cert/CertStore/NoLDAP.java
>> -> test/jdk/java/security/Provider/NewInstance.java
>> 
>> 
>> https://bugs.openjdk.org/browse/JDK-8370942
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8370942 : Remove the skip provider from the list.

Looks good to me

test/jdk/java/security/Provider/NewInstance.java line 49:

> 47:     public static void main(String[] args) throws Exception {
> 48: 
> 49:         System.out.println("Removing SunPCSC provider from the list (A smartcard might not be installed).");

Nit: I'd keep it a comment, but print is fine imo too

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

Marked as reviewed by myankelevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28112#pullrequestreview-3417058537
PR Review Comment: https://git.openjdk.org/jdk/pull/28112#discussion_r2490942456

From fguallini at openjdk.org  Tue Nov  4 15:23:50 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Tue, 4 Nov 2025 15:23:50 GMT
Subject: Integrated: 8366817:
 test/jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java and
 JdkProcClient.java should not delete logs
In-Reply-To: <168uceKQ-mqaigIebpwYvP0GaL2d0uynUzSqiHd6M-Q=.4a48511e-cc1b-44be-9019-407612df2e25@github.com>
References: <168uceKQ-mqaigIebpwYvP0GaL2d0uynUzSqiHd6M-Q=.4a48511e-cc1b-44be-9019-407612df2e25@github.com>
Message-ID: <MDG6eiWJWNv7hzkQvb22PjJ1d_M_9KoCwgMpl5C37Jo=.f7223c79-21b5-4ab8-bdbe-58654cedaee8@github.com>

On Wed, 3 Sep 2025 17:02:11 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> The following test helpers delete logs after the test completes:
> jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java
> jdk/javax/net/ssl/TLSCommon/interop/JdkProcClient.java
> 
> These helpers are used by tests located in jdk/javax/net/ssl/compatibility/*.java. Instead of explicitly deleting logs, cleanup should be handled by JTREG, as with other tests.
> 
> It is possible that the server process is still writing to this log when it tries to delete it, which could cause :
>  
> `java.nio.file.FileSystemException: server.log: The process cannot access the file because it is being used by another process`

This pull request has now been integrated.

Changeset: c0c76703
Author:    Fernando Guallini <fguallini at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0c76703bc10d5caa1cda7e2820d0702df5b8008
Stats:     12 lines in 3 files changed: 0 ins; 9 del; 3 mod

8366817: test/jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java and JdkProcClient.java should not delete logs

Reviewed-by: syan, rhalade

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

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

From duke at openjdk.org  Tue Nov  4 15:29:32 2025
From: duke at openjdk.org (Neha Joshi)
Date: Tue, 4 Nov 2025 15:29:32 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v6]
In-Reply-To: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
Message-ID: <-83ry1l8Rnw6JkZS_FRz5JVZMyzBluwkBQQ6eyLLIpQ=.b0eb3aaf-36cf-41af-a7fc-a4be363df579@github.com>

> This PR contain changes to handle skipped exception for below test cases.
> 
> -> test/jdk/java/security/cert/CertStore/NoLDAP.java
> -> test/jdk/java/security/Provider/NewInstance.java
> 
> 
> https://bugs.openjdk.org/browse/JDK-8370942

Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8370942 : Updated skip exception message.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28112/files
  - new: https://git.openjdk.org/jdk/pull/28112/files/fc3ae067..22743f1d

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

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

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

From myankelevich at openjdk.org  Tue Nov  4 15:29:32 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 4 Nov 2025 15:29:32 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v6]
In-Reply-To: <-83ry1l8Rnw6JkZS_FRz5JVZMyzBluwkBQQ6eyLLIpQ=.b0eb3aaf-36cf-41af-a7fc-a4be363df579@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
 <-83ry1l8Rnw6JkZS_FRz5JVZMyzBluwkBQQ6eyLLIpQ=.b0eb3aaf-36cf-41af-a7fc-a4be363df579@github.com>
Message-ID: <5BY1XXNo8W76_8IJ7SjHXMhWD3-Tnglao65HHz2LtF0=.6a9e925b-e23d-4280-aa81-f17e58b439e0@github.com>

On Tue, 4 Nov 2025 15:26:42 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> This PR contain changes to handle skipped exception for below test cases.
>> 
>> -> test/jdk/java/security/cert/CertStore/NoLDAP.java
>> -> test/jdk/java/security/Provider/NewInstance.java
>> 
>> 
>> https://bugs.openjdk.org/browse/JDK-8370942
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8370942 : Updated skip exception message.

Marked as reviewed by myankelevich (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28112#pullrequestreview-3417094360

From vpaprotski at openjdk.org  Tue Nov  4 16:46:36 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Tue, 4 Nov 2025 16:46:36 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
Message-ID: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>

- New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
   - `SignatureBench.MLDSA` is 1.2x-2.2x faster
   - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
- AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
  - `SignatureBench.MLDSA` is upto 5% faster, never slower

Note on intrinsic:
- The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
- Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2

Tests and benchmarks:
- Added a fuzz test to ensure Java and intrinsic produces exactly same result
- Added benchmark to measure the performance of intrinsic itself

make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"

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

Commit messages:
 - Merge remote-tracking branch 'origin/master' into avx2-ntt
 - add copyright, whitespace and test jtreg tags
 - Fixes and comments from Anas
 - AVX2 and AVX512 intrinsics for MLDSA

Changes: https://git.openjdk.org/jdk/pull/28136/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28136&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371259
  Stats: 2247 lines in 7 files changed: 1546 ins; 257 del; 444 mod
  Patch: https://git.openjdk.org/jdk/pull/28136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28136/head:pull/28136

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

From myankelevich at openjdk.org  Tue Nov  4 17:19:18 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 4 Nov 2025 17:19:18 GMT
Subject: RFR: 8371262: sun/security/pkcs11/Cipher/KeyWrap tests may silently
 skip
Message-ID: <6ZjHSGR6D_xW17JhNqgrxvOrY4cNFAJaMco5K5s9Qfo=.8762b3a5-a285-498b-b9a7-961bb68b045c@github.com>

KeyWrap tests may silently skip :
* test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
* test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
* test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java

Also, some cleanup of the files.

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

Commit messages:
 - JDK-8371262: sun/security/pkcs11/Cipher/KeyWrap tests may silently skip

Changes: https://git.openjdk.org/jdk/pull/28138/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28138&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371262
  Stats: 108 lines in 3 files changed: 67 ins; 7 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/28138.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28138/head:pull/28138

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

From vyazici at openjdk.org  Tue Nov  4 17:32:50 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 17:32:50 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v2]
In-Reply-To: <cceeQg1Sxyma2netm_p0KiPT8KqPw07spEK2TDBjnk8=.39e1c74d-17d7-469b-979f-3b1293b4bbeb@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
 <cceeQg1Sxyma2netm_p0KiPT8KqPw07spEK2TDBjnk8=.39e1c74d-17d7-469b-979f-3b1293b4bbeb@github.com>
Message-ID: <q0wItBUZg8NM8m_bhwPsWhlVknmX-udt4yDtafAKrgQ=.44531425-79ab-4e30-bbe2-4c743e363626@github.com>

On Tue, 4 Nov 2025 13:55:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve Javadoc
>
> src/java.base/share/classes/java/net/ServerSocket.java line 951:
> 
>> 949:      * @since 1.5
>> 950:      */
>> 951:     @Deprecated(since = "26", forRemoval = true)
> 
> Are you planning to add a `@deprecated` comment to these methods?

I was not intending to, but added in 41c918cfa60 after your nudge.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28129#discussion_r2491445107

From vyazici at openjdk.org  Tue Nov  4 17:32:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 17:32:48 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v2]
In-Reply-To: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
Message-ID: <iWd2B5ipaFsiIoP0HodsxVrqxukt2Lt1XaSvQO0FRkQ=.c7553e3d-6388-4586-8696-82ec341580a6@github.com>

> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
> 
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Improve Javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28129/files
  - new: https://git.openjdk.org/jdk/pull/28129/files/50826c3e..41c918cf

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

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

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

From weijun at openjdk.org  Tue Nov  4 18:05:16 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 4 Nov 2025 18:05:16 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v8]
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <PbYx6agso7eTr5jV6PEeMkqVE6v3KFKHq_GOmgN49r0=.802668c1-59c6-4266-982a-44f97dfd4802@github.com>

> Add support for ML-DSA signing of JAR files.
> 
> Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.
> 
> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.

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

  rewrite fetcher to open ZipFile only once

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26563/files
  - new: https://git.openjdk.org/jdk/pull/26563/files/989027cb..d276914e

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

  Stats: 106 lines in 2 files changed: 53 ins; 18 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/26563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26563/head:pull/26563

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

From duke at openjdk.org  Tue Nov  4 18:46:05 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Tue, 4 Nov 2025 18:46:05 GMT
Subject: Integrated: 8365069: Refactor tests to use PEM API (Phase 1)
In-Reply-To: <DsqvWZPzfHTHzZcUBlyHs6txGU41R38xovx3ZLsl2zM=.9752f9e0-1c05-4d4b-9b2e-3c4cd6e9b6a5@github.com>
References: <DsqvWZPzfHTHzZcUBlyHs6txGU41R38xovx3ZLsl2zM=.9752f9e0-1c05-4d4b-9b2e-3c4cd6e9b6a5@github.com>
Message-ID: <89D-_lYRim0VV7SqGGTDSH1Jp5kFS1gARJ141VK6ENY=.ec208061-e956-45c0-b264-549d1e3c0099@github.com>

On Sat, 13 Sep 2025 04:44:13 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The following tests have been identified as candidates for phase 1 of this change.
> 2. test/jdk/javax/net/ssl/TLSCommon/TLSTest.java
> 3. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java
> 4. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilderWithMD5.java
> 5. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java
> 9. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java
> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/PKIXExtendedTM.java
> 11. test/jdk/sun/security/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java
> 13. test/jdk/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java
> 16. test/jdk/java/security/cert/CertPathBuilder/selfIssued/DisableRevocation.java
> 17. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevel.java
> 18. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevelRevoked.java
> 20. test/jdk/java/security/KeyStore/PKCS12/WriteP12Test.java
> 21. test/jdk/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java
> 22. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithRID.java
> 23. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithUnexpectedRID.java
> 24. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithoutRID.java
> 25. test/jdk/java/security/cert/CertPathValidator/trustAnchor/ValWithAnchorByName.java
> 30. test/jdk/java/security/KeyStore/TestKeyStoreBasic.java

This pull request has now been integrated.

Changeset: 8224292b
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8224292ba57f3d6f79c1a3515348824d92ef45fe
Stats:     545 lines in 18 files changed: 103 ins; 221 del; 221 mod

8365069: Refactor tests to use PEM API (Phase 1)

Reviewed-by: ascarpino

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

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

From alanb at openjdk.org  Tue Nov  4 19:57:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Nov 2025 19:57:17 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v2]
In-Reply-To: <iWd2B5ipaFsiIoP0HodsxVrqxukt2Lt1XaSvQO0FRkQ=.c7553e3d-6388-4586-8696-82ec341580a6@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
 <iWd2B5ipaFsiIoP0HodsxVrqxukt2Lt1XaSvQO0FRkQ=.c7553e3d-6388-4586-8696-82ec341580a6@github.com>
Message-ID: <2cuzTthIX1oIW7Zv9oG4IvBSY1c_OV1k5HjP9JeynJg=.f3463afe-49d9-40b2-9081-47c8b65048a6@github.com>

On Tue, 4 Nov 2025 17:32:48 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
>> 
>> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve Javadoc

src/java.base/share/classes/java/net/SocketImpl.java line 362:

> 360:      *
> 361:      * @deprecated This function has always been a no-op.
> 362:      * It is deprecated for removal without any replacement.

The method  description already has "By default, this method does nothing, unless it is overridden in a sub-class".  What would you think about have the deprecated message be reduced down to "This method was intended to allow for protocols that are now obsolete"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28129#discussion_r2491879876

From vyazici at openjdk.org  Tue Nov  4 20:04:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 20:04:27 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v3]
In-Reply-To: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
Message-ID: <j-MQNksF9YCAKdt8M7qChZ8QIkPjxfkrjPHAAyIqLVU=.ed91ff66-7c6e-49cd-b4e5-73b1daf47e46@github.com>

> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
> 
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Shorten `@deprecated` message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28129/files
  - new: https://git.openjdk.org/jdk/pull/28129/files/41c918cf..c9384b09

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

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

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

From vyazici at openjdk.org  Tue Nov  4 20:04:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 20:04:29 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v2]
In-Reply-To: <2cuzTthIX1oIW7Zv9oG4IvBSY1c_OV1k5HjP9JeynJg=.f3463afe-49d9-40b2-9081-47c8b65048a6@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
 <iWd2B5ipaFsiIoP0HodsxVrqxukt2Lt1XaSvQO0FRkQ=.c7553e3d-6388-4586-8696-82ec341580a6@github.com>
 <2cuzTthIX1oIW7Zv9oG4IvBSY1c_OV1k5HjP9JeynJg=.f3463afe-49d9-40b2-9081-47c8b65048a6@github.com>
Message-ID: <h3t4tm2ncDSyb0SShmi7pBoDRbXhSikJgNOMkaKAkBA=.142de2fc-79c1-466b-9a9c-c1f359c9d5fa@github.com>

On Tue, 4 Nov 2025 19:54:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve Javadoc
>
> src/java.base/share/classes/java/net/SocketImpl.java line 362:
> 
>> 360:      *
>> 361:      * @deprecated This function has always been a no-op.
>> 362:      * It is deprecated for removal without any replacement.
> 
> The method  description already has "By default, this method does nothing, unless it is overridden in a sub-class".  What would you think about have the deprecated message be reduced down to "This method was intended to allow for protocols that are now obsolete"?

Implemented in c9384b09ba9. I'm right away updating the CSR specification too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28129#discussion_r2491895289

From mullan at openjdk.org  Tue Nov  4 20:16:27 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 4 Nov 2025 20:16:27 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v8]
In-Reply-To: <PbYx6agso7eTr5jV6PEeMkqVE6v3KFKHq_GOmgN49r0=.802668c1-59c6-4266-982a-44f97dfd4802@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <PbYx6agso7eTr5jV6PEeMkqVE6v3KFKHq_GOmgN49r0=.802668c1-59c6-4266-982a-44f97dfd4802@github.com>
Message-ID: <_jVOLEVHb9h9EGVTQMyo1C5CVFGunjwO_DrPreB1iYk=.9dad3988-6ad7-4297-9a59-4db57f964320@github.com>

On Tue, 4 Nov 2025 18:05:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add support for ML-DSA signing of JAR files.
>> 
>> Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.
>> 
>> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewrite fetcher to open ZipFile only once

src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 546:

> 544:                         && !digAlgId.equalsOID(AlgorithmId.SHAKE128_256_oid)
> 545:                         && !digAlgId.equalsOID(AlgorithmId.SHAKE256_512_oid)) {
> 546:                     throw new NoSuchAlgorithmException("Incompatible digest algorithm" + digAlgId);

Need space after "algorithm".

src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 555:

> 553:                         && !digAlgId.equalsOID(AlgorithmId.SHA3_512_oid)
> 554:                         && !digAlgId.equalsOID(AlgorithmId.SHAKE256_512_oid)) {
> 555:                     throw new NoSuchAlgorithmException("Incompatible digest algorithm");

Also include `digAlgId` in exception msg like on line 546. Same comment on line 562.

src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 575:

> 573:      * algorithm can be in any of the 3 forms:
> 574:      *
> 575:      * 1. Simply key algorithm like RSA, DSA, EC, this method returns

s/Simply/Simple/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2491917463
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2491916896
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2491920116

From mullan at openjdk.org  Tue Nov  4 20:24:34 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 4 Nov 2025 20:24:34 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v8]
In-Reply-To: <PbYx6agso7eTr5jV6PEeMkqVE6v3KFKHq_GOmgN49r0=.802668c1-59c6-4266-982a-44f97dfd4802@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <PbYx6agso7eTr5jV6PEeMkqVE6v3KFKHq_GOmgN49r0=.802668c1-59c6-4266-982a-44f97dfd4802@github.com>
Message-ID: <SBHqEHdJeqBcJTv6l1dMbdpt5do6zWOx37cMkgu8_fA=.958896e9-a268-43cf-911d-22395edd2d0c@github.com>

On Tue, 4 Nov 2025 18:05:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add support for ML-DSA signing of JAR files.
>> 
>> Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.
>> 
>> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewrite fetcher to open ZipFile only once

test/jdk/sun/security/tools/jarsigner/ML_DSA.java line 1:

> 1: /*

Suggest also adding a test using the `JarSigner` API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2491945946

From weijun at openjdk.org  Tue Nov  4 21:18:36 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 4 Nov 2025 21:18:36 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v9]
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <wlvd3dEgCYM-uOsYHR0MFKMXCSjd7ZuKJnVlryhWgk8=.72ec3e73-50f1-4358-9098-7112c14d5d98@github.com>

> Add support for ML-DSA signing of JAR files.
> 
> Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.
> 
> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.

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

  man page change; exception change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26563/files
  - new: https://git.openjdk.org/jdk/pull/26563/files/d276914e..c595d9aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26563&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26563&range=07-08

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

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

From duke at openjdk.org  Tue Nov  4 22:11:36 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Tue, 4 Nov 2025 22:11:36 GMT
Subject: Integrated: 8371296: Refactor tests to use PEM API (Phase 1) - Fix
 WriteP12Test failure
Message-ID: <aPbtlDUgUfKU8Hcm4OgBTT-zDFkRGlcqczunZIuhfJg=.3c475521-ee19-4127-ad78-cea1f465df51@github.com>

Fix WriteP12Test failure

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

Commit messages:
 - 8371296: Fix failing WriteP12Test

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

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

From ascarpino at openjdk.org  Tue Nov  4 22:11:36 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 4 Nov 2025 22:11:36 GMT
Subject: Integrated: 8371296: Refactor tests to use PEM API (Phase 1) - Fix
 WriteP12Test failure
In-Reply-To: <aPbtlDUgUfKU8Hcm4OgBTT-zDFkRGlcqczunZIuhfJg=.3c475521-ee19-4127-ad78-cea1f465df51@github.com>
References: <aPbtlDUgUfKU8Hcm4OgBTT-zDFkRGlcqczunZIuhfJg=.3c475521-ee19-4127-ad78-cea1f465df51@github.com>
Message-ID: <W1MHqG31pBcyYDbv5tp6YGXb_SAa1in6TJ0uLDXBrQI=.31702013-fa3f-4fb7-a9a7-3b4318bc2a93@github.com>

On Tue, 4 Nov 2025 22:00:45 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> Fix WriteP12Test failure

Marked as reviewed by ascarpino (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28140#pullrequestreview-3418784880

From duke at openjdk.org  Tue Nov  4 22:11:37 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Tue, 4 Nov 2025 22:11:37 GMT
Subject: Integrated: 8371296: Refactor tests to use PEM API (Phase 1) - Fix
 WriteP12Test failure
In-Reply-To: <aPbtlDUgUfKU8Hcm4OgBTT-zDFkRGlcqczunZIuhfJg=.3c475521-ee19-4127-ad78-cea1f465df51@github.com>
References: <aPbtlDUgUfKU8Hcm4OgBTT-zDFkRGlcqczunZIuhfJg=.3c475521-ee19-4127-ad78-cea1f465df51@github.com>
Message-ID: <79AvX43RPOX0PpEScr9r-9jGTnaYDigMVADjZPA5cBM=.d058a8cf-fff2-4922-bddc-97148b8026e2@github.com>

On Tue, 4 Nov 2025 22:00:45 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> Fix WriteP12Test failure

This pull request has now been integrated.

Changeset: 463f5dc1
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/463f5dc112386802b9ce0cc985a961ecfd3fbc55
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8371296: Refactor tests to use PEM API (Phase 1) - Fix WriteP12Test failure

Reviewed-by: ascarpino

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

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

From weijun at openjdk.org  Tue Nov  4 22:42:47 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 4 Nov 2025 22:42:47 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v10]
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <fj0RP9D_WwtktLa6U6kKbg7zU8i5PXdt1evrBF3Pjbg=.c005b376-3839-4f2f-b695-b49dae2d2174@github.com>

> Add support for ML-DSA signing of JAR files.
> 
> ~Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.~
> 
> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.

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

  Sean comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26563/files
  - new: https://git.openjdk.org/jdk/pull/26563/files/c595d9aa..f3b0b26d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26563&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26563&range=08-09

  Stats: 72 lines in 2 files changed: 43 ins; 10 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/26563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26563/head:pull/26563

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

From weijun at openjdk.org  Wed Nov  5 01:29:35 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 5 Nov 2025 01:29:35 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v11]
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <DJ00hSe67YzksBTXe2cSCjpLInmX8udLeCm1NMQ5gDM=.eede3df2-cde4-4305-b5e6-f354790f7c95@github.com>

> Add support for ML-DSA signing of JAR files.
> 
> ~Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.~
> 
> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.

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

  test issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26563/files
  - new: https://git.openjdk.org/jdk/pull/26563/files/f3b0b26d..4a20af7b

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

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

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

From weijun at openjdk.org  Wed Nov  5 01:29:37 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 5 Nov 2025 01:29:37 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v8]
In-Reply-To: <SBHqEHdJeqBcJTv6l1dMbdpt5do6zWOx37cMkgu8_fA=.958896e9-a268-43cf-911d-22395edd2d0c@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <PbYx6agso7eTr5jV6PEeMkqVE6v3KFKHq_GOmgN49r0=.802668c1-59c6-4266-982a-44f97dfd4802@github.com>
 <SBHqEHdJeqBcJTv6l1dMbdpt5do6zWOx37cMkgu8_fA=.958896e9-a268-43cf-911d-22395edd2d0c@github.com>
Message-ID: <VKfG4EEmWGEcSfx7UweS0uoVQ7D_hIMcAleLpvDSbUE=.2321f0a2-d3f0-49d8-a73d-56454cb2fbb8@github.com>

On Tue, 4 Nov 2025 20:22:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rewrite fetcher to open ZipFile only once
>
> test/jdk/sun/security/tools/jarsigner/ML_DSA.java line 1:
> 
>> 1: /*
> 
> Suggest also adding a test using the `JarSigner` API.

Added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2492502300

From fandreuzzi at openjdk.org  Wed Nov  5 09:58:13 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 5 Nov 2025 09:58:13 GMT
Subject: RFR: 8357880: Code formatting typo in
 Cipher.getMaxAllowedParameterSpec
In-Reply-To: <V74K8fkxqOWx-yD8zsJwrWDqr6arvPYirfPRyKustHU=.47822beb-c548-48a5-9e1f-2484ed56ebb4@github.com>
References: <V74K8fkxqOWx-yD8zsJwrWDqr6arvPYirfPRyKustHU=.47822beb-c548-48a5-9e1f-2484ed56ebb4@github.com>
Message-ID: <aBPPaUQwuQtCKzUqF7eZRFJj5IikPqxy38Eassc0GyE=.d52b6905-6763-40de-bc93-345f8ce43852@github.com>

On Wed, 5 Nov 2025 09:50:09 GMT, Peyang <duke at openjdk.org> wrote:

> Fix JavaDoc typos in `Cipher` class: correct `{code ...}` to `{@code ...}` in the constructor and `getMaxAllowedParameterSpec()`

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/28145#pullrequestreview-3420953990

From duke at openjdk.org  Wed Nov  5 09:58:13 2025
From: duke at openjdk.org (Peyang)
Date: Wed, 5 Nov 2025 09:58:13 GMT
Subject: RFR: 8357880: Code formatting typo in
 Cipher.getMaxAllowedParameterSpec
Message-ID: <V74K8fkxqOWx-yD8zsJwrWDqr6arvPYirfPRyKustHU=.47822beb-c548-48a5-9e1f-2484ed56ebb4@github.com>

Fix JavaDoc typos in `Cipher` class: correct `{code ...}` to `{@code ...}` in the constructor and `getMaxAllowedParameterSpec()`

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

Commit messages:
 - 8357880: Fix typos in Javadoc for Cipher class

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

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

From dfuchs at openjdk.org  Wed Nov  5 11:48:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Nov 2025 11:48:16 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v3]
In-Reply-To: <j-MQNksF9YCAKdt8M7qChZ8QIkPjxfkrjPHAAyIqLVU=.ed91ff66-7c6e-49cd-b4e5-73b1daf47e46@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
 <j-MQNksF9YCAKdt8M7qChZ8QIkPjxfkrjPHAAyIqLVU=.ed91ff66-7c6e-49cd-b4e5-73b1daf47e46@github.com>
Message-ID: <lsic7TKt-evAQAJ3VL6ZrlvYC-l73hRtasnC9VSEGA0=.7b82fc21-9055-4995-a6dc-a7a712b1ec72@github.com>

On Tue, 4 Nov 2025 20:04:27 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
>> 
>> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shorten `@deprecated` message

Looks good to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28129#pullrequestreview-3421476561

From alanb at openjdk.org  Wed Nov  5 11:54:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Nov 2025 11:54:05 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v3]
In-Reply-To: <j-MQNksF9YCAKdt8M7qChZ8QIkPjxfkrjPHAAyIqLVU=.ed91ff66-7c6e-49cd-b4e5-73b1daf47e46@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
 <j-MQNksF9YCAKdt8M7qChZ8QIkPjxfkrjPHAAyIqLVU=.ed91ff66-7c6e-49cd-b4e5-73b1daf47e46@github.com>
Message-ID: <3MKlB8kYKmJ7ZLwmhrIRYdVV7URoXFjr_EOdAByB-FU=.c1e05ed0-10f6-4ccd-af55-418ea417114d@github.com>

On Tue, 4 Nov 2025 20:04:27 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
>> 
>> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shorten `@deprecated` message

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28129#pullrequestreview-3421501498

From mullan at openjdk.org  Wed Nov  5 13:01:04 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 5 Nov 2025 13:01:04 GMT
Subject: RFR: 8357880: Code formatting typo in
 Cipher.getMaxAllowedParameterSpec
In-Reply-To: <V74K8fkxqOWx-yD8zsJwrWDqr6arvPYirfPRyKustHU=.47822beb-c548-48a5-9e1f-2484ed56ebb4@github.com>
References: <V74K8fkxqOWx-yD8zsJwrWDqr6arvPYirfPRyKustHU=.47822beb-c548-48a5-9e1f-2484ed56ebb4@github.com>
Message-ID: <QCwV6nnU4lwcP2_TBTPDunpEmh3DpgaREVjbh_WjXTk=.8547499a-84fa-4d34-8b9f-d0685acbc5c8@github.com>

On Wed, 5 Nov 2025 09:50:09 GMT, Peyang <duke at openjdk.org> wrote:

> Fix JavaDoc typos in `Cipher` class: correct `{code ...}` to `{@code ...}` in the constructor and `getMaxAllowedParameterSpec()`

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28145#pullrequestreview-3421849693

From weijun at openjdk.org  Wed Nov  5 14:04:19 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 5 Nov 2025 14:04:19 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v11]
In-Reply-To: <ZoxnuLAb2asWIsQrjBR_PRnzv2Mhd6bsmPAhK7qDyMA=.1584a779-da85-4b4a-8a84-08b0fe4846bd@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <HzlJasxY_-Jt_BEEylRbPJFnX0BupAcgABWr0lmN2Js=.a3202c8a-70e5-4dfd-ba24-146d190b3684@github.com>
 <GQ-E9Hi0ehjm8LvxHCmOIVDIx3U_8xmHMsDQTkPmPEU=.5ad15dd6-4c5c-431b-bc64-c2260130f633@github.com>
 <7YmfaBg-AC1UZHR7WhS-upiKolPsh91n9jB1vIzVu64=.5ba1c17a-a71b-42cf-bdb7-5dc7032a212e@github.com>
 <ZoxnuLAb2asWIsQrjBR_PRnzv2Mhd6bsmPAhK7qDyMA=.1584a779-da85-4b4a-8a84-08b0fe4846bd@github.com>
Message-ID: <kxjjdI8LufiRb-tA6ZgmExdG3gDvk2gOwxMrAD31jsU=.82fef1fe-b8fb-4296-85ad-5775718132cc@github.com>

On Thu, 30 Oct 2025 18:26:15 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Yes, but that means I need to download the ZIP bundles somewhere. This new property allows me to work with local or remote repositories directly. Maybe not many people will use it.
>
> The other option is to set `unpack=true` on the artifact class and then walk the directory returned from `ArtifactResolver.resolve()` to find the files you need. That would require people to have the files on their local machine but makes it easier to run the test.

This is doable but I cannot guarantee there won't be duplicated file names.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2494643561

From weijun at openjdk.org  Wed Nov  5 14:32:51 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 5 Nov 2025 14:32:51 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v12]
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <Wn3NDKx1sKSMHpcNIH89bOnIfBXWAZHssCiXLvVa1Mc=.b70859b2-c525-41f2-abd4-eac92d61c0e2@github.com>

> Add support for ML-DSA signing of JAR files.
> 
> ~Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.~
> 
> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.

Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:

 - rename DataFecther to RepositoryFileReader
 - more comments for DataFetcher

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26563/files
  - new: https://git.openjdk.org/jdk/pull/26563/files/4a20af7b..0902384e

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

  Stats: 309 lines in 3 files changed: 151 ins; 144 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/26563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26563/head:pull/26563

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

From mullan at openjdk.org  Wed Nov  5 17:50:23 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 5 Nov 2025 17:50:23 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
In-Reply-To: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
Message-ID: <n9EWu15d7W_eVsHkCkT350i5tVZPIyA3XrjL6jxRVKc=.a801b517-06a4-46c1-a2d0-e813232505c1@github.com>

On Tue, 4 Nov 2025 16:38:49 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
>    - `SignatureBench.MLDSA` is 1.2x-2.2x faster
>    - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
> - AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
>   - `SignatureBench.MLDSA` is upto 5% faster, never slower
> 
> Note on intrinsic:
> - The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
> - Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2
> 
> Tests and benchmarks:
> - Added a fuzz test to ensure Java and intrinsic produces exactly same result
> - Added benchmark to measure the performance of intrinsic itself
> 
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"

Nice speedup. This improvement seems worthy of a release note.

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

PR Comment: https://git.openjdk.org/jdk/pull/28136#issuecomment-3492562302

From weijun at openjdk.org  Wed Nov  5 18:27:51 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 5 Nov 2025 18:27:51 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v46]
In-Reply-To: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
Message-ID: <aDHigKaUY6B5bxvRyT-yH5bfzDes3-F8eB7BMKtw7BY=.5ff87048-e7b4-411a-986b-42afb665d9b0@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> <img alt="image" src="https://github.com/user-attachments/assets/df3b454d-2161-4036-9930-c4f84d887b31" />

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:

 - merge
 - Merge branch 'master' into 8325448
 - Tony's comment
 - more key checks; some small spec change
 - Merge branch 'master' into 8325448
 - about transformation
 - cannot reset with withMethods
 - algorithm identifier
 - withMethods
 - duplicated "value" words
 - ... and 52 more: https://git.openjdk.org/jdk/compare/cf45e09c...b5112151

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

Changes: https://git.openjdk.org/jdk/pull/18411/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=45
  Stats: 2176 lines in 12 files changed: 1967 ins; 86 del; 123 mod
  Patch: https://git.openjdk.org/jdk/pull/18411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411

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

From duke at openjdk.org  Wed Nov  5 18:41:16 2025
From: duke at openjdk.org (duke)
Date: Wed, 5 Nov 2025 18:41:16 GMT
Subject: RFR: 8357880: Code formatting typo in
 Cipher.getMaxAllowedParameterSpec
In-Reply-To: <V74K8fkxqOWx-yD8zsJwrWDqr6arvPYirfPRyKustHU=.47822beb-c548-48a5-9e1f-2484ed56ebb4@github.com>
References: <V74K8fkxqOWx-yD8zsJwrWDqr6arvPYirfPRyKustHU=.47822beb-c548-48a5-9e1f-2484ed56ebb4@github.com>
Message-ID: <VBG0dGdivDQ-GYH6AVCs3eNg6LPn6SiI25sy_mZq6lw=.41eb441d-4d90-44f4-92b9-0a641352cfb7@github.com>

On Wed, 5 Nov 2025 09:50:09 GMT, Peyang <duke at openjdk.org> wrote:

> Fix JavaDoc typos in `Cipher` class: correct `{code ...}` to `{@code ...}` in the constructor and `getMaxAllowedParameterSpec()`

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

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

PR Comment: https://git.openjdk.org/jdk/pull/28145#issuecomment-3492760520

From duke at openjdk.org  Wed Nov  5 22:29:15 2025
From: duke at openjdk.org (Peyang)
Date: Wed, 5 Nov 2025 22:29:15 GMT
Subject: Integrated: 8357880: Code formatting typo in
 Cipher.getMaxAllowedParameterSpec
In-Reply-To: <V74K8fkxqOWx-yD8zsJwrWDqr6arvPYirfPRyKustHU=.47822beb-c548-48a5-9e1f-2484ed56ebb4@github.com>
References: <V74K8fkxqOWx-yD8zsJwrWDqr6arvPYirfPRyKustHU=.47822beb-c548-48a5-9e1f-2484ed56ebb4@github.com>
Message-ID: <LXu3zrdl1v60p1jIut7CfZzsDhKf21UePbEUI318BtM=.6ebdca4c-4031-48b6-84ec-b924a93871df@github.com>

On Wed, 5 Nov 2025 09:50:09 GMT, Peyang <duke at openjdk.org> wrote:

> Fix JavaDoc typos in `Cipher` class: correct `{code ...}` to `{@code ...}` in the constructor and `getMaxAllowedParameterSpec()`

This pull request has now been integrated.

Changeset: d5831ed8
Author:    Peyang <peyang at peya.tokyo>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5831ed866cb3d1cf2c77d7a3e535afc9e2b688b
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8357880: Code formatting typo in Cipher.getMaxAllowedParameterSpec

Reviewed-by: fandreuzzi, mullan

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

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

From liach at openjdk.org  Wed Nov  5 23:34:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Nov 2025 23:34:14 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v20]
In-Reply-To: <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
Message-ID: <qdoshJM6YkMk1XK055rk8NLEb_mw0INP_ylFKSMPx2Y=.c52d2295-74d3-4681-8c56-14207a47a62e@github.com>

On Fri, 24 Oct 2025 09:01:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework toString implementations

src/java.base/share/classes/java/lang/LazyConstant.java line 94:

> 92:  * lazy constant remains uninitialized.
> 93:  *
> 94:  * <h2 id="composition">Composing lazy constants</h2>

This section has some interesting usage, but I don't believe it should be included in the API specification. Behaviors described here can be derived from the formal specifications.

src/java.base/share/classes/java/lang/LazyConstant.java line 209:

> 207: 
> 208:     /**
> 209:      * {@return the contents of this lazy constant if initialized, otherwise,\

Suggestion:

     * {@return the contents of this lazy constant if initialized, otherwise,

src/java.base/share/classes/java/util/AbstractMap.java line 34:

> 32: 
> 33: import jdk.internal.vm.annotation.AOTSafeClassInitializer;
> 34: import jdk.internal.vm.annotation.Stable;

Suggestion:

src/java.base/share/classes/java/util/Currency.java line 146:

> 144:     private static ConcurrentMap<String, Currency> instances = new ConcurrentHashMap<>(7);
> 145:     private static final LazyConstant<HashSet<Currency>> available =
> 146:             LazyConstant.of(new Supplier<HashSet<Currency>>() {

Why can't we retain the method reference here? This is not used in early bootstrap.

src/java.base/share/classes/java/util/LazyCollections.java line 516:

> 514: 
> 515:         @ForceInline
> 516:         private void disposeOfMutex(long offset) {

I recommend removing this unused and otherwise confusing method.

src/java.base/share/classes/java/util/LazyCollections.java line 559:

> 557:     }
> 558: 
> 559:     public static <E> int lastIndexOf(List<LazyConstant<E>> list, Object o) {

This indexOf and lastIndexOf appear unused.

src/java.base/share/classes/java/util/Map.java line 1814:

> 1812:         final Set<K> keyCopies = Set.copyOf(keys);
> 1813:         Objects.requireNonNull(computingFunction);
> 1814:         if (keys instanceof EnumSet<?> && !keys.isEmpty()) {

I wonder if it's premature for us to optimize like this - for example, this would be wasteful if the key set contains one enum constant but there are 1000 enum constants in this enum.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496459406
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496468213
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496478562
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496479687
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496503928
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496514844
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2496516750

From darcy at openjdk.org  Thu Nov  6 05:02:15 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Nov 2025 05:02:15 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v20]
In-Reply-To: <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
Message-ID: <LbYfgV9Gms8dQZG--UOFnysoefCwXEDuQLHUpkToeMo=.d2d02520-bce0-44e2-ab93-fc48ed669f02@github.com>

On Fri, 24 Oct 2025 09:01:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework toString implementations

src/java.base/share/classes/java/lang/LazyConstant.java line 184:

> 182:  *          Use in static initializers may interact with class initialization order;
> 183:  *          cyclic initialization may result in initialization errors as described
> 184:  *          in {@jls 12.4} of <cite>The Java Language Specification</cite>.

Please use some text like "section" or "&sect;" in from of the `@jls` tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2497396558

From hchao at openjdk.org  Thu Nov  6 05:44:55 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 6 Nov 2025 05:44:55 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v7]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <VstfohxqvSRgw_5_X40H4AMODyS-6OGxpgwA_A2OKsk=.cd4f3f3c-8baa-4603-85bf-a4ccc1cf5845@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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Merge
 - Revert changes to UseStrongDHSizes test as ffdhe6144/8192 added back
 - Updated comment in ServerHello and hybrid to upper-case in NamedGroup
 - Fix typo in NamedGroup test
 - Call getProvider() in NamedGroup.java
 - Rename NAMED_GROUP_KEM from PQC to KEM
 - Updates with review comments
 - Updates with review comments
 - 8314323: TLS 1.3 Hybrid Key Exchange
 - Merge
 - ... and 1 more: https://git.openjdk.org/jdk/compare/bafb5554...55503c0d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/f98b5385..55503c0d

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

  Stats: 122618 lines in 2163 files changed: 71151 ins; 38964 del; 12503 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 mdonovan at openjdk.org  Thu Nov  6 14:27:46 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 6 Nov 2025 14:27:46 GMT
Subject: RFR: 8362894: PKCS12 KeyStore PBMAC1 interoperability testing
Message-ID: <vQ2xN_1fTfrUQKCDsrUDUhYOUc21Mpa_5Z9dvbRr9ZU=.e372c2e0-e7c4-4db4-a675-fa2a0c3625af@github.com>

With the integration of JDK-8343232, this PR updates the Keytool/OpenSSL interop test to include a test case using PBMAC1.

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

Commit messages:
 - 8362894: PKCS12 KeyStore PBMAC1 interoperability testing

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

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

From myankelevich at openjdk.org  Thu Nov  6 14:27:49 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 6 Nov 2025 14:27:49 GMT
Subject: RFR: 8362894: PKCS12 KeyStore PBMAC1 interoperability testing
In-Reply-To: <vQ2xN_1fTfrUQKCDsrUDUhYOUc21Mpa_5Z9dvbRr9ZU=.e372c2e0-e7c4-4db4-a675-fa2a0c3625af@github.com>
References: <vQ2xN_1fTfrUQKCDsrUDUhYOUc21Mpa_5Z9dvbRr9ZU=.e372c2e0-e7c4-4db4-a675-fa2a0c3625af@github.com>
Message-ID: <NH5vJ7KeonY3y1Qflv-HyJJiMi7toiX8SkJrg17pNCY=.52ae6ea5-1470-44da-af09-b70bfd9e7f18@github.com>

On Wed, 5 Nov 2025 12:43:25 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> With the integration of JDK-8343232, this PR updates the Keytool/OpenSSL interop test to include a test case using PBMAC1.

test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 142:

> 140:                 .shouldHaveExitValue(0);
> 141: 
> 142:         ProcessTools.executeCommand(opensslPath, "pkcs12", "-export", "-in",

nit: do you think it might be a good idea to bump the timeout by 10? As this command can take up to 10 seconds. Just to prevent future timeouts

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28150#discussion_r2499147790

From mullan at openjdk.org  Thu Nov  6 18:00:14 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 6 Nov 2025 18:00:14 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v13]
In-Reply-To: <xSFJKTO7f9E8RzpwWRuUZWL0MEBSZlAfL7XQLG9vXoQ=.0615c53c-f29c-442c-9b53-2f99f25fe80c@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <xSFJKTO7f9E8RzpwWRuUZWL0MEBSZlAfL7XQLG9vXoQ=.0615c53c-f29c-442c-9b53-2f99f25fe80c@github.com>
Message-ID: <DkEhdQATKCPu1MlInWMTwUAvYLZaYJ72GHqvpvFUTeA=.5c96f65d-58d7-4a73-bbb1-caefdca2a7e0@github.com>

On Fri, 31 Oct 2025 21:57:56 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request 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 25 additional commits since the last revision:
> 
>  - mistakes
>  - Merge branch 'master' into pem26
>  - minor doc updates, fix some bugs, PEM set to 26
>  - more docs, remove runtimeexception
>  - EKPI has a lot of @link's
>  - docs
>  - more doc updates and zeroing
>  - fix non-pbe
>  - doc updates, zeroing, fix unencrypted keypair encoding, exception mods
>  - updates
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/8eea12a3...0d95043c

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27147#pullrequestreview-3429697573

From mullan at openjdk.org  Thu Nov  6 19:34:08 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 6 Nov 2025 19:34:08 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v12]
In-Reply-To: <Wn3NDKx1sKSMHpcNIH89bOnIfBXWAZHssCiXLvVa1Mc=.b70859b2-c525-41f2-abd4-eac92d61c0e2@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <Wn3NDKx1sKSMHpcNIH89bOnIfBXWAZHssCiXLvVa1Mc=.b70859b2-c525-41f2-abd4-eac92d61c0e2@github.com>
Message-ID: <-RXMG3Ypwg2Nw7ouXXI4eVesqZqNBxnaFrw7GRGJbDA=.95ce3f1e-514c-4ad5-bc34-42ae96e8de8a@github.com>

On Wed, 5 Nov 2025 14:32:51 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add support for ML-DSA signing of JAR files.
>> 
>> ~Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.~
>> 
>> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.
>
> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename DataFecther to RepositoryFileReader
>  - more comments for DataFetcher

test/jdk/sun/security/pkcs/pkcs7/DigestConformance.java line 47:

> 45: import java.util.Map;
> 46: 
> 47: public class DigestConformance {

Maybe call this `MLDSADigestConformance` or are you thinking you will enhance it to support EdDSA, etc?

test/jdk/sun/security/provider/pqc/ML_DSA_CMS.java line 50:

> 48:         // See https://datatracker.ietf.org/doc/html/rfc9882#name-examples
> 49:         try (var cmsReader = RepositoryFileReader.of(CMS_ML_DSA.class,
> 50:                     "cms-ml-dsa-draft-ietf-lamps-cms-ml-dsa-07/");

Can we call this "RFC9882" instead?

test/jdk/sun/security/provider/pqc/ML_DSA_CMS.java line 52:

> 50:                     "cms-ml-dsa-draft-ietf-lamps-cms-ml-dsa-07/");
> 51:             var dsaReader = RepositoryFileReader.of(DILITHIUM_CERTIFICATES.class,
> 52:                     "dilithium-certificates-draft-ietf-lamps-dilithium-certificates-13/")) {

Similarly, can we call this "RFC9881"?

test/jdk/sun/security/tools/jarsigner/ML_DSA.java line 81:

> 79:                 jf.getInputStream(je).readAllBytes();
> 80:                 Asserts.assertEquals(1, je.getCertificates().length);
> 81:                 checkDigestAlgorithm(jf, signer, KnownOIDs.SHA_512);

So there is currently no way to specify a different digest algorithm?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2500494559
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2500459775
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2500464197
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2500534760

From mpowers at openjdk.org  Thu Nov  6 19:56:25 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 6 Nov 2025 19:56:25 GMT
Subject: RFR: 8371156: PBKDF2 default values should not be DER encoded
Message-ID: <FDgInl6vK5pt6NliKB0Yw87jnp3xFKdWZzYB7S6n2Yk=.7b016069-73d6-49e0-be45-d2b74af5e950@github.com>

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

HmacSHA1 is the DEFAULT for PBKDF2. Therefore, it should not be DER encoded.


PBKDF2-params ::= SEQUENCE {
     salt CHOICE {
         specified OCTET STRING,
         otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}}
    },
    iterationCount INTEGER (1..MAX),
    keyLength INTEGER (1..MAX) OPTIONAL,
    prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT algid-hmacWithSHA1
}

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

Commit messages:
 - IJ comment
 - first iteration

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

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

From mullan at openjdk.org  Thu Nov  6 20:20:07 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 6 Nov 2025 20:20:07 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v12]
In-Reply-To: <Wn3NDKx1sKSMHpcNIH89bOnIfBXWAZHssCiXLvVa1Mc=.b70859b2-c525-41f2-abd4-eac92d61c0e2@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <Wn3NDKx1sKSMHpcNIH89bOnIfBXWAZHssCiXLvVa1Mc=.b70859b2-c525-41f2-abd4-eac92d61c0e2@github.com>
Message-ID: <NAzERIzMuC8t47aUtvpF1MlZzII98PJVwY_FQfhMq14=.e3e38c9b-0b76-4fb3-8726-ff6df0d4cf6b@github.com>

On Wed, 5 Nov 2025 14:32:51 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add support for ML-DSA signing of JAR files.
>> 
>> ~Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.~
>> 
>> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.
>
> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename DataFecther to RepositoryFileReader
>  - more comments for DataFetcher

I think it would also be useful to add or extend an existing test and test that the ML-DSA algorithms are disabled if set in the `jdk.jar.disabledAlgorithms` security property.

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

PR Comment: https://git.openjdk.org/jdk/pull/26563#issuecomment-3499231991

From ascarpino at openjdk.org  Fri Nov  7 00:23:28 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 7 Nov 2025 00:23:28 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v14]
In-Reply-To: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
Message-ID: <JvUuxiTWVrHfwG5P5lMYoB-wdTyaBx19ZYbM08Ubsnc=.51945797-dcf6-499b-963d-e9b547f7f3a8@github.com>

> Hi
> 
> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
> 
> - Renamed the name of `PEMRecord` class to `PEM`.
> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
> 
> thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  remove PEMRecord import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27147/files
  - new: https://git.openjdk.org/jdk/pull/27147/files/0d95043c..5cba4d9e

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

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

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

From hchao at openjdk.org  Fri Nov  7 06:01:31 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 7 Nov 2025 06:01:31 GMT
Subject: RFR: 8371383: Test sun/security/tools/jarsigner/DefaultOptions.java
 failed due to CertificateNotYetValidException
Message-ID: <bjzOva7DVF2_u5kSfMtgFy1Pw_fJ33sMNch3KNgq0p8=.f6abfa5d-023a-472b-ab49-d32ae2968cf3@github.com>

The `DefaultOptions.java` test may fail as the current system time is before the signing certificate NotBefore time, when jarsigner tool validates it in `CertificateValidity.valid()`. Please review the fix in this test to avoid such intermittent timing problem. Thanks.

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

Commit messages:
 - 8371383: Test sun/security/tools/jarsigner/DefaultOptions.java failed due to CertificateNotYetValidException

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

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

From duke at openjdk.org  Fri Nov  7 08:09:33 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 7 Nov 2025 08:09:33 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule generation
Message-ID: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>

This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.

The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.

Thank you @jnimeh for catching the unnecessary byte mask!

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

Commit messages:
 - Fix tabs to whitespaces
 - 8371450: AES performance improvements for key schedule generation

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

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

From vyazici at openjdk.org  Fri Nov  7 08:19:13 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 7 Nov 2025 08:19:13 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v3]
In-Reply-To: <3MKlB8kYKmJ7ZLwmhrIRYdVV7URoXFjr_EOdAByB-FU=.c1e05ed0-10f6-4ccd-af55-418ea417114d@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
 <j-MQNksF9YCAKdt8M7qChZ8QIkPjxfkrjPHAAyIqLVU=.ed91ff66-7c6e-49cd-b4e5-73b1daf47e46@github.com>
 <3MKlB8kYKmJ7ZLwmhrIRYdVV7URoXFjr_EOdAByB-FU=.c1e05ed0-10f6-4ccd-af55-418ea417114d@github.com>
Message-ID: <5lFkd83GWOyxNKMFhlYafqWpv3Zlp1YixpHastNIPsE=.9d6113f5-fee1-49d8-8659-9b3acb49eb50@github.com>

On Wed, 5 Nov 2025 11:51:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Shorten `@deprecated` message
>
> Marked as reviewed by alanb (Reviewer).

@AlanBateman, @dfuch, @jaikiran, thanks so much for the reviews.

Tier 1-2 is clear on 50826c3e099 ? succeeding commits were simple JavaDoc updates, hence not issuing another CI run.

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

PR Comment: https://git.openjdk.org/jdk/pull/28129#issuecomment-3501218485

From vyazici at openjdk.org  Fri Nov  7 08:19:14 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 7 Nov 2025 08:19:14 GMT
Subject: Integrated: 8366577: Deprecate
 java.net.Socket::setPerformancePreferences
In-Reply-To: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
Message-ID: <WumKF45ABlN9Uq4lrv1xuv0KhH7-irfMWF0eDuFGjdA=.226348f1-392d-4ae0-a574-e8735fcb89ae@github.com>

On Tue, 4 Nov 2025 10:53:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
> 
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

This pull request has now been integrated.

Changeset: 866faa9d
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/866faa9d40ab336e4c4861a55edc4c91d8aa0c74
Stats:     14 lines in 4 files changed: 13 ins; 0 del; 1 mod

8366577: Deprecate java.net.Socket::setPerformancePreferences

Reviewed-by: dfuchs, alanb, jpai

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

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

From duke at openjdk.org  Fri Nov  7 10:42:02 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 7 Nov 2025 10:42:02 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation
In-Reply-To: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
Message-ID: <1K8M1GYvFvmBssknqrQryPA4kc5_AlOsmgYnMf9l2Gk=.da65851b-d899-44a9-af71-44a522ea8c81@github.com>

On Fri, 7 Nov 2025 07:53:37 GMT, Shawn M Emery <duke at openjdk.org> wrote:

> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
> 
> Thank you @jnimeh for catching the unnecessary byte mask!

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1017:

> 1015:                 | ((SBOX[(b1 & 0xF0) >> 4][b1 & 0x0F] & 0xFF) << 16)
> 1016:                 | ((SBOX[(b2 & 0xF0) >> 4][b2 & 0x0F] & 0xFF) << 8)
> 1017:                 | (SBOX[(word & 0xF0) >> 4][word & 0x0F] & 0xFF);

I think there is no need for any of these bytes. Every index can be computed as "(word >> offset) & 0x0F.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2502711179

From mdonovan at openjdk.org  Fri Nov  7 12:11:03 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 7 Nov 2025 12:11:03 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: <D8XWMpI3IFuOdGddY6CIyIv-awCICHbwd0AAt7vusKw=.4ad6a85b-4827-4499-984d-ed0a2cb7d746@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

Hello, I'm still looking for a reviewer/approval for this PR. Thanks!

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

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

From myankelevich at openjdk.org  Fri Nov  7 12:36:02 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 7 Nov 2025 12:36:02 GMT
Subject: RFR: 8371383: Test
 sun/security/tools/jarsigner/DefaultOptions.java failed due to
 CertificateNotYetValidException
In-Reply-To: <bjzOva7DVF2_u5kSfMtgFy1Pw_fJ33sMNch3KNgq0p8=.f6abfa5d-023a-472b-ab49-d32ae2968cf3@github.com>
References: <bjzOva7DVF2_u5kSfMtgFy1Pw_fJ33sMNch3KNgq0p8=.f6abfa5d-023a-472b-ab49-d32ae2968cf3@github.com>
Message-ID: <4w2pDH_eSwl59nPYQCECZQfU5V70DbT6O2DjWAvgv2s=.44eda89c-2f7d-455c-8192-1bd7cba08bd3@github.com>

On Fri, 7 Nov 2025 05:55:34 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> The `DefaultOptions.java` test may fail as the current system time is before the signing certificate NotBefore time, when jarsigner tool validates it in `CertificateValidity.valid()`. Please review the fix in this test to avoid such intermittent timing problem. Thanks.

Changes requested by myankelevich (Committer).

test/jdk/sun/security/tools/jarsigner/DefaultOptions.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8049834 8371383

Minor: This is a test issue, could you please remove the bug id from here, as it only tracks product ones?

test/jdk/sun/security/tools/jarsigner/DefaultOptions.java line 79:

> 77:         // Add delay to help the signing certificate?s NotBefore time has
> 78:         // passed and avoid CertificateNotYetValidException.
> 79:         Thread.sleep(5000);

I wonder if it wouldn't be cleaner to add ` -startdate -1M ` to the cert gen instead of sleeping in the test. similar to [this pr](https://github.com/openjdk/jdk/pull/23001).
 
What do you think?

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

PR Review: https://git.openjdk.org/jdk/pull/28186#pullrequestreview-3433610698
PR Review Comment: https://git.openjdk.org/jdk/pull/28186#discussion_r2503270363
PR Review Comment: https://git.openjdk.org/jdk/pull/28186#discussion_r2503293197

From weijun at openjdk.org  Fri Nov  7 14:33:06 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Nov 2025 14:33:06 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v12]
In-Reply-To: <-RXMG3Ypwg2Nw7ouXXI4eVesqZqNBxnaFrw7GRGJbDA=.95ce3f1e-514c-4ad5-bc34-42ae96e8de8a@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <Wn3NDKx1sKSMHpcNIH89bOnIfBXWAZHssCiXLvVa1Mc=.b70859b2-c525-41f2-abd4-eac92d61c0e2@github.com>
 <-RXMG3Ypwg2Nw7ouXXI4eVesqZqNBxnaFrw7GRGJbDA=.95ce3f1e-514c-4ad5-bc34-42ae96e8de8a@github.com>
Message-ID: <n5je9pBsPlWtJzy4lnClqjXXZckrsE_N6z_kNYUbg0k=.216b3f73-5b63-423a-8036-10bc0e44c2df@github.com>

On Thu, 6 Nov 2025 19:19:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - rename DataFecther to RepositoryFileReader
>>  - more comments for DataFetcher
>
> test/jdk/sun/security/pkcs/pkcs7/DigestConformance.java line 47:
> 
>> 45: import java.util.Map;
>> 46: 
>> 47: public class DigestConformance {
> 
> Maybe call this `MLDSADigestConformance` or are you thinking you will enhance it to support EdDSA, etc?

I'll rename it. No plan to add others at the moment.

> test/jdk/sun/security/provider/pqc/ML_DSA_CMS.java line 50:
> 
>> 48:         // See https://datatracker.ietf.org/doc/html/rfc9882#name-examples
>> 49:         try (var cmsReader = RepositoryFileReader.of(CMS_ML_DSA.class,
>> 50:                     "cms-ml-dsa-draft-ietf-lamps-cms-ml-dsa-07/");
> 
> Can we call this "RFC9882" instead?

That's the prefix used in the latest ZIP bundle on https://github.com/lamps-wg/cms-ml-dsa/tags. I'll add more comment.

> test/jdk/sun/security/provider/pqc/ML_DSA_CMS.java line 52:
> 
>> 50:                     "cms-ml-dsa-draft-ietf-lamps-cms-ml-dsa-07/");
>> 51:             var dsaReader = RepositoryFileReader.of(DILITHIUM_CERTIFICATES.class,
>> 52:                     "dilithium-certificates-draft-ietf-lamps-dilithium-certificates-13/")) {
> 
> Similarly, can we call this "RFC9881"?

Same.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2503843190
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2503833426
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2503834109

From weijun at openjdk.org  Fri Nov  7 14:39:04 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Nov 2025 14:39:04 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v12]
In-Reply-To: <-RXMG3Ypwg2Nw7ouXXI4eVesqZqNBxnaFrw7GRGJbDA=.95ce3f1e-514c-4ad5-bc34-42ae96e8de8a@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <Wn3NDKx1sKSMHpcNIH89bOnIfBXWAZHssCiXLvVa1Mc=.b70859b2-c525-41f2-abd4-eac92d61c0e2@github.com>
 <-RXMG3Ypwg2Nw7ouXXI4eVesqZqNBxnaFrw7GRGJbDA=.95ce3f1e-514c-4ad5-bc34-42ae96e8de8a@github.com>
Message-ID: <rzWWovwKaUAwoydR46jZ_yL2vInX5K1duREF1K_zHy8=.9443216f-a4dc-4348-9d34-732931f7eac6@github.com>

On Thu, 6 Nov 2025 19:31:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - rename DataFecther to RepositoryFileReader
>>  - more comments for DataFetcher
>
> test/jdk/sun/security/tools/jarsigner/ML_DSA.java line 81:
> 
>> 79:                 jf.getInputStream(je).readAllBytes();
>> 80:                 Asserts.assertEquals(1, je.getCertificates().length);
>> 81:                 checkDigestAlgorithm(jf, signer, KnownOIDs.SHA_512);
> 
> So there is currently no way to specify a different digest algorithm?

No. As you can see, ML-DSA is the first algorithm that there are more than one digest algorithm can pass the `algorithmsConformanceCheck` check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2503879708

From duke at openjdk.org  Fri Nov  7 14:46:58 2025
From: duke at openjdk.org (Neha Joshi)
Date: Fri, 7 Nov 2025 14:46:58 GMT
Subject: RFR: 8334928: Test sun/security/ssl/SSLSocketImpl/ReuseAddr.java
 failed: java.net.BindException: Address already in use
Message-ID: <7cMnQ_0i8xFpK7tvRPxATOg7YGFW65K-ifbDnmPu7BA=.e0773694-2555-444b-ad64-24ae13d4038f@github.com>

This tests is not fixable and reproducible. The only thing we can do in order to minimize intermittent failures is increasing the retry count and adding a thread.sleep() before retrying.


Old PR link for the reference :- https://github.com/openjdk/jdk/pull/19358

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

Commit messages:
 - JDK-8334928 : Increase retry count and added loggers.

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

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

From myankelevich at openjdk.org  Fri Nov  7 14:51:12 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 7 Nov 2025 14:51:12 GMT
Subject: RFR: 8334928: Test sun/security/ssl/SSLSocketImpl/ReuseAddr.java
 failed: java.net.BindException: Address already in use
In-Reply-To: <7cMnQ_0i8xFpK7tvRPxATOg7YGFW65K-ifbDnmPu7BA=.e0773694-2555-444b-ad64-24ae13d4038f@github.com>
References: <7cMnQ_0i8xFpK7tvRPxATOg7YGFW65K-ifbDnmPu7BA=.e0773694-2555-444b-ad64-24ae13d4038f@github.com>
Message-ID: <TuTt8q94CgXx-GBvL0D_V02CLkfWKVgF78WML4OFNls=.e57204e4-0bbc-4bce-8f81-9c111cbbd3a3@github.com>

On Fri, 7 Nov 2025 14:39:14 GMT, Neha Joshi <duke at openjdk.org> wrote:

> This tests is not fixable and reproducible. The only thing we can do in order to minimize intermittent failures is increasing the retry count and adding a thread.sleep() before retrying.
> 
> 
> Old PR link for the reference :- https://github.com/openjdk/jdk/pull/19358

Looks good to me

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

PR Comment: https://git.openjdk.org/jdk/pull/28198#issuecomment-3502993936

From hchao at openjdk.org  Fri Nov  7 15:14:34 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 7 Nov 2025 15:14:34 GMT
Subject: RFR: 8371383: Test
 sun/security/tools/jarsigner/DefaultOptions.java failed due to
 CertificateNotYetValidException [v2]
In-Reply-To: <bjzOva7DVF2_u5kSfMtgFy1Pw_fJ33sMNch3KNgq0p8=.f6abfa5d-023a-472b-ab49-d32ae2968cf3@github.com>
References: <bjzOva7DVF2_u5kSfMtgFy1Pw_fJ33sMNch3KNgq0p8=.f6abfa5d-023a-472b-ab49-d32ae2968cf3@github.com>
Message-ID: <YtsuCvZB-UD5q3X3l5ttONj81fCkOvPykPHptODyBZM=.0fc346d9-5993-4af7-a4f1-a96327f0bdb6@github.com>

> The `DefaultOptions.java` test may fail as the current system time is before the signing certificate NotBefore time, when jarsigner tool validates it in `CertificateValidity.valid()`. Please review the fix in this test to avoid such intermittent timing problem. Thanks.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Update with Mikhail's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28186/files
  - new: https://git.openjdk.org/jdk/pull/28186/files/606341e3..55c83609

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

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

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

From hchao at openjdk.org  Fri Nov  7 15:14:36 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 7 Nov 2025 15:14:36 GMT
Subject: RFR: 8371383: Test
 sun/security/tools/jarsigner/DefaultOptions.java failed due to
 CertificateNotYetValidException [v2]
In-Reply-To: <4w2pDH_eSwl59nPYQCECZQfU5V70DbT6O2DjWAvgv2s=.44eda89c-2f7d-455c-8192-1bd7cba08bd3@github.com>
References: <bjzOva7DVF2_u5kSfMtgFy1Pw_fJ33sMNch3KNgq0p8=.f6abfa5d-023a-472b-ab49-d32ae2968cf3@github.com>
 <4w2pDH_eSwl59nPYQCECZQfU5V70DbT6O2DjWAvgv2s=.44eda89c-2f7d-455c-8192-1bd7cba08bd3@github.com>
Message-ID: <mzntgG_RJGJn_pZHe4J5IRq2ho6TPaI9TCbLYiJX-tY=.22a1b04c-7097-48da-a13e-229b8fc8ef2d@github.com>

On Fri, 7 Nov 2025 12:28:21 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update with Mikhail's comments
>
> test/jdk/sun/security/tools/jarsigner/DefaultOptions.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 8049834 8371383
> 
> Minor: This is a test issue, could you please remove the bug id from here, as it only tracks product ones?

Removed the bug id.

> test/jdk/sun/security/tools/jarsigner/DefaultOptions.java line 79:
> 
>> 77:         // Add delay to help the signing certificate?s NotBefore time has
>> 78:         // passed and avoid CertificateNotYetValidException.
>> 79:         Thread.sleep(5000);
> 
> I wonder if it wouldn't be cleaner to add ` -startdate -1M ` to the cert gen instead of sleeping in the test. similar to [this pr](https://github.com/openjdk/jdk/pull/23001).
>  
> What do you think?

Updated code as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28186#discussion_r2504065098
PR Review Comment: https://git.openjdk.org/jdk/pull/28186#discussion_r2504068528

From weijun at openjdk.org  Fri Nov  7 16:06:43 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Nov 2025 16:06:43 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v13]
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <vD0edREXp8M9k8K5HNJQ-mDhspoa5VCemhKZhyuYGyk=.f7546249-1d6a-4dba-8171-a181941595e9@github.com>

> Add support for ML-DSA signing of JAR files.
> 
> ~Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.~
> 
> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.

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

  a rename, a comment, and a new test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26563/files
  - new: https://git.openjdk.org/jdk/pull/26563/files/0902384e..7e65174d

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

  Stats: 72 lines in 3 files changed: 65 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26563/head:pull/26563

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

From mullan at openjdk.org  Fri Nov  7 16:37:13 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 7 Nov 2025 16:37:13 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v8]
In-Reply-To: <0iLyQFtldK7kJHvRpdXwcMXoNrjWKfFCJfo_a5BhJpM=.290016fd-53f4-4303-b665-8f31e4e19cd2@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <0iLyQFtldK7kJHvRpdXwcMXoNrjWKfFCJfo_a5BhJpM=.290016fd-53f4-4303-b665-8f31e4e19cd2@github.com>
Message-ID: <RqBLdkwG_qLbJIuf-vuLasv85aavUABXFatlQ-7BwSM=.d66b0efb-703b-47e0-a25c-97a5289a1fd1@github.com>

On Thu, 30 Oct 2025 23:07:23 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this is a proposal to fix 8352728.
>> 
>> The main idea is 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 rationale behind this decision is the following:
>> 
>> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`.
>> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`.
>> 
>> #### Windows Case
>> 
>> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf:
>> 
>> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`:
>>     * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473")
>>     * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288")
>>     * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop)
>>     * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/ja...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Detect cyclic includes with Files::isSameFile
>   
>   checkCyclicInclude() is invoked after we successfully get an InputStream
>   for the path to avoid skipping the same IOException several times inside
>   checkCyclicInclude() if the path doesn't exist.
>   
>   Also, perform symlinks resolution only in the following cases:
>    ? When we need to resolve a relative include
>    ? For clarity to the user in logging messages
>    ? For clarity to the user in exception messages
>   
>   In the first case, the resolution is a requirement, in the last two
>   cases it is a nice-to-have. But given the last two are exceptional
>   cases anyway, we let any resolution error bubble up.

src/java.base/share/classes/java/security/Security.java line 286:

> 284:                     if (Files.isSameFile(path, activePath)) {
> 285:                         throw new InternalError(
> 286:                                 "Cyclic include of '" + resolve(path) + "'");

Why try to resolve the path for an exception message? If that causes an exception an `InternalError` will be thrown and this error message will be lost, making it harder to debug.

src/java.base/share/classes/java/security/Security.java line 288:

> 286:                                 "Cyclic include of '" + resolve(path) + "'");
> 287:                     }
> 288:                 } catch (IOException ignore) {}

Not sure you want to ignore this - seems better to let this propagate and be thrown as an `InternalError`.

src/java.base/share/classes/java/security/Security.java line 295:

> 293:                 throws IOException {
> 294:             boolean isRegularFile = Files.isRegularFile(path);
> 295:             if (!isRegularFile && Files.isDirectory(path)) {

Can a directory ever be a regular file? If not, you don't need the `!isRegularFile` check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2504468308
PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2504448064
PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2504402772

From ascarpino at openjdk.org  Fri Nov  7 17:26:53 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 7 Nov 2025 17:26:53 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v15]
In-Reply-To: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
Message-ID: <d3MSuq-IIFMuc5LmpCXKNt7e51pPaxowq187BnkRVQo=.b359e6b4-5023-48ea-8100-89e74370b48b@github.com>

> Hi
> 
> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
> 
> - Renamed the name of `PEMRecord` class to `PEM`.
> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
> 
> thanks
> 
> Tony

Anthony Scarpino has updated the pull request 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 27 additional commits since the last revision:

 - Merge branch 'master' into pem26
 - remove PEMRecord import
 - mistakes
 - Merge branch 'master' into pem26
 - minor doc updates, fix some bugs, PEM set to 26
 - more docs, remove runtimeexception
 - EKPI has a lot of @link's
 - docs
 - more doc updates and zeroing
 - fix non-pbe
 - ... and 17 more: https://git.openjdk.org/jdk/compare/70ba91ed...2ee3e7a4

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27147/files
  - new: https://git.openjdk.org/jdk/pull/27147/files/5cba4d9e..2ee3e7a4

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

  Stats: 43834 lines in 872 files changed: 26634 ins; 12871 del; 4329 mod
  Patch: https://git.openjdk.org/jdk/pull/27147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27147/head:pull/27147

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

From jnimeh at openjdk.org  Fri Nov  7 17:30:08 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 7 Nov 2025 17:30:08 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation
In-Reply-To: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
Message-ID: <nlVAp9HzECZytsa9XJoK-InhksKafkHV71z5INj7A6c=.fc21930a-ac64-4910-858c-f7ae7e3cc607@github.com>

On Fri, 7 Nov 2025 07:53:37 GMT, Shawn M Emery <duke at openjdk.org> wrote:

> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
> 
> Thank you @jnimeh for catching the unnecessary byte mask!

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 986:

> 984:             int idx = kLen - widx;
> 985: 
> 986:             dw[idx] = TMI0[w[widx] >>> 24] ^ TMI1[(w[widx] >> 16) & 0xFF]

Do you think there would be any benefit to putting w[widx] through w[widx+3] on local int variables?  In some cases I've seen where that increases register pressure and can lead to some perf benefits.  I'm not sure if this is one of those cases but it seems like you'd only need to reference memory once instead of 4 times per assignment.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1011:

> 1009:      */
> 1010:     private static int subWord(int word) {
> 1011:         byte b0 = (byte) (word >>> 24);

Nits (unrelated to this block of code, but I can't put comments on the lines directly since they're not part of the modified code):

- Lines 37-43: I think you could do an `@link` annotation with <a href></a> surrounding the links.
- Lines 1004-1005: Looks like a bit of comment rot, I think you just need an `@param` for `word`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2504680092
PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2504700496

From abarashev at openjdk.org  Fri Nov  7 17:31:09 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 7 Nov 2025 17:31:09 GMT
Subject: RFR: 8261513: Various BasicConstraintsExtension issues [v4]
In-Reply-To: <jBqNWV8GlR79k1tpgE4HKatO9E7heoMcAHxqA945ZHI=.8fbf974d-1c2a-434d-81d2-2a57691c6bef@github.com>
References: <_-E8euMT24qWQQJBRbNusSF_tHiDCiYdWzqlVccO2BA=.d5f20c54-1178-489f-9eac-75bbbc381791@github.com>
 <jBqNWV8GlR79k1tpgE4HKatO9E7heoMcAHxqA945ZHI=.8fbf974d-1c2a-434d-81d2-2a57691c6bef@github.com>
Message-ID: <so4NAi3MsbLkKj0kOLW463619MLBFgaG_0DkPfqYIVk=.1cdcb002-4baa-46d2-969b-9291c74a4d8c@github.com>

On Fri, 21 Feb 2025 16:40:08 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> 8261513: Various BasicConstraintsExtension issues
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed toString wording, no longer set critical to ca

src/java.base/share/classes/sun/security/x509/BasicConstraintsExtension.java line 196:

> 194: 
> 195:     public int getPathLen() {
> 196:          return (pathLen < 0) ? Integer.MAX_VALUE : Integer.valueOf(pathLen);

Why are we converting `pathLen` to `Integer` when the return type is `int`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20224#discussion_r2504710264

From abarashev at openjdk.org  Fri Nov  7 17:38:09 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 7 Nov 2025 17:38:09 GMT
Subject: RFR: 8261513: Various BasicConstraintsExtension issues [v4]
In-Reply-To: <jBqNWV8GlR79k1tpgE4HKatO9E7heoMcAHxqA945ZHI=.8fbf974d-1c2a-434d-81d2-2a57691c6bef@github.com>
References: <_-E8euMT24qWQQJBRbNusSF_tHiDCiYdWzqlVccO2BA=.d5f20c54-1178-489f-9eac-75bbbc381791@github.com>
 <jBqNWV8GlR79k1tpgE4HKatO9E7heoMcAHxqA945ZHI=.8fbf974d-1c2a-434d-81d2-2a57691c6bef@github.com>
Message-ID: <07HXw2zwYOcT-DjZGILF1krxErk-iDmwQ4vWbSiRFuI=.ca4e81d9-5eb5-4f58-a28d-cc3cc1a66953@github.com>

On Fri, 21 Feb 2025 16:40:08 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> 8261513: Various BasicConstraintsExtension issues
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed toString wording, no longer set critical to ca

src/java.base/share/classes/sun/security/x509/BasicConstraintsExtension.java line 1:

> 1: /*

Why don't we have a unit test for these changes?

src/java.base/share/classes/sun/security/x509/BasicConstraintsExtension.java line 166:

> 164:      public String toString() {
> 165:          String pathLenAsString;
> 166:          if (pathLen < 0 || pathLen == Integer.MAX_VALUE) {

What's the practical difference between `-1` and `Integer.MAX_VALUE`? Should we set the default value of `pathlen` to `Integer.MAX_VALUE` to simplify things?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20224#discussion_r2504740883
PR Review Comment: https://git.openjdk.org/jdk/pull/20224#discussion_r2504738436

From weijun at openjdk.org  Fri Nov  7 17:47:15 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Nov 2025 17:47:15 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v15]
In-Reply-To: <d3MSuq-IIFMuc5LmpCXKNt7e51pPaxowq187BnkRVQo=.b359e6b4-5023-48ea-8100-89e74370b48b@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <d3MSuq-IIFMuc5LmpCXKNt7e51pPaxowq187BnkRVQo=.b359e6b4-5023-48ea-8100-89e74370b48b@github.com>
Message-ID: <gt3ITkXN---RhU1FPhd4zSYJAC-65NnTnQqFbIJRtx0=.a8f5280d-c341-4e80-a4a9-6e526df4185f@github.com>

On Fri, 7 Nov 2025 17:26:53 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request 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 27 additional commits since the last revision:
> 
>  - Merge branch 'master' into pem26
>  - remove PEMRecord import
>  - mistakes
>  - Merge branch 'master' into pem26
>  - minor doc updates, fix some bugs, PEM set to 26
>  - more docs, remove runtimeexception
>  - EKPI has a lot of @link's
>  - docs
>  - more doc updates and zeroing
>  - fix non-pbe
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/0b80a3bd...2ee3e7a4

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27147#pullrequestreview-3435437252

From ascarpino at openjdk.org  Fri Nov  7 19:58:14 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 7 Nov 2025 19:58:14 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v46]
In-Reply-To: <aDHigKaUY6B5bxvRyT-yH5bfzDes3-F8eB7BMKtw7BY=.5ff87048-e7b4-411a-986b-42afb665d9b0@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <aDHigKaUY6B5bxvRyT-yH5bfzDes3-F8eB7BMKtw7BY=.5ff87048-e7b4-411a-986b-42afb665d9b0@github.com>
Message-ID: <lzWuHEbdJSRoRciwVTSqQOo7D8KNPcGsMevvH6XjOsA=.9952ac27-1196-4c51-9ea6-25fbd03a7669@github.com>

On Wed, 5 Nov 2025 18:27:51 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> <img alt="image" src="https://github.com/user-attachments/assets/df3b454d-2161-4036-9930-c4f84d887b31" />
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:
> 
>  - merge
>  - Merge branch 'master' into 8325448
>  - Tony's comment
>  - more key checks; some small spec change
>  - Merge branch 'master' into 8325448
>  - about transformation
>  - cannot reset with withMethods
>  - algorithm identifier
>  - withMethods
>  - duplicated "value" words
>  - ... and 52 more: https://git.openjdk.org/jdk/compare/cf45e09c...b5112151

src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 137:

> 135:             throws InvalidKeyException, InvalidAlgorithmParameterException {
> 136:         impl = new Impl(opmode);
> 137:         if (!(key instanceof AsymmetricKey ak)) {

Is a null check needed for `key` and `params`?  It appears Cipher leaves that to the SPI to accept or reject.

src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 318:

> 316:             }
> 317: 
> 318:             SecretKey ExportKey(String algorithm, byte[] exporter_context, int L) {

Why are the methods in this class capitalized?

src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 540:

> 538:                 // thw builder are just byte arrays. Any KDF impl can handle this.
> 539:                 var kdf = KDF.getInstance(kdfAlg);
> 540:                 var key_schedule_context = concat(new byte[]{(byte) mode},

Is `key_sechedule_context` worth zero'ing?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2495870196
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2496532422
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2496764265

From mpowers at openjdk.org  Fri Nov  7 20:04:06 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 7 Nov 2025 20:04:06 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v13]
In-Reply-To: <vD0edREXp8M9k8K5HNJQ-mDhspoa5VCemhKZhyuYGyk=.f7546249-1d6a-4dba-8171-a181941595e9@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <vD0edREXp8M9k8K5HNJQ-mDhspoa5VCemhKZhyuYGyk=.f7546249-1d6a-4dba-8171-a181941595e9@github.com>
Message-ID: <MPwkrc5oxh-ClNVkr_O5SkrFCLHGSSC23AO-Pc2U57Q=.fa5d5283-2226-4d3d-9c55-5c5240e96959@github.com>

On Fri, 7 Nov 2025 16:06:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add support for ML-DSA signing of JAR files.
>> 
>> ~Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.~
>> 
>> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   a rename, a comment, and a new test case

src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 540:

> 538:      * This verifies a given SignerInfo.
> 539:      *
> 540:      * @param info the signer information.

I don't believe the period is necessary.

src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 544:

> 542:      * @param cert certificate used to verify; find one inside the block if null
> 543:      *
> 544:      * @exception NoSuchAlgorithmException on unrecognized algorithms.

Shouldn't this be `@throws`? `@exception` is the old tag name.

test/jdk/sun/security/tools/jarsigner/ML_DSA.java line 70:

> 68:             prepare();
> 69:             testAPI();
> 70:             testTool(); // call this last, it modified a.jar.

s/modified/modifies/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2505007343
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2505015654
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2505271711

From mullan at openjdk.org  Fri Nov  7 20:22:06 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 7 Nov 2025 20:22:06 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v13]
In-Reply-To: <vD0edREXp8M9k8K5HNJQ-mDhspoa5VCemhKZhyuYGyk=.f7546249-1d6a-4dba-8171-a181941595e9@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <vD0edREXp8M9k8K5HNJQ-mDhspoa5VCemhKZhyuYGyk=.f7546249-1d6a-4dba-8171-a181941595e9@github.com>
Message-ID: <q3FZk1GEXbnjLoN-nX9-i18oxVZ8UCKZPlYqPLH8tzw=.3685a334-4f9d-4e32-89f8-a5357de17f4f@github.com>

On Fri, 7 Nov 2025 16:06:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add support for ML-DSA signing of JAR files.
>> 
>> ~Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.~
>> 
>> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   a rename, a comment, and a new test case

One minor comment, otherwise looks good.

test/jdk/sun/security/provider/pqc/ML_DSA_CMS.java line 52:

> 50:         //   https://github.com/lamps-wg/cms-ml-dsa/releases/tag/draft-ietf-lamps-cms-ml-dsa-07
> 51:         //   https://github.com/lamps-wg/dilithium-certificates/releases/tag/draft-ietf-lamps-dilithium-certificates-13
> 52:         // Although the release tags include "draft", these values are the same as those in the final RFC 9882.

and RFC 9881.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26563#pullrequestreview-3436167538
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2505331629

From hchao at openjdk.org  Fri Nov  7 22:17:28 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 7 Nov 2025 22:17:28 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v8]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <5ctkq7RR5dwJ5UK_Y3Er_Iu83NT0GICNKLsYCvGcubw=.5f7e0c72-80eb-4df9-a04b-53249be103e1@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 incrementally with five additional commits since the last revision:

 - Remove bugid from FipsModeTLS.java test
 - Define NamedParameterSpec for hybrid groups and update with Xuelei's comments
 - Define NamedParameterSpec for hybrid groups in Hybrid.java
 - Revert changes to NamedParameterSpec due to not expose hybrid NamedParameterSpecs
 - Revert changes to TestNamedParameterSpec due to not expose hybrid NamedParameterSpecs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/55503c0d..3a14b88d

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

  Stats: 88 lines in 5 files changed: 38 ins; 35 del; 15 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 hchao at openjdk.org  Fri Nov  7 22:17:30 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 7 Nov 2025 22:17:30 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <rnvj8T0dfhB25JE3I9IBG2QAGxfpnqXRmkCCHkBMaZk=.d397a41b-d807-4dcf-8ffe-5d2318633aff@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
 <rnvj8T0dfhB25JE3I9IBG2QAGxfpnqXRmkCCHkBMaZk=.d397a41b-d807-4dcf-8ffe-5d2318633aff@github.com>
Message-ID: <6rDDcakVjSInFYHmfmDmu697jiO2oQ_N9A4dP2kLhKA=.dc8040d6-49ae-4a83-bf90-6c3e91dbb231@github.com>

On Wed, 15 Oct 2025 14:25:50 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert changes to UseStrongDHSizes test as ffdhe6144/8192 added back
>>  - Updated comment in ServerHello and hybrid to upper-case in NamedGroup
>
> src/java.base/share/classes/java/security/spec/NamedParameterSpec.java line 141:
> 
>> 139:      * @since 26
>> 140:      */
>> 141:     public static final NamedParameterSpec SecP384r1MLKEM1024
> 
> Nit: Let's make these all upper-case as well to keep things consistent across files.

We don?t need to make the `NamedParameterSpec` instances for hybrid named groups public, as they do not need to be exposed through the public API. So change is made to deine them in `Hybrid.java` now, and to keep all hybrid-related constants in one place. Their names are written in all uppercase: `X25519_MLKEM768`, `SECP256R1_MLKEM768`, and `SECP384R1_MLKEM1024`. We use a two-part naming style (for left and right algorithm).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2505710074

From hchao at openjdk.org  Fri Nov  7 22:17:31 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 7 Nov 2025 22:17:31 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <mp9gUW-8y8ptv42yDrYC8npMLK9B8pL9H4T50QyL6aQ=.2c15ba44-e8a3-40a2-85c2-2251fe657729@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
 <mp9gUW-8y8ptv42yDrYC8npMLK9B8pL9H4T50QyL6aQ=.2c15ba44-e8a3-40a2-85c2-2251fe657729@github.com>
Message-ID: <Uf5MR5kJXtfGnlKI85q03QRnUXuWcxElVmqyiIPQDwU=.4f463fc7-b7f7-47b2-a0c9-1cfbfd7f3d1c@github.com>

On Mon, 27 Oct 2025 02:40:39 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert changes to UseStrongDHSizes test as ffdhe6144/8192 added back
>>  - Updated comment in ServerHello and hybrid to upper-case in NamedGroup
>
> src/java.base/share/classes/sun/security/util/Hybrid.java line 230:
> 
>> 228:             }
>> 229: 
>> 230:             throw new InvalidKeySpecException(keySpec.toString());
> 
> Please check null keySpec, and  `throw new InvalidKeySpecException("keySpec must not be null")`.
> 
> For non-null keySpec, I may use:
> `throw new InvalidKeySpecException(keySpec.getClass().getName() + " not supported.");
> `

Added null `keySpec` check, and updated `InvalidKeySpecException` message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2505711695

From hchao at openjdk.org  Fri Nov  7 22:29:16 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 7 Nov 2025 22:29:16 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <YWEzKsmEJUiMUfcrGBXJth-Nm7SwflkX7GOLrERFzjw=.e5347676-95ce-4ce1-ba10-6f58c22ecf04@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
 <YWEzKsmEJUiMUfcrGBXJth-Nm7SwflkX7GOLrERFzjw=.e5347676-95ce-4ce1-ba10-6f58c22ecf04@github.com>
Message-ID: <o6_D2oPVf5ekJoCJNwZzJanQ-vyHtEpVa6AJPO1DEc8=.20cc1aca-5ebf-4978-858c-32122f3a3417@github.com>

On Mon, 27 Oct 2025 04:16:03 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert changes to UseStrongDHSizes test as ffdhe6144/8192 added back
>>  - Updated comment in ServerHello and hybrid to upper-case in NamedGroup
>
> src/java.base/share/classes/sun/security/util/Hybrid.java line 134:
> 
>> 132:                 right.initialize(rightSpec, random);
>> 133:                 initialized = true;
>> 134:             } catch (Exception e) {
> 
> It may be nice if not wrap InvalidParameterException twice.

Yes, updated the code.

> src/java.base/share/classes/sun/security/util/Hybrid.java line 149:
> 
>> 147:                     throw new ProviderException(e);
>> 148:                 }
>> 149:             }
> 
> The initialization block could be saved if call initialize in the constructor.  See sun/security/ec/ECKeyPairGenerator.java

Moved it to the `KeyPairGeneratorImpl` constructor.

> src/java.base/share/classes/sun/security/util/Hybrid.java line 178:
> 
>> 176:                 throws InvalidKeySpecException {
>> 177:             if (keySpec instanceof RawKeySpec rks) {
>> 178:                 byte[] key = rks.getKeyArr();
> 
> null check on key may be missed.  If the API expose to public in the future, the key length checking may be good before Arrays.copyOfRange.

Good catch. Added key length checking.

> test/jdk/java/security/spec/TestNamedParameterSpec.java line 44:
> 
>> 42:         "ML_DSA_44", "ML_DSA_65", "ML_DSA_87",
>> 43:         "ML_KEM_512", "ML_KEM_768", "ML_KEM_1024",
>> 44:         "X25519MLKEM768", "SecP256r1MLKEM768", "SecP384r1MLKEM1024",
> 
> Does it sound like an option to use the similar naming style like "ML_KEM_512" for the new names?  for example, X25519MLKEM768 -> X25519_ML_KEM_768

We don't need to change `TestNamedParameterSpec.java` test now as the `NamedParameterSpec` instances for hybrid named groups are defined in `Hybrid.java` as internal constants. We use a "two-part" naming style (left and right algorithm), such as `X25519_MLKEM768`. It seems cleaner and more readable than breaking it into multiple parts with additional underscores.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2505741676
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2505745109
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2505738721
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2505735771

From hchao at openjdk.org  Fri Nov  7 22:29:17 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 7 Nov 2025 22:29:17 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <w4viPpBniC6pmXxhTPTKGTu5bJNgyOyECe_yRNiqOEI=.8e0eb096-f5ba-494b-84f1-0313efe466b8@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
 <w4viPpBniC6pmXxhTPTKGTu5bJNgyOyECe_yRNiqOEI=.8e0eb096-f5ba-494b-84f1-0313efe466b8@github.com>
Message-ID: <3SrYvzex1v3qhj3zBZHS_TPKEH7A5JCzD02-jsk9_ds=.9ddb251d-9ed1-4198-b356-1878f9ade104@github.com>

On Thu, 30 Oct 2025 15:10:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert changes to UseStrongDHSizes test as ffdhe6144/8192 added back
>>  - Updated comment in ServerHello and hybrid to upper-case in NamedGroup
>
> test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java line 27:
> 
>> 25: /*
>> 26:  * @test
>> 27:  * @bug 8029661 8325164 8368073 8368514 8368520 8314323
> 
> This isn't specifically testing Hybrid Key Exchange, so I don't think the bugid should be added.

Removed the bugid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2505745755

From weijun at openjdk.org  Fri Nov  7 22:37:05 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Nov 2025 22:37:05 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v13]
In-Reply-To: <MPwkrc5oxh-ClNVkr_O5SkrFCLHGSSC23AO-Pc2U57Q=.fa5d5283-2226-4d3d-9c55-5c5240e96959@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <vD0edREXp8M9k8K5HNJQ-mDhspoa5VCemhKZhyuYGyk=.f7546249-1d6a-4dba-8171-a181941595e9@github.com>
 <MPwkrc5oxh-ClNVkr_O5SkrFCLHGSSC23AO-Pc2U57Q=.fa5d5283-2226-4d3d-9c55-5c5240e96959@github.com>
Message-ID: <bs4zkD2yrlYXmue3BRJtSicWi-23Tsp1RyaitIg7hko=.a0122863-db4a-4f8a-8649-a6f67a38d7a8@github.com>

On Fri, 7 Nov 2025 18:52:38 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   a rename, a comment, and a new test case
>
> src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 540:
> 
>> 538:      * This verifies a given SignerInfo.
>> 539:      *
>> 540:      * @param info the signer information.
> 
> I don't believe the period is necessary.

Correct. There are too many such issues in this file, and I'd rather not touch any of them. After all, this is not a public API.

> src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 544:
> 
>> 542:      * @param cert certificate used to verify; find one inside the block if null
>> 543:      *
>> 544:      * @exception NoSuchAlgorithmException on unrecognized algorithms.
> 
> Shouldn't this be `@throws`? `@exception` is the old tag name.

Same as above.

> test/jdk/sun/security/tools/jarsigner/ML_DSA.java line 70:
> 
>> 68:             prepare();
>> 69:             testAPI();
>> 70:             testTool(); // call this last, it modified a.jar.
> 
> s/modified/modifies/

Will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2505753853
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2505754119
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2505754644

From weijun at openjdk.org  Fri Nov  7 22:37:08 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Nov 2025 22:37:08 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v13]
In-Reply-To: <q3FZk1GEXbnjLoN-nX9-i18oxVZ8UCKZPlYqPLH8tzw=.3685a334-4f9d-4e32-89f8-a5357de17f4f@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <vD0edREXp8M9k8K5HNJQ-mDhspoa5VCemhKZhyuYGyk=.f7546249-1d6a-4dba-8171-a181941595e9@github.com>
 <q3FZk1GEXbnjLoN-nX9-i18oxVZ8UCKZPlYqPLH8tzw=.3685a334-4f9d-4e32-89f8-a5357de17f4f@github.com>
Message-ID: <0PKRnvMeIHh-XMavbMIgCP0z7W5lf08NvzH8sgDoNZ0=.9d62ca8f-7440-44cd-8b04-040b41255e6a@github.com>

On Fri, 7 Nov 2025 20:16:18 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   a rename, a comment, and a new test case
>
> test/jdk/sun/security/provider/pqc/ML_DSA_CMS.java line 52:
> 
>> 50:         //   https://github.com/lamps-wg/cms-ml-dsa/releases/tag/draft-ietf-lamps-cms-ml-dsa-07
>> 51:         //   https://github.com/lamps-wg/dilithium-certificates/releases/tag/draft-ietf-lamps-dilithium-certificates-13
>> 52:         // Although the release tags include "draft", these values are the same as those in the final RFC 9882.
> 
> and RFC 9881.

OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2505758386

From weijun at openjdk.org  Fri Nov  7 22:46:42 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Nov 2025 22:46:42 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v14]
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <5Y6VmhPL6-8RFUB8UZ6DuxJAYuK9ulZFAGMX83Restk=.5dee4e19-7a91-4a0e-bf09-060e092d892e@github.com>

> Add support for ML-DSA signing of JAR files.
> 
> ~Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.~
> 
> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.

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

  more comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26563/files
  - new: https://git.openjdk.org/jdk/pull/26563/files/7e65174d..8532d3c8

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

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

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

From duke at openjdk.org  Fri Nov  7 22:49:09 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 7 Nov 2025 22:49:09 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation
In-Reply-To: <1K8M1GYvFvmBssknqrQryPA4kc5_AlOsmgYnMf9l2Gk=.da65851b-d899-44a9-af71-44a522ea8c81@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <1K8M1GYvFvmBssknqrQryPA4kc5_AlOsmgYnMf9l2Gk=.da65851b-d899-44a9-af71-44a522ea8c81@github.com>
Message-ID: <RD7FJyMLuInL1_7LrqcGfnNhRUR3NLXlWLYrT4MaPtw=.6067805d-e779-4fed-99ad-1df07d86b419@github.com>

On Fri, 7 Nov 2025 10:39:37 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
>> 
>> Thank you @jnimeh for catching the unnecessary byte mask!
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1017:
> 
>> 1015:                 | ((SBOX[(b1 & 0xF0) >> 4][b1 & 0x0F] & 0xFF) << 16)
>> 1016:                 | ((SBOX[(b2 & 0xF0) >> 4][b2 & 0x0F] & 0xFF) << 8)
>> 1017:                 | (SBOX[(word & 0xF0) >> 4][word & 0x0F] & 0xFF);
> 
> I think there is no need for any of these bytes. Every index can be computed as "(word >> offset) & 0x0F". Actually, if you define SBOX as a 1-dim array, you can index into it with "(word >> offset) & 0xFF".

Thank you for your review.  The byte assignments were to avoid three redundant shift operations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2505772947

From weijun at openjdk.org  Fri Nov  7 22:52:12 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Nov 2025 22:52:12 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v46]
In-Reply-To: <lzWuHEbdJSRoRciwVTSqQOo7D8KNPcGsMevvH6XjOsA=.9952ac27-1196-4c51-9ea6-25fbd03a7669@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <aDHigKaUY6B5bxvRyT-yH5bfzDes3-F8eB7BMKtw7BY=.5ff87048-e7b4-411a-986b-42afb665d9b0@github.com>
 <lzWuHEbdJSRoRciwVTSqQOo7D8KNPcGsMevvH6XjOsA=.9952ac27-1196-4c51-9ea6-25fbd03a7669@github.com>
Message-ID: <ZrpxQbcqtwS7LYz5-a3NdxH9GQrSSxlap2Z1GWpyfvQ=.be5d0d40-d23b-4a95-bb2b-611e521154bf@github.com>

On Wed, 5 Nov 2025 23:40:15 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:
>> 
>>  - merge
>>  - Merge branch 'master' into 8325448
>>  - Tony's comment
>>  - more key checks; some small spec change
>>  - Merge branch 'master' into 8325448
>>  - about transformation
>>  - cannot reset with withMethods
>>  - algorithm identifier
>>  - withMethods
>>  - duplicated "value" words
>>  - ... and 52 more: https://git.openjdk.org/jdk/compare/cf45e09c...b5112151
>
> src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 318:
> 
>> 316:             }
>> 317: 
>> 318:             SecretKey ExportKey(String algorithm, byte[] exporter_context, int L) {
> 
> Why are the methods in this class capitalized?

I like using the original function names from the RFC. If you don't like, I can modify them to Java-style.

> src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 540:
> 
>> 538:                 // thw builder are just byte arrays. Any KDF impl can handle this.
>> 539:                 var kdf = KDF.getInstance(kdfAlg);
>> 540:                 var key_schedule_context = concat(new byte[]{(byte) mode},
> 
> Is `key_sechedule_context` worth zero'ing?

Maybe not? `psk_id` does not sound like a secret thing. I understand `psk` is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2505776074
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2505777566

From weijun at openjdk.org  Fri Nov  7 23:08:13 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Nov 2025 23:08:13 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v46]
In-Reply-To: <lzWuHEbdJSRoRciwVTSqQOo7D8KNPcGsMevvH6XjOsA=.9952ac27-1196-4c51-9ea6-25fbd03a7669@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <aDHigKaUY6B5bxvRyT-yH5bfzDes3-F8eB7BMKtw7BY=.5ff87048-e7b4-411a-986b-42afb665d9b0@github.com>
 <lzWuHEbdJSRoRciwVTSqQOo7D8KNPcGsMevvH6XjOsA=.9952ac27-1196-4c51-9ea6-25fbd03a7669@github.com>
Message-ID: <lOuNPxwBhBZGQUYymbFAXhjToaU-2lZvQjb6zFHzDnw=.d6810bcb-0bb4-488c-a71e-a1b0356ad37f@github.com>

On Wed, 5 Nov 2025 19:35:59 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:
>> 
>>  - merge
>>  - Merge branch 'master' into 8325448
>>  - Tony's comment
>>  - more key checks; some small spec change
>>  - Merge branch 'master' into 8325448
>>  - about transformation
>>  - cannot reset with withMethods
>>  - algorithm identifier
>>  - withMethods
>>  - duplicated "value" words
>>  - ... and 52 more: https://git.openjdk.org/jdk/compare/cf45e09c...b5112151
>
> src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 137:
> 
>> 135:             throws InvalidKeyException, InvalidAlgorithmParameterException {
>> 136:         impl = new Impl(opmode);
>> 137:         if (!(key instanceof AsymmetricKey ak)) {
> 
> Is a null check needed for `key` and `params`?  It appears Cipher leaves that to the SPI to accept or reject.

If `key` is null, you will see "InvalidKeyException: Not an asymmetric key". I assume that's also OK?

I'll deal with `params`, there is a similar exception but unfortunately I called `params.getClass()` there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2505795657

From weijun at openjdk.org  Fri Nov  7 23:08:09 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Nov 2025 23:08:09 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v47]
In-Reply-To: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
Message-ID: <VByKeoNV2l6bY7aOspXof8gjuotIWmGRrI2VaBsPhXE=.1a43f198-3a08-4465-99e9-8401b5ec7df0@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> <img alt="image" src="https://github.com/user-attachments/assets/df3b454d-2161-4036-9930-c4f84d887b31" />

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

  check null and tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/b5112151..4d5b15f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=45-46

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

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

From hchao at openjdk.org  Fri Nov  7 23:21:10 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 7 Nov 2025 23:21:10 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <9W7IE13CTQC8WF8239p05fovkC2IRVazTK9VxWUCq8A=.6ad8a6dc-fcf1-4b35-8c50-7cb110b4898c@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
 <9W7IE13CTQC8WF8239p05fovkC2IRVazTK9VxWUCq8A=.6ad8a6dc-fcf1-4b35-8c50-7cb110b4898c@github.com>
Message-ID: <AE2tJc5Ld6eAXKq3ONMV6H1uez96C3BXULOasW36yVI=.392157cb-06b8-45f0-9f16-1d20bcf18cbc@github.com>

On Mon, 27 Oct 2025 02:49:39 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert changes to UseStrongDHSizes test as ffdhe6144/8192 added back
>>  - Updated comment in ServerHello and hybrid to upper-case in NamedGroup
>
> src/java.base/share/classes/sun/security/util/Hybrid.java line 60:
> 
>> 58:         @Override
>> 59:         public String getAlgorithm() {
>> 60:             return "Hybrid";
> 
> Will this name be added to CSR and Java Security Standard Algorithm Names doc?

No, this name is just for internal only. It It serves as an internal label for composite key handling and is not for use in the JCA API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2505818363

From duke at openjdk.org  Fri Nov  7 23:37:02 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 7 Nov 2025 23:37:02 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation
In-Reply-To: <nlVAp9HzECZytsa9XJoK-InhksKafkHV71z5INj7A6c=.fc21930a-ac64-4910-858c-f7ae7e3cc607@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <nlVAp9HzECZytsa9XJoK-InhksKafkHV71z5INj7A6c=.fc21930a-ac64-4910-858c-f7ae7e3cc607@github.com>
Message-ID: <h6rBQOMdlmd81eJe5-FkuxxT2qpf-LU8YUzal0s8REs=.98550d2a-4512-42bd-a2ae-42c93a7bd16d@github.com>

On Fri, 7 Nov 2025 17:20:05 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
>> 
>> Thank you @jnimeh for catching the unnecessary byte mask!
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 986:
> 
>> 984:             int idx = kLen - widx;
>> 985: 
>> 986:             dw[idx] = TMI0[w[widx] >>> 24] ^ TMI1[(w[widx] >> 16) & 0xFF]
> 
> Do you think there would be any benefit to putting w[widx] through w[widx+3] on local int variables?  In some cases I've seen where that increases register pressure and can lead to some perf benefits.  I'm not sure if this is one of those cases but it seems like you'd only need to reference memory once instead of 4 times per assignment.

I believe my original changes here utilize a "MergeStore" technique that the compiler optimizes.  I've asked @minborg to see if I got this right.  To verify the optimization here, I used the separate local int variable technique and saw a 0.7% decrease in benchmark performance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2505847151

From duke at openjdk.org  Sat Nov  8 00:39:02 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Sat, 8 Nov 2025 00:39:02 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation
In-Reply-To: <nlVAp9HzECZytsa9XJoK-InhksKafkHV71z5INj7A6c=.fc21930a-ac64-4910-858c-f7ae7e3cc607@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <nlVAp9HzECZytsa9XJoK-InhksKafkHV71z5INj7A6c=.fc21930a-ac64-4910-858c-f7ae7e3cc607@github.com>
Message-ID: <2he28MTjAbxY6n2LVnU0o1AAGNdtU-h7WUSvt27i3tk=.90440ddb-a437-4a5a-99d2-97bf39066011@github.com>

On Fri, 7 Nov 2025 17:25:51 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
>> 
>> Thank you @jnimeh for catching the unnecessary byte mask!
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1011:
> 
>> 1009:      */
>> 1010:     private static int subWord(int word) {
>> 1011:         byte b0 = (byte) (word >>> 24);
> 
> Nits (unrelated to this block of code, but I can't put comments on the lines directly since they're not part of the modified code):
> 
> - Lines 37-43: I think you could do an `@link` annotation with <a href></a> surrounding the links.
> - Lines 1004-1005: Looks like a bit of comment rot, I think you just need an `@param` for `word`.

Re: `@link` - I'm not for sure I understand the context and couldn't find an example of this in the existing code base.
Re: `@param` - Good catch.  I've made this update and a couple of others that needed cleaning up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2505914134

From duke at openjdk.org  Sat Nov  8 00:46:29 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Sat, 8 Nov 2025 00:46:29 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v2]
In-Reply-To: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
Message-ID: <GVlVcLCHu73zc4MlGZUboY2wLJrt_kq66bswMM9jT7M=.ca05b0db-f302-457c-a3c5-c526df2f45fb@github.com>

> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
> 
> Thank you @jnimeh for catching the unnecessary byte mask!

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

  Updates for code review comments from @jnimeh

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28188/files
  - new: https://git.openjdk.org/jdk/pull/28188/files/c462a58e..0e9d14f9

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

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

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

From weijun at openjdk.org  Sat Nov  8 14:57:11 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 8 Nov 2025 14:57:11 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v15]
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <9mglaJvtY--kOAKyAUdEFxpOkdVNOg8KEwyVtJPKbVw=.cef5f8da-89e9-403a-b3bf-08e8bf841ba0@github.com>

> Add support for ML-DSA signing of JAR files.
> 
> ~Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.~
> 
> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.

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

  add othervm to prevent interference with other tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26563/files
  - new: https://git.openjdk.org/jdk/pull/26563/files/8532d3c8..beeeca17

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

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

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

From jnimeh at openjdk.org  Sat Nov  8 17:11:06 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Sat, 8 Nov 2025 17:11:06 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v2]
In-Reply-To: <GVlVcLCHu73zc4MlGZUboY2wLJrt_kq66bswMM9jT7M=.ca05b0db-f302-457c-a3c5-c526df2f45fb@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <GVlVcLCHu73zc4MlGZUboY2wLJrt_kq66bswMM9jT7M=.ca05b0db-f302-457c-a3c5-c526df2f45fb@github.com>
Message-ID: <aWCiasLF5vYKP_EefIEaV1iAul5MTEU8rZkqyoukSQ0=.6078f952-4734-4e8b-b1d5-01185522e2ec@github.com>

On Sat, 8 Nov 2025 00:46:29 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
>> 
>> Thank you @jnimeh for catching the unnecessary byte mask!
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @jnimeh

Marked as reviewed by jnimeh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28188#pullrequestreview-3438482876

From jnimeh at openjdk.org  Sat Nov  8 17:11:08 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Sat, 8 Nov 2025 17:11:08 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v2]
In-Reply-To: <h6rBQOMdlmd81eJe5-FkuxxT2qpf-LU8YUzal0s8REs=.98550d2a-4512-42bd-a2ae-42c93a7bd16d@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <nlVAp9HzECZytsa9XJoK-InhksKafkHV71z5INj7A6c=.fc21930a-ac64-4910-858c-f7ae7e3cc607@github.com>
 <h6rBQOMdlmd81eJe5-FkuxxT2qpf-LU8YUzal0s8REs=.98550d2a-4512-42bd-a2ae-42c93a7bd16d@github.com>
Message-ID: <TcaEKkGJ1oo5YQdHOX6lf-2mVAyUmP2U9B2aJ0HFeNg=.207e9bdd-ea33-4396-8e5b-9caaed9d4689@github.com>

On Fri, 7 Nov 2025 23:34:10 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 986:
>> 
>>> 984:             int idx = kLen - widx;
>>> 985: 
>>> 986:             dw[idx] = TMI0[w[widx] >>> 24] ^ TMI1[(w[widx] >> 16) & 0xFF]
>> 
>> Do you think there would be any benefit to putting w[widx] through w[widx+3] on local int variables?  In some cases I've seen where that increases register pressure and can lead to some perf benefits.  I'm not sure if this is one of those cases but it seems like you'd only need to reference memory once instead of 4 times per assignment.
>
> I believe my original changes here utilize a "MergeStore" technique that the compiler optimizes.  I've asked @minborg to see if I got this right.  To verify the optimization here, I used the separate local int variable technique and saw a 0.7% decrease in benchmark performance.

Well, your experiment answers my question.  Unless @minborg says otherwise I'm fine with what you have.  You're already seeing improvements so that's great.

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1011:
>> 
>>> 1009:      */
>>> 1010:     private static int subWord(int word) {
>>> 1011:         byte b0 = (byte) (word >>> 24);
>> 
>> Nits (unrelated to this block of code, but I can't put comments on the lines directly since they're not part of the modified code):
>> 
>> - Lines 37-43: I think you could do an `@link` annotation with <a href></a> surrounding the links.
>> - Lines 1004-1005: Looks like a bit of comment rot, I think you just need an `@param` for `word`.
>
> Re: `@link` - I'm not for sure I understand the context and couldn't find an example of this in the existing code base.
> Re: `@param` - Good catch.  I've made this update and a couple of others that needed cleaning up.

When I was looking at the code in IntelliJ it was giving warnings about the links, but I think it just wanted them to be inside href HTML tags so the links would be active when rendering the comment block.  After looking at the `@link` tag in reference docs I think it's the wrong tag.  Honestly, let's just forget this - if it was a public-facing javadoc comment it would be more important but what you have here is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2507020546
PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2507019920

From duke at openjdk.org  Sun Nov  9 04:31:51 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Sun, 9 Nov 2025 04:31:51 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v3]
In-Reply-To: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
Message-ID: <oq0BbR25u2UT_8MBMsS09nMvWrsvEqIX5WQ5V09FIBg=.a8eedcb9-d8d0-4fcd-9a10-c8c5a256f034@github.com>

> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
> 
> Thank you @jnimeh for catching the unnecessary byte mask!

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

  Clean up comments - take two

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28188/files
  - new: https://git.openjdk.org/jdk/pull/28188/files/0e9d14f9..55e052f6

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

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

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

From duke at openjdk.org  Sun Nov  9 19:45:08 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Sun, 9 Nov 2025 19:45:08 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v3]
In-Reply-To: <RD7FJyMLuInL1_7LrqcGfnNhRUR3NLXlWLYrT4MaPtw=.6067805d-e779-4fed-99ad-1df07d86b419@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <1K8M1GYvFvmBssknqrQryPA4kc5_AlOsmgYnMf9l2Gk=.da65851b-d899-44a9-af71-44a522ea8c81@github.com>
 <RD7FJyMLuInL1_7LrqcGfnNhRUR3NLXlWLYrT4MaPtw=.6067805d-e779-4fed-99ad-1df07d86b419@github.com>
Message-ID: <vyoSTeQYTy_d76ZiJEG2y1C-cf_rLOpJsJ5Euymc3V8=.b90de6f2-9c53-4089-8616-95873ac54f09@github.com>

On Fri, 7 Nov 2025 22:45:33 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1017:
>> 
>>> 1015:                 | ((SBOX[(b1 & 0xF0) >> 4][b1 & 0x0F] & 0xFF) << 16)
>>> 1016:                 | ((SBOX[(b2 & 0xF0) >> 4][b2 & 0x0F] & 0xFF) << 8)
>>> 1017:                 | (SBOX[(word & 0xF0) >> 4][word & 0x0F] & 0xFF);
>> 
>> I think there is no need for any of these bytes. Every index can be computed as "(word >> offset) & 0x0F". Actually, if you define SBOX as a 1-dim array, you can index into it with "(word >> offset) & 0xFF".
>
> Thank you for your review.  The byte assignments were to avoid three redundant shift operations.

What were those "redundant shifts"? 
What I am suggesting is:
 return (SBOX(word >>>24] << 24) |
             (SBOX[(word >> 16) & 0xFF] << 16) |
             (SBOX[(word >> 8) & 0xFF] << 8) |
             SBOX[word & 0xFF];

if you define SBOX as an int[256] array.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2508285414

From duke at openjdk.org  Sun Nov  9 23:11:02 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Sun, 9 Nov 2025 23:11:02 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v3]
In-Reply-To: <vyoSTeQYTy_d76ZiJEG2y1C-cf_rLOpJsJ5Euymc3V8=.b90de6f2-9c53-4089-8616-95873ac54f09@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <1K8M1GYvFvmBssknqrQryPA4kc5_AlOsmgYnMf9l2Gk=.da65851b-d899-44a9-af71-44a522ea8c81@github.com>
 <RD7FJyMLuInL1_7LrqcGfnNhRUR3NLXlWLYrT4MaPtw=.6067805d-e779-4fed-99ad-1df07d86b419@github.com>
 <vyoSTeQYTy_d76ZiJEG2y1C-cf_rLOpJsJ5Euymc3V8=.b90de6f2-9c53-4089-8616-95873ac54f09@github.com>
Message-ID: <NyUoP_76sD6GN8gfaXzV5oZ1QsYFkgNpWtzBPGi0kmE=.764acaca-dde9-42bf-bf2a-e58b66dd068b@github.com>

On Sun, 9 Nov 2025 19:42:44 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Thank you for your review.  The byte assignments were to avoid three redundant shift operations.
>
> What were those "redundant shifts"? 
> What I am suggesting is:
>  return (SBOX(word >>>24] << 24) |
>              (SBOX[(word >> 16) & 0xFF] << 16) |
>              (SBOX[(word >> 8) & 0xFF] << 8) |
>              SBOX[word & 0xFF];
> 
> if you define SBOX as an int[256] array.

Yes, this would definitely speed up key schedule generation, but at the cost of additional memory; +768 bytes per instance, where the total AES cipher would be 1,268 bytes more per instance than the original Cryptix implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2508383356

From duke at openjdk.org  Mon Nov 10 00:29:05 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Mon, 10 Nov 2025 00:29:05 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v3]
In-Reply-To: <NyUoP_76sD6GN8gfaXzV5oZ1QsYFkgNpWtzBPGi0kmE=.764acaca-dde9-42bf-bf2a-e58b66dd068b@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <1K8M1GYvFvmBssknqrQryPA4kc5_AlOsmgYnMf9l2Gk=.da65851b-d899-44a9-af71-44a522ea8c81@github.com>
 <RD7FJyMLuInL1_7LrqcGfnNhRUR3NLXlWLYrT4MaPtw=.6067805d-e779-4fed-99ad-1df07d86b419@github.com>
 <vyoSTeQYTy_d76ZiJEG2y1C-cf_rLOpJsJ5Euymc3V8=.b90de6f2-9c53-4089-8616-95873ac54f09@github.com>
 <NyUoP_76sD6GN8gfaXzV5oZ1QsYFkgNpWtzBPGi0kmE=.764acaca-dde9-42bf-bf2a-e58b66dd068b@github.com>
Message-ID: <1xCoDp3OsBuejxUrI0rOVhYcpxgjA8NJuiEXQCxO8cc=.523a9b43-a4f5-44cf-bf30-934151ac7e23@github.com>

On Sun, 9 Nov 2025 23:08:25 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> What were those "redundant shifts"? 
>> What I am suggesting is:
>>  return (SBOX(word >>>24] << 24) |
>>              (SBOX[(word >> 16) & 0xFF] << 16) |
>>              (SBOX[(word >> 8) & 0xFF] << 8) |
>>              SBOX[word & 0xFF];
>> 
>> if you define SBOX as an int[256] array.
>
> Yes, this would definitely speed up key schedule generation, but at the cost of additional memory; +768 bytes per instance, where the total AES cipher would be 1,268 bytes more per instance than the original Cryptix implementation.

The int[256] SBOX solution would increase performance by 2.64% for the AESReinit benchmark.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2508442533

From duke at openjdk.org  Mon Nov 10 02:17:08 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Mon, 10 Nov 2025 02:17:08 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v3]
In-Reply-To: <1xCoDp3OsBuejxUrI0rOVhYcpxgjA8NJuiEXQCxO8cc=.523a9b43-a4f5-44cf-bf30-934151ac7e23@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <1K8M1GYvFvmBssknqrQryPA4kc5_AlOsmgYnMf9l2Gk=.da65851b-d899-44a9-af71-44a522ea8c81@github.com>
 <RD7FJyMLuInL1_7LrqcGfnNhRUR3NLXlWLYrT4MaPtw=.6067805d-e779-4fed-99ad-1df07d86b419@github.com>
 <vyoSTeQYTy_d76ZiJEG2y1C-cf_rLOpJsJ5Euymc3V8=.b90de6f2-9c53-4089-8616-95873ac54f09@github.com>
 <NyUoP_76sD6GN8gfaXzV5oZ1QsYFkgNpWtzBPGi0kmE=.764acaca-dde9-42bf-bf2a-e58b66dd068b@github.com>
 <1xCoDp3OsBuejxUrI0rOVhYcpxgjA8NJuiEXQCxO8cc=.523a9b43-a4f5-44cf-bf30-934151ac7e23@github.com>
Message-ID: <-mejkXqA8reXQ-7ZdpJuq1O6CN8nrpQKBXc1lgotPmM=.e47834dc-edb2-4b34-a290-ac26276d6201@github.com>

On Mon, 10 Nov 2025 00:26:22 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> Yes, this would definitely speed up key schedule generation, but at the cost of additional memory; +768 bytes per instance, where the total AES cipher would be 1,268 bytes more per instance than the original Cryptix implementation.
>
> The int[256] SBOX solution would increase performance by 2.64% for the AESReinit benchmark.

Switching from a byte[16][16] to a byte[256] SBOX would still increase performance by 1.24% for the AESReinit benchmark w/o sacrificing memory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2508528417

From alanb at openjdk.org  Mon Nov 10 10:06:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Nov 2025 10:06:31 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:

 - Merge branch 'master' into JDK-8353835
 - Fix typo in test comment
 - Merge branch 'master' into JDK-8353835
 - Merge branch 'master' into JDK-8353835
 - Suppress warnings from some tests
 - Change -Xcheck:jni to be warning rather than fatal error
 - Merge branch 'master' into JDK-8353835
 - Simplify filter
 - Merge branch 'master' into JDK-8353835
 - Update Xcheck:jni description
 - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02

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

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=09
  Stats: 4852 lines in 70 files changed: 4667 ins; 54 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

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

From vyazici at openjdk.org  Mon Nov 10 10:18:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 10 Nov 2025 10:18:10 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
Message-ID: <gueTV_xhVN6XvbIV-iyw87yH3RWeQNLUlDL7tTcx_8E=.99e760de-0c58-4265-a885-4b9d5ecd254b@github.com>

On Mon, 10 Nov 2025 10:06:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Fix typo in test comment
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3442211078

From pminborg at openjdk.org  Mon Nov 10 11:11:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 11:11:05 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v21]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <mW7TeaAZkRkmps0ITBT8LMdbEP7JPKL1lSixAc45KWQ=.7bdcb888-ae4b-428f-b286-bebb28078a8b@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits:

 - Merge master
 - Rework toString implementations
 - Update after doc comments
 - Merge branch 'master' into lazy-constants
 - Revert the AbstractMap.keySet @Stable annotation
 - Update docs after comments
 - Improve method docs
 - Improve equals/hashCode document
 - Update wording on List/Map Object methods
 - Update javadocs
 - ... and 97 more: https://git.openjdk.org/jdk/compare/681dab72...f775aaf1

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

Changes: https://git.openjdk.org/jdk/pull/27605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=20
  Stats: 8482 lines in 60 files changed: 3875 ins; 4490 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From pminborg at openjdk.org  Mon Nov 10 11:17:43 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 11:17:43 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v22]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <i7TM8ZzBjWYHIV28uZ2yCqPuRsYd-xeerIaSRpASFPI=.f9898317-3e6e-428e-ab18-c53d3e2f5059@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix merge mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/f775aaf1..003eaf1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=20-21

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

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

From pminborg at openjdk.org  Mon Nov 10 12:36:12 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 12:36:12 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v20]
In-Reply-To: <qdoshJM6YkMk1XK055rk8NLEb_mw0INP_ylFKSMPx2Y=.c52d2295-74d3-4681-8c56-14207a47a62e@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
 <qdoshJM6YkMk1XK055rk8NLEb_mw0INP_ylFKSMPx2Y=.c52d2295-74d3-4681-8c56-14207a47a62e@github.com>
Message-ID: <uAti75Ny7_zN9LInVXAewUujk3kcqIkzJuW_KqxbEro=.6652f9d9-2f8f-471d-83e0-69b90d5c9a51@github.com>

On Wed, 5 Nov 2025 23:31:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework toString implementations
>
> src/java.base/share/classes/java/util/Map.java line 1814:
> 
>> 1812:         final Set<K> keyCopies = Set.copyOf(keys);
>> 1813:         Objects.requireNonNull(computingFunction);
>> 1814:         if (keys instanceof EnumSet<?> && !keys.isEmpty()) {
> 
> I wonder if it's premature for us to optimize like this - for example, this would be wasteful if the key set contains one enum constant but there are 1000 enum constants in this enum.

There is a `min` and a `max` ordinal calculated, so in your example above, only one array item is used. I.e., if there are 1,000 enum constant and we are using enum with ordinal 42, then min = max = 42 and only a one-element array is ever allocated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2510377932

From pminborg at openjdk.org  Mon Nov 10 13:00:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 13:00:35 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v23]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <VdvBzwLN3yzDRSz3UYvaEJOKYaUtQVRVorlbDJc-dls=.81b0a2b8-3654-4cb0-bcd4-2f5649a222dc@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Address comments in PR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/003eaf1c..03616ef6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=21-22

  Stats: 119 lines in 6 files changed: 17 ins; 72 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From alan.bateman at oracle.com  Mon Nov 10 13:22:36 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Nov 2025 13:22:36 +0000
Subject: <i18n dev> Proposal: 8338093: Localization of yes/no options in
 console input
In-Reply-To: <19a6dbae0ad.7e56af0a221616.1073185985223008803@peya.tokyo>
References: <19a6dbae0ad.7e56af0a221616.1073185985223008803@peya.tokyo>
Message-ID: <12b66ef8-0802-41ae-8d34-84a414e51e43@oracle.com>


Adding security-dev to the discussion as keytool is maintained there.

On 10/11/2025 12:25, Daisuke Yamazaki wrote:
> Hello,
>
> Currently, keytool accepts input only in English, even though the options
> labels are localised.
> This raises the question: Should the options also be localised in accordance
> with user's language?
>
> We basically have two choices:
> 1. Localise the options and accept input in the corresponding language
> 2. Keep the options uniform in English and accept only English input
>
> Some languages require input via an IME. For example:
> - In japanese, "???" must be typed as "iie".
> - In chinese, "?" must be typed as "fou" and then selected from candidates.
>
> Performing this kind of input can be cumbersome in a console environment,
> so I personally prefer the second approach: keeping options in English.
>
> Currently, some options are incorrectly localized (i.e., the program does not
> accept input in these languages): German, French, Japanese, Korean,
> Portuguese (pt_BR), Swedish, Chinese (CN/TW).
>
> I am planning to create a patch to unify this behavior and would like to
> discuss which approach would be preferable.
>
> Thank you,
> D.Yamazaki


From mullan at openjdk.org  Mon Nov 10 13:25:04 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 10 Nov 2025 13:25:04 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v15]
In-Reply-To: <9mglaJvtY--kOAKyAUdEFxpOkdVNOg8KEwyVtJPKbVw=.cef5f8da-89e9-403a-b3bf-08e8bf841ba0@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <9mglaJvtY--kOAKyAUdEFxpOkdVNOg8KEwyVtJPKbVw=.cef5f8da-89e9-403a-b3bf-08e8bf841ba0@github.com>
Message-ID: <CKnUKExw0W697z3j48jNUsnxclm8b8vkg5wctOdfzgo=.d2544f8d-979d-4620-a3d3-204eff64a8ce@github.com>

On Sat, 8 Nov 2025 14:57:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add support for ML-DSA signing of JAR files.
>> 
>> ~Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.~
>> 
>> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add othervm to prevent interference with other tests

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26563#pullrequestreview-3443229063

From duke at openjdk.org  Mon Nov 10 13:55:37 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 10 Nov 2025 13:55:37 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v3]
In-Reply-To: <-mejkXqA8reXQ-7ZdpJuq1O6CN8nrpQKBXc1lgotPmM=.e47834dc-edb2-4b34-a290-ac26276d6201@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <1K8M1GYvFvmBssknqrQryPA4kc5_AlOsmgYnMf9l2Gk=.da65851b-d899-44a9-af71-44a522ea8c81@github.com>
 <RD7FJyMLuInL1_7LrqcGfnNhRUR3NLXlWLYrT4MaPtw=.6067805d-e779-4fed-99ad-1df07d86b419@github.com>
 <vyoSTeQYTy_d76ZiJEG2y1C-cf_rLOpJsJ5Euymc3V8=.b90de6f2-9c53-4089-8616-95873ac54f09@github.com>
 <NyUoP_76sD6GN8gfaXzV5oZ1QsYFkgNpWtzBPGi0kmE=.764acaca-dde9-42bf-bf2a-e58b66dd068b@github.com>
 <1xCoDp3OsBuejxUrI0rOVhYcpxgjA8NJuiEXQCxO8cc=.523a9b43-a4f5-44cf-bf30-934151ac7e23@github.com>
 <-mejkXqA8reXQ-7ZdpJuq1O6CN8nrpQKBXc1lgotPmM=.e47834dc-edb2-4b34-a290-ac26276d6201@github.com>
Message-ID: <eQ1jPLPTAvFHcnLV0ryiyQi7AjciIyPy4taaoBKjWYQ=.c6265e92-7d5a-4f34-aa14-5532be7cd632@github.com>

On Mon, 10 Nov 2025 02:13:53 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> The int[256] SBOX solution would increase performance by 2.64% for the AESReinit benchmark.
>
> Switching from a byte[16][16] to a byte[256] SBOX would still increase performance by 1.24% for the AESReinit benchmark w/o sacrificing memory.

> Yes, this would definitely speed up key schedule generation, but at the cost of additional memory; +768 bytes per instance, where the total AES cipher would be 1,268 bytes more per instance than the original Cryptix implementation.

I don't think that when even a Raspberry Pi comes with gigabytes of memory, a 1k increase in constant data size should be an issue to consider. On the other hand, a 1-2% speed increase in a rarely called function is also insignificant, so if you want to keep things unchanged here, I won't object to it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2510666809

From weijun at openjdk.org  Mon Nov 10 14:43:02 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 10 Nov 2025 14:43:02 GMT
Subject: Integrated: 8349732: Add support for JARs signed with ML-DSA
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <UnA5YcZD6XhzB-Yp6QncyqCNqUMTh03JM5SViRZRilw=.bd15055a-4d1e-4440-8e12-3c17685d3f46@github.com>

On Wed, 30 Jul 2025 18:48:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add support for ML-DSA signing of JAR files.
> 
> ~Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.~
> 
> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.

This pull request has now been integrated.

Changeset: 2d4f2fde
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d4f2fde2281affd90bdd608d49a021f6cac2fed
Stats:     740 lines in 11 files changed: 636 ins; 22 del; 82 mod

8349732: Add support for JARs signed with ML-DSA

Reviewed-by: mullan

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

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

From pminborg at openjdk.org  Mon Nov 10 14:59:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Nov 2025 14:59:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v24]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add @AOTSafeClassInitializer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/03616ef6..e479cb4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=22-23

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

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

From myankelevich at openjdk.org  Mon Nov 10 15:37:58 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 10 Nov 2025 15:37:58 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v15]
In-Reply-To: <d3MSuq-IIFMuc5LmpCXKNt7e51pPaxowq187BnkRVQo=.b359e6b4-5023-48ea-8100-89e74370b48b@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <d3MSuq-IIFMuc5LmpCXKNt7e51pPaxowq187BnkRVQo=.b359e6b4-5023-48ea-8100-89e74370b48b@github.com>
Message-ID: <alwQ_V5cU0WPF5nS7qgQEHMYUfZqqEGy7_5n9b7uW6g=.dc18d952-3802-4510-ba2e-42b1d9b8c229@github.com>

On Fri, 7 Nov 2025 17:26:53 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request 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 27 additional commits since the last revision:
> 
>  - Merge branch 'master' into pem26
>  - remove PEMRecord import
>  - mistakes
>  - Merge branch 'master' into pem26
>  - minor doc updates, fix some bugs, PEM set to 26
>  - more docs, remove runtimeexception
>  - EKPI has a lot of @link's
>  - docs
>  - more doc updates and zeroing
>  - fix non-pbe
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/a5db9ab2...2ee3e7a4

src/java.base/share/classes/java/security/PEM.java line 144:

> 142:      * @throws IllegalArgumentException if decoding fails
> 143:      */
> 144:     final public byte[] decode() {

This method doesn't seem to be covered by the tests. I have created a ticket to add this https://bugs.openjdk.org/browse/JDK-8371574. 
It also covers the 2 methods in PEM.java in utils, which could be covered further

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2511040775

From weijun.wang at oracle.com  Mon Nov 10 18:53:31 2025
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Mon, 10 Nov 2025 18:53:31 +0000
Subject: <i18n dev> Proposal: 8338093: Localization of yes/no options in
 console input
In-Reply-To: <12b66ef8-0802-41ae-8d34-84a414e51e43@oracle.com>
References: <19a6dbae0ad.7e56af0a221616.1073185985223008803@peya.tokyo>
 <12b66ef8-0802-41ae-8d34-84a414e51e43@oracle.com>
Message-ID: <823F82ED-F242-48AC-9145-83747AE5BAC0@oracle.com>

The current code accepts y/n/yes/no (case insensitive) and it's quite good. I think modifying the prompts to be clearer is good.

I'm adding Justin and Naoto here. The current prompts mostly look like

    Do you still want to add it? [no]

How do you suggest we rewrite it to be more clear on expected inputs? And how to avoid translators translating them to localized words like "???" or "?"?

Thanks,
Weijun

> On Nov 10, 2025, at 08:22, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> 
> Adding security-dev to the discussion as keytool is maintained there.
> 
> On 10/11/2025 12:25, Daisuke Yamazaki wrote:
>> Hello,
>> 
>> Currently, keytool accepts input only in English, even though the options
>> labels are localised.
>> This raises the question: Should the options also be localised in accordance
>> with user's language?
>> 
>> We basically have two choices:
>> 1. Localise the options and accept input in the corresponding language
>> 2. Keep the options uniform in English and accept only English input
>> 
>> Some languages require input via an IME. For example:
>> - In japanese, "???" must be typed as "iie".
>> - In chinese, "?" must be typed as "fou" and then selected from candidates.
>> 
>> Performing this kind of input can be cumbersome in a console environment,
>> so I personally prefer the second approach: keeping options in English.
>> 
>> Currently, some options are incorrectly localized (i.e., the program does not
>> accept input in these languages): German, French, Japanese, Korean,
>> Portuguese (pt_BR), Swedish, Chinese (CN/TW).
>> 
>> I am planning to create a patch to unify this behavior and would like to
>> discuss which approach would be preferable.
>> 
>> Thank you,
>> D.Yamazaki
> 


From naoto.sato at oracle.com  Mon Nov 10 19:05:28 2025
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 10 Nov 2025 11:05:28 -0800
Subject: <i18n dev> Proposal: 8338093: Localization of yes/no options in
 console input
In-Reply-To: <823F82ED-F242-48AC-9145-83747AE5BAC0@oracle.com>
References: <19a6dbae0ad.7e56af0a221616.1073185985223008803@peya.tokyo>
 <12b66ef8-0802-41ae-8d34-84a414e51e43@oracle.com>
 <823F82ED-F242-48AC-9145-83747AE5BAC0@oracle.com>
Message-ID: <6e8a4971-f702-44e7-8621-566d1273382a@oracle.com>

I think the common prompt format is [Y/n] or [y/N], where capitalization 
indicates the default. That should also have translators not translate 
it. (Commenting on it would be safer too)

Naoto

On 11/10/25 10:53 AM, Wei-Jun Wang wrote:
> The current code accepts y/n/yes/no (case insensitive) and it's quite good. I think modifying the prompts to be clearer is good.
> 
> I'm adding Justin and Naoto here. The current prompts mostly look like
> 
>      Do you still want to add it? [no]
> 
> How do you suggest we rewrite it to be more clear on expected inputs? And how to avoid translators translating them to localized words like "???" or "?"?
> 
> Thanks,
> Weijun
> 
>> On Nov 10, 2025, at 08:22, Alan Bateman <alan.bateman at oracle.com> wrote:
>>
>>
>> Adding security-dev to the discussion as keytool is maintained there.
>>
>> On 10/11/2025 12:25, Daisuke Yamazaki wrote:
>>> Hello,
>>>
>>> Currently, keytool accepts input only in English, even though the options
>>> labels are localised.
>>> This raises the question: Should the options also be localised in accordance
>>> with user's language?
>>>
>>> We basically have two choices:
>>> 1. Localise the options and accept input in the corresponding language
>>> 2. Keep the options uniform in English and accept only English input
>>>
>>> Some languages require input via an IME. For example:
>>> - In japanese, "???" must be typed as "iie".
>>> - In chinese, "?" must be typed as "fou" and then selected from candidates.
>>>
>>> Performing this kind of input can be cumbersome in a console environment,
>>> so I personally prefer the second approach: keeping options in English.
>>>
>>> Currently, some options are incorrectly localized (i.e., the program does not
>>> accept input in these languages): German, French, Japanese, Korean,
>>> Portuguese (pt_BR), Swedish, Chinese (CN/TW).
>>>
>>> I am planning to create a patch to unify this behavior and would like to
>>> discuss which approach would be preferable.
>>>
>>> Thank you,
>>> D.Yamazaki
>>
> 


From weijun.wang at oracle.com  Mon Nov 10 19:35:45 2025
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Mon, 10 Nov 2025 19:35:45 +0000
Subject: <i18n dev> Proposal: 8338093: Localization of yes/no options in
 console input
In-Reply-To: <6e8a4971-f702-44e7-8621-566d1273382a@oracle.com>
References: <19a6dbae0ad.7e56af0a221616.1073185985223008803@peya.tokyo>
 <12b66ef8-0802-41ae-8d34-84a414e51e43@oracle.com>
 <823F82ED-F242-48AC-9145-83747AE5BAC0@oracle.com>
 <6e8a4971-f702-44e7-8621-566d1273382a@oracle.com>
Message-ID: <B4509423-7CBA-4810-8C0C-81904D5F1882@oracle.com>

Hello, D.Yamazaki,

Welcome to contributing to JDK. For your patch, please only update the English properties file, I think there is a policy that translations should always be handled by dedicated teams.

I assume you are already familiar with the key sections of the OpenJDK Developers' Guide [1] and the OCA [2].

Thanks,
Weijun

[1] https://openjdk.org/guide/
[2] https://oca.opensource.oracle.com/?ojr=faq

> On Nov 10, 2025, at 14:05, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> I think the common prompt format is [Y/n] or [y/N], where capitalization indicates the default. That should also have translators not translate it. (Commenting on it would be safer too)
> 
> Naoto
> 
> On 11/10/25 10:53 AM, Wei-Jun Wang wrote:
>> The current code accepts y/n/yes/no (case insensitive) and it's quite good. I think modifying the prompts to be clearer is good.
>> I'm adding Justin and Naoto here. The current prompts mostly look like
>>     Do you still want to add it? [no]
>> How do you suggest we rewrite it to be more clear on expected inputs? And how to avoid translators translating them to localized words like "???" or "?"?
>> Thanks,
>> Weijun
>>> On Nov 10, 2025, at 08:22, Alan Bateman <alan.bateman at oracle.com> wrote:
>>> 
>>> 
>>> Adding security-dev to the discussion as keytool is maintained there.
>>> 
>>> On 10/11/2025 12:25, Daisuke Yamazaki wrote:
>>>> Hello,
>>>> 
>>>> Currently, keytool accepts input only in English, even though the options
>>>> labels are localised.
>>>> This raises the question: Should the options also be localised in accordance
>>>> with user's language?
>>>> 
>>>> We basically have two choices:
>>>> 1. Localise the options and accept input in the corresponding language
>>>> 2. Keep the options uniform in English and accept only English input
>>>> 
>>>> Some languages require input via an IME. For example:
>>>> - In japanese, "???" must be typed as "iie".
>>>> - In chinese, "?" must be typed as "fou" and then selected from candidates.
>>>> 
>>>> Performing this kind of input can be cumbersome in a console environment,
>>>> so I personally prefer the second approach: keeping options in English.
>>>> 
>>>> Currently, some options are incorrectly localized (i.e., the program does not
>>>> accept input in these languages): German, French, Japanese, Korean,
>>>> Portuguese (pt_BR), Swedish, Chinese (CN/TW).
>>>> 
>>>> I am planning to create a patch to unify this behavior and would like to
>>>> discuss which approach would be preferable.
>>>> 
>>>> Thank you,
>>>> D.Yamazaki
>>> 
> 


From liach at openjdk.org  Mon Nov 10 20:27:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Nov 2025 20:27:39 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
Message-ID: <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>

On Mon, 10 Nov 2025 10:06:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Fix typo in test comment
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02

I still wonder about the decision for JNI to call final Field.set with an unconditional export check instead of an unconditional open check - the open check is done for all Java code already.

src/java.base/share/classes/java/lang/reflect/doc-files/MutationMethods.html line 56:

> 54:     <li><a href="../Field.html#setDouble(java.lang.Object,double)">
> 55:         java.lang.reflect.Field.setDouble(Object, double)</a></li>
> 56:     <li><a href="{@docRoot}/java.base/java/lang/invoke/MethodHandles.Lookup.html#unreflectSetter(java.lang.reflect.Field)">

Nit: Since javadoc process tags here, you could just use `{@link Field#set java.lang.reflect.Field.set(Object, Object)}` instead of full-fledged a tags.

src/java.base/share/classes/java/lang/reflect/doc-files/MutationMethods.html line 66:

> 64: <p> In the reference implementation, a module can be granted the capability to mutate
> 65: final instance fields of classes in packages that are open to the module using
> 66: the command line option <code>--enable-final-field-mutation=M1,M2, ... M}</code> where

Suggestion:

the command line option <code>--enable-final-field-mutation=M1,M2, ... Mn}</code> where

src/java.base/share/classes/java/lang/reflect/doc-files/MutationMethods.html line 72:

> 70: <em>illegal</em>.
> 71: 
> 72: The command line option <code>--illegal-final-field-mutation</code> controls how illegal

Missing `<p>`?

test/jdk/java/lang/reflect/Field/mutateFinals/cli/CommandLineTest.java line 234:

> 232:     @Test
> 233:     void testSetPropertyToAllow() throws Exception {
> 234:         test("setSystemPropertyToAllow+testFieldSetInt")

I thought this was setting the property before the VM boot. Can we have another test that does something like:

test("testFieldSetInt", "-Djdk.module.illegal.final.field.mutation=allow")

Which I think is closer to what @vy asks for.

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

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3444803078
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2511838513
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2511840059
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2511841318
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2511708135

From liach at openjdk.org  Mon Nov 10 20:27:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Nov 2025 20:27:41 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v4]
In-Reply-To: <hHCto7awcMiCRgApOPp3OEpbrGy5BcQAVnwhVAyBwH0=.d8974829-8f29-491c-b09d-ce3e2e544463@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <e9iXm-BSdvvUoZQK3aAarNc0ER3GwByVS9UorOyeyJs=.cab06bfc-81be-4f9c-ac06-b142af67db0f@github.com>
 <HqL4iMPA3RNYPXe3qWGZajhaEddQEnU4wHmo--Wk0a8=.484a4841-7593-4d57-87bf-6723689a8803@github.com>
 <hHCto7awcMiCRgApOPp3OEpbrGy5BcQAVnwhVAyBwH0=.d8974829-8f29-491c-b09d-ce3e2e544463@github.com>
Message-ID: <VtpwemFcbpFE0MfmBirqkyqvjWyoIqUvk-biNoPdxms=.1aa009e3-d9b1-4bf3-a3ed-64ac68dbc25e@github.com>

On Tue, 30 Sep 2025 08:12:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 2281:
>> 
>>> 2279:       }
>>> 2280:     } else if (match_option(option, "--illegal-final-field-mutation=", &tail)) {
>>> 2281:       if (strcmp(tail, "allow") == 0 || strcmp(tail, "warn") == 0 || strcmp(tail, "debug") == 0 || strcmp(tail, "deny") == 0) {
>> 
>> Is the `jdk.module.illegal.final.field.mutation` property intended as a public API? If so, where is it documented?
>
> System properties are used to "communicate" the value of options from the VM to the library code. All internal/undocumented.  There is a test in mutateFinal/cli/CommandLineTests.java that checks that specifying the system property on the command line is not effective.

In my followup investigation for how InternalProperty/internal() flag really works, I noted it has been effectively broken since the recent updates - back in 2018, the referenced VM.saveAndRemoveProperties is gone, and now filtering is done by System.createProperties. We should probably address that in another RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2511752805

From valeriep at openjdk.org  Mon Nov 10 21:09:16 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 10 Nov 2025 21:09:16 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v3]
In-Reply-To: <eQ1jPLPTAvFHcnLV0ryiyQi7AjciIyPy4taaoBKjWYQ=.c6265e92-7d5a-4f34-aa14-5532be7cd632@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <1K8M1GYvFvmBssknqrQryPA4kc5_AlOsmgYnMf9l2Gk=.da65851b-d899-44a9-af71-44a522ea8c81@github.com>
 <RD7FJyMLuInL1_7LrqcGfnNhRUR3NLXlWLYrT4MaPtw=.6067805d-e779-4fed-99ad-1df07d86b419@github.com>
 <vyoSTeQYTy_d76ZiJEG2y1C-cf_rLOpJsJ5Euymc3V8=.b90de6f2-9c53-4089-8616-95873ac54f09@github.com>
 <NyUoP_76sD6GN8gfaXzV5oZ1QsYFkgNpWtzBPGi0kmE=.764acaca-dde9-42bf-bf2a-e58b66dd068b@github.com>
 <1xCoDp3OsBuejxUrI0rOVhYcpxgjA8NJuiEXQCxO8cc=.523a9b43-a4f5-44cf-bf30-934151ac7e23@github.com>
 <-mejkXqA8reXQ-7ZdpJuq1O6CN8nrpQKBXc1lgotPmM=.e47834dc-edb2-4b34-a290-ac26276d6201@github.com>
 <eQ1jPLPTAvFHcnLV0ryiyQi7AjciIyPy4taaoBKjWYQ=.c6265e92-7d5a-4f34-aa14-5532be7cd632@github.com>
Message-ID: <P6I_1vNPFRfXeH1bSjwf3denh5IHm0FxW8ibF3eJDNU=.54939977-9eb3-432a-909d-8a88ebbb80c4@github.com>

On Mon, 10 Nov 2025 13:53:11 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Switching from a byte[16][16] to a byte[256] SBOX would still increase performance by 1.24% for the AESReinit benchmark w/o sacrificing memory.
>
>> Yes, this would definitely speed up key schedule generation, but at the cost of additional memory; +768 bytes per instance, where the total AES cipher would be 1,268 bytes more per instance than the original Cryptix implementation.
> 
> I don't think that when even a Raspberry Pi comes with gigabytes of memory, a 1k increase in static data size (or even in per instance data size) should be an issue to consider. On the other hand, a 1-2% speed increase in a rarely called function is also insignificant, so if you want to keep things unchanged here, I won't object to it.

Interesting idea.... So, the int[256] vs byte[256] speedup is due to less byte->int conversion? The values in both arrays are essentially the same, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2511970014

From valeriep at openjdk.org  Mon Nov 10 21:16:07 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 10 Nov 2025 21:16:07 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v3]
In-Reply-To: <oq0BbR25u2UT_8MBMsS09nMvWrsvEqIX5WQ5V09FIBg=.a8eedcb9-d8d0-4fcd-9a10-c8c5a256f034@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <oq0BbR25u2UT_8MBMsS09nMvWrsvEqIX5WQ5V09FIBg=.a8eedcb9-d8d0-4fcd-9a10-c8c5a256f034@github.com>
Message-ID: <FU9J88d-pFaPKcQFIjadoRCz6cZC2ZBDcLUGS_UuujM=.af5e8bfd-b3d3-4714-8fcb-3536fa21cbb8@github.com>

On Sun, 9 Nov 2025 04:31:51 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
>> 
>> Thank you @jnimeh for catching the unnecessary byte mask!
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up comments - take two

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 974:

> 972:      * Generate the inverse cipher round keys.
> 973:      *
> 974:      * @param w [in] the targeted word for substituion.

nit: substitution

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 975:

> 973:      *
> 974:      * @param w [in] the targeted word for substituion.
> 975:      * @param rounds [in] the number rounds for generating the round keys.

nit: missing "of"?

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1011:

> 1009: 
> 1010:     /**
> 1011:      * Subtitute the word as a step of key expansion.

nit: Substitute

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1013:

> 1011:      * Subtitute the word as a step of key expansion.
> 1012:      *
> 1013:      * @param word [in] the targeted word for substituion.

nit: substitution

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2511986644
PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2511988103
PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2511982055
PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2511983052

From duke at openjdk.org  Mon Nov 10 22:55:08 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Mon, 10 Nov 2025 22:55:08 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v3]
In-Reply-To: <P6I_1vNPFRfXeH1bSjwf3denh5IHm0FxW8ibF3eJDNU=.54939977-9eb3-432a-909d-8a88ebbb80c4@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <1K8M1GYvFvmBssknqrQryPA4kc5_AlOsmgYnMf9l2Gk=.da65851b-d899-44a9-af71-44a522ea8c81@github.com>
 <RD7FJyMLuInL1_7LrqcGfnNhRUR3NLXlWLYrT4MaPtw=.6067805d-e779-4fed-99ad-1df07d86b419@github.com>
 <vyoSTeQYTy_d76ZiJEG2y1C-cf_rLOpJsJ5Euymc3V8=.b90de6f2-9c53-4089-8616-95873ac54f09@github.com>
 <NyUoP_76sD6GN8gfaXzV5oZ1QsYFkgNpWtzBPGi0kmE=.764acaca-dde9-42bf-bf2a-e58b66dd068b@github.com>
 <1xCoDp3OsBuejxUrI0rOVhYcpxgjA8NJuiEXQCxO8cc=.523a9b43-a4f5-44cf-bf30-934151ac7e23@github.com>
 <-mejkXqA8reXQ-7ZdpJuq1O6CN8nrpQKBXc1lgotPmM=.e47834dc-edb2-4b34-a290-ac26276d6201@github.com>
 <eQ1jPLPTAvFHcnLV0ryiyQi7AjciIyPy4taaoBKjWYQ=.c6265e92-7d5a-4f34-aa14-5532be7cd632@github.com>
 <P6I_1vNPFRfXeH1bSjwf3denh5IHm0FxW8ibF3eJDNU=.54939977-9eb3-432a-909d-8a88ebbb80c4@github.com>
Message-ID: <PLX6K3lDZkhFEd7q9dpV5oNN_FRreSx-kzBXqIRA3Sg=.05252142-da68-4a08-a051-0e9f836496aa@github.com>

On Mon, 10 Nov 2025 21:06:16 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>>> Yes, this would definitely speed up key schedule generation, but at the cost of additional memory; +768 bytes per instance, where the total AES cipher would be 1,268 bytes more per instance than the original Cryptix implementation.
>> 
>> I don't think that when even a Raspberry Pi comes with gigabytes of memory, a 1k increase in static data size (or even in per instance data size) should be an issue to consider. On the other hand, a 1-2% speed increase in a rarely called function is also insignificant, so if you want to keep things unchanged here, I won't object to it.
>
> Interesting idea.... So, the int[256] vs byte[256] speedup is due to less byte->int conversion? The values in both arrays are essentially the same, right?

Yes, the values are repeated per array element for int[256], but doesn't require an additional left shift operation unlike the byte[256] design.  TI4[] is the inverse substitution transform of the int[256] design.  Whereas byte[256]  is faster than the byte[16][16] design because of the addition shift operation for indexing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2512239069

From duke at openjdk.org  Mon Nov 10 23:02:08 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Mon, 10 Nov 2025 23:02:08 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v3]
In-Reply-To: <FU9J88d-pFaPKcQFIjadoRCz6cZC2ZBDcLUGS_UuujM=.af5e8bfd-b3d3-4714-8fcb-3536fa21cbb8@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <oq0BbR25u2UT_8MBMsS09nMvWrsvEqIX5WQ5V09FIBg=.a8eedcb9-d8d0-4fcd-9a10-c8c5a256f034@github.com>
 <FU9J88d-pFaPKcQFIjadoRCz6cZC2ZBDcLUGS_UuujM=.af5e8bfd-b3d3-4714-8fcb-3536fa21cbb8@github.com>
Message-ID: <0yCu6ieN7YE3RiGJ_oFqOVexmKtc2gVpPXvOBZt7Plc=.ad0c13a7-f06a-42c9-8add-7372322713dd@github.com>

On Mon, 10 Nov 2025 21:13:10 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up comments - take two
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 974:
> 
>> 972:      * Generate the inverse cipher round keys.
>> 973:      *
>> 974:      * @param w [in] the targeted word for substituion.
> 
> nit: substitution

Updated.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 975:
> 
>> 973:      *
>> 974:      * @param w [in] the targeted word for substituion.
>> 975:      * @param rounds [in] the number rounds for generating the round keys.
> 
> nit: missing "of"?

Updated.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1011:
> 
>> 1009: 
>> 1010:     /**
>> 1011:      * Subtitute the word as a step of key expansion.
> 
> nit: Substitute

Updated.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1013:
> 
>> 1011:      * Subtitute the word as a step of key expansion.
>> 1012:      *
>> 1013:      * @param word [in] the targeted word for substituion.
> 
> nit: substitution

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2512255650
PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2512257025
PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2512254700
PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2512255257

From duke at openjdk.org  Mon Nov 10 23:33:49 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Mon, 10 Nov 2025 23:33:49 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v4]
In-Reply-To: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
Message-ID: <MZzzlVN6XFGXICof0wwa_jdIivbteahC9IDiE2GRc-4=.fe3d9280-62b7-4ab1-99d5-6d41345cfe56@github.com>

> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
> 
> Thank you @jnimeh for catching the unnecessary byte mask!

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

  Update for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28188/files
  - new: https://git.openjdk.org/jdk/pull/28188/files/55e052f6..fc2d1662

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

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

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

From valeriep at openjdk.org  Tue Nov 11 00:44:06 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 11 Nov 2025 00:44:06 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v4]
In-Reply-To: <MZzzlVN6XFGXICof0wwa_jdIivbteahC9IDiE2GRc-4=.fe3d9280-62b7-4ab1-99d5-6d41345cfe56@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <MZzzlVN6XFGXICof0wwa_jdIivbteahC9IDiE2GRc-4=.fe3d9280-62b7-4ab1-99d5-6d41345cfe56@github.com>
Message-ID: <wV-GtGUMUB8hIbPDuS2HvZxnCn7gKf3wFs6FgVdu6LI=.54e0fd7b-d3d5-4cdf-bdb6-9efa887ef9d0@github.com>

On Mon, 10 Nov 2025 23:33:49 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
>> 
>> Thank you @jnimeh for catching the unnecessary byte mask!
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update for code review comments from @valeriepeng

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28188#pullrequestreview-3445740732

From duke at openjdk.org  Tue Nov 11 04:50:03 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 11 Nov 2025 04:50:03 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v4]
In-Reply-To: <TcaEKkGJ1oo5YQdHOX6lf-2mVAyUmP2U9B2aJ0HFeNg=.207e9bdd-ea33-4396-8e5b-9caaed9d4689@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <nlVAp9HzECZytsa9XJoK-InhksKafkHV71z5INj7A6c=.fc21930a-ac64-4910-858c-f7ae7e3cc607@github.com>
 <h6rBQOMdlmd81eJe5-FkuxxT2qpf-LU8YUzal0s8REs=.98550d2a-4512-42bd-a2ae-42c93a7bd16d@github.com>
 <TcaEKkGJ1oo5YQdHOX6lf-2mVAyUmP2U9B2aJ0HFeNg=.207e9bdd-ea33-4396-8e5b-9caaed9d4689@github.com>
Message-ID: <yM-UybXvqH3Z3TmK4n8keMwd1afFkxDZectUyb3zt4g=.b9823960-8b9c-4675-a6e2-aa32510af731@github.com>

On Sat, 8 Nov 2025 17:07:55 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> I believe my original changes here utilize a "MergeStore" technique that the compiler optimizes.  I've asked @minborg to see if I got this right.  To verify the optimization here, I used the separate local int variable technique and saw a 0.7% decrease in benchmark performance.
>
> Well, your experiment answers my question.  Unless @minborg says otherwise I'm fine with what you have.  You're already seeing improvements so that's great.

At first look, @minborg believes that "MergeStore" is not being activated here because the xors are being performed at the "element level".  So the speedup is more likely to come from eliminating the temp object and the extra instructions for the assignments and array copy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28188#discussion_r2512826553

From duke at openjdk.org  Tue Nov 11 05:40:55 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 11 Nov 2025 05:40:55 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v5]
In-Reply-To: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
Message-ID: <yV6tuPGN7WNTavPtrI_Yq_09vkkKZDfWeeq_cizJKxI=.4da4779a-1e17-4619-8c8f-ba1c0396a8ca@github.com>

> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
> 
> Thank you @jnimeh for catching the unnecessary byte mask!

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

  Comment updates - take three

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28188/files
  - new: https://git.openjdk.org/jdk/pull/28188/files/fc2d1662..2718a125

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

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

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

From pminborg at openjdk.org  Tue Nov 11 08:01:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 11 Nov 2025 08:01:08 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v24]
In-Reply-To: <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>
Message-ID: <vqHNGKFE_YgCSlw0IFjWYKp7jxAEQGXAG8EkvjwyI78=.e505b8b6-ed21-4cb8-aa39-978db6cc0bef@github.com>

On Mon, 10 Nov 2025 14:59:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @AOTSafeClassInitializer

As per https://github.com/openjdk/jdk/pull/27605/commits/e479cb4bbe54f3e0caa129cc45aec2ec2bffd9cf, this PR passes tier 1-4 on multiple platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3515424778

From alanb at openjdk.org  Tue Nov 11 08:36:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 08:36:12 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
Message-ID: <TFENi52GHOakL---BDTzGKEB6gXwyUBp-4EJYbmLKjM=.40aabbe9-cade-4568-9825-118bf58bfddd@github.com>

On Mon, 10 Nov 2025 20:11:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
>> 
>>  - Merge branch 'master' into JDK-8353835
>>  - Fix typo in test comment
>>  - Merge branch 'master' into JDK-8353835
>>  - Merge branch 'master' into JDK-8353835
>>  - Suppress warnings from some tests
>>  - Change -Xcheck:jni to be warning rather than fatal error
>>  - Merge branch 'master' into JDK-8353835
>>  - Simplify filter
>>  - Merge branch 'master' into JDK-8353835
>>  - Update Xcheck:jni description
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02
>
> src/java.base/share/classes/java/lang/reflect/doc-files/MutationMethods.html line 56:
> 
>> 54:     <li><a href="../Field.html#setDouble(java.lang.Object,double)">
>> 55:         java.lang.reflect.Field.setDouble(Object, double)</a></li>
>> 56:     <li><a href="{@docRoot}/java.base/java/lang/invoke/MethodHandles.Lookup.html#unreflectSetter(java.lang.reflect.Field)">
> 
> Nit: Since javadoc process tags here, you could just use `{@link Field#set java.lang.reflect.Field.set(Object, Object)}` instead of full-fledged a tags.

I wasn't aware that javadoc allowed this in .html docs-files, thanks for the tip.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2513298915

From alanb at openjdk.org  Tue Nov 11 09:00:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 09:00:11 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
Message-ID: <1aQu6ywsFGh3TMN3XjBevjqmTFP7CdQRrbzQtuN-wfI=.814c0236-caa8-469a-9a42-dfafb56ebf64@github.com>

On Mon, 10 Nov 2025 20:24:53 GMT, Chen Liang <liach at openjdk.org> wrote:

> I still wonder about the decision for JNI to call final Field.set with an unconditional export check instead of an unconditional open check - the open check is done for all Java code already.

It's aligned with setAccessible. It's a bit of corner case, but if a JNI attached thread invokes setAccessible with no java frames on the stack, then it specified to only succeed if the API element is public and declared in a public class in an exported package.

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

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

From d.yamazaki at peya.tokyo  Tue Nov 11 11:17:48 2025
From: d.yamazaki at peya.tokyo (Daisuke Yamazaki)
Date: Tue, 11 Nov 2025 20:17:48 +0900
Subject: Proposal: 8338093: Localization of yes/no options in console input
In-Reply-To: <BLAPR10MB4897CCAE383CBCA297D613C68BCEA@BLAPR10MB4897.namprd10.prod.outlook.com>
References: <19a6dbae0ad.7e56af0a221616.1073185985223008803@peya.tokyo>
 <12b66ef8-0802-41ae-8d34-84a414e51e43@oracle.com>
 <823F82ED-F242-48AC-9145-83747AE5BAC0@oracle.com>
 <6e8a4971-f702-44e7-8621-566d1273382a@oracle.com>
 <B4509423-7CBA-4810-8C0C-81904D5F1882@oracle.com>
 <BLAPR10MB4897CCAE383CBCA297D613C68BCEA@BLAPR10MB4897.namprd10.prod.outlook.com>
Message-ID: <19a72a2e116.34c3587b964650.6882619064763357505@peya.tokyo>

Thanks Weijun and Justin for the clarification.

I will leave the localised files as they are and let the dedicated localisation team handle them.

Best regards,  
D. Yamazaki


---- On Tue, 11 Nov 2025 07:29:08 +0900 Justin Lu <justin.lu at oracle.com> wrote ---

 > Weijun is right that we do not manually update the localized files ourselves. I would suggest leaving a comment in the English properties file on the line above the key/val with the options that should not be translated. For example, "#L10N: do not localize:
 >  [no]?.
 > 
 > Thanks,
 > Justin

From egahlin at openjdk.org  Tue Nov 11 12:40:21 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 11 Nov 2025 12:40:21 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v7]
In-Reply-To: <uIxLQJE7F6w8qDRRX1NWF4kc8iHQe5RTNTV0JBTLF-k=.01d912c3-af44-4a02-8d48-b62141fdb20a@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
 <k6_-Fsk4Q3cQH8q1j3qAVbhkuDQXtWOcBn-c1QyBsFY=.03be8309-396e-46d5-9c0e-d4cf29fd327a@github.com>
 <uIxLQJE7F6w8qDRRX1NWF4kc8iHQe5RTNTV0JBTLF-k=.01d912c3-af44-4a02-8d48-b62141fdb20a@github.com>
Message-ID: <r6Fj8N9_nN1-XJo171i_-vxJ66j44jav2y5L1oovrhw=.92ca7ab8-5f35-4798-924a-c4dc0001b1d7@github.com>

On Tue, 7 Oct 2025 07:59:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The APIs are in Field and Lookup so having the API method as the top frame is useful. It would be possible to reduce the filter to `{ "java.lang.reflect.ReflectAccess", "java.lang.invoke.MethodHandles$Lookup::unreflectField" }` with determineStackTraceOffset returning 6 but it's too fiddly and requires knowing about two "faraway places" when doing any refactoring. Mutating final fields is the slow path so performance is not a concern. So I think the trade-off to keep it as maintainable as possible is okay. The test checks the top frame and also scans the StackFilter to ensure the class is visible and that any filter value with a method name at least names a method that is declared in the class.

 We shouldn't push it as high as 6, that's fragile, but the offer(...) method could be skipped immediately if the offset is bumped. Class filters avoid specifying individual methods, which are more likely to be refactored.

I can see the argument for not having the user's method as the top frame. A user may get a quick hint (instead of looking at the line number) if they see something like setInt(...), but this doesn?t work as well with tooling when you want to group stack traces by top frame, for example in a tree view. You typically want to see the application frame and then expand the nodes. If setInt, setFloat, setLong, etc. appear as the top nodes, users have to click and expand every setter, instead of seeing an aggregated list directly of packages, classes, or methods where finals are modified.

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

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

From alanb at openjdk.org  Tue Nov 11 14:34:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 14:34:33 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
Message-ID: <unQ-BEV3uyKQItzqb09Vf12E2zQRgy-4LUiAGTlfRNg=.1383bb38-9b6b-4b9e-8a73-fa59d3767944@github.com>

On Mon, 10 Nov 2025 19:26:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
>> 
>>  - Merge branch 'master' into JDK-8353835
>>  - Fix typo in test comment
>>  - Merge branch 'master' into JDK-8353835
>>  - Merge branch 'master' into JDK-8353835
>>  - Suppress warnings from some tests
>>  - Change -Xcheck:jni to be warning rather than fatal error
>>  - Merge branch 'master' into JDK-8353835
>>  - Simplify filter
>>  - Merge branch 'master' into JDK-8353835
>>  - Update Xcheck:jni description
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02
>
> test/jdk/java/lang/reflect/Field/mutateFinals/cli/CommandLineTest.java line 234:
> 
>> 232:     @Test
>> 233:     void testSetPropertyToAllow() throws Exception {
>> 234:         test("setSystemPropertyToAllow+testFieldSetInt")
> 
> I thought this was setting the property before the VM boot. Can we have another test that does something like:
> 
> test("testFieldSetInt", "-Djdk.module.illegal.final.field.mutation=allow")
> 
> Which I think is closer to what @vy asks for.

The test sets the internal property at runtime in the launched VM. You are right that another test could launch with the internal property set on the command line with -D.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2514460463

From liach at openjdk.org  Tue Nov 11 15:04:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Nov 2025 15:04:38 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <1aQu6ywsFGh3TMN3XjBevjqmTFP7CdQRrbzQtuN-wfI=.814c0236-caa8-469a-9a42-dfafb56ebf64@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
 <1aQu6ywsFGh3TMN3XjBevjqmTFP7CdQRrbzQtuN-wfI=.814c0236-caa8-469a-9a42-dfafb56ebf64@github.com>
Message-ID: <-nBSdu-3kaHjMyaZTD8epppqP4EjowO5kvo3eTakJdg=.bec77fef-edc2-48b1-b961-d646fc994810@github.com>

On Tue, 11 Nov 2025 08:56:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's aligned with setAccessible. It's corner case of course but if a JNI attached thread invokes setAccessible with no java frames on the stack, then it is specified to only succeed if the API element is public and declared in a public class in an exported package.

Consider setting the field `java.lang.constant.DirectMethodHandleDesc$Kind.refKind` (public final instance field in public class in exported, non-open package) in 3 ways:
1. `Field.setAccessible` + `set` in Java code: Now `set` fails without `--add-opens` (not open)
2. Performing the 2 Java calls in JNI: Completely permitted (exported)
3. jni_Set##Result##Field: Completely permitted, one warning message

I find it a bit weird that 1 is inconsistent with 2, but given case 3, we have plenty of time to restrict 2 and 3 together in future releases.

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

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

From rgangadhar at openjdk.org  Tue Nov 11 15:12:41 2025
From: rgangadhar at openjdk.org (Ramesh Bhagavatam Gangadhar)
Date: Tue, 11 Nov 2025 15:12:41 GMT
Subject: RFR: 8357874: UNLIMTED_CRYPTO typo in class description of
 JceSecurity.java.template
Message-ID: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>

Very Trivial Changing in JceSecurity.java.template

Changed from UNLIMTED_CRYPTO to
                          UNLIMITED_CRYPTO

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

Commit messages:
 - 8357874: UNLIMTED_CRYPTO typo in class description of JceSecurity.java.template

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

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

From rgangadhar at openjdk.org  Tue Nov 11 15:12:42 2025
From: rgangadhar at openjdk.org (Ramesh Bhagavatam Gangadhar)
Date: Tue, 11 Nov 2025 15:12:42 GMT
Subject: RFR: 8357874: UNLIMTED_CRYPTO typo in class description of
 JceSecurity.java.template
In-Reply-To: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>
References: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>
Message-ID: <TOPQ31ZBk1L6XYC0Bzp3Umq8_oQAuPwqKrDx4JoSgpY=.e31cabd1-9604-4982-bfef-00c85592a8e7@github.com>

On Tue, 11 Nov 2025 15:03:06 GMT, Ramesh Bhagavatam Gangadhar <rgangadhar at openjdk.org> wrote:

> Very Trivial Changing in JceSecurity.java.template
> 
> Changed from UNLIMTED_CRYPTO to
>                           UNLIMITED_CRYPTO

@seanjmullan : pls review this PR

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

PR Comment: https://git.openjdk.org/jdk/pull/28238#issuecomment-3517358578

From vklang at openjdk.org  Tue Nov 11 17:33:29 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 11 Nov 2025 17:33:29 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
Message-ID: <OMhBQoI-U8WEuxS4BDx0K7cgwZwVZkP92eM0MDfHQus=.ca8f413c-1ba1-4c99-9ace-c7f5010bd0d8@github.com>

On Mon, 10 Nov 2025 10:06:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Fix typo in test comment
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02

src/java.base/share/classes/java/lang/reflect/doc-files/MutationMethods.html line 79:

> 77: </body>
> 78: 
> 79: </body>

Many-body problem?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2515065507

From alanb at openjdk.org  Tue Nov 11 17:48:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 17:48:43 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v11]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <Ddyd0WMnGK8wiiCIHJRAOC0kDj6oJNxyJoZXkOB28Ow=.fcc2c280-6eb4-4819-8b29-a18496f7826b@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:

 - Remove dup end body tag
 - Change FinalFieldMutationEvent so that caller is top frame in stack trace
 - Merge branch 'master' into JDK-8353835
 - Review feedback: Add tests for setting internal properties, improve links in Mutation methods page
 - Merge branch 'master' into JDK-8353835
 - Merge branch 'master' into JDK-8353835
 - Fix typo in test comment
 - Merge branch 'master' into JDK-8353835
 - Merge branch 'master' into JDK-8353835
 - Suppress warnings from some tests
 - ... and 40 more: https://git.openjdk.org/jdk/compare/2902436f...b22947c7

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

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=10
  Stats: 4882 lines in 71 files changed: 4697 ins; 54 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

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

From alanb at openjdk.org  Tue Nov 11 17:48:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 17:48:44 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v7]
In-Reply-To: <r6Fj8N9_nN1-XJo171i_-vxJ66j44jav2y5L1oovrhw=.92ca7ab8-5f35-4798-924a-c4dc0001b1d7@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
 <k6_-Fsk4Q3cQH8q1j3qAVbhkuDQXtWOcBn-c1QyBsFY=.03be8309-396e-46d5-9c0e-d4cf29fd327a@github.com>
 <uIxLQJE7F6w8qDRRX1NWF4kc8iHQe5RTNTV0JBTLF-k=.01d912c3-af44-4a02-8d48-b62141fdb20a@github.com>
 <r6Fj8N9_nN1-XJo171i_-vxJ66j44jav2y5L1oovrhw=.92ca7ab8-5f35-4798-924a-c4dc0001b1d7@github.com>
Message-ID: <CGw008kTqnsokeBHs_NFQ6KpJzNUjo32UWvQyKSyc6E=.10bba2b2-2dec-4861-aa87-2fb4a050495f@github.com>

On Tue, 11 Nov 2025 12:37:59 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I can see the argument for not having the user's method as the top frame. A user may get a quick hint (instead of looking at the line number) if they see something like setInt(...), but this doesn?t work as well with tooling when you want to group stack traces by top frame, for example in a tree view. You typically want to see the application frame and then expand the nodes. If setInt, setFloat, setLong, etc. appear as the top nodes, users have to click and expand every setter, instead of seeing an aggregated list directly of packages, classes, or methods where finals are modified.

@egahlin and I discussed this and agreed to have the top-frame of the stack trace recorded with the event be the caller's method. This allows the stack filter include j.l.r.Field with listing method names. We might revisit this later to add further fields to the event to indicate an unreflect op and/or the field type.

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

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

From alanb at openjdk.org  Tue Nov 11 17:48:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 17:48:45 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <-nBSdu-3kaHjMyaZTD8epppqP4EjowO5kvo3eTakJdg=.bec77fef-edc2-48b1-b961-d646fc994810@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
 <1aQu6ywsFGh3TMN3XjBevjqmTFP7CdQRrbzQtuN-wfI=.814c0236-caa8-469a-9a42-dfafb56ebf64@github.com>
 <-nBSdu-3kaHjMyaZTD8epppqP4EjowO5kvo3eTakJdg=.bec77fef-edc2-48b1-b961-d646fc994810@github.com>
Message-ID: <qrd3tLUbQ68_OK8kno-rLI4guFMYtbWZarfglXPi3SY=.ccf5110a-3300-4609-aca0-ee6e2b9af2d1@github.com>

On Tue, 11 Nov 2025 15:01:14 GMT, Chen Liang <liach at openjdk.org> wrote:

> we have plenty of time to restrict 2 and 3 together in future releases.

There isn't any proposal to change JNI. It has never done any access checking. The only change is to -Xcheck:jni warning and logging to catch JNI code that is mutating finals. Once we dial up to have mutating finals be denied by default then we might dial up -Xcheck:jni at the same time to make it fatal.

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

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

From alanb at openjdk.org  Tue Nov 11 17:48:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Nov 2025 17:48:49 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
Message-ID: <HFicJcbb0TWbdaiuH3biej0hbUE8lEmWwkvS5aco6zk=.5d3d6b50-b758-49c2-81af-a43315c9a52e@github.com>

On Mon, 10 Nov 2025 20:12:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
>> 
>>  - Merge branch 'master' into JDK-8353835
>>  - Fix typo in test comment
>>  - Merge branch 'master' into JDK-8353835
>>  - Merge branch 'master' into JDK-8353835
>>  - Suppress warnings from some tests
>>  - Change -Xcheck:jni to be warning rather than fatal error
>>  - Merge branch 'master' into JDK-8353835
>>  - Simplify filter
>>  - Merge branch 'master' into JDK-8353835
>>  - Update Xcheck:jni description
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/066810c8...6671ae02
>
> src/java.base/share/classes/java/lang/reflect/doc-files/MutationMethods.html line 72:
> 
>> 70: <em>illegal</em>.
>> 71: 
>> 72: The command line option <code>--illegal-final-field-mutation</code> controls how illegal
> 
> Missing `<p>`?

Just a blank line, it's all the one paragraph.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2515095873

From duke at openjdk.org  Wed Nov 12 01:40:12 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 12 Nov 2025 01:40:12 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v10]
In-Reply-To: <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com>
Message-ID: <kWAAVX9IaV4MYzRhGUKnIOMBigUHonFtFKYir3Yd5Eo=.bab44be0-25e9-431a-9119-e8a37b10808c@github.com>

On Mon, 3 Nov 2025 18:50:37 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address second set of @erikj79's build comments

make/test/JtregNativeJdk.gmk line 126:

> 124:   # macOS: build with system krb5 and disable deprecation warnings
> 125:   BUILD_JDK_JTREG_LIBRARIES_LDFLAGS_libNativeCredentialCacheHelper := -lkrb5 -lcom_err
> 126:   BUILD_JDK_JTREG_LIBRARIES_CFLAGS_libNativeCredentialCacheHelper := -Wno-deprecated-declarations

Why doesn't the macosx target use the KRB5* variables as well?

src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2024, Oracle and/or its affiliates. All rights reserved.

nit: update copyright year

src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 335:

> 333:             if (OperatingSystem.isWindows() ||
> 334:                     OperatingSystem.isMacOS() ||
> 335:                         OperatingSystem.isLinux()) {

nit: extra tab?

src/java.security.jgss/share/native/libkrb5shared/nativeccache.c line 2:

> 1: /*
> 2:  * Copyright (c) 2011, 2024, Oracle and/or its affiliates. All rights reserved.

nit: update copyright year

test/jdk/sun/security/krb5/native/NativeCacheTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8123456

`@bug` annotation not relevant here

test/jdk/sun/security/krb5/native/libNativeCredentialCacheHelper.c line 71:

> 69:     if (utf_chars == NULL) return NULL;
> 70: 
> 71:     char *result = strdup(utf_chars);

Should check for NULL here

test/jdk/sun/security/krb5/native/libNativeCredentialCacheHelper.c line 143:

> 141: }
> 142: 
> 143: 

nit: extra line

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2516387392
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2516256982
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2516241205
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2516233000
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2516271877
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2513002208
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2513007140

From alanb at openjdk.org  Wed Nov 12 08:21:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Nov 2025 08:21:12 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v10]
In-Reply-To: <-nBSdu-3kaHjMyaZTD8epppqP4EjowO5kvo3eTakJdg=.bec77fef-edc2-48b1-b961-d646fc994810@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <PpU3xdWHq7DcpiGuRgOVSe_nZBtZb0gM0J1XTuRXoyM=.67d11cd2-050b-4988-a996-bdbcb4f85267@github.com>
 <VYTB17gugA1qillo0s3f5MvoYjEdAdUjrXTwfOP8Dgk=.01fbf53b-2cd0-46dd-bc36-dd05a97fd01e@github.com>
 <1aQu6ywsFGh3TMN3XjBevjqmTFP7CdQRrbzQtuN-wfI=.814c0236-caa8-469a-9a42-dfafb56ebf64@github.com>
 <-nBSdu-3kaHjMyaZTD8epppqP4EjowO5kvo3eTakJdg=.bec77fef-edc2-48b1-b961-d646fc994810@github.com>
Message-ID: <t_h54JLqwtUPhfVq8gZSdua9Ad-6x8a00NwDq1Qu6y4=.9b25ed17-bfb4-4039-9c27-a43f6c0e1bdc@github.com>

On Tue, 11 Nov 2025 15:01:14 GMT, Chen Liang <liach at openjdk.org> wrote:

> > It's aligned with setAccessible. It's corner case of course but if a JNI attached thread invokes setAccessible with no java frames on the stack, then it is specified to only succeed if the API element is public and declared in a public class in an exported package.
> 
> Consider setting the field `java.lang.constant.DirectMethodHandleDesc$Kind.refKind` (public final instance field in public class in exported, non-open package) in 3 ways:
> 
> 1. `Field.setAccessible` + `set` in Java code: Now `set` fails without `--add-opens` (not open)

There is a spec issue here. Field.set on final instance fields should align with setAccessible. So assuming setAccessible has succeeded, final field mutation for the caller module is enabled, then Field.set should be specified to succeed when the field is public and its declaring class is public and in a package that its module exports "statically" to the caller module.  Right now, we specify that the package must be statically open to the caller which is more than setAccessible requires for this case. I agree this may be surprising. I've drafted spec (and implementation) changes to align them but I want to check with Alex and Ron as it doing it now would require changing a line in the JEP too.

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

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

From pminborg at openjdk.org  Wed Nov 12 10:07:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Nov 2025 10:07:39 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:

 - Clarify toString spec
 - Merge branch 'master' into lazy-constants
 - Add @AOTSafeClassInitializer
 - Address comments in PR
 - Fix merge mistake
 - Merge master
 - Rework toString implementations
 - Update after doc comments
 - Merge branch 'master' into lazy-constants
 - Revert the AbstractMap.keySet @Stable annotation
 - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

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

Changes: https://git.openjdk.org/jdk/pull/27605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=24
  Stats: 8445 lines in 60 files changed: 3836 ins; 4490 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From duke at openjdk.org  Wed Nov 12 11:38:05 2025
From: duke at openjdk.org (Nick Hall)
Date: Wed, 12 Nov 2025 11:38:05 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v10]
In-Reply-To: <kWAAVX9IaV4MYzRhGUKnIOMBigUHonFtFKYir3Yd5Eo=.bab44be0-25e9-431a-9119-e8a37b10808c@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com>
 <kWAAVX9IaV4MYzRhGUKnIOMBigUHonFtFKYir3Yd5Eo=.bab44be0-25e9-431a-9119-e8a37b10808c@github.com>
Message-ID: <CDJXIDK2yO4xg-huM12_Ey7XpLEEdgKwCPIdyo_ffjI=.17be2359-11e3-47b2-a93a-dd1007a1c13e@github.com>

On Wed, 12 Nov 2025 00:13:27 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address second set of @erikj79's build comments
>
> src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 335:
> 
>> 333:             if (OperatingSystem.isWindows() ||
>> 334:                     OperatingSystem.isMacOS() ||
>> 335:                         OperatingSystem.isLinux()) {
> 
> nit: extra tab?

This is the overall structure currently:

            if (OperatingSystem.isWindows() ||
                    OperatingSystem.isMacOS() ||
                        OperatingSystem.isLinux()) {


Would you prefer the second two line up or all line up?  It _looks_ like generally the JDK source I've looked at would line them all up (although that's not what was there before!)?

> test/jdk/sun/security/krb5/native/libNativeCredentialCacheHelper.c line 143:
> 
>> 141: }
>> 142: 
>> 143: 
> 
> nit: extra line

Thanks, fixed in next commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2517957978
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2517961143

From duke at openjdk.org  Wed Nov 12 11:42:06 2025
From: duke at openjdk.org (Nick Hall)
Date: Wed, 12 Nov 2025 11:42:06 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v10]
In-Reply-To: <kWAAVX9IaV4MYzRhGUKnIOMBigUHonFtFKYir3Yd5Eo=.bab44be0-25e9-431a-9119-e8a37b10808c@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com>
 <kWAAVX9IaV4MYzRhGUKnIOMBigUHonFtFKYir3Yd5Eo=.bab44be0-25e9-431a-9119-e8a37b10808c@github.com>
Message-ID: <uN4y18yZlnJfjoAUwQ83r83bnBfloknZxQqC5TSGavs=.aa7ca96c-b522-431a-8325-f3b09815afe7@github.com>

On Wed, 12 Nov 2025 01:36:19 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address second set of @erikj79's build comments
>
> make/test/JtregNativeJdk.gmk line 126:
> 
>> 124:   # macOS: build with system krb5 and disable deprecation warnings
>> 125:   BUILD_JDK_JTREG_LIBRARIES_LDFLAGS_libNativeCredentialCacheHelper := -lkrb5 -lcom_err
>> 126:   BUILD_JDK_JTREG_LIBRARIES_CFLAGS_libNativeCredentialCacheHelper := -Wno-deprecated-declarations
> 
> Why doesn't the macosx target use the KRB5* variables as well?

Only because I was trying to avoid making changes there, but you're right - the resultant value of this on MacOS would be the hard-coded set of libs there, so there's no harm in using at (and potentially some advantage to people building on MacOS against a non-system version of Kerberos).  Fixed in next commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2517970400

From duke at openjdk.org  Wed Nov 12 11:55:40 2025
From: duke at openjdk.org (Nick Hall)
Date: Wed, 12 Nov 2025 11:55:40 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v11]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Nick Hall has updated the pull request incrementally with one additional commit since the last revision:

  Attend to @smemery's code review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/8c8288a3..f4a8543f

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

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

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

From duke at openjdk.org  Wed Nov 12 11:58:03 2025
From: duke at openjdk.org (Nick Hall)
Date: Wed, 12 Nov 2025 11:58:03 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v10]
In-Reply-To: <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com>
Message-ID: <2Gf8L8DssBH2K1M8P_Fal_fzKJY3OpwCT8ZwLVmQgUA=.33912153-55a6-46de-9bb9-cac1f5c04f49@github.com>

On Mon, 3 Nov 2025 18:50:37 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address second set of @erikj79's build comments

@smemery have pushed fixes for your comments.  I've tested the changes on Linux, but don't have a Mac here today to test the build changes - so will attend to anything that fails in the CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3521561415

From weijun at openjdk.org  Wed Nov 12 12:42:24 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Nov 2025 12:42:24 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v48]
In-Reply-To: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
Message-ID: <mM_j0c5SgKmR7pbb7CqQXvZ7KEdwS86zXilFBoaufhg=.03bdbf1d-8315-43f2-9368-52a2b4c4c96c@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> <img alt="image" src="https://github.com/user-attachments/assets/df3b454d-2161-4036-9930-c4f84d887b31" />

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

  java style method names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/4d5b15f7..52c4d84b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=46-47

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

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

From vklang at openjdk.org  Wed Nov 12 12:54:34 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 12 Nov 2025 12:54:34 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v11]
In-Reply-To: <Ddyd0WMnGK8wiiCIHJRAOC0kDj6oJNxyJoZXkOB28Ow=.fcc2c280-6eb4-4819-8b29-a18496f7826b@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <Ddyd0WMnGK8wiiCIHJRAOC0kDj6oJNxyJoZXkOB28Ow=.fcc2c280-6eb4-4819-8b29-a18496f7826b@github.com>
Message-ID: <CbMHUboGTEm5WEWnHmGymb-rO9QVFU3c-QEsr0HeJlQ=.a711870b-91a3-4be0-8a78-814bfc649142@github.com>

On Tue, 11 Nov 2025 17:48:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
> 
>  - Remove dup end body tag
>  - Change FinalFieldMutationEvent so that caller is top frame in stack trace
>  - Merge branch 'master' into JDK-8353835
>  - Review feedback: Add tests for setting internal properties, improve links in Mutation methods page
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Fix typo in test comment
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Suppress warnings from some tests
>  - ... and 40 more: https://git.openjdk.org/jdk/compare/2902436f...b22947c7

src/java.base/share/classes/java/lang/reflect/Field.java line 1543:

> 1541:      * the given possibly-null caller.
> 1542:      */
> 1543:     private String finalFieldMutationWarning(Class<?> caller, boolean unreflect) {

It may make sense to have this method return a StringBuilder instance (and use it internally before returning it) as that would cut down on extra String-instance creation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2518192839

From weijun at openjdk.org  Wed Nov 12 14:19:25 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Nov 2025 14:19:25 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v11]
In-Reply-To: <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
Message-ID: <_qK2Pq7bH7zwkzKipujnNbQD8SH4t6Bamrt_lj2VaEM=.4c20d7ed-33e3-4dd4-a661-b640ff4c0b26@github.com>

On Wed, 12 Nov 2025 11:55:40 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Attend to @smemery's code review comments

test/jdk/sun/security/krb5/native/NativeCredentialCacheHelper.h line 1:

> 1: /* DO NOT EDIT THIS FILE - it is machine generated */

Even if this is machine generated, I suggest adding the copyright header as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518482935

From mullan at openjdk.org  Wed Nov 12 14:24:35 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 12 Nov 2025 14:24:35 GMT
Subject: RFR: 8357874: UNLIMTED_CRYPTO typo in class description of
 JceSecurity.java.template
In-Reply-To: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>
References: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>
Message-ID: <c2kBtyyeL5Ts52auO_QURTNOodHZSTnRc3u-9WT-5pQ=.c86dbb20-6b48-4a6a-b624-74bb4e3696c8@github.com>

On Tue, 11 Nov 2025 15:03:06 GMT, Ramesh Bhagavatam Gangadhar <rgangadhar at openjdk.org> wrote:

> Very Trivial Changing in JceSecurity.java.template
> 
> Changed from UNLIMTED_CRYPTO to
>                           UNLIMITED_CRYPTO

src/java.base/share/classes/javax/crypto/JceSecurity.java.template line 1:

> 1: /*

Update the last copyright date to 2025.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28238#discussion_r2518505310

From weijun at openjdk.org  Wed Nov 12 14:32:15 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Nov 2025 14:32:15 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v11]
In-Reply-To: <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
Message-ID: <-S7R7tafpyU8i0p6qkySw3Brq3_fVtv7ZJFUhx4yVUU=.145b6f0a-5a04-4a91-9f3a-cfa41599ec3d@github.com>

On Wed, 12 Nov 2025 11:55:40 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Attend to @smemery's code review comments

src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 536:

> 534:             System.loadLibrary("osxkrb5");
> 535:         } else if (OperatingSystem.isLinux()) {
> 536:             System.loadLibrary("linuxkrb5");

Can we use the same lib name on macOS and Linux?

test/jdk/sun/security/krb5/native/NativeCacheTest.java line 146:

> 144:         }
> 145: 
> 146:         // Fallback to the default cache if copying from file cache fails

Could this happen? Will there be unexpected ticket in the default cache?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518534368
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518524200

From vklang at openjdk.org  Wed Nov 12 14:35:54 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 12 Nov 2025 14:35:54 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v11]
In-Reply-To: <Ddyd0WMnGK8wiiCIHJRAOC0kDj6oJNxyJoZXkOB28Ow=.fcc2c280-6eb4-4819-8b29-a18496f7826b@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <Ddyd0WMnGK8wiiCIHJRAOC0kDj6oJNxyJoZXkOB28Ow=.fcc2c280-6eb4-4819-8b29-a18496f7826b@github.com>
Message-ID: <DlB7TLAa1cvtzrwptN3rNFbsFfqzRFGyNn074tnj2p4=.bc36884f-0a6a-4e6e-a957-7a7307eb8713@github.com>

On Tue, 11 Nov 2025 17:48:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
> 
>  - Remove dup end body tag
>  - Change FinalFieldMutationEvent so that caller is top frame in stack trace
>  - Merge branch 'master' into JDK-8353835
>  - Review feedback: Add tests for setting internal properties, improve links in Mutation methods page
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Fix typo in test comment
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Suppress warnings from some tests
>  - ... and 40 more: https://git.openjdk.org/jdk/compare/2902436f...b22947c7

src/java.base/share/man/java.md line 482:

> 480: 
> 481:     -   `allow`: This mode allows illegal final field mutation in all modules,
> 482:         without any warings.

Suggestion:

        without any warnings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2518551065

From weijun at openjdk.org  Wed Nov 12 14:55:23 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Nov 2025 14:55:23 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v11]
In-Reply-To: <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
Message-ID: <vGVwOgyVEqg6JQzk0Tg1MTjA-zFFikOZx-bsrQksWOk=.684e0eff-5f74-40ae-964b-ee30cb215fee@github.com>

On Wed, 12 Nov 2025 11:55:40 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Attend to @smemery's code review comments

test/jdk/sun/security/krb5/native/NativeCacheTest.java line 124:

> 122:      * Copy the TGT to an in-memory cache using JNI
> 123:      */
> 124:     private static String copyTGTToInMemoryCache() throws Exception {

All native methods are called here with the same order. Is it possible to just create one single native method and do everything inside?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518628852

From duke at openjdk.org  Wed Nov 12 15:15:25 2025
From: duke at openjdk.org (Nick Hall)
Date: Wed, 12 Nov 2025 15:15:25 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v11]
In-Reply-To: <-S7R7tafpyU8i0p6qkySw3Brq3_fVtv7ZJFUhx4yVUU=.145b6f0a-5a04-4a91-9f3a-cfa41599ec3d@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
 <-S7R7tafpyU8i0p6qkySw3Brq3_fVtv7ZJFUhx4yVUU=.145b6f0a-5a04-4a91-9f3a-cfa41599ec3d@github.com>
Message-ID: <w_2oXqrsmdZNNc8CQHS2r_aREToUhs1cQuTllVQJZok=.0aa6b8bc-23e8-46f4-be9f-673a3d846b00@github.com>

On Wed, 12 Nov 2025 14:28:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Attend to @smemery's code review comments
>
> src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 536:
> 
>> 534:             System.loadLibrary("osxkrb5");
>> 535:         } else if (OperatingSystem.isLinux()) {
>> 536:             System.loadLibrary("linuxkrb5");
> 
> Can we use the same lib name on macOS and Linux?

We can - this was mostly just an attempt to avoid changing MacOS for the sake of a library name - I also wasn't sure if this might lead to other packaging changes/issues for people who package JVMs for MacOS?  My original approach had a single name, so it would straightforward to make this happen.  What do you think?

> test/jdk/sun/security/krb5/native/NativeCacheTest.java line 146:
> 
>> 144:         }
>> 145: 
>> 146:         // Fallback to the default cache if copying from file cache fails
> 
> Could this happen? Will there be unexpected ticket in the default cache?

I think this (and your other comment on the test helper) could be simplified, I'll do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518702065
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518703906

From weijun at openjdk.org  Wed Nov 12 15:39:45 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Nov 2025 15:39:45 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v11]
In-Reply-To: <w_2oXqrsmdZNNc8CQHS2r_aREToUhs1cQuTllVQJZok=.0aa6b8bc-23e8-46f4-be9f-673a3d846b00@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
 <-S7R7tafpyU8i0p6qkySw3Brq3_fVtv7ZJFUhx4yVUU=.145b6f0a-5a04-4a91-9f3a-cfa41599ec3d@github.com>
 <w_2oXqrsmdZNNc8CQHS2r_aREToUhs1cQuTllVQJZok=.0aa6b8bc-23e8-46f4-be9f-673a3d846b00@github.com>
Message-ID: <weBzSZbuQ-IMTGpVoAb62GIa5v1XpydzBz_U9DlRooU=.c98d8765-48c2-4cc8-9940-1e4dad30d291@github.com>

On Wed, 12 Nov 2025 15:12:04 GMT, Nick Hall <duke at openjdk.org> wrote:

>> src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 536:
>> 
>>> 534:             System.loadLibrary("osxkrb5");
>>> 535:         } else if (OperatingSystem.isLinux()) {
>>> 536:             System.loadLibrary("linuxkrb5");
>> 
>> Can we use the same lib name on macOS and Linux?
>
> We can - this was mostly just an attempt to avoid changing MacOS for the sake of a library name - I also wasn't sure if this might lead to other packaging changes/issues for people who package JVMs for MacOS?  My original approach had a single name, so it would straightforward to make this happen.  What do you think?

I don't have a strong opinion. This is internal structure, but you're right if someone tries to package a macOS-only JVM they would need some change. If we want this feature to be backported, maybe it's safe to keep using the old name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518798712

From weijun at openjdk.org  Wed Nov 12 15:39:50 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Nov 2025 15:39:50 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v11]
In-Reply-To: <vGVwOgyVEqg6JQzk0Tg1MTjA-zFFikOZx-bsrQksWOk=.684e0eff-5f74-40ae-964b-ee30cb215fee@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
 <vGVwOgyVEqg6JQzk0Tg1MTjA-zFFikOZx-bsrQksWOk=.684e0eff-5f74-40ae-964b-ee30cb215fee@github.com>
Message-ID: <NWr_ZdXUhzc1G5DrS2TWw1w-yapmyd52-1v2ZDAI5N4=.4beea032-320a-4eb5-82a4-2740a8d23128@github.com>

On Wed, 12 Nov 2025 14:53:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Attend to @smemery's code review comments
>
> test/jdk/sun/security/krb5/native/NativeCacheTest.java line 124:
> 
>> 122:      * Copy the TGT to an in-memory cache using JNI
>> 123:      */
>> 124:     private static String copyTGTToInMemoryCache() throws Exception {
> 
> All native methods are called here with the same order. Is it possible to just create one single native method and do everything inside?

You can even try using the latest FFM API. Not a request, just 0.01 cent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518802974

From jvernee at openjdk.org  Wed Nov 12 16:39:57 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 16:39:57 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
Message-ID: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>

On Wed, 12 Nov 2025 10:07:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
> 
>  - Clarify toString spec
>  - Merge branch 'master' into lazy-constants
>  - Add @AOTSafeClassInitializer
>  - Address comments in PR
>  - Fix merge mistake
>  - Merge master
>  - Rework toString implementations
>  - Update after doc comments
>  - Merge branch 'master' into lazy-constants
>  - Revert the AbstractMap.keySet @Stable annotation
>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

Some initial comments on the spec and implementation. I still need to look at the tests.

src/java.base/share/classes/java/lang/LazyConstant.java line 48:

> 46:  * (provided at construction) will be invoked and the result will be used to initialize
> 47:  * the constant. Once a lazy constant is initialized, its contents can <em>never change</em>
> 48:  * and will be retrieved over and over again upon subsequent {@linkplain #get() get}

Are the above links to `#get()` also intended to have a the plain `get` text?

src/java.base/share/classes/java/lang/LazyConstant.java line 169:

> 167:  *          a lazy constant {@linkplain java.lang.ref##reachability strongly references}
> 168:  *          it contents. Hence, a lazy constant will hold its contents until
> 169:  *          the lazy constant itself is collected (if ever).

Maybe you could avoid the word 'collected' here, as there are no other references to the GC in this section, and no link to what GC is/does. i.e. I think 'collected' is not well-defined enough to be used here.

Suggestion:

 *          it contents. Hence, the contents of a lazy constant will be reachable as long
 *          as the lazy constant itself is reachable.

src/java.base/share/classes/java/lang/LazyConstant.java line 249:

> 247: 
> 248:     /**
> 249:      * {@return the {@linkplain System#identityHashCode(Object)} for this lazy constant}

How does this link render? It doesn't have any plain text. Maybe it's missing?

Suggestion:

     * {@return the {@linkplain System#identityHashCode(Object) identity hash code} for this lazy constant}

src/java.base/share/classes/java/lang/LazyConstant.java line 257:

> 255: 
> 256:     /**
> 257:      * {@return a non-initializing string suitable for debugging}

What is a 'non-initializing string'? ;) I think the second paragraph already covers this aspect, so you can leave it out here.

src/java.base/share/classes/java/lang/LazyConstant.java line 275:

> 273:     /**
> 274:      * {@return a lazy constant to be computed later via the provided
> 275:      *          {@code computingFunction}}

The function computes the contents, not the LC itself, so:

Suggestion:

     * {@return a lazy constant whose contents is to be computed later via the provided
     *          {@code computingFunction}}

src/java.base/share/classes/java/util/LazyCollections.java line 55:

> 53: 
> 54:     // Unsafe allows LazyCollection classes to be used early in the boot sequence
> 55:     static final Unsafe UNSAFE = Unsafe.getUnsafe();

Suggestion:

    private static final Unsafe UNSAFE = Unsafe.getUnsafe();

src/java.base/share/classes/java/util/LazyCollections.java line 66:

> 64:         // using `elements.length`.
> 65:         @Stable
> 66:         private final int size;

Is this really that important? What about the extra footprint added by the `int` field? We might have many instances of this class, but only one copy of the bytecode.

src/java.base/share/classes/java/util/LazyCollections.java line 199:

> 197:                 final int size = base.size();
> 198:                 subListRangeCheck(fromIndex, toIndex, size);
> 199:                 return new ReverseOrderLazyListView<>(base.subList(size - toIndex, size - fromIndex));

Why not this? (maybe add a comment?)
Suggestion:

                return new ReverseOrderLazyListView<>(base.subList(fromIndex, toIndex));

src/java.base/share/classes/java/util/LazyCollections.java line 264:

> 262: 
> 263:         @Stable
> 264:         private final Map<K, Integer> indexMapper;

This index mapper is a clever solution that avoids implementing a hashing function again. Lookups through this map can be folded because it is created using `Map.ofEntries`. I think you should put that in a comment here as well.

src/java.base/share/classes/java/util/LazyCollections.java line 433:

> 431:             @Override public V      getValue() {
> 432:                 final int index = map.indexFor(getKey);
> 433:                 final V v = map.getAcquire(getKey);

I suppose you could use `orElseCompute` here, since you already have the index

src/java.base/share/classes/java/util/LazyCollections.java line 488:

> 486:     static final class Mutexes {
> 487: 
> 488:         static final Object TOMB_STONE = new Object();

Suggestion:

        private static final Object TOMB_STONE = new Object();

src/java.base/share/classes/java/util/LazyCollections.java line 578:

> 576:             if (t == null) {
> 577:                 final T newValue = switch (functionHolder.function()) {
> 578:                     case Supplier<?> sup     -> (T) sup.get();

Is the held function ever a Supplier? I don't see a FunctionHolder being created with one.

src/java.base/share/classes/java/util/LazyCollections.java line 607:

> 605:         assert Thread.holdsLock(mutex) : index + "didn't hold " + mutex;
> 606:         // We know we hold the monitor here so plain semantic is enough
> 607:         if (array[index] == null) {

This should always be true when we get here, right?

src/java.base/share/classes/java/util/List.java line 1222:

> 1220:      * <p>
> 1221:      * Any {@link List#subList(int, int) subList()} or {@link List#reversed()} views
> 1222:      * of the returned list are also lazily computed.

Is this really about the views itself? Or about the elements? (AFAIK these views are typically lazily computed/created for others List impls as well)

Suggestion:

     * The elements of any {@link List#subList(int, int) subList()} or {@link List#reversed()} views
     * of the returned list are also lazily computed.

src/java.base/share/classes/java/util/Map.java line 1765:

> 1763:      * at most once per key, even in a multi-threaded environment. Competing
> 1764:      * threads accessing a value already under computation will block until an element
> 1765:      * is computed or an exception is thrown by the computing thread.

I think technically it's more correct to say something like '... or the computing function completes abnormally'. Since, if an exception is throw inside the computing function (by the computing thread), it may be caught and handled inside the computing function as well.

src/java.base/share/classes/java/util/Map.java line 1778:

> 1776:      * <p>
> 1777:      * Any {@link Map#values()} or {@link Map#entrySet()} views of the returned map are
> 1778:      * also lazily computed.

Suggestion:

     * The values of any {@link Map#values()} or {@link Map#entrySet()} views of the returned map are
     * also lazily computed.

src/java.base/share/classes/java/util/Map.java line 1817:

> 1815:         final Set<K> keyCopies = Set.copyOf(keys);
> 1816:         Objects.requireNonNull(computingFunction);
> 1817:         if (keys instanceof EnumSet<?> && !keys.isEmpty()) {

The fact that `keys` is being used here and not `keyCopies` looks a bit fishy. In general we should use the validated copy of our data in subsequent processing. Since `EnumSet` is mutable, it seems that these two could go out of sync.

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

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3448944313
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518699095
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518745565
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518765422
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518768972
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518779499
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518885149
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518897461
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518919343
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518968294
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518950708
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518970767
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2519007486
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2519002745
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518813240
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518832566
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518837814
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518880555

From jvernee at openjdk.org  Wed Nov 12 16:39:58 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 16:39:58 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <BPsL8gRBQYDTohQqPmBLVaEJ5NBxHEignbOmqf4YSVU=.30ee3776-265a-4966-860b-7f8ff7fc91a6@github.com>

On Wed, 12 Nov 2025 15:23:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/lang/LazyConstant.java line 169:
> 
>> 167:  *          a lazy constant {@linkplain java.lang.ref##reachability strongly references}
>> 168:  *          it contents. Hence, a lazy constant will hold its contents until
>> 169:  *          the lazy constant itself is collected (if ever).
> 
> Maybe you could avoid the word 'collected' here, as there are no other references to the GC in this section, and no link to what GC is/does. i.e. I think 'collected' is not well-defined enough to be used here.
> 
> Suggestion:
> 
>  *          it contents. Hence, the contents of a lazy constant will be reachable as long
>  *          as the lazy constant itself is reachable.

Alternatively you could say something like 'becomes eligible for garbage collection', but I think defining the spec in terms of reachability is better, since that has a better definition in `java.lang.ref##reachability`.

> src/java.base/share/classes/java/util/Map.java line 1765:
> 
>> 1763:      * at most once per key, even in a multi-threaded environment. Competing
>> 1764:      * threads accessing a value already under computation will block until an element
>> 1765:      * is computed or an exception is thrown by the computing thread.
> 
> I think technically it's more correct to say something like '... or the computing function completes abnormally'. Since, if an exception is throw inside the computing function (by the computing thread), it may be caught and handled inside the computing function as well.

(Same for List)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518789003
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518834700

From jvernee at openjdk.org  Wed Nov 12 16:39:59 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 16:39:59 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <P1Ti8_ofzrMmdzekvWxWvLQP5Khkt8Ivfb_xGQArNl4=.14fdc4b4-bec7-4b6f-ab71-86d42fb64006@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <qtZot2WX6UOjKT0P4mi4CQKOjoIU5CJMmCieIplwO00=.5ae10b17-9aae-471e-866a-ed876c4d0ffe@github.com>
 <-lErHk2PzyJCaPQGrEwCt3nObTrTHs7_p53eBXspUGE=.50dc2375-8769-49a5-9308-ab40132bbd19@github.com>
 <P1Ti8_ofzrMmdzekvWxWvLQP5Khkt8Ivfb_xGQArNl4=.14fdc4b4-bec7-4b6f-ab71-86d42fb64006@github.com>
Message-ID: <dhFCSfTNXvOxuS2Qx41yPqplCUhXTq4IWT-7OWvhK8M=.fc1e937b-1fb2-4572-aa50-db9e1192a4ef@github.com>

On Mon, 13 Oct 2025 11:25:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Usually a null sentinel is used when null indicates something different. I think maybe to allow folding the empty case, we should probably add a new annotation or a new element-value to indicate this status and properly handle it in C1/C2 (similar to the field trusting in ciField)
>
> I've added two new benchmarks:
> 
> 
>     private static final LazyConstant<Optional<Integer>> OPTIONAL_42 = LazyConstant.of(() -> Optional.of(42));
>     private static final LazyConstant<Optional<Integer>> OPTIONAL_42_2 = LazyConstant.of(() -> Optional.of(42));
>     private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY = LazyConstant.of(Optional::empty);
>     private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY2 = LazyConstant.of(Optional::empty);
>     
>     ...
>     
>         @Benchmark
>     public int staticOptional42() {
>         return OPTIONAL_42.get().orElseThrow() + OPTIONAL_42_2.get().orElseThrow();
>     }
> 
>     @Benchmark
>     public boolean staticOptionalEmpty() {
>         return OPTIONAL_EMPTY.get().isEmpty() ^ OPTIONAL_EMPTY2.get().isEmpty();
>     }
> 
>     
> 
> 
> Which gives:
> 
> 
> Benchmark                              Mode  Cnt  Score   Error  Units
> StableValueBenchmark.staticOptional42  avgt   10  0.354 ? 0.045  ns/op
> 
> Benchmark                                 Mode  Cnt  Score   Error  Units
> StableValueBenchmark.staticOptionalEmpty  avgt   10  0.370 ? 0.030  ns/op
> 
> 
> So, both `Optional` variants appears to support constant folding.

I don't think we can drawn that conclusion just based on the speed. For the non-constant folded cases, this would be 2 loads and an xor.

I don't see how C2 would be allowed to constant fold the loads if the value is `null`, since that's explicitly forbidden by `@Stable` (and there's no easy way around that AFAIK, since the JIT thread may see a partially initialized object, so it conservatively ignores default values).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2514951017

From jvernee at openjdk.org  Wed Nov 12 16:40:02 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Nov 2025 16:40:02 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v24]
In-Reply-To: <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <rZu3xk8xs7k6TVwukju8krdWhrkFgESL8ozoi7trNYM=.ea245e58-b745-4565-8508-047d81720304@github.com>
Message-ID: <fZvWSosJ0dpOekq5kMHya1CWSi5gEARpc_t-9KhX5qc=.203d607b-631d-46b3-a7fa-5def2552f15d@github.com>

On Mon, 10 Nov 2025 14:59:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @AOTSafeClassInitializer

src/java.base/share/classes/jdk/internal/lang/LazyConstantImpl.java line 47:

> 45: 
> 46:     // Unsafe allows `LazyConstant` instances to be used early in the boot sequence
> 47:     static final Unsafe UNSAFE = Unsafe.getUnsafe();

Suggestion:

    private static final Unsafe UNSAFE = Unsafe.getUnsafe();

test/jdk/java/lang/LazyConstant/LazyConstantSafePublicationTest.java line 117:

> 115:     @Test
> 116:     void mainTest() {
> 117:         CONSTANTS.set(constants());

Instead of passing this through a static field, why not just pass it through the constructor of Producer and Consumer? (which are created below)

test/micro/org/openjdk/bench/java/lang/stable/StableMapSingleBenchmark.java line 66:

> 64:     private static final Map<MyEnum, Integer> MAP_ENUM = Map.ofLazy(EnumSet.allOf(MyEnum.class), MyEnum::ordinal);
> 65:     private static final Map<MyEnum, Optional<Integer>> MAP_ENUM_OPTIONAL = Map.ofLazy(EnumSet.allOf(MyEnum.class), e -> Optional.of(e.ordinal()));
> 66:     private static final Function<Integer, Integer> FUNCTION = MAP::get;

I suppose the function variants are not very interesting to test, since they just delegate to Map::get, Maybe consider removing them

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2514957700
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2514930623
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2514913683

From justin.lu at oracle.com  Mon Nov 10 22:29:08 2025
From: justin.lu at oracle.com (Justin Lu)
Date: Mon, 10 Nov 2025 22:29:08 +0000
Subject: Proposal: 8338093: Localization of yes/no options in console input
In-Reply-To: <B4509423-7CBA-4810-8C0C-81904D5F1882@oracle.com>
References: <19a6dbae0ad.7e56af0a221616.1073185985223008803@peya.tokyo>
 <12b66ef8-0802-41ae-8d34-84a414e51e43@oracle.com>
 <823F82ED-F242-48AC-9145-83747AE5BAC0@oracle.com>
 <6e8a4971-f702-44e7-8621-566d1273382a@oracle.com>
 <B4509423-7CBA-4810-8C0C-81904D5F1882@oracle.com>
Message-ID: <BLAPR10MB4897CCAE383CBCA297D613C68BCEA@BLAPR10MB4897.namprd10.prod.outlook.com>

Weijun is right that we do not manually update the localized files ourselves. I would suggest leaving a comment in the English properties file on the line above the key/val with the options that should not be translated. For example, "#L10N: do not localize: [no]?.

Thanks,
Justin

> Hello, D.Yamazaki,
> Welcome to contributing to JDK. For your patch, please only update the English properties file, I think there is a policy that translations should always be handled by dedicated teams.
> I assume you are already familiar with the key sections of the OpenJDK Developers' Guide [1] and the OCA [2].
> Thanks,
> Weijun
> [1] https://openjdk.org/guide/
> [2] https://oca.opensource.oracle.com/?ojr=faq


Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20251110/d4bb81cd/attachment-0001.htm>

From tjkra at itm8.com  Tue Nov 11 10:19:29 2025
From: tjkra at itm8.com (Tjalfe Krause)
Date: Tue, 11 Nov 2025 10:19:29 +0000
Subject: Potential issues found in fix for SunMSCAPI (JDK-8313367 )
Message-ID: <DU0PR03MB98511F758C8E09E2DC4DDEEE9BCFA@DU0PR03MB9851.eurprd03.prod.outlook.com>

Greetings,

I'm new to OpenJDK development so please forgive if this is not the correct protocol.

Regarding the fix for unprivileged read access to the Windows truststores (JDK-8313367 [1]) it seems it results in some problematic behavior.

If the user used to access the "Windows-MY-LOCALMACHINE" keystore has write access to the store but is not an administrator it is possible to read certificates from "Windows-MY-LOCALMACHINE", but when importing or deleting certificates the store used is "Windows-MY-CURRENTUSER".
After the (JDK-8313367) change an executing account can read certificates in the "Windows-MY-LOCALMACHINE" keystore without issue. The issue arises when using the same keystore to import or delete certificates in the then the "Windows-MY-LOCALMACHINE " store, they are unexpectedly targeting the "Windows-MY-CURRENTUSER" keystore instead do to the fact that the changes from (JDK-8313367) is not implemented in the store/delete operations.

Steps to reproduce:

1: Give an account write access to "Windows-MY-LOCALMACHINE" by setting "Full control" permissions on " HKLM:\SOFTWARE\Microsoft\SystemCertificates\MY"
2: In Java: Open "Windows-MY-LOCALMACHINE" keystore as the account
3: In Java: Import at certificate into the keystore
4: The certificate ends up in "Windows-MY-CURRENTUSER" instead of the specified "Windows-MY-LOCALMACHINE" keystore.

The fix seems be quite simple: 
Implement the same logic that was introduced in PR #8211 [2].

In security.cpp: Add "jint jCertStoreLocation" parameter to "Java_sun_security_mscapi_CKeyStore_storeCertificate" and "Java_sun_security_mscapi_CKeyStore_removeCertificate"
In sun/security/mscapi/CKeyStore.java: pass in the "getLocation()" value in setCertificateChain/delete

If you need a working code to reproduce the error or a diff of the suggested fix, I can provide these as well.

Regards,
Tjalfe


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

[2] https://github.com/openjdk/jdk/pull/8211

From mdonovan at openjdk.org  Wed Nov 12 18:04:24 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 12 Nov 2025 18:04:24 GMT
Subject: RFR: 8343316: Review and update tests using explicit provider names
Message-ID: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>

In this PR, I updated a few crypto tests to remove the hard-coded provider name and use the `test.provider.name` property instead. These tests were missed while working on [JDK-8341927](https://bugs.openjdk.org/browse/JDK-8341927).

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

Commit messages:
 - 8343316: Review and update tests using explicit provider names

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

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

From fferrari at openjdk.org  Wed Nov 12 18:37:44 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 12 Nov 2025 18:37:44 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v8]
In-Reply-To: <RqBLdkwG_qLbJIuf-vuLasv85aavUABXFatlQ-7BwSM=.d66b0efb-703b-47e0-a25c-97a5289a1fd1@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <0iLyQFtldK7kJHvRpdXwcMXoNrjWKfFCJfo_a5BhJpM=.290016fd-53f4-4303-b665-8f31e4e19cd2@github.com>
 <RqBLdkwG_qLbJIuf-vuLasv85aavUABXFatlQ-7BwSM=.d66b0efb-703b-47e0-a25c-97a5289a1fd1@github.com>
Message-ID: <nfo4oPIDQF3VV80e0ydNPleRnHITagMckKfjbtrShHE=.bacc221d-c4b1-4811-afd2-8e743b49280f@github.com>

On Fri, 7 Nov 2025 16:18:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Detect cyclic includes with Files::isSameFile
>>   
>>   checkCyclicInclude() is invoked after we successfully get an InputStream
>>   for the path to avoid skipping the same IOException several times inside
>>   checkCyclicInclude() if the path doesn't exist.
>>   
>>   Also, perform symlinks resolution only in the following cases:
>>    ? When we need to resolve a relative include
>>    ? For clarity to the user in logging messages
>>    ? For clarity to the user in exception messages
>>   
>>   In the first case, the resolution is a requirement, in the last two
>>   cases it is a nice-to-have. But given the last two are exceptional
>>   cases anyway, we let any resolution error bubble up.
>
> src/java.base/share/classes/java/security/Security.java line 295:
> 
>> 293:                 throws IOException {
>> 294:             boolean isRegularFile = Files.isRegularFile(path);
>> 295:             if (!isRegularFile && Files.isDirectory(path)) {
> 
> Can a directory ever be a regular file? If not, you don't need the `!isRegularFile` check.

A directory is not a regular file, but we need `isRegularFile` later here:

https://github.com/openjdk/jdk/blob/a8d865c4985e6660655b27df28e76882855b2087/src/java.base/share/classes/java/security/Security.java#L302

So `!isRegularFile` is part of the condition to save the posible `Files::isDirectory` I/O operations in the most likely case (we are including a regular file).

Previous code was also saving this I/O:

https://github.com/openjdk/jdk/blob/4b315111493ac65511890bc2127489ceee693915/src/java.base/share/classes/java/security/Security.java#L268-L272

I would prefer not to, but I can remove the condition and inline `Files::isRegularFile` on line 302:


currentPath = Files.isRegularFile(path) ? path : null;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2519385066

From fferrari at openjdk.org  Wed Nov 12 18:40:48 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 12 Nov 2025 18:40:48 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v8]
In-Reply-To: <RqBLdkwG_qLbJIuf-vuLasv85aavUABXFatlQ-7BwSM=.d66b0efb-703b-47e0-a25c-97a5289a1fd1@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <0iLyQFtldK7kJHvRpdXwcMXoNrjWKfFCJfo_a5BhJpM=.290016fd-53f4-4303-b665-8f31e4e19cd2@github.com>
 <RqBLdkwG_qLbJIuf-vuLasv85aavUABXFatlQ-7BwSM=.d66b0efb-703b-47e0-a25c-97a5289a1fd1@github.com>
Message-ID: <MULZ_k7nB-WnO7lDPLYRUtJG6Ve-zCGicM5hJoscagQ=.83633f1d-bbef-4ed0-bef8-fe85cc24685f@github.com>

On Fri, 7 Nov 2025 16:31:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Detect cyclic includes with Files::isSameFile
>>   
>>   checkCyclicInclude() is invoked after we successfully get an InputStream
>>   for the path to avoid skipping the same IOException several times inside
>>   checkCyclicInclude() if the path doesn't exist.
>>   
>>   Also, perform symlinks resolution only in the following cases:
>>    ? When we need to resolve a relative include
>>    ? For clarity to the user in logging messages
>>    ? For clarity to the user in exception messages
>>   
>>   In the first case, the resolution is a requirement, in the last two
>>   cases it is a nice-to-have. But given the last two are exceptional
>>   cases anyway, we let any resolution error bubble up.
>
> src/java.base/share/classes/java/security/Security.java line 286:
> 
>> 284:                     if (Files.isSameFile(path, activePath)) {
>> 285:                         throw new InternalError(
>> 286:                                 "Cyclic include of '" + resolve(path) + "'");
> 
> Why try to resolve the path for an exception message? If that causes an exception an `InternalError` will be thrown and this error message will be lost, making it harder to debug.

Was just for a nicer error message, but I agree it could make things even harder to debug than an unresolved path.

I will be changing this, adjusting the test case and re-testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2519391452

From fferrari at openjdk.org  Wed Nov 12 19:16:03 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 12 Nov 2025 19:16:03 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v8]
In-Reply-To: <RqBLdkwG_qLbJIuf-vuLasv85aavUABXFatlQ-7BwSM=.d66b0efb-703b-47e0-a25c-97a5289a1fd1@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <0iLyQFtldK7kJHvRpdXwcMXoNrjWKfFCJfo_a5BhJpM=.290016fd-53f4-4303-b665-8f31e4e19cd2@github.com>
 <RqBLdkwG_qLbJIuf-vuLasv85aavUABXFatlQ-7BwSM=.d66b0efb-703b-47e0-a25c-97a5289a1fd1@github.com>
Message-ID: <41RTmykCC1A-4ExHq7HWsqmlS5lobm0PVxDub7P85j0=.281cee13-471e-4863-917e-0bf3094335b6@github.com>

On Fri, 7 Nov 2025 16:27:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Detect cyclic includes with Files::isSameFile
>>   
>>   checkCyclicInclude() is invoked after we successfully get an InputStream
>>   for the path to avoid skipping the same IOException several times inside
>>   checkCyclicInclude() if the path doesn't exist.
>>   
>>   Also, perform symlinks resolution only in the following cases:
>>    ? When we need to resolve a relative include
>>    ? For clarity to the user in logging messages
>>    ? For clarity to the user in exception messages
>>   
>>   In the first case, the resolution is a requirement, in the last two
>>   cases it is a nice-to-have. But given the last two are exceptional
>>   cases anyway, we let any resolution error bubble up.
>
> src/java.base/share/classes/java/security/Security.java line 288:
> 
>> 286:                                 "Cyclic include of '" + resolve(path) + "'");
>> 287:                     }
>> 288:                 } catch (IOException ignore) {}
> 
> Not sure you want to ignore this - seems better to let this propagate and be thrown as an `InternalError`.

We can make this an `InternalError`, the most common failure case is one of the two files nonexistence. So before proceeding I want to make sure you are aware that this would make the following filesystem race-condition noticeable:

1. File **A** is included, _OpenJDK_ starts reading it
2. File **A** is deleted by and administrator who is changing the settings
    * But _OpenJDK_ keeps it open, this is possible in _Linux_
3. File **B** is included, _OpenJDK_ wants to check for a circular inclusion
4. `Files.isSameFile(path, activePath)` throws `IOException` when `path` is file **B** and `activePath` is file **A** (now deleted)
5. `IOException` isn't ignored but wrapped in an `InternalError` and thrown

Current code wouldn't fail in this scenario, although I recognize it's a corner case. I decided to ignore the exception under the assumption that `Files.isSameFile(x, y)` can be treated as `false` in this context for cases in which either `x` or `y` is nonexistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2519491637

From fferrari at openjdk.org  Wed Nov 12 19:19:46 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 12 Nov 2025 19:19:46 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions
In-Reply-To: <mDxHjy4Fr4F7WPcBADeQPDldGV96Gwgm6LETZxx_xjo=.5a567b9c-032b-4a13-9204-0c1fbd15c3c7@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <VOpnIb1YIv419CudMEK6ftGQ0a6OSolUquaAO63BKtI=.7a414618-6d5a-4b8f-9a9c-3c35e7655960@github.com>
 <45gEnigXd-WxofLVYu0K6QDbLq72YZvzroUWy-owk6M=.d25d1075-2488-4982-906f-5cc431429823@github.com>
 <MuR9VSyvlMyr0kAhcBa2g7tce-HOlYf1Q9TFdi4uzR4=.e650723a-d351-4193-8db0-5ec00335276b@github.com>
 <mDxHjy4Fr4F7WPcBADeQPDldGV96Gwgm6LETZxx_xjo=.5a567b9c-032b-4a13-9204-0c1fbd15c3c7@github.com>
Message-ID: <GK5iy6Jf2WQdkS4gU86q216vHZF-9bQrg7nV0x-Cejc=.76233c77-6dc1-4095-aae3-f56f8ced4dc4@github.com>

On Mon, 27 Oct 2025 19:38:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hi @AlanBateman, have you had time to review my previous message?
>
> @franferrax Have you tried Alan's suggestion?
> 
> Also, since this is a regression, and you think it will take longer to come up with a fix, can I suggest as a temporary fix you revert to using `FileInputStream` to load the security properties file (in the default location or via the -Djava.security.properties system property), and only call `loadFromPath` if an include directive is specified? Is that feasible? If so, you can then address this issue separately. This should at least fix the common case where no include directive is specified. It would be good to get the primary use case fixed in 26.

Hi @seanjmullan, thanks for your review, I replied to the three comments. I will start by removing `resolve()` when a cycle is detected, which will require test updates. For the remaining two, I'll wait for your responses before making any change.

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

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

From abarashev at openjdk.org  Wed Nov 12 21:39:24 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 12 Nov 2025 21:39:24 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in X509TrustManagerImpl
Message-ID: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>

The 3 checkTrusted methods in X509TrustManagerImpl have a lot of repeating code that can be moved into a helper method.
Also refactoring X509TrustManagerImpl logging code since we are touching this file.

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

Commit messages:
 - 8371721: Refactor checkTrusted methods in X509TrustManagerImpl

Changes: https://git.openjdk.org/jdk/pull/28275/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28275&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371721
  Stats: 152 lines in 2 files changed: 38 ins; 71 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/28275.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28275/head:pull/28275

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

From duke at openjdk.org  Wed Nov 12 21:49:10 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 12 Nov 2025 21:49:10 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
Message-ID: <ggdw6IJLb8vSl_FSPlfD6B-JOIQbaPXXetiZzK9r-SM=.e6340448-e798-4d81-a2d0-54e23a127f3c@github.com>

On Wed, 12 Nov 2025 10:07:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
> 
>  - Clarify toString spec
>  - Merge branch 'master' into lazy-constants
>  - Add @AOTSafeClassInitializer
>  - Address comments in PR
>  - Fix merge mistake
>  - Merge master
>  - Rework toString implementations
>  - Update after doc comments
>  - Merge branch 'master' into lazy-constants
>  - Revert the AbstractMap.keySet @Stable annotation
>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

src/java.base/share/classes/java/util/LazyCollections.java line 509:

> 507:                 return mutex;
> 508:             }
> 509:             // Protect against racy stores of mutexe candidates

Suggestion:

            // Protect against racy stores of mutex candidates

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2518540555

From duke at openjdk.org  Wed Nov 12 21:49:12 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 12 Nov 2025 21:49:12 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <QOrBcIEhpsiMtBjYAIXYvE5gTFQDmQUUtNplF-uBTGU=.10d80411-1396-4e42-80d1-aa13749520f7@github.com>

On Wed, 12 Nov 2025 16:33:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 578:
> 
>> 576:             if (t == null) {
>> 577:                 final T newValue = switch (functionHolder.function()) {
>> 578:                     case Supplier<?> sup     -> (T) sup.get();
> 
> Is the held function ever a Supplier? I don't see a FunctionHolder being created with one.

This?is from?when `FunctionHolder` was?located in?the?`jdk.internal.lang.stable` package in?[GH?25878], and?was?used to?implement the?computing?function freeing?mechanism in?[`StableValue?::supplier(?)`].

[GH?25878]: https://github.com/openjdk/jdk/pull/25878
[`StableValue?::supplier(?)`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/StableValue.html#supplier(java.util.function.Supplier)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2519902578

From duke at openjdk.org  Wed Nov 12 22:25:08 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 12 Nov 2025 22:25:08 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v10]
In-Reply-To: <CDJXIDK2yO4xg-huM12_Ey7XpLEEdgKwCPIdyo_ffjI=.17be2359-11e3-47b2-a93a-dd1007a1c13e@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com>
 <kWAAVX9IaV4MYzRhGUKnIOMBigUHonFtFKYir3Yd5Eo=.bab44be0-25e9-431a-9119-e8a37b10808c@github.com>
 <CDJXIDK2yO4xg-huM12_Ey7XpLEEdgKwCPIdyo_ffjI=.17be2359-11e3-47b2-a93a-dd1007a1c13e@github.com>
Message-ID: <wudaWKSNShRzEYJwg_b3k2iehHduDf8G_3WNpU5lyHg=.36a905e2-e368-4fd5-a555-6cbff109a5b0@github.com>

On Wed, 12 Nov 2025 11:34:13 GMT, Nick Hall <duke at openjdk.org> wrote:

>> src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 335:
>> 
>>> 333:             if (OperatingSystem.isWindows() ||
>>> 334:                     OperatingSystem.isMacOS() ||
>>> 335:                         OperatingSystem.isLinux()) {
>> 
>> nit: extra tab?
>
> This is the overall structure currently:
> 
>             if (OperatingSystem.isWindows() ||
>                     OperatingSystem.isMacOS() ||
>                         OperatingSystem.isLinux()) {
> 
> 
> Would you prefer the second two line up or all line up?  It _looks_ like generally the JDK source I've looked at would line them all up (although that's not what was there before!)?

The following would meet code conventions:

            if (OperatingSystem.isWindows() || OperatingSystem.isMacOS()
                    || OperatingSystem.isLinux()) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2519995635

From rgangadhar at openjdk.org  Wed Nov 12 23:49:40 2025
From: rgangadhar at openjdk.org (Ramesh Bhagavatam Gangadhar)
Date: Wed, 12 Nov 2025 23:49:40 GMT
Subject: RFR: 8357874: UNLIMTED_CRYPTO typo in class description of
 JceSecurity.java.template [v2]
In-Reply-To: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>
References: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>
Message-ID: <2LfigqHWJeLS95I9WMiUapX9KM8aIRw2AJLdEDyKLN8=.031a39c0-4067-42e5-b600-a5db7add9a79@github.com>

> Very Trivial Changing in JceSecurity.java.template
> 
> Changed from UNLIMTED_CRYPTO to
>                           UNLIMITED_CRYPTO

Ramesh Bhagavatam Gangadhar has updated the pull request incrementally with one additional commit since the last revision:

  Modified Copyright Year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28238/files
  - new: https://git.openjdk.org/jdk/pull/28238/files/91154699..a86d7661

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

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

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

From rgangadhar at openjdk.org  Wed Nov 12 23:49:41 2025
From: rgangadhar at openjdk.org (Ramesh Bhagavatam Gangadhar)
Date: Wed, 12 Nov 2025 23:49:41 GMT
Subject: RFR: 8357874: UNLIMTED_CRYPTO typo in class description of
 JceSecurity.java.template [v2]
In-Reply-To: <c2kBtyyeL5Ts52auO_QURTNOodHZSTnRc3u-9WT-5pQ=.c86dbb20-6b48-4a6a-b624-74bb4e3696c8@github.com>
References: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>
 <c2kBtyyeL5Ts52auO_QURTNOodHZSTnRc3u-9WT-5pQ=.c86dbb20-6b48-4a6a-b624-74bb4e3696c8@github.com>
Message-ID: <xs9nI1G8K2tPGxSKGRqh7laz2-M45rNuJYvLeGHGjtU=.ac99428e-cd92-446d-9310-6cbc0cc3acf2@github.com>

On Wed, 12 Nov 2025 14:22:10 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ramesh Bhagavatam Gangadhar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified Copyright Year
>
> src/java.base/share/classes/javax/crypto/JceSecurity.java.template line 1:
> 
>> 1: /*
> 
> Update the last copyright date to 2025.

Corrected copyright year @seanjmullan

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28238#discussion_r2520226252

From fferrari at openjdk.org  Thu Nov 13 01:18:16 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 13 Nov 2025 01:18:16 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v9]
In-Reply-To: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
Message-ID: <B2CHuJ7hgLMGv_4Z5YE_TnpQC5IemLsYfgQcCQq9c0o=.fa0fd4d6-8c86-4767-904f-9804894009f8@github.com>

> Hi, this is a proposal to fix 8352728.
> 
> The main idea is 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 rationale behind this decision is the following:
> 
> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`.
> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`.
> 
> #### Windows Case
> 
> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf:
> 
> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`:
>     * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473")
>     * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288")
>     * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop)
>     * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/java.base/windows/native/libjava/c...

Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:

  Remove path resolution from exception message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24465/files
  - new: https://git.openjdk.org/jdk/pull/24465/files/a8d865c4..40bc832e

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

  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 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 fferrari at openjdk.org  Thu Nov 13 01:18:18 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 13 Nov 2025 01:18:18 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v8]
In-Reply-To: <MULZ_k7nB-WnO7lDPLYRUtJG6Ve-zCGicM5hJoscagQ=.83633f1d-bbef-4ed0-bef8-fe85cc24685f@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <0iLyQFtldK7kJHvRpdXwcMXoNrjWKfFCJfo_a5BhJpM=.290016fd-53f4-4303-b665-8f31e4e19cd2@github.com>
 <RqBLdkwG_qLbJIuf-vuLasv85aavUABXFatlQ-7BwSM=.d66b0efb-703b-47e0-a25c-97a5289a1fd1@github.com>
 <MULZ_k7nB-WnO7lDPLYRUtJG6Ve-zCGicM5hJoscagQ=.83633f1d-bbef-4ed0-bef8-fe85cc24685f@github.com>
Message-ID: <tiGVQOQqTelXQuJI_y1unX84Wq4kOJVj2Se9Qj6xrhU=.19ae48f9-cfb2-4fda-9c5f-55dde12faabb@github.com>

On Wed, 12 Nov 2025 18:38:00 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 286:
>> 
>>> 284:                     if (Files.isSameFile(path, activePath)) {
>>> 285:                         throw new InternalError(
>>> 286:                                 "Cyclic include of '" + resolve(path) + "'");
>> 
>> Why try to resolve the path for an exception message? If that causes an exception an `InternalError` will be thrown and this error message will be lost, making it harder to debug.
>
> Was just for a nicer error message, but I agree it could make things even harder to debug than an unresolved path.
> 
> I will be changing this, adjusting the test case and re-testing.

Done: 40bc832ef22670a6ba2481fb53d2ebe4b3bbd434.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2520614612

From wetmore at openjdk.org  Thu Nov 13 01:30:09 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 13 Nov 2025 01:30:09 GMT
Subject: RFR: 8357874: UNLIMTED_CRYPTO typo in class description of
 JceSecurity.java.template [v2]
In-Reply-To: <2LfigqHWJeLS95I9WMiUapX9KM8aIRw2AJLdEDyKLN8=.031a39c0-4067-42e5-b600-a5db7add9a79@github.com>
References: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>
 <2LfigqHWJeLS95I9WMiUapX9KM8aIRw2AJLdEDyKLN8=.031a39c0-4067-42e5-b600-a5db7add9a79@github.com>
Message-ID: <sT04rxdr7OCyMySJi9_ajxQ68xPlVMBmKwRJgwUHd8E=.23b34936-f137-49cf-9357-1b865bdfb7ab@github.com>

On Wed, 12 Nov 2025 23:49:40 GMT, Ramesh Bhagavatam Gangadhar <rgangadhar at openjdk.org> wrote:

>> Very Trivial Changing in JceSecurity.java.template
>> 
>> Changed from UNLIMTED_CRYPTO to
>>                           UNLIMITED_CRYPTO
>
> Ramesh Bhagavatam Gangadhar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified Copyright Year

Well, that's kind of embarrassing.  ;)  Good catch.

LGTM.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28238#pullrequestreview-3456552695

From duke at openjdk.org  Thu Nov 13 03:35:13 2025
From: duke at openjdk.org (duke)
Date: Thu, 13 Nov 2025 03:35:13 GMT
Subject: Withdrawn: 8367344: Better error message when decryption of AP-REQ
 fails because of kvno mismatch
In-Reply-To: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com>
References: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com>
Message-ID: <3gws3ZTULKxgqSc5WQOHUN9CrGjjM8aibxxWjbvM45E=.c0e0e899-454a-4fac-9080-de8232ae2c68@github.com>

On Mon, 15 Sep 2025 15:49:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 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.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu Nov 13 05:09:03 2025
From: duke at openjdk.org (duke)
Date: Thu, 13 Nov 2025 05:09:03 GMT
Subject: RFR: 8357874: UNLIMTED_CRYPTO typo in class description of
 JceSecurity.java.template [v2]
In-Reply-To: <2LfigqHWJeLS95I9WMiUapX9KM8aIRw2AJLdEDyKLN8=.031a39c0-4067-42e5-b600-a5db7add9a79@github.com>
References: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>
 <2LfigqHWJeLS95I9WMiUapX9KM8aIRw2AJLdEDyKLN8=.031a39c0-4067-42e5-b600-a5db7add9a79@github.com>
Message-ID: <nBi7H6saG3pbRfv_Y9tNIiZDq1r1RaQaDeC4obxt79Q=.1d3d031a-b795-4693-bb72-46850e5db9e8@github.com>

On Wed, 12 Nov 2025 23:49:40 GMT, Ramesh Bhagavatam Gangadhar <rgangadhar at openjdk.org> wrote:

>> Very Trivial Changing in JceSecurity.java.template
>> 
>> Changed from UNLIMTED_CRYPTO to
>>                           UNLIMITED_CRYPTO
>
> Ramesh Bhagavatam Gangadhar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified Copyright Year

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

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

PR Comment: https://git.openjdk.org/jdk/pull/28238#issuecomment-3525406526

From rgangadhar at openjdk.org  Thu Nov 13 05:12:02 2025
From: rgangadhar at openjdk.org (Ramesh Bhagavatam Gangadhar)
Date: Thu, 13 Nov 2025 05:12:02 GMT
Subject: RFR: 8357874: UNLIMTED_CRYPTO typo in class description of
 JceSecurity.java.template [v2]
In-Reply-To: <sT04rxdr7OCyMySJi9_ajxQ68xPlVMBmKwRJgwUHd8E=.23b34936-f137-49cf-9357-1b865bdfb7ab@github.com>
References: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>
 <2LfigqHWJeLS95I9WMiUapX9KM8aIRw2AJLdEDyKLN8=.031a39c0-4067-42e5-b600-a5db7add9a79@github.com>
 <sT04rxdr7OCyMySJi9_ajxQ68xPlVMBmKwRJgwUHd8E=.23b34936-f137-49cf-9357-1b865bdfb7ab@github.com>
Message-ID: <6YQl52wjvbtZ_W86ylefgaQV8CXv_UoAmkQvWZ3cXJY=.5a19c316-225d-443d-9096-13bb88214c88@github.com>

On Thu, 13 Nov 2025 01:26:54 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Ramesh Bhagavatam Gangadhar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified Copyright Year
>
> Well, that's kind of embarrassing.  ;)  Good catch.
> 
> LGTM.

@bradfordwetmore / @seanjmullan pls sponsor

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

PR Comment: https://git.openjdk.org/jdk/pull/28238#issuecomment-3525418855

From valeriep at openjdk.org  Thu Nov 13 06:38:07 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 13 Nov 2025 06:38:07 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v5]
In-Reply-To: <yV6tuPGN7WNTavPtrI_Yq_09vkkKZDfWeeq_cizJKxI=.4da4779a-1e17-4619-8c8f-ba1c0396a8ca@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <yV6tuPGN7WNTavPtrI_Yq_09vkkKZDfWeeq_cizJKxI=.4da4779a-1e17-4619-8c8f-ba1c0396a8ca@github.com>
Message-ID: <X9_IbNtcSETx-Tk24_5CJsiWdR_dYaCHaaM6KviMmms=.18ad7bf9-535c-4f77-a950-0c0b05e8d769@github.com>

On Tue, 11 Nov 2025 05:40:55 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
>> 
>> Thank you @jnimeh for catching the unnecessary byte mask!
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment updates - take three

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28188#pullrequestreview-3457786037

From duke at openjdk.org  Thu Nov 13 06:43:06 2025
From: duke at openjdk.org (duke)
Date: Thu, 13 Nov 2025 06:43:06 GMT
Subject: RFR: 8371450: AES performance improvements for key schedule
 generation [v5]
In-Reply-To: <yV6tuPGN7WNTavPtrI_Yq_09vkkKZDfWeeq_cizJKxI=.4da4779a-1e17-4619-8c8f-ba1c0396a8ca@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
 <yV6tuPGN7WNTavPtrI_Yq_09vkkKZDfWeeq_cizJKxI=.4da4779a-1e17-4619-8c8f-ba1c0396a8ca@github.com>
Message-ID: <2GHi-R0-8PNJrafSvlt8tJoTlv35Rgw3oG-CyVubOXc=.8b8a4eb5-7e32-4b84-8f8a-942501eb7b50@github.com>

On Tue, 11 Nov 2025 05:40:55 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
>> 
>> Thank you @jnimeh for catching the unnecessary byte mask!
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment updates - take three

@smemery 
Your change (at version 2718a1256f0f8685b67251c39b2064b214b4712f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28188#issuecomment-3525782893

From alanb at openjdk.org  Thu Nov 13 06:46:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Nov 2025 06:46:13 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v9]
In-Reply-To: <B2CHuJ7hgLMGv_4Z5YE_TnpQC5IemLsYfgQcCQq9c0o=.fa0fd4d6-8c86-4767-904f-9804894009f8@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <B2CHuJ7hgLMGv_4Z5YE_TnpQC5IemLsYfgQcCQq9c0o=.fa0fd4d6-8c86-4767-904f-9804894009f8@github.com>
Message-ID: <EJt6BTeyduDPS0PoqqBnU7wVEnXt6qYJla_4wTqnVcY=.f90e3231-fb01-4ec3-bc73-93520c95e1c5@github.com>

On Thu, 13 Nov 2025 01:18:16 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this is a proposal to fix 8352728.
>> 
>> The main idea is 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 rationale behind this decision is the following:
>> 
>> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`.
>> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`.
>> 
>> #### Windows Case
>> 
>> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf:
>> 
>> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`:
>>     * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473")
>>     * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288")
>>     * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop)
>>     * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/ja...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove path resolution from exception message

src/java.base/share/classes/java/security/Security.java line 275:

> 273:             // specified to exist even for nonexistent/inaccessible files.
> 274:             try {
> 275:                 return path.toFile().getCanonicalFile().toPath();

@seanjmullan If this change is integrated, can we create a follow-up on issue to replace it? I strongly disagree with the changes in this PR, we should not be using File::getCanonicalFile here to work around an issue with an inaccessible parent directory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2521834309

From hchao at openjdk.org  Thu Nov 13 07:41:27 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 13 Nov 2025 07:41:27 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v3]
In-Reply-To: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
Message-ID: <j9mDXmYUEYFfxDMf2KzIIpDtfzAt7OW4bkghiKoHJqo=.0bf3b268-1a47-4a70-9260-ea4813fb81ba@github.com>

> This PR improves security warning when using JKS or JCEKS keystores.

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

 - Merge
 - Add warning at store and probe for real type in jarsigner
 - Updates with review comments
 - Updates with review comments
 - Revert changes to KeyStore.java
 - Remove test TestOutdatedKeyStore.java
 - Merge
 - 8353749: Improve security warning when using JKS or JCEKS keystores

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27624/files
  - new: https://git.openjdk.org/jdk/pull/27624/files/452e5cda..f582d0fa

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

  Stats: 286565 lines in 2755 files changed: 183088 ins; 63927 del; 39550 mod
  Patch: https://git.openjdk.org/jdk/pull/27624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27624/head:pull/27624

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

From hchao at openjdk.org  Thu Nov 13 07:50:02 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 13 Nov 2025 07:50:02 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v2]
In-Reply-To: <w_iuX7NFa2fGfuKT7C15twDpNL_101nScNj4KX2J1fw=.d67b62ea-6011-4f66-88ea-444eda2f870f@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
 <T82JcGsvUqdnw3wQ9I4cnb1SUS3jXOOQ_B8-_y53IeQ=.45fcacaf-7e3b-4406-98f5-aa8370b376fb@github.com>
 <w_iuX7NFa2fGfuKT7C15twDpNL_101nScNj4KX2J1fw=.d67b62ea-6011-4f66-88ea-444eda2f870f@github.com>
Message-ID: <l3Y6JCUKinEhdLSzGuFz6K_gYbBmlSj_cX5iv29GtVo=.7c7f7e2b-4ff6-41bc-a29e-8c19abec79e3@github.com>

On Fri, 10 Oct 2025 15:31:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Do we need to add a warning at `store`? For example, someone `getInstance("JKS")` and `load(null, null)`, and finally `store` it.

Added warning at engineStore(), and added a testcase for this scenario.

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

PR Comment: https://git.openjdk.org/jdk/pull/27624#issuecomment-3526137462

From hchao at openjdk.org  Thu Nov 13 07:50:06 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 13 Nov 2025 07:50:06 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v2]
In-Reply-To: <k3xOsGy4xCKxbn8AKaNiVzUwVul95IJxn-nzANCD_xU=.3de5eda3-65cf-4c43-a2d2-28e87ebdc918@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
 <T82JcGsvUqdnw3wQ9I4cnb1SUS3jXOOQ_B8-_y53IeQ=.45fcacaf-7e3b-4406-98f5-aa8370b376fb@github.com>
 <k3xOsGy4xCKxbn8AKaNiVzUwVul95IJxn-nzANCD_xU=.3de5eda3-65cf-4c43-a2d2-28e87ebdc918@github.com>
Message-ID: <Fh6QHnmPsM_awO1d925mtbS0o3rC6CCaPHizR56jYbE=.49a79f7e-d9f3-4620-a021-0bd389c9efd9@github.com>

On Fri, 10 Oct 2025 14:19:18 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Updates with review comments
>>  - Updates with review comments
>>  - Revert changes to KeyStore.java
>>  - Remove test TestOutdatedKeyStore.java
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 2432:
> 
>> 2430:                         }
>> 2431:                     }
>> 2432:                     if (store.getType().equalsIgnoreCase("JKS")
> 
> We should put in the same logic here as in `keytool` to check if the real storetype is JKS or JCEKS. See https://github.com/openjdk/jdk/blob/f6d77cb33299ae0636a2b52ee752f27e9ea9191b/src/java.base/share/classes/sun/security/tools/keytool/Main.java#L1392

Fixed.

> test/jdk/sun/security/tools/jarsigner/warnings/Test.java line 1:
> 
>> 1: /*
> 
> I think you should create a new test which is a subclass of this Test which checks that JKS and JCEKS produce the proper warnings when using jarsigner.

A new test was created under sun/security/tools/keytool to provide test coverage for keytool on JKS and JCEKS followed by using jarsigner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2522077007
PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2522076843

From hchao at openjdk.org  Thu Nov 13 07:54:57 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 13 Nov 2025 07:54:57 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v4]
In-Reply-To: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
Message-ID: <OggDZsb-SB866nDVpcifh8EcgiFO64uszj7Oti7zwkg=.4bc8495f-3c4c-4bd0-8684-28ca61028196@github.com>

> This PR improves security warning when using JKS or JCEKS keystores.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Removed bugid from Compatibility.java test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27624/files
  - new: https://git.openjdk.org/jdk/pull/27624/files/f582d0fa..af301060

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

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

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

From hchao at openjdk.org  Thu Nov 13 07:55:01 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 13 Nov 2025 07:55:01 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v2]
In-Reply-To: <k3xOsGy4xCKxbn8AKaNiVzUwVul95IJxn-nzANCD_xU=.3de5eda3-65cf-4c43-a2d2-28e87ebdc918@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
 <T82JcGsvUqdnw3wQ9I4cnb1SUS3jXOOQ_B8-_y53IeQ=.45fcacaf-7e3b-4406-98f5-aa8370b376fb@github.com>
 <k3xOsGy4xCKxbn8AKaNiVzUwVul95IJxn-nzANCD_xU=.3de5eda3-65cf-4c43-a2d2-28e87ebdc918@github.com>
Message-ID: <qabi0zGvGFJBOH5ZxFxat-YQZW9ZGGonDDZhwhAPjCo=.68cd5509-3d0b-42d6-bf61-6b8f59b5676e@github.com>

On Fri, 10 Oct 2025 13:40:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Updates with review comments
>>  - Updates with review comments
>>  - Revert changes to KeyStore.java
>>  - Remove test TestOutdatedKeyStore.java
>
> test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 8217375 8260286 8267319 8353749
> 
> This is not specifically testing this issue, so I don't think you should include the bugid.

Removed the bugid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2522096494

From duke at openjdk.org  Thu Nov 13 08:13:28 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 13 Nov 2025 08:13:28 GMT
Subject: Integrated: 8371450: AES performance improvements for key schedule
 generation
In-Reply-To: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
References: <D1u6DmYuV-n60Dw6TknAFbjGoal_4Rky3cSqcY_YGhw=.bf541e26-6019-4853-b29b-dd1ed561a131@github.com>
Message-ID: <JcUbhHZVFEnThgAbV35BXJuAA1tZSuYddVZ1L9t-uuc=.1e7682d3-32e7-49ae-bf65-678afe3dc162@github.com>

On Fri, 7 Nov 2025 07:53:37 GMT, Shawn M Emery <duke at openjdk.org> wrote:

> This fix improves performance in the AES key schedule generation by eliminating an unnecessary object and unnecessary mask in the inverse key schedule.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 6.96% for arm64 and 7.79% for x86_64.
> 
> Thank you @jnimeh for catching the unnecessary byte mask!

This pull request has now been integrated.

Changeset: 436b3357
Author:    Shawn M Emery <shawn.emery at oracle.com>
Committer: Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/436b3357e9791f6acb2673e2ac96d33c6a2782e6
Stats:     36 lines in 1 file changed: 11 ins; 5 del; 20 mod

8371450: AES performance improvements for key schedule generation

Reviewed-by: valeriep, jnimeh

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

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

From duke at openjdk.org  Thu Nov 13 10:10:27 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 13 Nov 2025 10:10:27 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v11]
In-Reply-To: <weBzSZbuQ-IMTGpVoAb62GIa5v1XpydzBz_U9DlRooU=.c98d8765-48c2-4cc8-9940-1e4dad30d291@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
 <-S7R7tafpyU8i0p6qkySw3Brq3_fVtv7ZJFUhx4yVUU=.145b6f0a-5a04-4a91-9f3a-cfa41599ec3d@github.com>
 <w_2oXqrsmdZNNc8CQHS2r_aREToUhs1cQuTllVQJZok=.0aa6b8bc-23e8-46f4-be9f-673a3d846b00@github.com>
 <weBzSZbuQ-IMTGpVoAb62GIa5v1XpydzBz_U9DlRooU=.c98d8765-48c2-4cc8-9940-1e4dad30d291@github.com>
Message-ID: <jmtIUN9lrNWY3vmox1Qoc2qMQzOETjni96lmgr_jcuM=.eb514d2a-9b2e-46fb-a48e-e649ff49ee6c@github.com>

On Wed, 12 Nov 2025 15:35:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> We can - this was mostly just an attempt to avoid changing MacOS for the sake of a library name - I also wasn't sure if this might lead to other packaging changes/issues for people who package JVMs for MacOS?  My original approach had a single name, so it would straightforward to make this happen.  What do you think?
>
> I don't have a strong opinion. This is internal structure, but you're right if someone tries to package a macOS-only JVM they would need some change. If we want this feature to be backported, maybe it's safe to keep using the old name.

I can only speak for myself/my employer, but we would find utility in this feature being backported for sure.  I'll leave as-is for now, but happy to adjust in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2522730226

From duke at openjdk.org  Thu Nov 13 10:30:39 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 13 Nov 2025 10:30:39 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v11]
In-Reply-To: <NWr_ZdXUhzc1G5DrS2TWw1w-yapmyd52-1v2ZDAI5N4=.4beea032-320a-4eb5-82a4-2740a8d23128@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
 <vGVwOgyVEqg6JQzk0Tg1MTjA-zFFikOZx-bsrQksWOk=.684e0eff-5f74-40ae-964b-ee30cb215fee@github.com>
 <NWr_ZdXUhzc1G5DrS2TWw1w-yapmyd52-1v2ZDAI5N4=.4beea032-320a-4eb5-82a4-2740a8d23128@github.com>
Message-ID: <tb88yMNRcKbPfahjZP6BDcYzmLhJK5fzWR3MbrL2YSA=.c97a9022-dda3-4ef7-bf1d-2e6837a8572c@github.com>

On Wed, 12 Nov 2025 15:36:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/sun/security/krb5/native/NativeCacheTest.java line 124:
>> 
>>> 122:      * Copy the TGT to an in-memory cache using JNI
>>> 123:      */
>>> 124:     private static String copyTGTToInMemoryCache() throws Exception {
>> 
>> All native methods are called here with the same order. Is it possible to just create one single native method and do everything inside?
>
> You can even try using the latest FFM API. Not a request, just 0.01 cent.

I've updated this as requested in the next set of commits (much simpler given this is just a test helper).  I'll leave as JNI for now, because this improves the ability for this to be backported to earlier versions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2522825810

From duke at openjdk.org  Thu Nov 13 11:02:21 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 13 Nov 2025 11:02:21 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v12]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Nick Hall has updated the pull request incrementally with three additional commits since the last revision:

 - Small doc fix
 - Attend to @wangweij's code review comments - in particular a large clean-up of the test helper and the output it creates
 - Attend to remaining comments from @smemery

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/f4a8543f..d7ea6c9e

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

  Stats: 275 lines in 5 files changed: 69 ins; 147 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/28075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28075/head:pull/28075

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

From duke at openjdk.org  Thu Nov 13 11:02:24 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 13 Nov 2025 11:02:24 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v11]
In-Reply-To: <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EDWY7uTjC2Lp5spmiVfi3SgvpXhqyYfjpbMNgnFMamY=.c8f5bc88-2dde-4068-bb2c-afc8dcbce7bb@github.com>
Message-ID: <wbgLZvJQZZrwRavJjelYR92-z9E9DKKrJJiu6pmKVlw=.d2f5901a-84a2-4af1-9602-07a3020e1930@github.com>

On Wed, 12 Nov 2025 11:55:40 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Attend to @smemery's code review comments

@smemery @wangweij have pushed some commits addressing your requested changes - thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3527221313

From duke at openjdk.org  Thu Nov 13 11:13:18 2025
From: duke at openjdk.org (Bernd)
Date: Thu, 13 Nov 2025 11:13:18 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v12]
In-Reply-To: <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
Message-ID: <JSAmc4KNMRA6GhrCZJGmHRdzyJLZtOY7OwME_ALlAVU=.2f326c16-dbb3-4fdd-98ab-bbb3dc606b86@github.com>

On Thu, 13 Nov 2025 11:02:21 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Small doc fix
>  - Attend to @wangweij's code review comments - in particular a large clean-up of the test helper and the output it creates
>  - Attend to remaining comments from @smemery

Thanks for the work and maybe sorry for a dumb question but maybe it helps with documentation - if i get this right this only works for cases where the native client actually can extract the key credentials but not for things where a external component would be needed to apply them (like ssdp, tpm, sssd and the like, right?)

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3527284675

From duke at openjdk.org  Thu Nov 13 11:38:24 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 13 Nov 2025 11:38:24 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v12]
In-Reply-To: <JSAmc4KNMRA6GhrCZJGmHRdzyJLZtOY7OwME_ALlAVU=.2f326c16-dbb3-4fdd-98ab-bbb3dc606b86@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
 <JSAmc4KNMRA6GhrCZJGmHRdzyJLZtOY7OwME_ALlAVU=.2f326c16-dbb3-4fdd-98ab-bbb3dc606b86@github.com>
Message-ID: <4eOyzxFSjWagfXUPVXtIT57FXFud9OSgvsEzW6IHre0=.cae874d5-503a-4ba8-b8dc-6c5a886e4746@github.com>

On Thu, 13 Nov 2025 11:09:49 GMT, Bernd <duke at openjdk.org> wrote:

> Thanks for the work and maybe sorry for a dumb question but maybe it helps with documentation - if i get this right this only works for cases where the native client actually can extract the key credentials but not for things where a external component would be needed to apply them (like ssdp, tpm, sssd and the like, right?)

Assuming I've understood your question:
- this works for all cases where the system libraries could get to a TGT in a ccache - so FILE:, MEMORY:, KEYRING:, KCM:, etc.  For things like `sssd`, assuming that's using the `sssd` KCM implementation, that should work (we use KCM here, though not `sssd`'s implementation).
- If something else is needed to extract/convert a secret that's stored in another place and use it as a key to get a TGT from the KDC, this wouldn't help, although as you can hopefully see from the test helper, once you've got the TGT in Java, it wouldn't be that hard to have a set of JNI helper functions so that it could be _written_ to the right ccache type (as opposed to now, when this would have to be a FILE: ccache).  My reading of the way this works in JAAS currently though is that any acquired key/keytab etc is only written to the private credentials in the `javax.security.auth.Subject` object, and never actually written back to the ccache.

Was that what you were getting at?

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3527396396

From duke at openjdk.org  Thu Nov 13 11:53:19 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 13 Nov 2025 11:53:19 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v12]
In-Reply-To: <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
Message-ID: <vW_-2jFAI8Rd_91g_NAlP-qmD7HtUQfOd1az6HfT8GE=.6d555fd1-6223-4e39-adcd-85ae7c6cb47b@github.com>

On Thu, 13 Nov 2025 11:02:21 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Small doc fix
>  - Attend to @wangweij's code review comments - in particular a large clean-up of the test helper and the output it creates
>  - Attend to remaining comments from @smemery

I'm not sure if there's precedent for it in other `java.security.Principal` types that JAAS can operate on, but it wouldn't be that hard to enhance the JAAS `Krb5LoginModule` to accept a new piece of JAAS configuration that would cause it to write the acquired credential back to an actual ccache as part of storing the keys during commit (within the limits of the local system arrangements - e.g. this wouldn't work on Windows because of the way LSASS protects the ccache, but likely works in Linux/MacOS cases using natively supported cache types).

That said, it's not clear that's needed for client applications that use the various security frameworks / principals in the JVM (where the stored keys in the principal are used), but could be useful for helper applications written in Java that do some kind of credential exchange to create a TGT, or perhaps things written partly in JNI.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3527448204

From rgangadhar at openjdk.org  Thu Nov 13 13:01:24 2025
From: rgangadhar at openjdk.org (Ramesh Bhagavatam Gangadhar)
Date: Thu, 13 Nov 2025 13:01:24 GMT
Subject: Integrated: 8357874: UNLIMTED_CRYPTO typo in class description of
 JceSecurity.java.template
In-Reply-To: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>
References: <pZMBWZ-SD3khq_Pgd5P_8bh4dqJiVQ64Cm39qM4IjW4=.770852af-f32c-4cb2-94f7-c0ef18cbdc51@github.com>
Message-ID: <aDXK8UiUcAMXWGzAFMNnel0I1svaLnTMnlSWMSo_lV0=.cacde1a5-71b8-4031-a592-8e1e97630ec9@github.com>

On Tue, 11 Nov 2025 15:03:06 GMT, Ramesh Bhagavatam Gangadhar <rgangadhar at openjdk.org> wrote:

> Very Trivial Changing in JceSecurity.java.template
> 
> Changed from UNLIMTED_CRYPTO to
>                           UNLIMITED_CRYPTO

This pull request has now been integrated.

Changeset: 6b6fdf1d
Author:    Ramesh Bhagavatam Gangadhar <rgangadhar at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b6fdf1d9222eb03cd013cbe792fa77fd78c1acb
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8357874: UNLIMTED_CRYPTO typo in class description of JceSecurity.java.template

Reviewed-by: wetmore

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

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

From alanb at openjdk.org  Thu Nov 13 13:31:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Nov 2025 13:31:52 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v11]
In-Reply-To: <CbMHUboGTEm5WEWnHmGymb-rO9QVFU3c-QEsr0HeJlQ=.a711870b-91a3-4be0-8a78-814bfc649142@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <Ddyd0WMnGK8wiiCIHJRAOC0kDj6oJNxyJoZXkOB28Ow=.fcc2c280-6eb4-4819-8b29-a18496f7826b@github.com>
 <CbMHUboGTEm5WEWnHmGymb-rO9QVFU3c-QEsr0HeJlQ=.a711870b-91a3-4be0-8a78-814bfc649142@github.com>
Message-ID: <1QetBwPtcolO6_qPQSSRdSofa79BD4UNn9Ri68DGryo=.3dc36aee-0e70-4f88-a5e9-0ac0de3ed121@github.com>

On Wed, 12 Nov 2025 12:51:37 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
>> 
>>  - Remove dup end body tag
>>  - Change FinalFieldMutationEvent so that caller is top frame in stack trace
>>  - Merge branch 'master' into JDK-8353835
>>  - Review feedback: Add tests for setting internal properties, improve links in Mutation methods page
>>  - Merge branch 'master' into JDK-8353835
>>  - Merge branch 'master' into JDK-8353835
>>  - Fix typo in test comment
>>  - Merge branch 'master' into JDK-8353835
>>  - Merge branch 'master' into JDK-8353835
>>  - Suppress warnings from some tests
>>  - ... and 40 more: https://git.openjdk.org/jdk/compare/2902436f...b22947c7
>
> src/java.base/share/classes/java/lang/reflect/Field.java line 1543:
> 
>> 1541:      * the given possibly-null caller.
>> 1542:      */
>> 1543:     private String finalFieldMutationWarning(Class<?> caller, boolean unreflect) {
> 
> It may make sense to have this method return a StringBuilder instance (and use it internally before returning it) as that would cut down on extra String-instance creation.

We could but this is the slow path that prints the warning on the first final field mutation. So I think I'll keep it as simple as possible.

> src/java.base/share/man/java.md line 482:
> 
>> 480: 
>> 481:     -   `allow`: This mode allows illegal final field mutation in all modules,
>> 482:         without any warings.
> 
> Suggestion:
> 
>         without any warnings.

Well spotted, this text was copied down `--illegal-native-access` so I'll fix the typo in both places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2523476042
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2523469262

From djelinski at openjdk.org  Thu Nov 13 14:37:43 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 13 Nov 2025 14:37:43 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v5]
In-Reply-To: <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
Message-ID: <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>

On Fri, 31 Oct 2025 15:02:42 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed line wrapping

Can you convert or remove the `IPAddressDNSIdentities` test as well?

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 36:

> 34:  * @library /test/lib
> 35:  * @modules java.base/sun.security.x509 java.base/sun.security.util
> 36:  * @run main/othervm CriticalSubjectAltName TLSv1.2 MD5withRSA

as far as I could tell, this test doesn't verify any functionality that would require a specific key type, it's simply using MD5 because that was the popular choice in 2008. Do we need to keep using MD5, or can we make it use whatever key type is the default?

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 39:

> 37: 
> 38: /*
> 39:  * This test depends on binary keystore, crisubn.jks and trusted.jks. Because

Peease remove the crisubn.jks and trusted.jks files from this directory, they aren't used anywhere else.

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 157:

> 155:         ks.setCertificateEntry("Trusted Cert", trustedCert);
> 156: 
> 157:         Certificate[] chain = new Certificate[] {serverCert, trustedCert};

(probably preexisting) you can remove the trusted cert from the chain; real servers usually don't send it.

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 190:

> 188:     void doClientSide() throws Exception {
> 189: 
> 190:         if (!serverReady.await(SERVER_WAIT_SECS, TimeUnit.SECONDS)) {

I'd remove the time limit, it only causes trouble when people increase test concurrency and timeout factors.

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 1:

> 1: /*

This might be preexisting, but this file is identical to `test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java` now. Can we remove one?

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 104:

> 102:                         CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)
> 103:                 .addBasicConstraintsExt(false, false, -1)
> 104:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))

I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 119:

> 117:                         CertificateBuilder.KeyUsage.NONREPUDIATION,
> 118:                         CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)
> 119:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))

Same here.

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

PR Review: https://git.openjdk.org/jdk/pull/27342#pullrequestreview-3459883168
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523546617
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523539070
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523561169
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523555451
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523677717
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523705701
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523706426

From fferrari at openjdk.org  Thu Nov 13 14:46:55 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 13 Nov 2025 14:46:55 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v10]
In-Reply-To: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
Message-ID: <4pVdQLYkpLqJ0yH7BPgS3aX1vTKV6Njb3CdMizpwiks=.57bf38bc-528e-4b4c-9937-61f93c1e8c6b@github.com>

> Hi, this is a proposal to fix 8352728.
> 
> The main idea is 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 rationale behind this decision is the following:
> 
> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`.
> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`.
> 
> #### Windows Case
> 
> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf:
> 
> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`:
>     * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473")
>     * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288")
>     * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop)
>     * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/java.base/windows/native/libjava/c...

Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:

  Use the right OutputAnalyzer method
  
  OutputAnalyzer::stderrMatches returns a boolean while
  OutputAnalyzer::stderrShouldMatch performs the check.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24465/files
  - new: https://git.openjdk.org/jdk/pull/24465/files/40bc832e..4483469e

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 fferrari at openjdk.org  Thu Nov 13 14:46:58 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 13 Nov 2025 14:46:58 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v9]
In-Reply-To: <EJt6BTeyduDPS0PoqqBnU7wVEnXt6qYJla_4wTqnVcY=.f90e3231-fb01-4ec3-bc73-93520c95e1c5@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <B2CHuJ7hgLMGv_4Z5YE_TnpQC5IemLsYfgQcCQq9c0o=.fa0fd4d6-8c86-4767-904f-9804894009f8@github.com>
 <EJt6BTeyduDPS0PoqqBnU7wVEnXt6qYJla_4wTqnVcY=.f90e3231-fb01-4ec3-bc73-93520c95e1c5@github.com>
Message-ID: <EqpwA1Hhtczxpew7cd0R8PLgCCS_8q5otoFsoxHpev0=.b90b4135-8d94-4772-9837-3bd4d8405b7b@github.com>

On Thu, 13 Nov 2025 06:43:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove path resolution from exception message
>
> src/java.base/share/classes/java/security/Security.java line 275:
> 
>> 273:             // specified to exist even for nonexistent/inaccessible files.
>> 274:             try {
>> 275:                 return path.toFile().getCanonicalFile().toPath();
> 
> @seanjmullan If this change is integrated, can we create a follow-up on issue to replace it? I strongly disagree with the changes in this PR, we should not be using File::getCanonicalFile here to work around an issue with an inaccessible parent directory.

Just wanted to note that I also dislike this change, but is the only way I found to support relative includes in Windows UWP Java applications.

I'm open to other suggestions, including going back to `Path::toRealPath` and dropping that use-case (while still fixing the original [JDK-8352728](https://bugs.openjdk.org/browse/JDK-8352728 "InternalError loading java.security due to Windows parent folder permissions") issue), even though that isn't my preference.

@AlanBateman: do you disagree with other changes in this PR? I'm not comfortable integrating something that we haven't agreed upon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2523745568

From swen at openjdk.org  Thu Nov 13 15:12:03 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 13 Nov 2025 15:12:03 GMT
Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient
 two-digit formatting and refactor DateTimeHelper [v20]
In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com>
Message-ID: <w6FwWosIcKTsC5cXLsoP1I804te0wFEIDUJq8olLJOA=.eef6670b-ed88-492c-b172-223836cf9def@github.com>

> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality.
> 
> Changes include:
> 
> 1. New `appendPair` method for efficient two-digit integer formatting (00-99):
>    - Added `AbstractStringBuilder.appendLatin1(char c1, char c2)` with core implementation
>    - Added `JavaLangAccess.appendPair(StringBuilder, char c1, char c2)` for internal access
>    - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method
>    - Enhanced Javadoc documentation for all new methods
> 
> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`:
>    - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime`
>    - Replaced manual formatting logic with the new efficient two-digit appending
>    - Improved code clarity and consistency in date/time formatting
> 
> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use JLA

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26911/files
  - new: https://git.openjdk.org/jdk/pull/26911/files/70fc504e..458cfcdb

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

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

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

From mdoerr at openjdk.org  Thu Nov 13 16:56:36 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 13 Nov 2025 16:56:36 GMT
Subject: RFR: 8371820: Further AES performance improvements for key schedule
 generation
Message-ID: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>

This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.

The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.

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

Commit messages:
 - 8371820: Further AES performance improvements for key schedule generation

Changes: https://git.openjdk.org/jdk/pull/28299/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28299&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371820
  Stats: 33 lines in 2 files changed: 12 ins; 8 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28299.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28299/head:pull/28299

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

From mdoerr at openjdk.org  Thu Nov 13 16:56:37 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 13 Nov 2025 16:56:37 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation
In-Reply-To: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
Message-ID: <hMls9inldccUCrA6QZWIgnnLlewfuXUgiIml0qMTSqY=.56de38d9-5ecd-4bb8-9bc0-98f650671997@github.com>

On Thu, 13 Nov 2025 16:48:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.

@smemery: I've seen your recent improvements and performance measurements. It would be great if you could take a look at this proposal and check the performance results in your environment.

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

PR Comment: https://git.openjdk.org/jdk/pull/28299#issuecomment-3528746436

From mdonovan at openjdk.org  Thu Nov 13 18:12:49 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 13 Nov 2025 18:12:49 GMT
Subject: RFR: 8371349: Update NSS library to 3.117
Message-ID: <w4TY_UMKv-zI8AKsVWjurlgnSQ-krHFnGIS0KXFnc30=.dd863021-d385-4f8c-81ed-9b936ae03e07@github.com>

This is a trivial PR that bumps the version number of NSS to 3.117

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

Commit messages:
 - 8371349: Update NSS library to 3.117

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

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

From weijun at openjdk.org  Thu Nov 13 19:13:16 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Nov 2025 19:13:16 GMT
Subject: RFR: 8371349: Update NSS library to 3.117
In-Reply-To: <w4TY_UMKv-zI8AKsVWjurlgnSQ-krHFnGIS0KXFnc30=.dd863021-d385-4f8c-81ed-9b936ae03e07@github.com>
References: <w4TY_UMKv-zI8AKsVWjurlgnSQ-krHFnGIS0KXFnc30=.dd863021-d385-4f8c-81ed-9b936ae03e07@github.com>
Message-ID: <QRSeyJBA9jzlNfAkTyB2pSLhlxTRDNzGuYmx3MS41VU=.d51bfec2-5a35-4e68-bdbe-2dfb9130b300@github.com>

On Thu, 13 Nov 2025 18:05:25 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This is a trivial PR that bumps the version number of NSS to 3.117

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28303#pullrequestreview-3461280194

From vpaprotski at openjdk.org  Thu Nov 13 19:40:08 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 13 Nov 2025 19:40:08 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
In-Reply-To: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
Message-ID: <cTgnXuli6ZZCwA46IUzgS3OU5e7ZgsNxghT15Yd1LhY=.f3dd2d71-da7d-4ce8-b288-adbfd64c80fc@github.com>

On Tue, 4 Nov 2025 16:38:49 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
>    - `SignatureBench.MLDSA` is 1.2x-2.2x faster
>    - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
> - AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
>   - `SignatureBench.MLDSA` is upto 5% faster, never slower
> 
> Note on intrinsic:
> - The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
> - Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2
> 
> Tests and benchmarks:
> - Added a fuzz test to ensure Java and intrinsic produces exactly same result
> - Added benchmark to measure the performance of intrinsic itself
> 
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"

@ferakocz @ascarpino when you can spare some time, would appreciate a review (would like to get this into 26 if possible..)

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

PR Comment: https://git.openjdk.org/jdk/pull/28136#issuecomment-3529414018

From myankelevich at openjdk.org  Thu Nov 13 21:08:35 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 13 Nov 2025 21:08:35 GMT
Subject: RFR: 8371349: Update NSS library to 3.117
In-Reply-To: <w4TY_UMKv-zI8AKsVWjurlgnSQ-krHFnGIS0KXFnc30=.dd863021-d385-4f8c-81ed-9b936ae03e07@github.com>
References: <w4TY_UMKv-zI8AKsVWjurlgnSQ-krHFnGIS0KXFnc30=.dd863021-d385-4f8c-81ed-9b936ae03e07@github.com>
Message-ID: <SlJcExRXNbk2zLJhx-yHjtBZcs8u7UcnueY3fwPqa6M=.47dee5d0-8de5-48f8-8de5-cea42e61fdaa@github.com>

On Thu, 13 Nov 2025 18:05:25 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This is a trivial PR that bumps the version number of NSS to 3.117

Marked as reviewed by myankelevich (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28303#pullrequestreview-3461685814

From myankelevich at openjdk.org  Thu Nov 13 21:34:08 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 13 Nov 2025 21:34:08 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl
In-Reply-To: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
Message-ID: <eH2PI9T7eTUD1tjycifXp0EkU2zW03eHVtpuzj6-K9k=.0f5ba874-5393-4fdc-82a6-afc7a1d07ec1@github.com>

On Wed, 12 Nov 2025 21:32:36 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> The 3 checkTrusted methods in X509TrustManagerImpl have a lot of repeating code that can be moved into a helper method.
> Also refactoring X509TrustManagerImpl logging code since we are touching this file.

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 228:

> 226:     // Logs an info message and always returns false. This method
> 227:     // can be used as an OR Predicate to add a log in a stream filter.
> 228:     public static boolean logInfo(String option, String s, Object... params) {

Could you please add tests for this in `test/jdk/sun/security/ssl/SSLLogger`? `loginfo` is not hit by the X509Trust manager and could be reused.  The tests could be also added to ssl testing, via `getValidator` method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2524977930

From abarashev at openjdk.org  Thu Nov 13 22:15:03 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 13 Nov 2025 22:15:03 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl
In-Reply-To: <eH2PI9T7eTUD1tjycifXp0EkU2zW03eHVtpuzj6-K9k=.0f5ba874-5393-4fdc-82a6-afc7a1d07ec1@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <eH2PI9T7eTUD1tjycifXp0EkU2zW03eHVtpuzj6-K9k=.0f5ba874-5393-4fdc-82a6-afc7a1d07ec1@github.com>
Message-ID: <N2annh59WXdVEoKGMV0tfCAD8kPTfqNia5st1n-KpWA=.fd996ec6-103a-4311-8955-77e8a6648c81@github.com>

On Thu, 13 Nov 2025 21:23:24 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> The 3 checkTrusted methods in X509TrustManagerImpl have a lot of repeating code that can be moved into a helper method.
>> Also refactoring X509TrustManagerImpl logging code since we are touching this file.
>
> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 228:
> 
>> 226:     // Logs an info message and always returns false. This method
>> 227:     // can be used as an OR Predicate to add a log in a stream filter.
>> 228:     public static boolean logInfo(String option, String s, Object... params) {
> 
> Could you please add tests for this in `test/jdk/sun/security/ssl/SSLLogger`? `loginfo` is not hit by the X509Trust manager and could be reused.  The tests could be also added to ssl testing, via `getValidator` method

`logInfo` is being called by `X509TrustManagerImpl` actually.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2525096165

From duke at openjdk.org  Fri Nov 14 07:19:06 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 14 Nov 2025 07:19:06 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation
In-Reply-To: <hMls9inldccUCrA6QZWIgnnLlewfuXUgiIml0qMTSqY=.56de38d9-5ecd-4bb8-9bc0-98f650671997@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <hMls9inldccUCrA6QZWIgnnLlewfuXUgiIml0qMTSqY=.56de38d9-5ecd-4bb8-9bc0-98f650671997@github.com>
Message-ID: <7ilzxthduL8v18I-SAyihrSyNxkep_mEYkxRBL3lHAY=.41ce1a68-928d-4fb3-a312-f2b8e4b907fd@github.com>

On Thu, 13 Nov 2025 16:49:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.
>
> @smemery: I've seen your recent improvements and performance measurements. It would be great if you could take a look at this proposal and check the performance results in your environment.

@TheRealMDoerr: I've ran your update of the init key schedule w/intrinsics logic and obtained the following results for AESReinit:
x86_64:  19.51% improvement
arm64: 3.11% improvement
Changes in performance for the other AES-related benchmarks (AES[Decrypt].testBaseline and AESBench) had the expected nominal changes.
AES regression tests (Cipher/AES and hotspot/*/aes) have passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28299#issuecomment-3531238034

From duke at openjdk.org  Fri Nov 14 07:31:13 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 14 Nov 2025 07:31:13 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation
In-Reply-To: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
Message-ID: <6lsTW4mcptKcVAuFHu3h39LMajICZZVDhHwrkxM6Rl8=.787cc24a-ae13-49ed-bc56-9c71ad8659b0@github.com>

On Thu, 13 Nov 2025 16:48:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 61:

> 59:     // used for everything else.
> 60:     private int[] sessionKe = null; // key for encryption
> 61:     private int[] sessionKd = null; // preprocessed key for decryption

We really don't need sessionKd, since it's just assigned to K, but I'm fine leaving it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28299#discussion_r2526136351

From duke at openjdk.org  Fri Nov 14 07:35:09 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 14 Nov 2025 07:35:09 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation
In-Reply-To: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
Message-ID: <tXMe1eO0kp63_g0APP7QFZ3qkDnWeUWQ6-jXSOA4j6s=.c6ae21dd-bd88-4ef9-bd6c-047ba7821dc9@github.com>

On Thu, 13 Nov 2025 16:48:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.

src/hotspot/share/opto/library_call.cpp line 7483:

> 7481:   // However, ppc64 vncipher processes MixColumns and requires the same round keys with encryption.
> 7482:   // The ppc64 and riscv64 stubs of encryption and decryption use the same round keys (sessionK[0]).
> 7483:   Node* objSessionK = load_field_from_object(aescrypt_object, "sessionK", "[[I");

Good catch, as I didn't see that intrinsics wasn't using the second array element (inverse key schedule) for these platforms all this time!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28299#discussion_r2526153490

From duke at openjdk.org  Fri Nov 14 07:39:05 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 14 Nov 2025 07:39:05 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation
In-Reply-To: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
Message-ID: <FWAPkaaGzmnIOohLwpBmlCz1CWBlzf7kYg51nDKOHpg=.491ba4f9-7df1-482d-94bb-3af295365f93@github.com>

On Thu, 13 Nov 2025 16:48:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 941:

> 939:         if (decrypting) {
> 940:             if (sessionKd == null) {
> 941:                 sessionKd = genInvRoundKeys(sessionKe, rounds);

Good catch, as this is more efficient given that the inverse key schedule is dependent upon the (encryption) key schedule in the code's current state.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28299#discussion_r2526173217

From duke at openjdk.org  Fri Nov 14 07:46:31 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 14 Nov 2025 07:46:31 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation
In-Reply-To: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
Message-ID: <U-exjyHKmeHkzimoW_j277H9AObaeHJac5FQB1Tv_cs=.fd3e05a7-a894-4a56-9176-b9bfd01076b5@github.com>

On Thu, 13 Nov 2025 16:48:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.

Good catch in eliminating the unnecessary construction of both key schedules on the PPC64, S390, and RISCV64 architectures.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 59:

> 57:     // Following attribute is specific to Intrinsics where the unprocessed
> 58:     // key is used for PPC64, S390, and RISCV64 architectures, whereas K is
> 59:     // used for everything else.

I would change this to:
// Following attributes (sessionKe and K) are specific to Intrinsics, where sessionKe
// is the unprocessed key that is used for PPC64, S390, and RISCV64 architectures,
// whereas K is used for everything else.

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

PR Review: https://git.openjdk.org/jdk/pull/28299#pullrequestreview-3463343453
PR Review Comment: https://git.openjdk.org/jdk/pull/28299#discussion_r2526196244

From mcimadamore at openjdk.org  Fri Nov 14 09:48:28 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Nov 2025 09:48:28 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
Message-ID: <_twwdOdK3jZMnAaDPFubJhbEbR_FEK99I4obbpttveU=.21e193fa-067e-4df1-8cff-4cd0fc704e4f@github.com>

On Wed, 12 Nov 2025 10:07:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
> 
>  - Clarify toString spec
>  - Merge branch 'master' into lazy-constants
>  - Add @AOTSafeClassInitializer
>  - Address comments in PR
>  - Fix merge mistake
>  - Merge master
>  - Rework toString implementations
>  - Update after doc comments
>  - Merge branch 'master' into lazy-constants
>  - Revert the AbstractMap.keySet @Stable annotation
>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

src/java.base/share/classes/java/lang/LazyConstant.java line 241:

> 239: 
> 240:     /**
> 241:      * {@return if this lazy constant is the same as the provided {@code obj}}

maybe add (either in this PR or as follow up) a clarification saying that two different lazy constant that point to the same contents are **not** equals

src/java.base/share/classes/java/lang/LazyConstant.java line 280:

> 278:      * {@code computingFunction} at least until initialization completes successfully.
> 279:      * <p>
> 280:      * If the provided computing function is already an instance of

Not sure how I feel about that -- it seems to soft-break equals...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2526752889
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2526762818

From mcimadamore at openjdk.org  Fri Nov 14 09:55:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Nov 2025 09:55:14 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
Message-ID: <dlCmKBiCeip7juDtJLwy9oYLpsGRTUMVStcF9mDyLV8=.1ab12a3c-32e6-45d5-b02d-6766fae68287@github.com>

On Wed, 12 Nov 2025 10:07:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
> 
>  - Clarify toString spec
>  - Merge branch 'master' into lazy-constants
>  - Add @AOTSafeClassInitializer
>  - Address comments in PR
>  - Fix merge mistake
>  - Merge master
>  - Rework toString implementations
>  - Update after doc comments
>  - Merge branch 'master' into lazy-constants
>  - Revert the AbstractMap.keySet @Stable annotation
>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec

Looks great -- just a couple more javadoc tweaks ;-)

src/java.base/share/classes/java/util/List.java line 1233:

> 1231:      * The returned list's {@linkplain Object#equals(Object) equals()} and
> 1232:      * {@linkplain Object#hashCode() hashCode()} methods may trigger initialization of one
> 1233:      * or more lazy elements. The returned list's {@linkplain Object#toString() toString()}

I thought we have concluded that all Object methods should behave as those in any other list, to maximize migration opportunities.

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

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3464050345
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2526787780

From dfuchs at openjdk.org  Fri Nov 14 10:10:01 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Nov 2025 10:10:01 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v5]
In-Reply-To: <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
 <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>
Message-ID: <k0HaJQgs8MfPE7lwS6NdzMXMlHgFACLozmxm37bcQ2I=.96db4b27-1332-49fb-91fc-8af7a5dbb4dd@github.com>

On Thu, 13 Nov 2025 14:32:33 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed line wrapping
>
> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 104:
> 
>> 102:                         CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)
>> 103:                 .addBasicConstraintsExt(false, false, -1)
>> 104:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))
> 
> I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities

If there is an alternative SAN for IPv4 loopback address there should be one for the IPv6 loopback too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2526848102

From myankelevich at openjdk.org  Fri Nov 14 10:24:40 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 14 Nov 2025 10:24:40 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl
In-Reply-To: <N2annh59WXdVEoKGMV0tfCAD8kPTfqNia5st1n-KpWA=.fd996ec6-103a-4311-8955-77e8a6648c81@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <eH2PI9T7eTUD1tjycifXp0EkU2zW03eHVtpuzj6-K9k=.0f5ba874-5393-4fdc-82a6-afc7a1d07ec1@github.com>
 <N2annh59WXdVEoKGMV0tfCAD8kPTfqNia5st1n-KpWA=.fd996ec6-103a-4311-8955-77e8a6648c81@github.com>
Message-ID: <0rACGkoUmz-o-dDFdDGYVp_wv9voVjssGkOCXrtMeLA=.8caa76a4-d5cb-4b4b-b271-9e305a6022d2@github.com>

On Thu, 13 Nov 2025 22:12:06 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 228:
>> 
>>> 226:     // Logs an info message and always returns false. This method
>>> 227:     // can be used as an OR Predicate to add a log in a stream filter.
>>> 228:     public static boolean logInfo(String option, String s, Object... params) {
>> 
>> Could you please add tests for this in `test/jdk/sun/security/ssl/SSLLogger`? `loginfo` is not hit by the X509Trust manager and could be reused.  The tests could be also added to ssl testing, via `getHostNameInSNI` method
>
> `logInfo` is being called by `X509TrustManagerImpl` actually.

Apologies, I meant the tests. `getHostNameInSNI` itself doesn't seem to be tested either, so there code will never be tested in the current state. Unless there is a test, which I'm just missing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2526923721

From alanb at openjdk.org  Fri Nov 14 12:05:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 12:05:51 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v12]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <nA-LYfoW7cV-mw3hebIVTO2w66lkvu9BGVP267hAOpI=.cd76734b-b8b9-4571-aa8a-4546b59c7432@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge branch 'master' into JDK-8353835
 - Cleanup
 - More cleanup of Field.set API docs, including some restructure from Alex
 - Cleanup
 - Merge branch 'master' into JDK-8353835
 - Update mutateFinals/modules test to exercise exports and opens cases
 - Update Field.set spec to better align with setAccessible for public final field in public class in exported package
 - Fix typo in java man page
 - Add method to test if package exported
 - Remove dup end body tag
 - ... and 49 more: https://git.openjdk.org/jdk/compare/9eaa364a...7693e8fa

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

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=11
  Stats: 5347 lines in 76 files changed: 5152 ins; 55 del; 140 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

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

From mdoerr at openjdk.org  Fri Nov 14 12:13:25 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 14 Nov 2025 12:13:25 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v2]
In-Reply-To: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
Message-ID: <xrzGDyPsjkfEb7u0YwvYQzIDwvLXUrOhZP9XV0ROiBs=.f8abb202-af3c-45cf-8e68-ed112d0b31a6@github.com>

> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Improve comment and minor cleanup.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28299/files
  - new: https://git.openjdk.org/jdk/pull/28299/files/477a3dda..b03e6b43

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

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

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

From mdoerr at openjdk.org  Fri Nov 14 12:13:27 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 14 Nov 2025 12:13:27 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v2]
In-Reply-To: <U-exjyHKmeHkzimoW_j277H9AObaeHJac5FQB1Tv_cs=.fd3e05a7-a894-4a56-9176-b9bfd01076b5@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <U-exjyHKmeHkzimoW_j277H9AObaeHJac5FQB1Tv_cs=.fd3e05a7-a894-4a56-9176-b9bfd01076b5@github.com>
Message-ID: <jN1U6KNB7NGqa2Es10K8QGjTzofQlGTOwcaDZjVek8I=.b2f92cae-3e6f-4f75-8e23-50c42693cd4f@github.com>

On Fri, 14 Nov 2025 07:41:05 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment and minor cleanup.
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 59:
> 
>> 57:     // Following attribute is specific to Intrinsics where the unprocessed
>> 58:     // key is used for PPC64, S390, and RISCV64 architectures, whereas K is
>> 59:     // used for everything else.
> 
> I would change this to:
> // Following attributes (sessionKe and K) are specific to Intrinsics, where sessionKe
> // is the unprocessed key that is used for PPC64, S390, and RISCV64 architectures,
> // whereas K is used for everything else.

Updated. I have also cleaned up the hotspot part a bit.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 61:
> 
>> 59:     // used for everything else.
>> 60:     private int[] sessionKe = null; // key for encryption
>> 61:     private int[] sessionKd = null; // preprocessed key for decryption
> 
> We really don't need sessionKd, since it's just assigned to K, but I'm fine leaving it as is.

Currently, `sessionKd` is needed if we switch between encryption and decryption while using the same key. We could easier remove `K` and pass the information to `LibraryCallKit::get_key_start_from_aescrypt_object` if we are doing encryption or decryption. I can change that if you want, but I'm not sure if it's worth the effort.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28299#discussion_r2527275801
PR Review Comment: https://git.openjdk.org/jdk/pull/28299#discussion_r2527271643

From alanb at openjdk.org  Fri Nov 14 12:35:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 12:35:49 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v12]
In-Reply-To: <nA-LYfoW7cV-mw3hebIVTO2w66lkvu9BGVP267hAOpI=.cd76734b-b8b9-4571-aa8a-4546b59c7432@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <nA-LYfoW7cV-mw3hebIVTO2w66lkvu9BGVP267hAOpI=.cd76734b-b8b9-4571-aa8a-4546b59c7432@github.com>
Message-ID: <O79QRtXKdYOkhJK7oFljv-apKZV1b_GGW-UdinPaVMw=.df1d905d-7a85-486a-b674-3192d006be68@github.com>

On Fri, 14 Nov 2025 12:05:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Cleanup
>  - More cleanup of Field.set API docs, including some restructure from Alex
>  - Cleanup
>  - Merge branch 'master' into JDK-8353835
>  - Update mutateFinals/modules test to exercise exports and opens cases
>  - Update Field.set spec to better align with setAccessible for public final field in public class in exported package
>  - Fix typo in java man page
>  - Add method to test if package exported
>  - Remove dup end body tag
>  - ... and 49 more: https://git.openjdk.org/jdk/compare/9eaa364a...7693e8fa

Just to follow-up on this discussion. The checks done by Field.set on a final field need to the same as, or more restrictive, than the checks done by setAccessible, this is important to preserve traceability. A caller of setAccessible can suppress access checks on a public final in a public class in a package that is exported to at least the caller. So your observation that it is "surprising" to require the package be opened to the caller in order to mutate the field when it is final is a good observation. It's not wrong, it's just more draconian that it should be. I discussed with Alex and Ron and we agreed to adjust the spec for this. We will need to re-submit the CSR with the (small) update.

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

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

From pminborg at openjdk.org  Fri Nov 14 13:35:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 13:35:17 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <dhFCSfTNXvOxuS2Qx41yPqplCUhXTq4IWT-7OWvhK8M=.fc1e937b-1fb2-4572-aa50-db9e1192a4ef@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <qtZot2WX6UOjKT0P4mi4CQKOjoIU5CJMmCieIplwO00=.5ae10b17-9aae-471e-866a-ed876c4d0ffe@github.com>
 <-lErHk2PzyJCaPQGrEwCt3nObTrTHs7_p53eBXspUGE=.50dc2375-8769-49a5-9308-ab40132bbd19@github.com>
 <P1Ti8_ofzrMmdzekvWxWvLQP5Khkt8Ivfb_xGQArNl4=.14fdc4b4-bec7-4b6f-ab71-86d42fb64006@github.com>
 <dhFCSfTNXvOxuS2Qx41yPqplCUhXTq4IWT-7OWvhK8M=.fc1e937b-1fb2-4572-aa50-db9e1192a4ef@github.com>
Message-ID: <ScfYyTv6C7xkXpvHpTblrpnDZPVDn2LjYQHtjPjoevI=.ae9fbf73-afb3-48ff-87ee-c48ca1603ea1@github.com>

On Tue, 11 Nov 2025 16:48:58 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I've added two new benchmarks:
>> 
>> 
>>     private static final LazyConstant<Optional<Integer>> OPTIONAL_42 = LazyConstant.of(() -> Optional.of(42));
>>     private static final LazyConstant<Optional<Integer>> OPTIONAL_42_2 = LazyConstant.of(() -> Optional.of(42));
>>     private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY = LazyConstant.of(Optional::empty);
>>     private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY2 = LazyConstant.of(Optional::empty);
>>     
>>     ...
>>     
>>         @Benchmark
>>     public int staticOptional42() {
>>         return OPTIONAL_42.get().orElseThrow() + OPTIONAL_42_2.get().orElseThrow();
>>     }
>> 
>>     @Benchmark
>>     public boolean staticOptionalEmpty() {
>>         return OPTIONAL_EMPTY.get().isEmpty() ^ OPTIONAL_EMPTY2.get().isEmpty();
>>     }
>> 
>>     
>> 
>> 
>> Which gives:
>> 
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> StableValueBenchmark.staticOptional42  avgt   10  0.354 ? 0.045  ns/op
>> 
>> Benchmark                                 Mode  Cnt  Score   Error  Units
>> StableValueBenchmark.staticOptionalEmpty  avgt   10  0.370 ? 0.030  ns/op
>> 
>> 
>> So, both `Optional` variants appears to support constant folding.
>
> I don't think we can drawn that conclusion just based on the speed. For the non-constant folded cases, this would be 2 loads and an xor.
> 
> I don't see how C2 would be allowed to constant fold the loads if the value is `null`, since that's explicitly forbidden by `@Stable` (and there's no easy way around that AFAIK, since the JIT thread may see a partially initialized object, so it conservatively ignores default values).

Yes. I think you are right @JornVernee. I've explored several ways to fix this and the simplest one might be to have a sentinel value instead of `null` to flag emptiness. Splitting the class into a bimorphic implementation would not be good for `value` classes (at least not for now), even though the C2 might otherwise be able to optimize the two variants.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527523848

From abarashev at openjdk.org  Fri Nov 14 14:29:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 14 Nov 2025 14:29:00 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl
In-Reply-To: <0rACGkoUmz-o-dDFdDGYVp_wv9voVjssGkOCXrtMeLA=.8caa76a4-d5cb-4b4b-b271-9e305a6022d2@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <eH2PI9T7eTUD1tjycifXp0EkU2zW03eHVtpuzj6-K9k=.0f5ba874-5393-4fdc-82a6-afc7a1d07ec1@github.com>
 <N2annh59WXdVEoKGMV0tfCAD8kPTfqNia5st1n-KpWA=.fd996ec6-103a-4311-8955-77e8a6648c81@github.com>
 <0rACGkoUmz-o-dDFdDGYVp_wv9voVjssGkOCXrtMeLA=.8caa76a4-d5cb-4b4b-b271-9e305a6022d2@github.com>
Message-ID: <wgiXlKjRC3DvT8-4h1FSP8xcuL2kXJHEemTIIx0UlMg=.71bcd324-44ef-4da4-a2ea-718dbd4243ce@github.com>

On Fri, 14 Nov 2025 10:21:57 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> `logInfo` is being called by `X509TrustManagerImpl` actually.
>
> Apologies, I meant the tests. `getHostNameInSNI` itself doesn't seem to be tested either, so there code will never be tested in the current state. Unless there is a test, which I'm just missing

This is just a refactoring PR. Please file a new ticket if you think `getHostNameInSNI` needs a unit test. I think it's better to keep things separate. Refactoring assumes that no new tests needed. Also not sure if we should test new logging methods, I couldn't find any unit tests for existing logging methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2527702276

From pminborg at openjdk.org  Fri Nov 14 14:44:49 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 14:44:49 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <Wd007lKJSjzYhyuz3x2mNThGNk32iP9Mmh0ouOQc48Q=.98fb1ae5-ae22-458d-a2da-3ac3c4f7c2fe@github.com>

On Wed, 12 Nov 2025 16:02:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 66:
> 
>> 64:         // using `elements.length`.
>> 65:         @Stable
>> 66:         private final int size;
> 
> Is this really that important? What about the extra footprint added by the `int` field? We might have many instances of this class, but only one copy of the bytecode.

Hrrm. I wonder if the C2 compiler will end up producing equivalent code for the two variants? But there are merits to your argument.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527753354

From pminborg at openjdk.org  Fri Nov 14 15:15:51 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 15:15:51 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <7emI0lI9l1ZnKE89i3hDeQl4KiaE_GutmkDoIu772Ik=.276d7422-4102-425a-a92f-439134945f60@github.com>

On Wed, 12 Nov 2025 16:08:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 199:
> 
>> 197:                 final int size = base.size();
>> 198:                 subListRangeCheck(fromIndex, toIndex, size);
>> 199:                 return new ReverseOrderLazyListView<>(base.subList(size - toIndex, size - fromIndex));
> 
> Why not this? (maybe add a comment?)
> Suggestion:
> 
>                 return new ReverseOrderLazyListView<>(base.subList(fromIndex, toIndex));

Actually, now that toString() evaluates, we could just get rid of these classes and use the ones in the base class. Great!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527855543

From pminborg at openjdk.org  Fri Nov 14 15:35:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 15:35:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <sNjO1swdzNxW2L5GbPoiKqOMlTDoFlfr3SVhz3HHNgY=.4ee45512-ed3b-4ffb-bd00-580ea3844cf9@github.com>

On Wed, 12 Nov 2025 16:17:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 433:
> 
>> 431:             @Override public V      getValue() {
>> 432:                 final int index = map.indexFor(getKey);
>> 433:                 final V v = map.getAcquire(getKey);
> 
> I suppose you could use `orElseCompute` here, since you already have the index

Nice. Then we can get rid of the getAquire() method as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527915904

From pminborg at openjdk.org  Fri Nov 14 15:41:36 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Nov 2025 15:41:36 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <WBO95zELN7EAwB9UN4YiMsjASTj-BZymURJsrtFSG68=.9a84f15e-874b-4572-994b-daf3c543391f@github.com>
Message-ID: <6zrll105lMejyo1PAG6cfBFzYt3N2-_9lIK6uP-Wl8A=.3e7908a7-71da-452e-8703-c4b7b5d661c3@github.com>

On Wed, 12 Nov 2025 16:32:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/util/LazyCollections.java line 607:
> 
>> 605:         assert Thread.holdsLock(mutex) : index + "didn't hold " + mutex;
>> 606:         // We know we hold the monitor here so plain semantic is enough
>> 607:         if (array[index] == null) {
> 
> This should always be true when we get here, right?

This is just an extra safety net to emulate a CAS op (while we are holding the monitor).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2527936851

From mdoerr at openjdk.org  Fri Nov 14 17:21:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 14 Nov 2025 17:21:50 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v3]
In-Reply-To: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
Message-ID: <-srlt_N0wyBwCwOmZTJBdGNFm66doGBHr6Yx83pqSpQ=.be8e4031-f542-49ad-8271-ac9a2c8b9128@github.com>

> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  More minor cleanup.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28299/files
  - new: https://git.openjdk.org/jdk/pull/28299/files/b03e6b43..621616a4

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

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

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

From hchao at openjdk.org  Fri Nov 14 17:36:03 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 14 Nov 2025 17:36:03 GMT
Subject: RFR: 8371349: Update NSS library to 3.117
In-Reply-To: <w4TY_UMKv-zI8AKsVWjurlgnSQ-krHFnGIS0KXFnc30=.dd863021-d385-4f8c-81ed-9b936ae03e07@github.com>
References: <w4TY_UMKv-zI8AKsVWjurlgnSQ-krHFnGIS0KXFnc30=.dd863021-d385-4f8c-81ed-9b936ae03e07@github.com>
Message-ID: <8izoC6sIIESdKYFShp7eBqSjdJEVA9SdtpqLTvi6q3w=.7bac4682-7f48-4098-af49-23078195d379@github.com>

On Thu, 13 Nov 2025 18:05:25 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This is a trivial PR that bumps the version number of NSS to 3.117

Marked as reviewed by hchao (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28303#pullrequestreview-3466006897

From hchao at openjdk.org  Fri Nov 14 18:07:02 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 14 Nov 2025 18:07:02 GMT
Subject: RFR: 8343316: Review and update tests using explicit provider
 names
In-Reply-To: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>
References: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>
Message-ID: <-0AwayFznSjilir9ac6Xvi6L3gE88H785fCfGA2hypA=.e28149fa-9e33-48e3-a1ee-ba777d35051d@github.com>

On Wed, 12 Nov 2025 17:58:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I updated a few crypto tests to remove the hard-coded provider name and use the `test.provider.name` property instead. These tests were missed while working on [JDK-8341927](https://bugs.openjdk.org/browse/JDK-8341927).

nit: update the copyright year for the changed files

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

PR Review: https://git.openjdk.org/jdk/pull/28273#pullrequestreview-3466127183

From hchao at openjdk.org  Fri Nov 14 18:19:09 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 14 Nov 2025 18:19:09 GMT
Subject: RFR: 8343316: Review and update tests using explicit provider
 names
In-Reply-To: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>
References: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>
Message-ID: <bSFJMKuBLgpQovYwYY-40lDLrn5fzUUlTzxMhGC8NtY=.6fae8332-869e-4687-9430-16e8136d1f7d@github.com>

On Wed, 12 Nov 2025 17:58:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I updated a few crypto tests to remove the hard-coded provider name and use the `test.provider.name` property instead. These tests were missed while working on [JDK-8341927](https://bugs.openjdk.org/browse/JDK-8341927).

test/jdk/com/sun/crypto/provider/KeyAgreement/DHGenSharedSecret.java line 61:

> 59:         KeyPairGenerator keyGen =
> 60:             KeyPairGenerator.getInstance("DH",
> 61:                     System.getProperty("test.provider.name", "SunJCE"));

You may consider defining a final string `PROVIDER_NAME` used by this class like the other changed files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28273#discussion_r2528462927

From myankelevich at openjdk.org  Fri Nov 14 18:55:14 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 14 Nov 2025 18:55:14 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl
In-Reply-To: <wgiXlKjRC3DvT8-4h1FSP8xcuL2kXJHEemTIIx0UlMg=.71bcd324-44ef-4da4-a2ea-718dbd4243ce@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <eH2PI9T7eTUD1tjycifXp0EkU2zW03eHVtpuzj6-K9k=.0f5ba874-5393-4fdc-82a6-afc7a1d07ec1@github.com>
 <N2annh59WXdVEoKGMV0tfCAD8kPTfqNia5st1n-KpWA=.fd996ec6-103a-4311-8955-77e8a6648c81@github.com>
 <0rACGkoUmz-o-dDFdDGYVp_wv9voVjssGkOCXrtMeLA=.8caa76a4-d5cb-4b4b-b271-9e305a6022d2@github.com>
 <wgiXlKjRC3DvT8-4h1FSP8xcuL2kXJHEemTIIx0UlMg=.71bcd324-44ef-4da4-a2ea-718dbd4243ce@github.com>
Message-ID: <IltKwxljepn6cpKZXuMeb7MeoGF_a71uJ8fUp66vJDE=.8516f6da-4bbb-49a3-9979-c9e06a8332e4@github.com>

On Fri, 14 Nov 2025 14:25:45 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Apologies, I meant the tests. `getHostNameInSNI` itself doesn't seem to be tested either, so there code will never be tested in the current state. Unless there is a test, which I'm just missing
>
> This is just a refactoring PR. Please file a new ticket if you think `getHostNameInSNI` needs a unit test. I think it's better to keep things separate. Refactoring assumes that no new tests needed. Also not sure if we should test new logging methods, I couldn't find any unit tests for existing logging methods.

Ok, I have created [JDK-8371925 ](https://bugs.openjdk.org/browse/JDK-8371925 ). Will push a pr for it after this pr is closed. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2528579023

From weijun at openjdk.org  Fri Nov 14 19:14:10 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Nov 2025 19:14:10 GMT
Subject: RFR: 8371156: PBKDF2 default values should not be DER encoded
In-Reply-To: <FDgInl6vK5pt6NliKB0Yw87jnp3xFKdWZzYB7S6n2Yk=.7b016069-73d6-49e0-be45-d2b74af5e950@github.com>
References: <FDgInl6vK5pt6NliKB0Yw87jnp3xFKdWZzYB7S6n2Yk=.7b016069-73d6-49e0-be45-d2b74af5e950@github.com>
Message-ID: <IHuhaF23TvWHjfodZwvjkAKeYj07ruY6swSEjtEKmP4=.23fcfe0c-a198-42d1-936f-3d1f375cc8f9@github.com>

On Thu, 6 Nov 2025 19:49:56 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> [JDK-8371156](https://bugs.openjdk.org/browse/JDK-8371156)
> 
> HmacSHA1 is the DEFAULT for PBKDF2. Therefore, it should not be DER encoded.
> 
> 
> PBKDF2-params ::= SEQUENCE {
>      salt CHOICE {
>          specified OCTET STRING,
>          otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}}
>     },
>     iterationCount INTEGER (1..MAX),
>     keyLength INTEGER (1..MAX) OPTIONAL,
>     prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT algid-hmacWithSHA1
> }

test/jdk/sun/security/pkcs12/ImportPassKeyAlg.java line 96:

> 94:         // 003B:000E  [1013]                 SEQUENCE
> 95:         // 003D:000A  [10130]                     OID 1.2.840.113549.2.7 (HmacSHA1)
> 96:         // 0047:0002  [10131]                     NULL

Thanks for catching this. Unfortunately, the example encoding shown here is exactly for the HmacSHA1 case so it's incorrect now. You can change line 95 above to

003D:000A  [10130]                     OID 1.2.840.113549.2.9 (HmacSHA256)

Otherwise, all good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28182#discussion_r2528635531

From weijun at openjdk.org  Fri Nov 14 19:33:06 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Nov 2025 19:33:06 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v12]
In-Reply-To: <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
Message-ID: <Bgo4GRzWx9hAhopduyP6Y-uyTp4ftga6SqJLIJsJZq4=.3ad6718d-27f0-4b9e-a4c8-8a8a58f31850@github.com>

On Thu, 13 Nov 2025 11:02:21 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Small doc fix
>  - Attend to @wangweij's code review comments - in particular a large clean-up of the test helper and the output it creates
>  - Attend to remaining comments from @smemery

test/jdk/sun/security/krb5/native/NativeCredentialCacheHelper.java line 50:

> 48:     public static native boolean createInMemoryCacheFromFileCache(String inMemoryCacheName, String fileCacheName);
> 49: }
> 50: 

There are 2 newlines at the end. One is enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2528699601

From sviswanathan at openjdk.org  Fri Nov 14 19:51:13 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 14 Nov 2025 19:51:13 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
In-Reply-To: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
Message-ID: <ortiLDK7paRSaADR-rSRSIdZkDcLTad_8HUOffAdKXE=.d3235fc3-e3a0-46a0-b91b-f770d046f4b0@github.com>

On Tue, 4 Nov 2025 16:38:49 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
>    - `SignatureBench.MLDSA` is 1.2x-2.2x faster
>    - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
> - AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
>   - `SignatureBench.MLDSA` is upto 5% faster, never slower
> 
> Note on intrinsic:
> - The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
> - Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2
> 
> Tests and benchmarks:
> - Added a fuzz test to ensure Java and intrinsic produces exactly same result
> - Added benchmark to measure the performance of intrinsic itself
> 
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"

src/hotspot/cpu/x86/assembler_x86.cpp line 3865:

> 3863: void Assembler::vmovsldup(XMMRegister dst, XMMRegister src, int vector_len) {
> 3864:     assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
> 3865:             (vector_len == AVX_256bit ? VM_Version::supports_avx2() :

Vector length 256 bit is supported by AVX=1.

src/hotspot/cpu/x86/assembler_x86.cpp line 3874:

> 3872: void Assembler::vmovshdup(XMMRegister dst, XMMRegister src, int vector_len) {
> 3873:   assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
> 3874:           (vector_len == AVX_256bit ? VM_Version::supports_avx2() :

Vector length 256 bit is supported by AVX=1.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 83:

> 81: // size 0 and 1 are used for initial and final shuffles respectivelly of
> 82: // dilithiumAlmostInverseNtt and dilithiumAlmostNtt.
> 83: // NOTE: For size 0 and 1, input1[] and input2[] are modified in-place

what is the size-in-bits when size is 0 and 1? What is the difference between size 0 and size1? The overloading of size makes it confusing.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 137:

> 135:           for (int i = 0; i < regCnt; i++) {
> 136:             // 0b-1-2-3-1
> 137:             __ vshufps(output2[i], input1[i], input2[i], 0b11011101, vector_len);

Did you mean this to be //0b-1-3-1-3?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2528279719
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2528288894
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2528416321
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2528610634

From sviswanathan at openjdk.org  Fri Nov 14 19:51:14 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 14 Nov 2025 19:51:14 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
In-Reply-To: <ortiLDK7paRSaADR-rSRSIdZkDcLTad_8HUOffAdKXE=.d3235fc3-e3a0-46a0-b91b-f770d046f4b0@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
 <ortiLDK7paRSaADR-rSRSIdZkDcLTad_8HUOffAdKXE=.d3235fc3-e3a0-46a0-b91b-f770d046f4b0@github.com>
Message-ID: <LtMzYAXX97kBhpoynv3mUPTpnAEgHAl0dQPtIiiRiTk=.e3a17eab-8b42-4564-b3a4-86e48c48e2b8@github.com>

On Fri, 14 Nov 2025 17:51:24 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> - New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
>>    - `SignatureBench.MLDSA` is 1.2x-2.2x faster
>>    - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
>> - AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
>>   - `SignatureBench.MLDSA` is upto 5% faster, never slower
>> 
>> Note on intrinsic:
>> - The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
>> - Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2
>> 
>> Tests and benchmarks:
>> - Added a fuzz test to ensure Java and intrinsic produces exactly same result
>> - Added benchmark to measure the performance of intrinsic itself
>> 
>> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
>> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
>> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
>> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 83:
> 
>> 81: // size 0 and 1 are used for initial and final shuffles respectivelly of
>> 82: // dilithiumAlmostInverseNtt and dilithiumAlmostNtt.
>> 83: // NOTE: For size 0 and 1, input1[] and input2[] are modified in-place
> 
> what is the size-in-bits when size is 0 and 1? What is the difference between size 0 and size1? The overloading of size makes it confusing.

size 0 seems to be doing a different shuffle than what is described in the diagram.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 137:
> 
>> 135:           for (int i = 0; i < regCnt; i++) {
>> 136:             // 0b-1-2-3-1
>> 137:             __ vshufps(output2[i], input1[i], input2[i], 0b11011101, vector_len);
> 
> Did you mean this to be //0b-1-3-1-3?

or 3-1-3-1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2528747938
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2528753295

From ascarpino at openjdk.org  Fri Nov 14 21:11:34 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 14 Nov 2025 21:11:34 GMT
Subject: Integrated: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview)
In-Reply-To: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
Message-ID: <W-0XExUq__629PgK_dSJeLo_LGrU54xmiQEFnHkSm9s=.41b62e2b-d088-4a01-9a65-bc4de6c02e68@github.com>

On Mon, 8 Sep 2025 15:42:13 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
> 
> - Renamed the name of `PEMRecord` class to `PEM`.
> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
> 
> thanks
> 
> Tony

This pull request has now been integrated.

Changeset: ad3dfaf1
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad3dfaf1fc483bb2bfd5c26d76c43b8f69454cbd
Stats:     1967 lines in 23 files changed: 1044 ins; 475 del; 448 mod

8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview)

Reviewed-by: weijun, mullan

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

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

From weijun at openjdk.org  Fri Nov 14 23:51:34 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Nov 2025 23:51:34 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v12]
In-Reply-To: <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
Message-ID: <7eI7zey61hqLAL04UNE9DC82k86ulBvKp2kyr3ITA7M=.33adeb69-8c1f-4a49-b166-4c3d9c8b1657@github.com>

On Thu, 13 Nov 2025 11:02:21 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Small doc fix
>  - Attend to @wangweij's code review comments - in particular a large clean-up of the test helper and the output it creates
>  - Attend to remaining comments from @smemery

test/jdk/sun/security/krb5/native/NativeCacheTest.java line 37:

> 35:  *   --add-exports java.security.jgss/sun.security.jgss.krb5=ALL-UNNAMED
> 36:  *   --add-exports java.base/sun.security.util=ALL-UNNAMED
> 37:  *   --add-exports java.base/jdk.internal.misc=ALL-UNNAMED

Use

@modules java.security.jgss/sun.security.krb5
         java.security.jgss/sun.security.krb5.internal
         ...

It applies to both compile and run.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2529265765

From weijun at openjdk.org  Sat Nov 15 01:28:08 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 15 Nov 2025 01:28:08 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality
In-Reply-To: <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
Message-ID: <NSzf7P8xTUQicbN1UnWP73JPhP2vABPZTQ7WFkED2S4=.a745903e-dabd-4698-94b4-20e96851b4b7@github.com>

On Thu, 30 Oct 2025 22:55:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Is there a particular reason for build.sh in the tests or are you just not familiar with how native test code gets automatically compiled by the makefiles based on file naming conventions? In short, any file `lib*.c[pp]` will get compiled into a native library (and exe*.c[pp] into an executable). You can define any special flags or platform include/exclude in `make/test/JtregNativeJdk.gmk`.

Hi @erikj79, I noticed that in our CI build the library is not built and the log shows

checking for krb5 (<omitted>)... no
checking krb5.h usability... no
checking krb5.h presence... no
checking for krb5.h... no 

Should we require them to be present?

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3535280140

From ascarpino at openjdk.org  Sat Nov 15 02:42:37 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 15 Nov 2025 02:42:37 GMT
Subject: RFR: 8371934: EncryptedPrivateKeyInfo methods need @since updates
Message-ID: <sFJe3MVh5rz44TtVvLSEpvDNhvI1OMzpUk3-zu46PTM=.940edb9a-6de2-4a52-9814-63ac21aceeb5@github.com>

Need a review to fix simple doc test failure

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

Commit messages:
 - fix merge
 - Merge branch 'master' into pem26
 - @since fix for EKPI
 - Merge branch 'master' into pem26
 - remove PEMRecord import
 - mistakes
 - Merge branch 'master' into pem26
 - minor doc updates, fix some bugs, PEM set to 26
 - more docs, remove runtimeexception
 - EKPI has a lot of @link's
 - ... and 20 more: https://git.openjdk.org/jdk/compare/7c169c98...6bdcdfba

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

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

From jnimeh at openjdk.org  Sat Nov 15 02:45:04 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Sat, 15 Nov 2025 02:45:04 GMT
Subject: RFR: 8371934: EncryptedPrivateKeyInfo methods need @since updates
In-Reply-To: <sFJe3MVh5rz44TtVvLSEpvDNhvI1OMzpUk3-zu46PTM=.940edb9a-6de2-4a52-9814-63ac21aceeb5@github.com>
References: <sFJe3MVh5rz44TtVvLSEpvDNhvI1OMzpUk3-zu46PTM=.940edb9a-6de2-4a52-9814-63ac21aceeb5@github.com>
Message-ID: <bqN1gM-S7YSfJD7J07xJrirA7G25GDD3nmAeTmMRCeI=.c46b49b8-1255-4155-9d66-83e00be0d904@github.com>

On Sat, 15 Nov 2025 02:35:49 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Need a review to fix simple doc test failure

Marked as reviewed by jnimeh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28334#pullrequestreview-3467540198

From ascarpino at openjdk.org  Sat Nov 15 02:49:12 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 15 Nov 2025 02:49:12 GMT
Subject: Integrated: 8371934: EncryptedPrivateKeyInfo methods need @since
 updates
In-Reply-To: <sFJe3MVh5rz44TtVvLSEpvDNhvI1OMzpUk3-zu46PTM=.940edb9a-6de2-4a52-9814-63ac21aceeb5@github.com>
References: <sFJe3MVh5rz44TtVvLSEpvDNhvI1OMzpUk3-zu46PTM=.940edb9a-6de2-4a52-9814-63ac21aceeb5@github.com>
Message-ID: <Qc_3D5ZZCuvcNPSs3U2aQzWNoFobSzCGe05vKGTUeH0=.75b66247-fd27-4be2-9578-0e6005f444fb@github.com>

On Sat, 15 Nov 2025 02:35:49 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Need a review to fix simple doc test failure

This pull request has now been integrated.

Changeset: 6042c9a6
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6042c9a6f0c25c141a74d72ad462189da7f9e625
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8371934: EncryptedPrivateKeyInfo methods need @since updates

Reviewed-by: jnimeh

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

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

From liach at openjdk.org  Sat Nov 15 08:59:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 15 Nov 2025 08:59:19 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v12]
In-Reply-To: <nA-LYfoW7cV-mw3hebIVTO2w66lkvu9BGVP267hAOpI=.cd76734b-b8b9-4571-aa8a-4546b59c7432@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <nA-LYfoW7cV-mw3hebIVTO2w66lkvu9BGVP267hAOpI=.cd76734b-b8b9-4571-aa8a-4546b59c7432@github.com>
Message-ID: <Z6J31ksDj2H9Dicr0uemdgm1hToatESuJWmI3g_fb-Y=.9de2e579-6988-44d6-8589-da9354ea94e1@github.com>

On Fri, 14 Nov 2025 12:05:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Cleanup
>  - More cleanup of Field.set API docs, including some restructure from Alex
>  - Cleanup
>  - Merge branch 'master' into JDK-8353835
>  - Update mutateFinals/modules test to exercise exports and opens cases
>  - Update Field.set spec to better align with setAccessible for public final field in public class in exported package
>  - Fix typo in java man page
>  - Add method to test if package exported
>  - Remove dup end body tag
>  - ... and 49 more: https://git.openjdk.org/jdk/compare/9eaa364a...7693e8fa

src/java.base/share/classes/java/lang/Module.java line 1032:

> 1030:      * Updates this module to export a package to another module.
> 1031:      *
> 1032:      * @apiNote Used addExports, Instrumentation::redefineModule, and --add-exports

Suggestion:

     * @apiNote Used by addExports, Instrumentation::redefineModule, and --add-exports

src/java.base/share/classes/java/lang/reflect/Field.java line 1621:

> 1619:     private String notAccessibleToCallerMessage(Class<?> caller, boolean unreflect) {
> 1620:         String exportOrOpen = Modifier.isPublic(modifiers)
> 1621:                 && Modifier.isPublic(clazz.getModifiers()) ? "exports" : "open";

Suggestion:

                && Modifier.isPublic(clazz.getModifiers()) ? "export" : "open";

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2529101056
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2529099290

From alanb at openjdk.org  Sat Nov 15 08:59:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Nov 2025 08:59:20 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v12]
In-Reply-To: <Z6J31ksDj2H9Dicr0uemdgm1hToatESuJWmI3g_fb-Y=.9de2e579-6988-44d6-8589-da9354ea94e1@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <nA-LYfoW7cV-mw3hebIVTO2w66lkvu9BGVP267hAOpI=.cd76734b-b8b9-4571-aa8a-4546b59c7432@github.com>
 <Z6J31ksDj2H9Dicr0uemdgm1hToatESuJWmI3g_fb-Y=.9de2e579-6988-44d6-8589-da9354ea94e1@github.com>
Message-ID: <nfULlQYdzCqlUugtO2GhIBPk55nK2TiEL1pbeD6bzDs=.e4e02797-caa7-45e3-a9d5-03ae73dfdbc9@github.com>

On Fri, 14 Nov 2025 22:05:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:
>> 
>>  - Merge branch 'master' into JDK-8353835
>>  - Cleanup
>>  - More cleanup of Field.set API docs, including some restructure from Alex
>>  - Cleanup
>>  - Merge branch 'master' into JDK-8353835
>>  - Update mutateFinals/modules test to exercise exports and opens cases
>>  - Update Field.set spec to better align with setAccessible for public final field in public class in exported package
>>  - Fix typo in java man page
>>  - Add method to test if package exported
>>  - Remove dup end body tag
>>  - ... and 49 more: https://git.openjdk.org/jdk/compare/9eaa364a...7693e8fa
>
> src/java.base/share/classes/java/lang/reflect/Field.java line 1621:
> 
>> 1619:     private String notAccessibleToCallerMessage(Class<?> caller, boolean unreflect) {
>> 1620:         String exportOrOpen = Modifier.isPublic(modifiers)
>> 1621:                 && Modifier.isPublic(clazz.getModifiers()) ? "exports" : "open";
> 
> Suggestion:
> 
>                 && Modifier.isPublic(clazz.getModifiers()) ? "export" : "open";

With InaccessibleObjectException we put the (contextual) keyword in double quotes so that the exception message has `"exports" $P` or `"opens" $P`, and hopefully guide the developer to the module declaration. For this IllegalAccessException case then it should probably be the same so that the message has `"exports" $P to module $M`, in which case it should be "opens" rather than "open".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2529713811

From liach at openjdk.org  Sat Nov 15 19:07:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 15 Nov 2025 19:07:10 GMT
Subject: RFR: 8371934: EncryptedPrivateKeyInfo methods need @since updates
In-Reply-To: <sFJe3MVh5rz44TtVvLSEpvDNhvI1OMzpUk3-zu46PTM=.940edb9a-6de2-4a52-9814-63ac21aceeb5@github.com>
References: <sFJe3MVh5rz44TtVvLSEpvDNhvI1OMzpUk3-zu46PTM=.940edb9a-6de2-4a52-9814-63ac21aceeb5@github.com>
Message-ID: <hNbm61dCzkqN3Dfk2dSb10ZNsPatVBJTYQHnJgniGdI=.224b69a6-afa0-4bd6-aa1a-a1faa3b5ae4b@github.com>

On Sat, 15 Nov 2025 02:35:49 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Need a review to fix simple doc test failure

Indeed, the checker is right: a method is considered completely new if it involves any rename or erased parameter type change, so the since version should be 26.

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

PR Comment: https://git.openjdk.org/jdk/pull/28334#issuecomment-3536783023

From pminborg at openjdk.org  Sun Nov 16 09:40:19 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Sun, 16 Nov 2025 09:40:19 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v25]
In-Reply-To: <_twwdOdK3jZMnAaDPFubJhbEbR_FEK99I4obbpttveU=.21e193fa-067e-4df1-8cff-4cd0fc704e4f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <idgwb4mfKJ64Ro5OVi7NeuY4yLw5ry9cJ2_V2STzSo4=.0aff1f42-cfe5-4808-8823-59ddf34345b0@github.com>
 <_twwdOdK3jZMnAaDPFubJhbEbR_FEK99I4obbpttveU=.21e193fa-067e-4df1-8cff-4cd0fc704e4f@github.com>
Message-ID: <CQ7EtP0euKkv6mqVzXXTc40PyYxMwy_WPzuw9zf_K0A=.5abfa43c-df2f-4201-a196-7c533514bda8@github.com>

On Fri, 14 Nov 2025 09:45:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 112 commits:
>> 
>>  - Clarify toString spec
>>  - Merge branch 'master' into lazy-constants
>>  - Add @AOTSafeClassInitializer
>>  - Address comments in PR
>>  - Fix merge mistake
>>  - Merge master
>>  - Rework toString implementations
>>  - Update after doc comments
>>  - Merge branch 'master' into lazy-constants
>>  - Revert the AbstractMap.keySet @Stable annotation
>>  - ... and 102 more: https://git.openjdk.org/jdk/compare/76a1109d...1f439bec
>
> src/java.base/share/classes/java/lang/LazyConstant.java line 280:
> 
>> 278:      * {@code computingFunction} at least until initialization completes successfully.
>> 279:      * <p>
>> 280:      * If the provided computing function is already an instance of
> 
> Not sure how I feel about that -- it seems to soft-break equals...

Let's think about this once more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2531779955

From mpowers at openjdk.org  Sun Nov 16 13:44:47 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Sun, 16 Nov 2025 13:44:47 GMT
Subject: RFR: 8371156: PBKDF2 default values should not be DER encoded [v2]
In-Reply-To: <FDgInl6vK5pt6NliKB0Yw87jnp3xFKdWZzYB7S6n2Yk=.7b016069-73d6-49e0-be45-d2b74af5e950@github.com>
References: <FDgInl6vK5pt6NliKB0Yw87jnp3xFKdWZzYB7S6n2Yk=.7b016069-73d6-49e0-be45-d2b74af5e950@github.com>
Message-ID: <JknWjM_1SlkqN2nHXZb1wT7CH6rq-70vjHlJI5W1xjU=.7e7ebf38-8351-487c-bea9-d67e320aa3e0@github.com>

> [JDK-8371156](https://bugs.openjdk.org/browse/JDK-8371156)
> 
> HmacSHA1 is the DEFAULT for PBKDF2. Therefore, it should not be DER encoded.
> 
> 
> PBKDF2-params ::= SEQUENCE {
>      salt CHOICE {
>          specified OCTET STRING,
>          otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}}
>     },
>     iterationCount INTEGER (1..MAX),
>     keyLength INTEGER (1..MAX) OPTIONAL,
>     prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT algid-hmacWithSHA1
> }

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

  comment from weijun

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28182/files
  - new: https://git.openjdk.org/jdk/pull/28182/files/1172c284..b028ee29

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

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

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

From weijun at openjdk.org  Sun Nov 16 16:41:03 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 16 Nov 2025 16:41:03 GMT
Subject: RFR: 8371156: PBKDF2 default values should not be DER encoded [v2]
In-Reply-To: <JknWjM_1SlkqN2nHXZb1wT7CH6rq-70vjHlJI5W1xjU=.7e7ebf38-8351-487c-bea9-d67e320aa3e0@github.com>
References: <FDgInl6vK5pt6NliKB0Yw87jnp3xFKdWZzYB7S6n2Yk=.7b016069-73d6-49e0-be45-d2b74af5e950@github.com>
 <JknWjM_1SlkqN2nHXZb1wT7CH6rq-70vjHlJI5W1xjU=.7e7ebf38-8351-487c-bea9-d67e320aa3e0@github.com>
Message-ID: <hSP4DdaLu8bYJzYxP8D6-f8ug5RswC-4WaKWRMNpDW8=.7c40d7c5-4ae4-4dfc-a262-1e959d1c76f1@github.com>

On Sun, 16 Nov 2025 13:44:47 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8371156](https://bugs.openjdk.org/browse/JDK-8371156)
>> 
>> HmacSHA1 is the DEFAULT for PBKDF2. Therefore, it should not be DER encoded.
>> 
>> 
>> PBKDF2-params ::= SEQUENCE {
>>      salt CHOICE {
>>          specified OCTET STRING,
>>          otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}}
>>     },
>>     iterationCount INTEGER (1..MAX),
>>     keyLength INTEGER (1..MAX) OPTIONAL,
>>     prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT algid-hmacWithSHA1
>> }
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from weijun

Everything looks fine. Thanks.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28182#pullrequestreview-3470287664

From mpowers at openjdk.org  Sun Nov 16 17:24:15 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Sun, 16 Nov 2025 17:24:15 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
In-Reply-To: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
Message-ID: <_TeZd3joeNkWYg7ZOgYRwzRJJjwMcUVOfe-pdXzJTv4=.d413a241-c8de-4267-8b98-0b41c7629371@github.com>

On Tue, 4 Nov 2025 16:38:49 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
>    - `SignatureBench.MLDSA` is 1.2x-2.2x faster
>    - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
> - AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
>   - `SignatureBench.MLDSA` is upto 5% faster, never slower
> 
> Note on intrinsic:
> - The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
> - Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2
> 
> Tests and benchmarks:
> - Added a fuzz test to ensure Java and intrinsic produces exactly same result
> - Added benchmark to measure the performance of intrinsic itself
> 
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"

You might want to have @kuksenko or @ericcaspole look at MLDSABench.java.

test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 29:

> 27: import java.lang.invoke.MethodHandle;
> 28: import java.lang.invoke.MethodHandles;
> 29: import java.lang.reflect.Field;

unused import statement

test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 31:

> 29: import java.lang.reflect.Field;
> 30: import java.lang.reflect.Method;
> 31: import java.lang.reflect.Constructor;

unused import

test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 123:

> 121:         try {
> 122:             for (int i = 0; i < repeat; i++) {
> 123:                 // seed = rnd.nextLong();

2 lines commented out

test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 219:

> 217:         int[] coeffs3 = new int[ML_DSA_N];
> 218:         for (int j = 0; j<ML_DSA_N; j++) {
> 219:             coeffs3[j] =

`coeffs3` is written to but never read

test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 517:

> 515:     };
> 516: }
> 517: // java --add-opens java.base/sun.security.provider=ALL-UNNAMED  -XX:+UseDilithiumIntrinsics test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java

This is line is useful. Not sure I would hide it at the bottom of the file.

test/micro/org/openjdk/bench/javax/crypto/full/MLDSABench.java line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.

Copyright date.

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

Marked as reviewed by mpowers (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28136#pullrequestreview-3470287661
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532070492
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532071025
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532075447
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532074544
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532078122
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532078790

From alanb at openjdk.org  Sun Nov 16 17:26:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Nov 2025 17:26:50 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v13]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <dbW07VkPhX6rVrXYfyFABHfOEg-K9CIqJhHbJRNo1EA=.12f84b43-0f5c-43e9-a976-33c893f7850b@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request incrementally with two additional commits since the last revision:

 - More wordsmithing
 - Improve IAE exception message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25115/files
  - new: https://git.openjdk.org/jdk/pull/25115/files/7693e8fa..e935c32e

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

  Stats: 38 lines in 4 files changed: 18 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

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

From liach at openjdk.org  Sun Nov 16 19:29:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 16 Nov 2025 19:29:21 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v13]
In-Reply-To: <dbW07VkPhX6rVrXYfyFABHfOEg-K9CIqJhHbJRNo1EA=.12f84b43-0f5c-43e9-a976-33c893f7850b@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <dbW07VkPhX6rVrXYfyFABHfOEg-K9CIqJhHbJRNo1EA=.12f84b43-0f5c-43e9-a976-33c893f7850b@github.com>
Message-ID: <La7Dc9CoJ5onq2CQLO_HCs_TciPvce383SMG89afWKA=.1c67bfe4-dc0e-4d23-86c9-3125eb243c05@github.com>

On Sun, 16 Nov 2025 17:26:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - More wordsmithing
>  - Improve IAE exception message

src/java.base/share/man/java.md line 471:

> 469: :   Mutation of final fields is possible with the reflection API of the Java Platform.
> 470:     _However, it compromises safety and performance in all programs.
> 471:     This option allows code_ in the specified modules to mutate final fields by reflection.

Intended that this emphasis ends at "code" instead of the end of the last sentence?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2532177598

From jbhateja at openjdk.org  Mon Nov 17 07:16:08 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 17 Nov 2025 07:16:08 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
In-Reply-To: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
Message-ID: <hECDkUBYRbCl4dduveBzidmTkO6EyI4BwiyzYlQ58g0=.3ca1c5b9-2e6a-402b-9797-b32b21cd73c5@github.com>

On Tue, 4 Nov 2025 16:38:49 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
>    - `SignatureBench.MLDSA` is 1.2x-2.2x faster
>    - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
> - AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
>   - `SignatureBench.MLDSA` is upto 5% faster, never slower
> 
> Note on intrinsic:
> - The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
> - Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2
> 
> Tests and benchmarks:
> - Added a fuzz test to ensure Java and intrinsic produces exactly same result
> - Added benchmark to measure the performance of intrinsic itself
> 
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"

Minor initial comments

src/hotspot/cpu/x86/assembler_x86.cpp line 3867:

> 3865:             (vector_len == AVX_256bit ? VM_Version::supports_avx2() :
> 3866:             (vector_len == AVX_512bit ? VM_Version::supports_evex() : false)), "");
> 3867:   InstructionAttr attributes(vector_len, /* vex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);

When you check for AVX512-VL you allow accessing 128/256 bit registers from the higher register bank [X/Y]MM(16-31) 

But your assertions are nowhere checking this.

src/hotspot/cpu/x86/assembler_x86.cpp line 3876:

> 3874:           (vector_len == AVX_256bit ? VM_Version::supports_avx2() :
> 3875:           (vector_len == AVX_512bit ? VM_Version::supports_evex() : false)), "");
> 3876:   InstructionAttr attributes(vector_len, /* vex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);

When you check for AVX512-VL you allow accessing 128/256 bit registers from the higher register bank [X/Y]MM(16-31)

But your assertions are nowhere checking this.

src/hotspot/cpu/x86/assembler_x86.cpp line 3882:

> 3880: 
> 3881: void Assembler::evmovsldup(XMMRegister dst, KRegister mask, XMMRegister src, bool merge, int vector_len) {
> 3882:   assert(VM_Version::supports_evex(), "");

Suggestion:

  assert(vector_len == AVX_512 || VM_Version::supports_avx512vl), "");

src/hotspot/cpu/x86/assembler_x86.cpp line 3894:

> 3892: 
> 3893: void Assembler::evmovshdup(XMMRegister dst, KRegister mask, XMMRegister src, bool merge, int vector_len) {
> 3894:   assert(VM_Version::supports_evex(), "");

Same as above

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 397:

> 395: //
> 396: static address generate_dilithiumAlmostNtt_avx(StubGenerator *stubgen,
> 397:                             int vector_len, MacroAssembler *_masm) {

Indentation corretness

test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, 2025, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 114:

> 112:         rnd.setSeed(seed);
> 113:         //Note: it might be useful to increase this number during development of new intrinsics
> 114:         final int repeat = 10000000;

Instead of high repetition count can you try tuning the tiered compilation threshold.

test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 145:

> 143:             coeffs1[j] = rnd.nextInt();
> 144:             coeffs2[j] = rnd.nextInt();
> 145:         }

You can uses generators for randome initialization of array

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

PR Review: https://git.openjdk.org/jdk/pull/28136#pullrequestreview-3471195396
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532894350
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532894989
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532900199
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532901821
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532910907
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532868326
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532875974
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2532872372

From pminborg at openjdk.org  Mon Nov 17 09:32:02 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 09:32:02 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v26]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <fiVbzfEtyzmeyqsFt4oJyaO7JqYV9og0Ox2FODrdZcQ=.b642fcf7-34c4-45e9-9173-67189cc8adb0@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 125 commits:

 - Merge branch 'master' into lazy-constants
 - Merge master
 - Fix tests and improve docs
 - Remove inner classes in LazyList
 - Fix TOC TOU issue
 - Improve documentation for List and Map factories
 - Improve doc details
 - Improve text for hashCode()
 - Refine text about reachabilit of the contents
 - Align doc links for get()
 - ... and 115 more: https://git.openjdk.org/jdk/compare/69e30244...3c26e095

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

Changes: https://git.openjdk.org/jdk/pull/27605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=25
  Stats: 8347 lines in 60 files changed: 3738 ins; 4490 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From alanb at openjdk.org  Mon Nov 17 10:48:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 10:48:38 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v14]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <33vXUyBAxy-_mh1VPp7hwz3K5GAur0YpkuzltVztiFU=.e2705104-44f7-4fdb-958c-aec66654ad7e@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits:

 - Merge branch 'master' into JDK-8353835
 - Spurious italics
 - More wordsmithing
 - Improve IAE exception message
 - Merge branch 'master' into JDK-8353835
 - Cleanup
 - More cleanup of Field.set API docs, including some restructure from Alex
 - Cleanup
 - Merge branch 'master' into JDK-8353835
 - Update mutateFinals/modules test to exercise exports and opens cases
 - ... and 53 more: https://git.openjdk.org/jdk/compare/8690d263...c3c3cfff

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

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=13
  Stats: 5365 lines in 76 files changed: 5170 ins; 55 del; 140 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

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

From mcimadamore at openjdk.org  Mon Nov 17 11:19:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 17 Nov 2025 11:19:15 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v26]
In-Reply-To: <fiVbzfEtyzmeyqsFt4oJyaO7JqYV9og0Ox2FODrdZcQ=.b642fcf7-34c4-45e9-9173-67189cc8adb0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <fiVbzfEtyzmeyqsFt4oJyaO7JqYV9og0Ox2FODrdZcQ=.b642fcf7-34c4-45e9-9173-67189cc8adb0@github.com>
Message-ID: <UsVyM2P1jaGf874UM25dFDMfBQWBlhOyN22wwSfWqtQ=.04e2a58d-9a6d-4cf7-a274-df3f1645c64e@github.com>

On Mon, 17 Nov 2025 09:32:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 125 commits:
> 
>  - Merge branch 'master' into lazy-constants
>  - Merge master
>  - Fix tests and improve docs
>  - Remove inner classes in LazyList
>  - Fix TOC TOU issue
>  - Improve documentation for List and Map factories
>  - Improve doc details
>  - Improve text for hashCode()
>  - Refine text about reachabilit of the contents
>  - Align doc links for get()
>  - ... and 115 more: https://git.openjdk.org/jdk/compare/69e30244...3c26e095

src/java.base/share/classes/java/lang/LazyConstant.java line 244:

> 242:      * <p>
> 243:      * In other words, equals compares the identity of this lazy constant and {@code obj}
> 244:      * to determine equality. Hence, two lazy constant with the same contents are

Suggestion:

     * to determine equality. Hence, two lazy constants with the same contents are

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533674027

From pminborg at openjdk.org  Mon Nov 17 11:29:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 11:29:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v27]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <wmiyzAjTgb4hBR9rFi5881eXvQIwzbbKNdYHSxj_VQI=.16face2a-40c5-4d1d-bd31-335b6b020d33@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix forgotten text about (List|Map)::toString

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/3c26e095..2d8f98fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=25-26

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

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

From pminborg at openjdk.org  Mon Nov 17 11:38:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 11:38:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/2d8f98fe..e5399c5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=26-27

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

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

From mcimadamore at openjdk.org  Mon Nov 17 11:38:04 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 17 Nov 2025 11:38:04 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <iq1Jk7NLAvqBhVwcS95kaY0cgFCRt1DKCg_FfVZZSYY=.730253ad-fb3c-4546-ba66-8a0a7924fda7@github.com>

On Mon, 17 Nov 2025 11:34:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Great work!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3472270393

From mdonovan at openjdk.org  Mon Nov 17 12:16:24 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 17 Nov 2025 12:16:24 GMT
Subject: Integrated: 8371349: Update NSS library to 3.117
In-Reply-To: <w4TY_UMKv-zI8AKsVWjurlgnSQ-krHFnGIS0KXFnc30=.dd863021-d385-4f8c-81ed-9b936ae03e07@github.com>
References: <w4TY_UMKv-zI8AKsVWjurlgnSQ-krHFnGIS0KXFnc30=.dd863021-d385-4f8c-81ed-9b936ae03e07@github.com>
Message-ID: <Qe09uIzLCFZTXIf5Cqve3mYCLkSHLR1QGtPf8fqKGy4=.703ffd50-4e13-469f-9e10-286afe3cb807@github.com>

On Thu, 13 Nov 2025 18:05:25 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This is a trivial PR that bumps the version number of NSS to 3.117

This pull request has now been integrated.

Changeset: cebb03ef
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cebb03ef24fad8705156f12cecd2da6351cd1ef6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8371349: Update NSS library to 3.117

Reviewed-by: weijun, myankelevich, hchao

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

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

From duke at openjdk.org  Mon Nov 17 13:26:20 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 17 Nov 2025 13:26:20 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <TPGlt2Gs6iU1gFx4-rGsygrzjYi7apia359gMsJwlBM=.dc939a2c-cd23-491f-9961-2ca0e48cd3a0@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

I've had a look mostly at the docs, everything I'm saying is optional (though I'd really like to see the Logger example changed).

src/java.base/share/classes/java/lang/LazyConstant.java line 42:

> 40:  * A lazy constant is created using the factory method
> 41:  * {@linkplain LazyConstant#of(Supplier) LazyConstant.of({@code <computing function>})}.
> 42:  * When created, the lazy constant is <em>not initialized</em>, meaning it has no contents.

Subjectively, might this be clearer as a bulleted list? This is a sequence of statements about the state transitions after all.

<ul>
<li>On creation the lazy constant is <em>not initialized</em> ...
<li>The first time {@linkplain #get() get()} is called ...
<li>Once a lazy constant is initialized ...

Or just splitting by paragraph.

src/java.base/share/classes/java/lang/LazyConstant.java line 60:

> 58:  *    private final LazyConstant<Logger> logger =
> 59:  *            // @link substring="of" target="#of" :
> 60:  *            LazyConstant.of( () -> Logger.create(Component.class) );

We had previously talked about whether the `Logger` example is a good one.

Personally I think it's a bad example if it encourages people to use loggers this way since:
* non static loggers aren't suitable to logging in static methods.
* The Logger framework has a perfectly functional mechanism for injecting static logger instances.
* Over-use of non-static logger instances pollutes internal APIs and ends up leaking a dependency on a specific logger instance, making refactoring hard.

src/java.base/share/classes/java/lang/LazyConstant.java line 66:

> 64:  *        // ...
> 65:  *    }
> 66:  * }

Arguably weird/wrong indents on closing '}' ?

src/java.base/share/classes/java/lang/LazyConstant.java line 241:

> 239: 
> 240:     /**
> 241:      * {@return if this lazy constant is the same as the provided {@code obj}}

Maybe say "is the same instance as ...", then you might be able to shorten the "In other words" paragraph below as they sort of say the same thing in almost the same words.

As a reader I'm more interested in *why* this slightly unexpected behaviour happens. Maybe a section in the class level docs, linked from here, explaining the issues with using the content for equals/hashCode would be better (that can also talk about lazy constants being mostly unsuitable as key types).

src/java.base/share/classes/java/lang/LazyConstant.java line 283:

> 281:      * <p>
> 282:      * The returned lazy constant strongly references the provided
> 283:      * {@code computingFunction} at least until initialization completes successfully.

As a reader I'm a bit nervous that I don't know if it will ever drop the function. Suppose my init relies on something chunky I want to be sure has gone away?

src/java.base/share/classes/java/nio/charset/Charset.java line 1:

> 1: /*

Side note: I'm slightly surprised to see the introduction and the usage happening in the same PR. Is this really being submitting in one go?

src/java.base/share/classes/java/nio/charset/Charset.java line 619:

> 617: 
> 618:     private static final LazyConstant<Charset> defaultCharset = LazyConstant.of(
> 619:             new Supplier<>() { public Charset get() { return defaultCharset0(); }});

Can these not be done with lambdas?

src/java.base/share/classes/java/util/List.java line 1210:

> 1208:      * invoked at most once per list index, even in a multi-threaded environment.
> 1209:      * Competing threads accessing an element already under computation will block until
> 1210:      * an element is computed or the computing function completes abnormally

Missing full-stop.

src/java.base/share/classes/java/util/List.java line 1238:

> 1236:      * <p>
> 1237:      * The returned lazy list strongly references its computing
> 1238:      * function used to compute elements at least so long as there are uninitialized

"at least so long as" sounds weird to me.

I think you would say either:
* "... at least *as* long as there are uninitialized elmements."
* "... so long as there are uninitialized elmements."

But you could always say:
* "... while there are uninitialized elements"

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

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3472336926
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533786705
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533801082
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533773546
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533830776
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533836397
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533841573
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533846906
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533855814
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2533865784

From pminborg at openjdk.org  Mon Nov 17 13:34:30 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 17 Nov 2025 13:34:30 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <TPGlt2Gs6iU1gFx4-rGsygrzjYi7apia359gMsJwlBM=.dc939a2c-cd23-491f-9961-2ca0e48cd3a0@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
 <TPGlt2Gs6iU1gFx4-rGsygrzjYi7apia359gMsJwlBM=.dc939a2c-cd23-491f-9961-2ca0e48cd3a0@github.com>
Message-ID: <6LpdzFJhGUHodyEKeOMXvKH9nYsPhz7oDM6k4NpNsNE=.2f8b7bd1-2886-48b7-9f97-22b3b8ed7368@github.com>

On Mon, 17 Nov 2025 12:16:52 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> src/java.base/share/classes/java/nio/charset/Charset.java line 1:
> 
>> 1: /*
> 
> Side note: I'm slightly surprised to see the introduction and the usage happening in the same PR. Is this really being submitting in one go?

I've replaced `StableValue` with `LazyConstant`. So there is no new introduction, but just an adaptation.

> src/java.base/share/classes/java/nio/charset/Charset.java line 619:
> 
>> 617: 
>> 618:     private static final LazyConstant<Charset> defaultCharset = LazyConstant.of(
>> 619:             new Supplier<>() { public Charset get() { return defaultCharset0(); }});
> 
> Can these not be done with lambdas?

They can, but I wanted to keep it verbatim to the existing code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2534085547
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2534087249

From mdonovan at openjdk.org  Mon Nov 17 13:42:00 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 17 Nov 2025 13:42:00 GMT
Subject: RFR: 8343316: Review and update tests using explicit provider
 names [v2]
In-Reply-To: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>
References: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>
Message-ID: <TGUyYY_KIPpFP7Ir058XPk7WBjr4_pOEqXMb9ggWFos=.a5618d5d-888d-4054-a466-f4419d87a90a@github.com>

> In this PR, I updated a few crypto tests to remove the hard-coded provider name and use the `test.provider.name` property instead. These tests were missed while working on [JDK-8341927](https://bugs.openjdk.org/browse/JDK-8341927).

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

 - updated copyright year and introduced PROVIDER_NAME variable
 - Merge branch 'master' into provider.name
 - 8343316: Review and update tests using explicit provider names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28273/files
  - new: https://git.openjdk.org/jdk/pull/28273/files/292c7d0c..f1f1142c

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

  Stats: 3968 lines in 66 files changed: 3032 ins; 595 del; 341 mod
  Patch: https://git.openjdk.org/jdk/pull/28273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28273/head:pull/28273

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

From coffeys at openjdk.org  Mon Nov 17 13:55:18 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 17 Nov 2025 13:55:18 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v24]
In-Reply-To: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
Message-ID: <0dI93M5rerO2poVEpo5CI9fsBl0hvLs_HIs4o6z8fyM=.b3bc46ec-5dcf-463e-b449-380f74bfe89e@github.com>

> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago.
> 
> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. 
> 
> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options :
> 
> 
>         System.err.println("help           print the help messages");
>         System.err.println("expand         expand debugging information");
>         System.err.println();
>         System.err.println("all            turn on all debugging");
>         System.err.println("ssl            turn on ssl debugging");
>         System.err.println();
>         System.err.println("The following can be used with ssl:");
>         System.err.println("\trecord       enable per-record tracing");
>         System.err.println("\thandshake    print each handshake message");
>         System.err.println("\tkeygen       print key generation data");
>         System.err.println("\tsession      print session activity");
>         System.err.println("\tdefaultctx   print default SSL initialization");
>         System.err.println("\tsslctx       print SSLContext tracing");
>         System.err.println("\tsessioncache print session cache tracing");
>         System.err.println("\tkeymanager   print key manager tracing");
>         System.err.println("\ttrustmanager print trust manager tracing");
>         System.err.println("\tpluggability print pluggability tracing");
>         System.err.println();
>         System.err.println("\thandshake debugging can be widened with:");
>         System.err.println("\tdata         hex dump of each handshake message");
>         System.err.println("\tverbose      verbose handshake message printing");
>         System.err.println();
>         System.err.println("\trecord debugging can be widened with:");
>         System.err.println("\tplaintext    hex dump of record plaintext");
>         System.err.println("\tpacket       print raw SSL/TLS packets");
> 
> 
> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. 
> 
> the output has changed slightly with respect to that  - less verbose
> 
> e.g. old style:
> 
> 
> javax.net.ssl|DEBUG|10|main|2024-04-12 15:47:24.302 GMT|SSLSocketOut...

Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Merge branch 'master' into 8044609-ssl
 - Merge branch 'master' into 8044609-ssl
 - Merge branch 'master' into 8044609-ssl
 - Incorporate review comments from Brad
 - Merge branch 'master' into 8044609-ssl
 - Further review comments, copyright years also
 - Initial review comments from Brad
 - Merge branch 'master' into 8044609-ssl
 - 1 file omitted during merge
 - Merge branch 'master' into 8044609-ssl
 - ... and 32 more: https://git.openjdk.org/jdk/compare/56a27d11...72a5a167

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

Changes: https://git.openjdk.org/jdk/pull/18764/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=23
  Stats: 1340 lines in 84 files changed: 486 ins; 92 del; 762 mod
  Patch: https://git.openjdk.org/jdk/pull/18764.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18764/head:pull/18764

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

From mpowers at openjdk.org  Mon Nov 17 15:02:58 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 17 Nov 2025 15:02:58 GMT
Subject: Integrated: 8371156: PBKDF2 default values should not be DER encoded
In-Reply-To: <FDgInl6vK5pt6NliKB0Yw87jnp3xFKdWZzYB7S6n2Yk=.7b016069-73d6-49e0-be45-d2b74af5e950@github.com>
References: <FDgInl6vK5pt6NliKB0Yw87jnp3xFKdWZzYB7S6n2Yk=.7b016069-73d6-49e0-be45-d2b74af5e950@github.com>
Message-ID: <JAuq1b2bUDubEHGieIq_lUqsu4NEXWVyr31mt01KkgI=.d1db2fc5-2dca-414a-95f8-c21f61fc6861@github.com>

On Thu, 6 Nov 2025 19:49:56 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> [JDK-8371156](https://bugs.openjdk.org/browse/JDK-8371156)
> 
> HmacSHA1 is the DEFAULT for PBKDF2. Therefore, it should not be DER encoded.
> 
> 
> PBKDF2-params ::= SEQUENCE {
>      salt CHOICE {
>          specified OCTET STRING,
>          otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}}
>     },
>     iterationCount INTEGER (1..MAX),
>     keyLength INTEGER (1..MAX) OPTIONAL,
>     prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT algid-hmacWithSHA1
> }

This pull request has now been integrated.

Changeset: 52ffe8a0
Author:    Mark Powers <mpowers at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/52ffe8a09637701cf93d3425b69089ced5ad4dcb
Stats:     23 lines in 3 files changed: 17 ins; 1 del; 5 mod

8371156: PBKDF2 default values should not be DER encoded

Reviewed-by: weijun

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

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

From mdoerr at openjdk.org  Mon Nov 17 15:12:46 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 17 Nov 2025 15:12:46 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v3]
In-Reply-To: <6lsTW4mcptKcVAuFHu3h39LMajICZZVDhHwrkxM6Rl8=.787cc24a-ae13-49ed-bc56-9c71ad8659b0@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <6lsTW4mcptKcVAuFHu3h39LMajICZZVDhHwrkxM6Rl8=.787cc24a-ae13-49ed-bc56-9c71ad8659b0@github.com>
Message-ID: <HA1vVmQmnSpUTrBo3hW2ina_1zZW9CT-LA5BCeXx3_8=.ee8e5672-1df0-4991-833e-20f0bc4ef89d@github.com>

On Fri, 14 Nov 2025 07:28:10 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More minor cleanup.
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 61:
> 
>> 59:     // used for everything else.
>> 60:     private int[] sessionKe = null; // key for encryption
>> 61:     private int[] sessionKd = null; // preprocessed key for decryption
> 
> We really don't need sessionKd, since it's just assigned to K, but I'm fine leaving it as is.

@smemery: I have made a proposal to remove `K`: https://github.com/TheRealMDoerr/jdk/commit/2907475958806cad6b5fc83541f66065475a93ec
Please take a look! I think it's a bit better readable, but makes the change a bit larger and will probably require a Graal update. What do you prefer?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28299#discussion_r2534468284

From jvernee at openjdk.org  Mon Nov 17 16:52:17 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Nov 2025 16:52:17 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <ESX4NSuqv_AXuodz38Wfa56U1Asqs9g44MiZeUSEZ3Y=.fe99ad0c-a3f2-41e5-99da-7af83e6845e9@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

test/jdk/java/lang/LazyConstant/LazyConstantTest.java line 234:

> 232:             return new Lazy<>(LazyConstant.of(computingFunction));
> 233:         }
> 234:     }

This appears to be unused?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2534822362

From jvernee at openjdk.org  Mon Nov 17 17:11:14 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 17 Nov 2025 17:11:14 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <VGv5qMEBjKT1FLCasY2G79nWj_AlN_8SmDHmfAJa1HM=.ec050ca4-d07f-4b29-92ff-2cf972045023@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by jvernee (Reviewer).

test/jdk/java/lang/LazyConstant/LazyListTest.java line 27:

> 25:  * @summary Basic tests for lazy list methods
> 26:  * @enablePreview
> 27:  * @run junit/othervm --add-opens java.base/java.util=ALL-UNNAMED LazyListTest

I think you can do this with

Suggestion:

 * @modules java.base/java.util:+open
 * @run junit LazyListTest

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

PR Review: https://git.openjdk.org/jdk/pull/27605#pullrequestreview-3473667773
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2534826477

From myankelevich at openjdk.org  Mon Nov 17 17:46:41 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 17 Nov 2025 17:46:41 GMT
Subject: RFR: 8367326: Refactor PEM API tests requiring PEMRecord usage
Message-ID: <2Ow4JVXCRsN-a3SauMcH2lR-HTP-S8e_oNN4T3fxMg8=.7f14fabc-1fa8-4053-a588-c91701734856@github.com>

Changed to use PEM API: 
* test/jdk/sun/security/validator/PKIXValAndRevCheckTests.java
* test/jdk/sun/security/rsa/pss/PSSKeyCompatibility.java
* test/jdk/sun/security/pkcs11/rsa/TestKeyFactory.java

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

Commit messages:
 - JDK-836732: Refactor PEM API tests requiring PEMRecord usage

Changes: https://git.openjdk.org/jdk/pull/28356/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28356&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367326
  Stats: 134 lines in 3 files changed: 52 ins; 23 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/28356.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28356/head:pull/28356

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

From liach at openjdk.org  Mon Nov 17 18:02:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Nov 2025 18:02:13 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v14]
In-Reply-To: <33vXUyBAxy-_mh1VPp7hwz3K5GAur0YpkuzltVztiFU=.e2705104-44f7-4fdb-958c-aec66654ad7e@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <33vXUyBAxy-_mh1VPp7hwz3K5GAur0YpkuzltVztiFU=.e2705104-44f7-4fdb-958c-aec66654ad7e@github.com>
Message-ID: <eR7Mgg7-b3UjII4_siBQHksyq-oA_gi_l5KGTiu69wo=.f1813ebc-62e4-4b7a-a800-221e8709c24c@github.com>

On Mon, 17 Nov 2025 10:48:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Spurious italics
>  - More wordsmithing
>  - Improve IAE exception message
>  - Merge branch 'master' into JDK-8353835
>  - Cleanup
>  - More cleanup of Field.set API docs, including some restructure from Alex
>  - Cleanup
>  - Merge branch 'master' into JDK-8353835
>  - Update mutateFinals/modules test to exercise exports and opens cases
>  - ... and 53 more: https://git.openjdk.org/jdk/compare/8690d263...c3c3cfff

The core library changes look good to me.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3473937951

From erikj at openjdk.org  Mon Nov 17 20:37:08 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Nov 2025 20:37:08 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality
In-Reply-To: <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
Message-ID: <FDxVZjRhh4m59QZhI_g8AUDiTaCtOOx-3RFXak92EGE=.bda3a24b-2dda-4ef2-a01e-19d904869a7c@github.com>

On Thu, 30 Oct 2025 22:55:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Is there a particular reason for build.sh in the tests or are you just not familiar with how native test code gets automatically compiled by the makefiles based on file naming conventions? In short, any file `lib*.c[pp]` will get compiled into a native library (and exe*.c[pp] into an executable). You can define any special flags or platform include/exclude in `make/test/JtregNativeJdk.gmk`.

> Hi @erikj79, I noticed that in our CI build the library is not built and the log shows
> 
> ```
> checking for krb5 (<omitted>)... no
> checking krb5.h usability... no
> checking krb5.h presence... no
> checking for krb5.h... no 
> ```
> 
> How can we require them to be present?

Is this intended to be a required dependency for OpenJDK or are you referring to how we would enable this feature and dependency for Oracle builds?

If the latter, they would need to be part of the devkit that we use. So the first step would be to modify the devkit creation makefiles for Linux in `make/devkit/...`, then create a new devkit, verify and deploy internally.

You will also need to verify that libkrb5 is reasonably stable and compatible across versions, since we only build one JDK distribution per architecture for Linux. We use a sysroot from the oldest Linux distribution we support, so you would need to verify that linking against libkrb5 in that sysroot/devkit results in a JDK that is still runtime compatible with all the Linux versions we support.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3543727972

From jiangli at openjdk.org  Mon Nov 17 22:57:07 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 17 Nov 2025 22:57:07 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2 intrinsics
 stubs cause AES-GCM encryption failure for certain payload sizes
Message-ID: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>

Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 

Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!

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

Commit messages:
 - Fix Whitespace errors
 - Add TestAesGcmIntrinsic.java. The test is authored by tholenst at google.com and zlukas at google.com.
 - JDK-8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes

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

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

From vpaprotski at openjdk.org  Mon Nov 17 23:35:44 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Nov 2025 23:35:44 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
 [v2]
In-Reply-To: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
Message-ID: <mzpPdK3E-jTbpaq-DfKQRGmc3WkHx8scm58ck2rpmBQ=.86b07f98-9464-494e-91a8-ccb843c57431@github.com>

> - New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
>    - `SignatureBench.MLDSA` is 1.2x-2.2x faster
>    - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
> - AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
>   - `SignatureBench.MLDSA` is upto 5% faster, never slower
> 
> Note on intrinsic:
> - The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
> - Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2
> 
> Tests and benchmarks:
> - Added a fuzz test to ensure Java and intrinsic produces exactly same result
> - Added benchmark to measure the performance of intrinsic itself
> 
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"

Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:

 - whitespace
 - address first comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28136/files
  - new: https://git.openjdk.org/jdk/pull/28136/files/6d3f7794..e9133401

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

  Stats: 42 lines in 5 files changed: 17 ins; 15 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28136/head:pull/28136

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

From vpaprotski at openjdk.org  Mon Nov 17 23:35:45 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Nov 2025 23:35:45 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
 [v2]
In-Reply-To: <hECDkUBYRbCl4dduveBzidmTkO6EyI4BwiyzYlQ58g0=.3ca1c5b9-2e6a-402b-9797-b32b21cd73c5@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
 <hECDkUBYRbCl4dduveBzidmTkO6EyI4BwiyzYlQ58g0=.3ca1c5b9-2e6a-402b-9797-b32b21cd73c5@github.com>
Message-ID: <og6CYamAceNfC56jjex4Xt3pSiwAQUEGuJv7MHgF0dk=.418c1487-5c50-4629-932c-edcc1ebbd7cb@github.com>

On Mon, 17 Nov 2025 06:44:39 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - whitespace
>>  - address first comments
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 3867:
> 
>> 3865:             (vector_len == AVX_256bit ? VM_Version::supports_avx2() :
>> 3866:             (vector_len == AVX_512bit ? VM_Version::supports_evex() : false)), "");
>> 3867:   InstructionAttr attributes(vector_len, /* vex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);
> 
> When you check for AVX512-VL you allow accessing 128/256 bit registers from the higher register bank [X/Y]MM(16-31) 
> 
> But your assertions are nowhere checking this.

I believe those asserts are in `vex_prefix_and_encode` (https://github.com/openjdk/jdk/blob/6d3f7794ee6658d48eb2120c7bfe66ac412c6d14/src/hotspot/cpu/x86/assembler_x86.cpp#L13164) and `vex_prefix` (https://github.com/openjdk/jdk/blob/6d3f7794ee6658d48eb2120c7bfe66ac412c6d14/src/hotspot/cpu/x86/assembler_x86.cpp#L13047)

I also haven't found any other instruction that does this check so I could emulate the style.

> src/hotspot/cpu/x86/assembler_x86.cpp line 3882:
> 
>> 3880: 
>> 3881: void Assembler::evmovsldup(XMMRegister dst, KRegister mask, XMMRegister src, bool merge, int vector_len) {
>> 3882:   assert(VM_Version::supports_evex(), "");
> 
> Suggestion:
> 
>   assert(vector_len == AVX_512 || VM_Version::supports_avx512vl), "");

Took the patch, but also kept the supports_evex() assert

> test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 114:
> 
>> 112:         rnd.setSeed(seed);
>> 113:         //Note: it might be useful to increase this number during development of new intrinsics
>> 114:         final int repeat = 10000000;
> 
> Instead of high repetition count can you try tuning the tiered compilation threshold.

The purpose of the test is to test various (pseudo-random) values and compare the results to the java implementation of same code. A single run-though of the test doesn't always prove that there are no bugs.

A bit philosophical.. as is well known, when writing crypto, branches (conditional on secret) are disallowed; but e.g. carry propagation has the same 'conditional execution' effect. (Instead of "have you tested every branch direction" its "have you tested every carry") Besides a very careful range/overflow analysis (which I also did.. ntt functions skate very close to the int limit), exhaustive fuzz testing is the best method to find conditions that manual (range/overflow) analysis hasn't found; fuzz testing has very little math built in, so its also good at finding 'blind spots' I (and whomever has to review) might have not thought of..

> test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 145:
> 
>> 143:             coeffs1[j] = rnd.nextInt();
>> 144:             coeffs2[j] = rnd.nextInt();
>> 145:         }
> 
> You can uses generators for randome initialization of array

I think you meant this?

        coeffs1 = rnd.ints(ML_DSA_N).toArray();
        coeffs2 = rnd.ints(ML_DSA_N).toArray();

Didn't know about this, thanks. It does work..

But the original purpose (perhaps misguided, but its done) was to 'factor out' the allocations; the outer loop runs many million times (I've left it running for 6+hours during development) and so I wanted a 'somewhat efficient' test.

In hindsight, these (1k) arrays could probably be stack allocated, but I did not want to depend on an optimization when I could just write it without allocations in the mainline

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2535460279
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2535804056
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2535373444
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2535199249

From vpaprotski at openjdk.org  Mon Nov 17 23:35:45 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Nov 2025 23:35:45 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
 [v2]
In-Reply-To: <_TeZd3joeNkWYg7ZOgYRwzRJJjwMcUVOfe-pdXzJTv4=.d413a241-c8de-4267-8b98-0b41c7629371@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
 <_TeZd3joeNkWYg7ZOgYRwzRJJjwMcUVOfe-pdXzJTv4=.d413a241-c8de-4267-8b98-0b41c7629371@github.com>
Message-ID: <XWmM2FdoPfpmDp4xZASAlkmR6KgJPY2zNLGk6a-kN-g=.782a7426-34ae-42ec-9f33-791aa0098980@github.com>

On Sun, 16 Nov 2025 16:47:29 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - whitespace
>>  - address first comments
>
> test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 123:
> 
>> 121:         try {
>> 122:             for (int i = 0; i < repeat; i++) {
>> 123:                 // seed = rnd.nextLong();
> 
> 2 lines commented out

This was useful during development and might be useful hint for debugging; instead of deleting, added a comment. Let me know if that works

> test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 517:
> 
>> 515:     };
>> 516: }
>> 517: // java --add-opens java.base/sun.security.provider=ALL-UNNAMED  -XX:+UseDilithiumIntrinsics test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java
> 
> This is line is useful. Not sure I would hide it at the bottom of the file.

I actually meant to delete it, but will move it to the top.

> test/micro/org/openjdk/bench/javax/crypto/full/MLDSABench.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
> 
> Copyright date.

That was some copy-paste! Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2535377021
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2535082275
PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2535078538

From serb at openjdk.org  Tue Nov 18 00:44:26 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 18 Nov 2025 00:44:26 GMT
Subject: RFR: 8371975: Apply java.io.Serial annotations in java.security.sasl
Message-ID: <WyApeD2-_IVVqenZaQ7Jdrmfb87WKzLY24qwaLQn8fM=.39e1d2c0-cee0-4d45-bdb2-ea180f1b8dc8@github.com>

Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the `java.security.sasl` module to enable stricter compile-time checking of serialization-related declarations.

Example of a similar change https://github.com/openjdk/jdk/pull/27925.

Note: this annotation can be applied to these methods and fields:
  * private void writeObject(java.io.ObjectOutputStream stream) throws IOException
  * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
  * private void readObjectNoData() throws ObjectStreamException 
   * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
   * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
   * private static final ObjectStreamField[] serialPersistentFields
   * private static final long serialVersionUID

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

Commit messages:
 - 8371975: Apply java.io.Serial annotations in java.security.sasl

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

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

From weijun at openjdk.org  Tue Nov 18 04:52:16 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Nov 2025 04:52:16 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v12]
In-Reply-To: <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
Message-ID: <25c1wupthdBJWf9lLmRnZG_Z4sVhwF3iqtDo42DX26w=.152e78c9-51b5-4b6d-b54a-44f126921d5f@github.com>

On Thu, 13 Nov 2025 11:02:21 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Small doc fix
>  - Attend to @wangweij's code review comments - in particular a large clean-up of the test helper and the output it creates
>  - Attend to remaining comments from @smemery

I am thinking this should be a required dependency. Otherwise, the JDK build will vary depending on the machine used. I don?t believe we?ve ever done this before (unless user explicitly specifies configure options), right?

@nrhall, a related question: what if the library is available at build time but not at runtime?

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3545020829

From thartmann at openjdk.org  Tue Nov 18 06:20:15 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 18 Nov 2025 06:20:15 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
In-Reply-To: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
Message-ID: <uygPZR0JaXYGUkOoKX1-Zi0e-dbp64H6W63trUDLfBM=.2a27b0e2-35f9-424b-9f83-149bf58236d0@github.com>

On Mon, 17 Nov 2025 22:34:14 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 
> 
> Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!

test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 41:

> 39: public class TestAesGcmIntrinsic {
> 40: 
> 41:   static final SecureRandom SECURE_RANDOM = newDefaultSecureRandom();

Drive-by comment: Java code should use 4x whitespace indentation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2536463222

From hchao at openjdk.org  Tue Nov 18 06:50:10 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 18 Nov 2025 06:50:10 GMT
Subject: RFR: 8343316: Review and update tests using explicit provider
 names [v2]
In-Reply-To: <TGUyYY_KIPpFP7Ir058XPk7WBjr4_pOEqXMb9ggWFos=.a5618d5d-888d-4054-a466-f4419d87a90a@github.com>
References: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>
 <TGUyYY_KIPpFP7Ir058XPk7WBjr4_pOEqXMb9ggWFos=.a5618d5d-888d-4054-a466-f4419d87a90a@github.com>
Message-ID: <gooQg3ag9BDPkpOhLV8w62WQ1ru-T_h_kXQflVB-wmg=.979a6dde-5c55-493e-95a3-f72ddb2286c2@github.com>

On Mon, 17 Nov 2025 13:42:00 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I updated a few crypto tests to remove the hard-coded provider name and use the `test.provider.name` property instead. These tests were missed while working on [JDK-8341927](https://bugs.openjdk.org/browse/JDK-8341927).
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - updated copyright year and introduced PROVIDER_NAME variable
>  - Merge branch 'master' into provider.name
>  - 8343316: Review and update tests using explicit provider names

test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreement3.java line 2:

> 1: /*
> 2:  * Copyright (c) 1998, 2025?, Oracle and/or its affiliates. All rights reserved.

s/20250/2025/

test/jdk/java/security/Provider/ProviderVersionCheck.java line 2:

> 1: /*
> 2:  * Copyright (c) 2013, 2024, Oracle and/or its affiliates. All rights reserved.

s/2024/2025/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28273#discussion_r2536531038
PR Review Comment: https://git.openjdk.org/jdk/pull/28273#discussion_r2536531320

From alanb at openjdk.org  Tue Nov 18 08:04:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Nov 2025 08:04:13 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v14]
In-Reply-To: <33vXUyBAxy-_mh1VPp7hwz3K5GAur0YpkuzltVztiFU=.e2705104-44f7-4fdb-958c-aec66654ad7e@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <33vXUyBAxy-_mh1VPp7hwz3K5GAur0YpkuzltVztiFU=.e2705104-44f7-4fdb-958c-aec66654ad7e@github.com>
Message-ID: <WL_1J9AQuA01zD_xh3lYP8DaoBBzxqyqEreFmz4nJfE=.8c7c57b0-3b15-4a77-9b64-bc99522d6140@github.com>

On Mon, 17 Nov 2025 10:48:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Spurious italics
>  - More wordsmithing
>  - Improve IAE exception message
>  - Merge branch 'master' into JDK-8353835
>  - Cleanup
>  - More cleanup of Field.set API docs, including some restructure from Alex
>  - Cleanup
>  - Merge branch 'master' into JDK-8353835
>  - Update mutateFinals/modules test to exercise exports and opens cases
>  - ... and 53 more: https://git.openjdk.org/jdk/compare/8690d263...c3c3cfff

Thanks for the comments and detailed reviews.

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

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

From alanb at openjdk.org  Tue Nov 18 08:10:21 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Nov 2025 08:10:21 GMT
Subject: Integrated: 8353835: Implement JEP 500: Prepare to Make Final Mean
 Final
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <s8o3-ZUCTSnulpiTqfDcWd8L91QR36zlpCTJ3XkE-kc=.44a7d9c6-92fc-4c6f-8049-cfbd5e48545b@github.com>

On Thu, 8 May 2025 11:22:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

This pull request has now been integrated.

Changeset: 26460b6f
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26460b6f12ce0763b79acfd98fca260b509a82c5
Stats:     5365 lines in 76 files changed: 5170 ins; 55 del; 140 mod

8353835: Implement JEP 500: Prepare to Make Final Mean Final

Reviewed-by: liach, vlivanov, dholmes, vyazici

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

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

From shade at openjdk.org  Tue Nov 18 09:04:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Nov 2025 09:04:23 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
In-Reply-To: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
Message-ID: <Vx1My0nkw2LYZ3KROxyhFCTfiV-6LTcB-8b5o1hsc9g=.c2805316-3c6e-4236-b938-c708eb35be08@github.com>

On Mon, 17 Nov 2025 22:34:14 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 
> 
> Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!

Good catch! Some stylistic comments for the product fix, and suggestions for the test.

src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 3530:

> 3528:   __ bind(MESG_BELOW_32_BLKS);
> 3529:   __ subl(len, 16 * 16);
> 3530:   __ cmpl(len, 256);

>From the stylistic logic, this should be written as `16 * 16`, to match the surrounding `subl` and `addl`.

test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 39:

> 37: import javax.crypto.spec.SecretKeySpec;
> 38: 
> 39: public class TestAesGcmIntrinsic {

This sounds like `TestGCMSplitBound` or some such; it is not a generic test for AES/GCM intrinsic.

test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 41:

> 39: public class TestAesGcmIntrinsic {
> 40: 
> 41:   static final SecureRandom SECURE_RANDOM = newDefaultSecureRandom();

Do you really need a `SecureRandom` here? `Random RANDOM = Utils.getRandomInstance();` gets you the pre-seeded random instance, which can be used to repeatably reproduce failures.

test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 93:

> 91:       }
> 92:     }
> 93:     for (int messageSize = SPLIT_LEN; messageSize < SPLIT_LEN + 300; messageSize++) {

`[SPLIT_LEN - 300; SPLIT_LEN + 300]` for completeness, perhaps?

test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 96:

> 94:       byte[] message = randBytes(messageSize);
> 95:       try {
> 96:         byte[] ciphertext = gcmEncrypt(key, message, aad);

I believe it makes sense to check that round-trip is successful, e.g. that `decrypt(encrypt(message)) == message`. Currently we implicitly rely on exceptions being thrown from the incorrectly executing code, which is IMO too weak -- in the boundary conditions like these, there might be bugs that _do not_ manifest in visible exceptions, and just the encryption is subtly broken.

test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 109:

> 107:     TestAesGcmIntrinsic test = new TestAesGcmIntrinsic();
> 108:     long startTime = System.currentTimeMillis();
> 109:     while (System.currentTimeMillis() - startTime < 60 * 1000) {

I get that you want a stress test. But time-limiting puts the test into weird condition: it can have different number of iterations, depending on auxiliary load on the machine. These tests are running in parallel with lots of other tests, so it is not uncommon. Do you even need to repeat `jitFunc()` call multiple times? Looks like it traverses the interesting configurations in one go?

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

PR Review: https://git.openjdk.org/jdk/pull/28363#pullrequestreview-3476170085
PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2536853113
PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2536930778
PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2536948179
PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2536932434
PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2536921000
PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2536910947

From myankelevich at openjdk.org  Tue Nov 18 10:20:25 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 18 Nov 2025 10:20:25 GMT
Subject: RFR: 8371574: Improve code coverage of PEM classes decode
 functionality
Message-ID: <q0H5KJ3OztsJvV2QIzBBlG-q2NmWlVPA2CxWF_j9-F4=.26888f3a-ac83-451c-8188-54f8a1eb147f@github.com>

Missing code coverage for PEM API preview 2

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

Commit messages:
 - JDK-8371574: Improve code coverage of PEM classes decode functionality

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

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

From duke at openjdk.org  Tue Nov 18 11:14:53 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 18 Nov 2025 11:14:53 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <bwaH6vYcIoTgJYP82UEA0OOsghn-xAy6nFcrNACU-Js=.a38419f2-9c6d-4dfd-8d3c-997c69aff313@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Wrt. replacing?`StableValue` with?a?`VarHandle` access?mode, that?has the?downside of?the?variable not?being constant?foldable[^1], as?the?`@Stable`?annotation is?only?available to?the?system?domain class?loaders (bootstrap?and?platform).

[^1]: Without making?use of?`-Xbootclasspath/a:?`.

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3547013114

From pminborg at openjdk.org  Tue Nov 18 12:19:34 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 18 Nov 2025 12:19:34 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v28]
In-Reply-To: <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <m9jn_zfsJuuiTSyDdQ69csyFCNQ0xXytpwvoWJc7IGQ=.871b3e0f-13ba-43e9-956d-98b004ce00f3@github.com>
Message-ID: <hZs96XTneTVOWiWq1dpNb_TbEKh-mkqg0MeWj-2vE-c=.2d7207dd-dc84-40af-b360-96c4c0e26a8e@github.com>

On Mon, 17 Nov 2025 11:38:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

> Wrt. replacing?`StableValue` with?a?`VarHandle` access?mode, that?has the?downside of?the?variable not?being constant?foldable[1](#user-content-fn-1-dd52c5569368829688622e7b8db815eb), as?the?`@Stable`?annotation is?only?available to?the?system?domain class?loaders (bootstrap?and?platform).

We think we can solve that. Stay tuned.

I will integrate this PR now.

There are outstanding comments in this PR that I will address in a separate follow-up PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3547354435
PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3547357897

From duke at openjdk.org  Tue Nov 18 12:21:09 2025
From: duke at openjdk.org (Nick Hall)
Date: Tue, 18 Nov 2025 12:21:09 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Nick Hall has updated the pull request incrementally with one additional commit since the last revision:

  Clean up jtreg run/compile directives, attend to other review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/d7ea6c9e..ed56092b

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

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

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

From duke at openjdk.org  Tue Nov 18 12:21:10 2025
From: duke at openjdk.org (Nick Hall)
Date: Tue, 18 Nov 2025 12:21:10 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v12]
In-Reply-To: <25c1wupthdBJWf9lLmRnZG_Z4sVhwF3iqtDo42DX26w=.152e78c9-51b5-4b6d-b54a-44f126921d5f@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
 <25c1wupthdBJWf9lLmRnZG_Z4sVhwF3iqtDo42DX26w=.152e78c9-51b5-4b6d-b54a-44f126921d5f@github.com>
Message-ID: <pbyD0L7UTQFlpOyS7PWKfpOAzHLRpwKA8QgzctVlZRc=.9c3811f9-d502-49e3-9164-1bb9c810349e@github.com>

On Tue, 18 Nov 2025 04:49:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I am thinking this should be a required dependency. Otherwise, the JDK build will vary depending on the machine used. I don?t believe we?ve ever done this before (unless user explicitly specifies configure options), right?
> 
> @nrhall, a related question: what if the library is available at build time but not at runtime?

If libkrb5 available at build time, it will build the new JNI library/test etc as expected; if libkrb5 is then not available at runtime, the library will fail to load silently (once, and then will not be retried) - this was actually already part of the code, so I imagine this case has happened before somewhere already - see Credentials.java L446:

            if (!alreadyTried) {
                // See if there's any native code to load
                try {
                    ensureLoaded();
                } catch (Exception e) {
                    if (DEBUG != null) {
                        DEBUG.println("Can not load native ccache library");
                        e.printStackTrace();
                    }
                    alreadyTried = true;
                }
            }


I will say that libkrb5 is largely pretty stable (it's really old code with few features being added), though I'm not sure what range is required to be supported here in terms of operating system builds?  Worst case though, any incompatibility will just result in this code not being used, although as it'd be a silent failure without debug flags, that's perhaps not ideal (but has always been the case, even before this change).

@wangweij I've attended to your code review feedback above (and cleaned up a few other bits of the jtreg directives that weren't required).

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3547350870
PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3547354335

From pminborg at openjdk.org  Tue Nov 18 12:24:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 18 Nov 2025 12:24:52 GMT
Subject: Integrated: 8366178: Implement JEP 526: Lazy Constants (Second
 Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <q_NHVMDzKC3YXrUppwHly5ADB4eB7ohZhcxi6wPN8kA=.92e38494-ced1-4c6b-8d80-28409de8888e@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

This pull request has now been integrated.

Changeset: f9464499
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f94644999766e752f7d60ce52c14a7db79005035
Stats:     8347 lines in 60 files changed: 3738 ins; 4490 del; 119 mod

8366178: Implement JEP 526: Lazy Constants (Second Preview)
8371882: Improve documentation for JEP 526: Lazy Constants

Reviewed-by: jvernee, mcimadamore

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

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

From mdonovan at openjdk.org  Tue Nov 18 12:26:17 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 18 Nov 2025 12:26:17 GMT
Subject: RFR: 8343316: Review and update tests using explicit provider
 names [v3]
In-Reply-To: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>
References: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>
Message-ID: <b1Erf4NUqIJ3Sz98gpuDj33REXFsoutyaYzEqf576Ow=.4f17fabc-cd1d-4cf4-b6ad-76af2b72d81a@github.com>

> In this PR, I updated a few crypto tests to remove the hard-coded provider name and use the `test.provider.name` property instead. These tests were missed while working on [JDK-8341927](https://bugs.openjdk.org/browse/JDK-8341927).

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  corrected copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28273/files
  - new: https://git.openjdk.org/jdk/pull/28273/files/f1f1142c..a4ba9827

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

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

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

From duke at openjdk.org  Tue Nov 18 13:20:42 2025
From: duke at openjdk.org (Nick Hall)
Date: Tue, 18 Nov 2025 13:20:42 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v12]
In-Reply-To: <pbyD0L7UTQFlpOyS7PWKfpOAzHLRpwKA8QgzctVlZRc=.9c3811f9-d502-49e3-9164-1bb9c810349e@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <EEnI-f-6HqKUfgtye9UWyrxcEzmlYctmqYifh3Bs6Uc=.57a30b73-371a-4cb1-a9e4-4e43c6e65a8a@github.com>
 <25c1wupthdBJWf9lLmRnZG_Z4sVhwF3iqtDo42DX26w=.152e78c9-51b5-4b6d-b54a-44f126921d5f@github.com>
 <pbyD0L7UTQFlpOyS7PWKfpOAzHLRpwKA8QgzctVlZRc=.9c3811f9-d502-49e3-9164-1bb9c810349e@github.com>
Message-ID: <D5OrYY_u7bTgLGNwyL-rxC4L6LyJsQocmb_294yaSSs=.cd266684-c4b2-4508-bcb1-4148d11b9939@github.com>

On Tue, 18 Nov 2025 12:15:38 GMT, Nick Hall <duke at openjdk.org> wrote:

> I will say that libkrb5 is largely pretty stable (it's really old code with few features being added), though I'm not sure what range is required to be supported here in terms of operating system builds? Worst case though, any incompatibility will just result in this code not being used, although as it'd be a silent failure without debug flags, that's perhaps not ideal (but has always been the case, even before this change).

Two data points, but the JVM/krb5 library/jtreg test compiled on RHEL8 works on Ubuntu 24.04, and these two are reasonably far apart:

- RHEL8
glibc 2.28
kernel 4.18.0
krb5 1.18

- Ubuntu 24.04
glibc 2.39
kernel 6.8.0
krb5 1.20

Obviously the reverse doesn't work, but that's to be expected.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3547609210

From coffeys at openjdk.org  Tue Nov 18 16:02:49 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 18 Nov 2025 16:02:49 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger
Message-ID: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>

`SSLLogger` utilizes `System.Logger` if the `javax.net.debug` system property key value is empty. However, since that class doesn't implement `SSLogger`, it misses the advantage of highlighting the exact calling site for each log statement.  Having `SSLLogger `simply implement `System.Logger` fixes this

I've also taken this opportunity to refractor the `isOn` boolean in `SSLLogger`. Encapsulated that boolean in a new method which callers can now use. I also used `ForceInline` directory on that method. Thanks to @dfuch for suggestions on that front.

Also updated an existing unit testcase to test for the new functionality

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

Commit messages:
 - 8372004

Changes: https://git.openjdk.org/jdk/pull/28376/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28376&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372004
  Stats: 827 lines in 80 files changed: 43 ins; 42 del; 742 mod
  Patch: https://git.openjdk.org/jdk/pull/28376.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28376/head:pull/28376

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

From myankelevich at openjdk.org  Tue Nov 18 16:02:51 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 18 Nov 2025 16:02:51 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger
In-Reply-To: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
Message-ID: <eoZ4D84Y0j05LDQqkmO3ZXW5Sa04hzsyZdN9ALNf86w=.5a8e7a9c-4cbb-4253-9491-218a3ece1546@github.com>

On Tue, 18 Nov 2025 15:50:42 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> `SSLLogger` utilizes `System.Logger` if the `javax.net.debug` system property key value is empty. However, since that class doesn't implement `SSLogger`, it misses the advantage of highlighting the exact calling site for each log statement.  Having `SSLLogger `simply implement `System.Logger` fixes this
> 
> I've also taken this opportunity to refractor the `isOn` boolean in `SSLLogger`. Encapsulated that boolean in a new method which callers can now use. I also used `ForceInline` directory on that method. Thanks to @dfuch for suggestions on that front.
> 
> Also updated an existing unit testcase to test for the new functionality

Also, copyrights ?

src/java.base/share/classes/sun/security/ssl/Alert.java line 241:

> 239: 
> 240:             AlertMessage am = new AlertMessage(tc, m);
> 241:             if (SSLLogger.isOn() && SSLLogger.isOn("ssl")) {

Would it make sense to add the calls to the helper methods introduced here [JDK-8371721](https://bugs.openjdk.org/browse/JDK-8371721)? I know this is not merged yet, but seems like changing it now and later changing it to be another method might not be the most efficient way. At least this is how it looks to me. 

What do you think?

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

PR Review: https://git.openjdk.org/jdk/pull/28376#pullrequestreview-3478535953
PR Review Comment: https://git.openjdk.org/jdk/pull/28376#discussion_r2538757474

From dfuchs at openjdk.org  Tue Nov 18 16:19:07 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Nov 2025 16:19:07 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger
In-Reply-To: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
Message-ID: <IkZoudKPbefTEwYHICuHlWqQvc3Jx9w__Xd1oiOhQ5c=.cc2f37ba-69cb-4385-b0ea-68a4c6e00bde@github.com>

On Tue, 18 Nov 2025 15:50:42 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> `SSLLogger` utilizes `System.Logger` if the `javax.net.debug` system property key value is empty. However, since that class doesn't implement `SSLogger`, it misses the advantage of highlighting the exact calling site for each log statement.  Having `SSLLogger `simply implement `System.Logger` fixes this
> 
> I've also taken this opportunity to refractor the `isOn` boolean in `SSLLogger`. Encapsulated that boolean in a new method which callers can now use. I also used `ForceInline` directory on that method. Thanks to @dfuch for suggestions on that front.
> 
> Also updated an existing unit testcase to test for the new functionality

Good to see `isOn` is now encapsulated. The mechanical changes `isOn` -> `isOn()` all look OK - I haven't spotted anything there.  A few comments to SSLLogger. I don't understand the changes to the DebugPropertyValuesTest.

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 146:

> 144: 
> 145:     public static void severe(String msg, Object... params) {
> 146:         SSLLogger.doLog(Level.ERROR, msg, params);

`log0` might be a better name than `doLog`

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 190:

> 188:     }
> 189: 
> 190:     private static void help() {

Keeping the help method at ~ the same place in the file would make it easier to review. Was there any change in this method?

test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 94:

> 92:                             + System.lineSeparator() +
> 93:                             "  \"certificate\" : \\{",
> 94:                         "sun.security.ssl.SSLSocketImpl close",

was that change intended? I don't see what it has to do with the rest.

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

PR Review: https://git.openjdk.org/jdk/pull/28376#pullrequestreview-3478576147
PR Review Comment: https://git.openjdk.org/jdk/pull/28376#discussion_r2538789696
PR Review Comment: https://git.openjdk.org/jdk/pull/28376#discussion_r2538795357
PR Review Comment: https://git.openjdk.org/jdk/pull/28376#discussion_r2538818340

From dfuchs at openjdk.org  Tue Nov 18 16:23:07 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Nov 2025 16:23:07 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger
In-Reply-To: <IkZoudKPbefTEwYHICuHlWqQvc3Jx9w__Xd1oiOhQ5c=.cc2f37ba-69cb-4385-b0ea-68a4c6e00bde@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
 <IkZoudKPbefTEwYHICuHlWqQvc3Jx9w__Xd1oiOhQ5c=.cc2f37ba-69cb-4385-b0ea-68a4c6e00bde@github.com>
Message-ID: <vFIt0cCsNJOBnoaOsy6QIv-N-GtVcOlR6HXxuJYVfxw=.bea284d8-10c4-4fc7-94ab-b49097c288c1@github.com>

On Tue, 18 Nov 2025 16:04:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> `SSLLogger` utilizes `System.Logger` if the `javax.net.debug` system property key value is empty. However, since that class doesn't implement `SSLogger`, it misses the advantage of highlighting the exact calling site for each log statement.  Having `SSLLogger `simply implement `System.Logger` fixes this
>> 
>> I've also taken this opportunity to refractor the `isOn` boolean in `SSLLogger`. Encapsulated that boolean in a new method which callers can now use. I also used `ForceInline` directory on that method. Thanks to @dfuch for suggestions on that front.
>> 
>> Also updated an existing unit testcase to test for the new functionality
>
> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 146:
> 
>> 144: 
>> 145:     public static void severe(String msg, Object... params) {
>> 146:         SSLLogger.doLog(Level.ERROR, msg, params);
> 
> `log0` might be a better name than `doLog`

Since you have now imported `@ForceInline` maybe you could also add it to `doLog` - the methods that call it are all one-liners.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28376#discussion_r2538847240

From coffeys at openjdk.org  Tue Nov 18 16:29:53 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 18 Nov 2025 16:29:53 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger [v2]
In-Reply-To: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
Message-ID: <UnOQOTDoBf5T-nd0TqXcPgrWVsry88Htjp0HkoODLiw=.16824d59-b1ed-4a99-ac8f-9884e9cd363c@github.com>

> `SSLLogger` utilizes `System.Logger` if the `javax.net.debug` system property key value is empty. However, since that class doesn't implement `SSLogger`, it misses the advantage of highlighting the exact calling site for each log statement.  Having `SSLLogger `simply implement `System.Logger` fixes this
> 
> I've also taken this opportunity to refractor the `isOn` boolean in `SSLLogger`. Encapsulated that boolean in a new method which callers can now use. I also used `ForceInline` directory on that method. Thanks to @dfuch for suggestions on that front.
> 
> Also updated an existing unit testcase to test for the new functionality

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Copyright year updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28376/files
  - new: https://git.openjdk.org/jdk/pull/28376/files/9477fa50..2ddecbc4

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

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

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

From coffeys at openjdk.org  Tue Nov 18 16:32:08 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 18 Nov 2025 16:32:08 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger [v2]
In-Reply-To: <eoZ4D84Y0j05LDQqkmO3ZXW5Sa04hzsyZdN9ALNf86w=.5a8e7a9c-4cbb-4253-9491-218a3ece1546@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
 <eoZ4D84Y0j05LDQqkmO3ZXW5Sa04hzsyZdN9ALNf86w=.5a8e7a9c-4cbb-4253-9491-218a3ece1546@github.com>
Message-ID: <WgQ9u6YDi6e1FGSn7llN-CIKi_J70jqqotNASb-HS3Y=.ed58c37a-783a-489b-a7b5-7287f05359ac@github.com>

On Tue, 18 Nov 2025 15:57:36 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright year updates
>
> src/java.base/share/classes/sun/security/ssl/Alert.java line 241:
> 
>> 239: 
>> 240:             AlertMessage am = new AlertMessage(tc, m);
>> 241:             if (SSLLogger.isOn() && SSLLogger.isOn("ssl")) {
> 
> Would it make sense to add the calls to the helper methods introduced here [JDK-8371721](https://bugs.openjdk.org/browse/JDK-8371721)? I know this is not merged yet, but seems like changing it now and later changing it to be another method might not be the most efficient way. At least this is how it looks to me. 
> 
> What do you think?

I'm ok to work this one separately. `SSLLogger.logWarning` is customized to return `boolean ` and is used in 3 SSL classes. Hopefully, that method code is inlined by JIT for performance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28376#discussion_r2538885173

From coffeys at openjdk.org  Tue Nov 18 16:48:48 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 18 Nov 2025 16:48:48 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger [v3]
In-Reply-To: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
Message-ID: <FpAvU1fJcJACeVnk-RFF59WPJ4qEyn9Sg6tZODCFvMQ=.df34e19a-6a96-476b-b256-a24a5cf8be2e@github.com>

> `SSLLogger` utilizes `System.Logger` if the `javax.net.debug` system property key value is empty. However, since that class doesn't implement `SSLogger`, it misses the advantage of highlighting the exact calling site for each log statement.  Having `SSLLogger `simply implement `System.Logger` fixes this
> 
> I've also taken this opportunity to refractor the `isOn` boolean in `SSLLogger`. Encapsulated that boolean in a new method which callers can now use. I also used `ForceInline` directory on that method. Thanks to @dfuch for suggestions on that front.
> 
> Also updated an existing unit testcase to test for the new functionality

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Review comments from Daniel

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28376/files
  - new: https://git.openjdk.org/jdk/pull/28376/files/2ddecbc4..5cd23089

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

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

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

From coffeys at openjdk.org  Tue Nov 18 16:48:55 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 18 Nov 2025 16:48:55 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger [v3]
In-Reply-To: <IkZoudKPbefTEwYHICuHlWqQvc3Jx9w__Xd1oiOhQ5c=.cc2f37ba-69cb-4385-b0ea-68a4c6e00bde@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
 <IkZoudKPbefTEwYHICuHlWqQvc3Jx9w__Xd1oiOhQ5c=.cc2f37ba-69cb-4385-b0ea-68a4c6e00bde@github.com>
Message-ID: <b0rOoYCZkeE68zPF-O1e7SySB1Iojf_M9f1vfz3XGMw=.210945a1-2402-4f88-bec4-beb9fc1d47be@github.com>

On Tue, 18 Nov 2025 16:05:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments from Daniel
>
> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 190:
> 
>> 188:     }
>> 189: 
>> 190:     private static void help() {
> 
> Keeping the help method at ~ the same place in the file would make it easier to review. Was there any change in this method?

yes - same code. Sorry, just thought it was better to move that method down the class. Not too interesting.

> test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 94:
> 
>> 92:                             + System.lineSeparator() +
>> 93:                             "  \"certificate\" : \\{",
>> 94:                         "sun.security.ssl.SSLSocketImpl close",
> 
> was that change intended? I don't see what it has to do with the rest.

yes - so with the System.Logger in use, we expect to see "sun.security.ssl.SSLSocketImpl close" now instead of the old "sun.security.ssl.SSLLogger log" calls. 

info in JBS report

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28376#discussion_r2538926633
PR Review Comment: https://git.openjdk.org/jdk/pull/28376#discussion_r2538930489

From coffeys at openjdk.org  Tue Nov 18 16:48:51 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 18 Nov 2025 16:48:51 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger [v3]
In-Reply-To: <-rtxK5LpPoY8LyEluxi8tARnDJqKK4rU1Gwurz8y-Jw=.858b9a74-308b-4659-8af8-44f617d75b69@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
 <IkZoudKPbefTEwYHICuHlWqQvc3Jx9w__Xd1oiOhQ5c=.cc2f37ba-69cb-4385-b0ea-68a4c6e00bde@github.com>
 <vFIt0cCsNJOBnoaOsy6QIv-N-GtVcOlR6HXxuJYVfxw=.bea284d8-10c4-4fc7-94ab-b49097c288c1@github.com>
 <-rtxK5LpPoY8LyEluxi8tARnDJqKK4rU1Gwurz8y-Jw=.858b9a74-308b-4659-8af8-44f617d75b69@github.com>
Message-ID: <h2glyJWZhNOSBUoGfEKjkUilufvd-P0xlLe59yu_hM8=.88408f10-07a5-4e17-827f-4dca0d9e8797@github.com>

On Tue, 18 Nov 2025 16:41:40 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Since you have now imported `@ForceInline` maybe you could also add it to `doLog` - the methods that call it are all one-liners.
>
> log0 has quite a bit of logic in it. Not sure if it warrants inlining, The isOn() check will short circuit nearly all log calls in the default JDK configuration in any case.

> `log0` might be a better name than `doLog`

thanks - made that change

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28376#discussion_r2538924890

From coffeys at openjdk.org  Tue Nov 18 16:48:50 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 18 Nov 2025 16:48:50 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger [v3]
In-Reply-To: <vFIt0cCsNJOBnoaOsy6QIv-N-GtVcOlR6HXxuJYVfxw=.bea284d8-10c4-4fc7-94ab-b49097c288c1@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
 <IkZoudKPbefTEwYHICuHlWqQvc3Jx9w__Xd1oiOhQ5c=.cc2f37ba-69cb-4385-b0ea-68a4c6e00bde@github.com>
 <vFIt0cCsNJOBnoaOsy6QIv-N-GtVcOlR6HXxuJYVfxw=.bea284d8-10c4-4fc7-94ab-b49097c288c1@github.com>
Message-ID: <-rtxK5LpPoY8LyEluxi8tARnDJqKK4rU1Gwurz8y-Jw=.858b9a74-308b-4659-8af8-44f617d75b69@github.com>

On Tue, 18 Nov 2025 16:18:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 146:
>> 
>>> 144: 
>>> 145:     public static void severe(String msg, Object... params) {
>>> 146:         SSLLogger.doLog(Level.ERROR, msg, params);
>> 
>> `log0` might be a better name than `doLog`
>
> Since you have now imported `@ForceInline` maybe you could also add it to `doLog` - the methods that call it are all one-liners.

log0 has quite a bit of logic in it. Not sure if it warrants inlining, The isOn() check will short circuit nearly all log calls in the default JDK configuration in any case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28376#discussion_r2538923895

From weijun at openjdk.org  Tue Nov 18 17:33:39 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Nov 2025 17:33:39 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>
Message-ID: <GAinmnN4ihtCrHCj6gwglE7A65wy4x53nEIa9JOKYX8=.c49ada30-6dcc-4abb-8557-5e7ea3010da5@github.com>

On Tue, 18 Nov 2025 12:21:09 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up jtreg run/compile directives, attend to other review comments

`UnsatisfiedLinkError` is not an `Exception`. It's just a `Throwable`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3548783827

From mdoerr at openjdk.org  Tue Nov 18 17:37:35 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 18 Nov 2025 17:37:35 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v3]
In-Reply-To: <-srlt_N0wyBwCwOmZTJBdGNFm66doGBHr6Yx83pqSpQ=.be8e4031-f542-49ad-8271-ac9a2c8b9128@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <-srlt_N0wyBwCwOmZTJBdGNFm66doGBHr6Yx83pqSpQ=.be8e4031-f542-49ad-8271-ac9a2c8b9128@github.com>
Message-ID: <xTSKInxkATuRFkM6HFUdQAc3QCHfEAv0ehYZuG5Ughg=.dbe05245-ab89-4a93-8014-74d5986c9045@github.com>

On Fri, 14 Nov 2025 17:21:50 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More minor cleanup.

@valeriep, @jnimeh: I've seen that you have reviewed other changes in this area and I need reviews from Security Group people. I will certainly find reviewers for the hotspot part. May I ask you to take a look at the Java part?
I would slightly prefer doing a bit more changes, but wanted to check with you, first: https://github.com/TheRealMDoerr/jdk/commit/2907475958806cad6b5fc83541f66065475a93ec

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

PR Comment: https://git.openjdk.org/jdk/pull/28299#issuecomment-3548795174

From dfuchs at openjdk.org  Tue Nov 18 18:15:46 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Nov 2025 18:15:46 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger [v3]
In-Reply-To: <FpAvU1fJcJACeVnk-RFF59WPJ4qEyn9Sg6tZODCFvMQ=.df34e19a-6a96-476b-b256-a24a5cf8be2e@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
 <FpAvU1fJcJACeVnk-RFF59WPJ4qEyn9Sg6tZODCFvMQ=.df34e19a-6a96-476b-b256-a24a5cf8be2e@github.com>
Message-ID: <IPHmF0dQoxrL-kkia_U166vuWj3Hb5fBvfdDMoU5wFI=.4a453cde-419d-4a8f-b936-a9f9052e6fca@github.com>

On Tue, 18 Nov 2025 16:48:48 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> `SSLLogger` utilizes `System.Logger` if the `javax.net.debug` system property key value is empty. However, since that class doesn't implement `SSLogger`, it misses the advantage of highlighting the exact calling site for each log statement.  Having `SSLLogger `simply implement `System.Logger` fixes this
>> 
>> I've also taken this opportunity to refractor the `isOn` boolean in `SSLLogger`. Encapsulated that boolean in a new method which callers can now use. I also used `ForceInline` directory on that method. Thanks to @dfuch for suggestions on that front.
>> 
>> Also updated an existing unit testcase to test for the new functionality
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments from Daniel

Looks good to me! Since I'm not a typical Reviewer for security-libs then please obtain an additional review from a Reviewer from that area before integrating.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28376#pullrequestreview-3479140282

From dfuchs at openjdk.org  Tue Nov 18 18:15:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Nov 2025 18:15:49 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger [v3]
In-Reply-To: <b0rOoYCZkeE68zPF-O1e7SySB1Iojf_M9f1vfz3XGMw=.210945a1-2402-4f88-bec4-beb9fc1d47be@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
 <IkZoudKPbefTEwYHICuHlWqQvc3Jx9w__Xd1oiOhQ5c=.cc2f37ba-69cb-4385-b0ea-68a4c6e00bde@github.com>
 <b0rOoYCZkeE68zPF-O1e7SySB1Iojf_M9f1vfz3XGMw=.210945a1-2402-4f88-bec4-beb9fc1d47be@github.com>
Message-ID: <UxfXdQHeW7AQLTD396uCP6BW5qmRg9AUqfRwEwuI0Ok=.c012436e-d8cd-4f3f-9dd4-c4366fba983d@github.com>

On Tue, 18 Nov 2025 16:43:40 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 94:
>> 
>>> 92:                             + System.lineSeparator() +
>>> 93:                             "  \"certificate\" : \\{",
>>> 94:                         "sun.security.ssl.SSLSocketImpl close",
>> 
>> was that change intended? I don't see what it has to do with the rest.
>
> yes - so with the System.Logger in use, we expect to see "sun.security.ssl.SSLSocketImpl close" now instead of the old "sun.security.ssl.SSLLogger log" calls. 
> 
> info in JBS report

Oh - OK - makes sense then. The logic of the test was not immediately obvious. I would have understood if `"sun.security.ssl.SSLSocketImpl close"` had replaced `"sun.security.ssl.SSLLogger log"`.  Now I see that it's adding a pattern that we expect to additionally find (and previously `"sun.security.ssl.SSLLogger log"` was not checked) - so that looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28376#discussion_r2539211833

From duke at openjdk.org  Tue Nov 18 18:23:21 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 18 Nov 2025 18:23:21 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v3]
In-Reply-To: <-srlt_N0wyBwCwOmZTJBdGNFm66doGBHr6Yx83pqSpQ=.be8e4031-f542-49ad-8271-ac9a2c8b9128@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <-srlt_N0wyBwCwOmZTJBdGNFm66doGBHr6Yx83pqSpQ=.be8e4031-f542-49ad-8271-ac9a2c8b9128@github.com>
Message-ID: <_rE68-lxqQMg8l1T9Mj2zl3vf2eXCSNc3SpIKRNOFvA=.6a9f3cbb-ef76-4079-bdec-a37f12d337fa@github.com>

On Fri, 14 Nov 2025 17:21:50 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More minor cleanup.

@valeriepeng or @jnimeh are good choices for review and someone besides myself will need to be a reviewer given that I don't have reviewer privileges.

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

PR Comment: https://git.openjdk.org/jdk/pull/28299#issuecomment-3548990626

From valeriep at openjdk.org  Tue Nov 18 18:43:07 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 18 Nov 2025 18:43:07 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v3]
In-Reply-To: <-srlt_N0wyBwCwOmZTJBdGNFm66doGBHr6Yx83pqSpQ=.be8e4031-f542-49ad-8271-ac9a2c8b9128@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <-srlt_N0wyBwCwOmZTJBdGNFm66doGBHr6Yx83pqSpQ=.be8e4031-f542-49ad-8271-ac9a2c8b9128@github.com>
Message-ID: <8NWK4oQBOjqg1Z7D-NsWuWn_ZhU9E6jWSWedJJQSJ08=.b0c9ef61-7880-4300-a90a-9b89d0a1ec8f@github.com>

On Fri, 14 Nov 2025 17:21:50 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More minor cleanup.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 62:

> 60:     private int[] sessionKe = null; // key for encryption
> 61:     private int[] sessionKd = null; // preprocessed key for decryption
> 62:     private int[] K = null; // preprocessed key in case of decryption

I find the comment confusing as `K` is sometimes assigned with `sessionKe`, so it can't be used only for decryption?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28299#discussion_r2539296610

From duke at openjdk.org  Tue Nov 18 18:51:05 2025
From: duke at openjdk.org (Nick Hall)
Date: Tue, 18 Nov 2025 18:51:05 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: <GAinmnN4ihtCrHCj6gwglE7A65wy4x53nEIa9JOKYX8=.c49ada30-6dcc-4abb-8557-5e7ea3010da5@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>
 <GAinmnN4ihtCrHCj6gwglE7A65wy4x53nEIa9JOKYX8=.c49ada30-6dcc-4abb-8557-5e7ea3010da5@github.com>
Message-ID: <vzKvikxwM-7s1KARalEBhseCJ7HWY8fUbj8kViUnLe0=.c30f5faf-db58-4b52-9ae7-5d6313752950@github.com>

On Tue, 18 Nov 2025 17:31:04 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `UnsatisfiedLinkError` is not an `Exception`. It's just a `Throwable`.

Good point.  I wonder what the intent of that exception handling code is, then.  I assumed it was to silently fall back to using the pure Java code in the event a library was un-loadable / not present, etc.  In this particular case, it's almost essential that this happens, because otherwise a JDK with this feature compiled in and distributed to a machine without libkrb5 installed would basically be unable to use anything that called the `Credentials` class methods.

Looking at the code further: `ensureLoaded()` calls only `System.loadLibrary()`, which only throws the following checked exceptions:

SecurityException
UnsatisfiedLinkError
NullPointerException

Of those, the libname is always a static string, so that just leaves the first two (or another `RuntimeException`).  Either of those will yield an un-loadable library, but the first will be swallowed.  Does that mean the code above should also catch the `UnsatisfiedLinkError`?

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3549093006

From valeriep at openjdk.org  Tue Nov 18 18:55:05 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 18 Nov 2025 18:55:05 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v3]
In-Reply-To: <-srlt_N0wyBwCwOmZTJBdGNFm66doGBHr6Yx83pqSpQ=.be8e4031-f542-49ad-8271-ac9a2c8b9128@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <-srlt_N0wyBwCwOmZTJBdGNFm66doGBHr6Yx83pqSpQ=.be8e4031-f542-49ad-8271-ac9a2c8b9128@github.com>
Message-ID: <L43-8BSAIJbjLtuqyFuAp0nFSi-NpwIEwlCGPeSeyaw=.d3cd5fd2-6b0f-49af-9c25-a6a06cdc31d8@github.com>

On Fri, 14 Nov 2025 17:21:50 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More minor cleanup.

I can review until COB this Thursday, then I will be on vacation and return on Dec 2nd. Just FYI.

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

PR Comment: https://git.openjdk.org/jdk/pull/28299#issuecomment-3549101690

From duke at openjdk.org  Tue Nov 18 18:59:07 2025
From: duke at openjdk.org (Nick Hall)
Date: Tue, 18 Nov 2025 18:59:07 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>
Message-ID: <-ZOtR8BhuO9VihBuWdAi_Anygy_imtkjr9AwqUgdQ0k=.56f35e65-6cec-45bd-993a-87ff1af9599e@github.com>

On Tue, 18 Nov 2025 12:21:09 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up jtreg run/compile directives, attend to other review comments

For what it's worth, here's how this looks using KCM on a host...

...with libkrb5

krb5loginmodule[0x3|main|Krb5LoginModule.java:647|2025-11-18 13:30:45.208]: Acquire TGT from Cache
krb5loginmodule[0x3|main|Krb5LoginModule.java:678|2025-11-18 13:30:45.252]: Principal is user-redacted at REALM.REDACTED
krb5loginmodule[0x3|main|Krb5LoginModule.java:1140|2025-11-18 13:30:45.272]: Commit Succeeded 

krb5loginmodule[0x3|main|Krb5LoginModule.java:1190|2025-11-18 13:30:45.273]:            [Krb5LoginModule]: Entering logout
krb5loginmodule[0x3|main|Krb5LoginModule.java:1218|2025-11-18 13:30:45.273]:            [Krb5LoginModule]: logged out Subject

...without libkrb5:

krb5loginmodule[0x3|main|Krb5LoginModule.java:647|2025-11-18 13:34:13.604]: Acquire TGT from Cache
Exception in thread "main" java.lang.UnsatisfiedLinkError: /path/redacted/jdk/build/linux-x86_64-server-release/jdk/lib/liblinuxkrb5.so: libkrb5.so.3: cannot open shared object file: No such file or directory
        at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
        at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:326)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:187)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:129)
        at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:254)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:239)
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2315)
        at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:822)
        at java.base/java.lang.System.loadLibrary(System.java:1685)
        at java.security.jgss/sun.security.krb5.Credentials.ensureLoaded(Credentials.java:535)
        at java.security.jgss/sun.security.krb5.Credentials.acquireDefaultCreds(Credentials.java:449)
        at java.security.jgss/sun.security.krb5.Credentials.acquireTGTFromCache(Credentials.java:335)
        at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:649)
        at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:601)
        at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:603)
        at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:460)
        at RunWhoAmI.main(RunWhoAmI.java:22)

...without libkrb5, but with a small patch to also catch `UnsatisfiedLinkError`:

krb5loginmodule[0x3|main|Krb5LoginModule.java:647|2025-11-18 13:52:09.045]: Acquire TGT from Cache
krb5loginmodule[0x3|main|Krb5LoginModule.java:678|2025-11-18 13:52:09.053]: Principal is null
krb5loginmodule[0x3|main|Krb5LoginModule.java:681|2025-11-18 13:52:09.053]: null credentials from Ticket Cache
krb5loginmodule[0x3|main|Krb5LoginModule.java:608|2025-11-18 13:52:09.054]:             [Krb5LoginModule] authentication failed 
Unable to obtain Principal Name for authentication 
Login failed
javax.security.auth.login.LoginException: Unable to obtain Principal Name for authentication 
        at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:816)
        at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:693)
        at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:601)
        at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:603)
        at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:460)
        at RunWhoAmI.main(RunWhoAmI.java:22)

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3549110005

From mdoerr at openjdk.org  Tue Nov 18 21:48:12 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 18 Nov 2025 21:48:12 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v4]
In-Reply-To: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
Message-ID: <0HJnSUSQA8RuwnNxu-SiGvZTzHYLJ5kY0_B6lG2EbAQ=.10868fac-1516-4a80-b4e5-9ff14997ba01@github.com>

> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Remove K from AES_Crypt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28299/files
  - new: https://git.openjdk.org/jdk/pull/28299/files/621616a4..2b981288

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

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

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

From mdoerr at openjdk.org  Tue Nov 18 21:48:15 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 18 Nov 2025 21:48:15 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v3]
In-Reply-To: <8NWK4oQBOjqg1Z7D-NsWuWn_ZhU9E6jWSWedJJQSJ08=.b0c9ef61-7880-4300-a90a-9b89d0a1ec8f@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <-srlt_N0wyBwCwOmZTJBdGNFm66doGBHr6Yx83pqSpQ=.be8e4031-f542-49ad-8271-ac9a2c8b9128@github.com>
 <8NWK4oQBOjqg1Z7D-NsWuWn_ZhU9E6jWSWedJJQSJ08=.b0c9ef61-7880-4300-a90a-9b89d0a1ec8f@github.com>
Message-ID: <4RdGgD3PA7s5RYgaZsHA-V2pgqh8BrP19FczkmVYDbM=.f9cb08ec-2fb7-4af6-9ad2-f232fb4a9004@github.com>

On Tue, 18 Nov 2025 18:40:12 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More minor cleanup.
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 62:
> 
>> 60:     private int[] sessionKe = null; // key for encryption
>> 61:     private int[] sessionKd = null; // preprocessed key for decryption
>> 62:     private int[] K = null; // preprocessed key in case of decryption
> 
> I find the comment confusing as `K` is sometimes assigned with `sessionKe`, so it can't be used only for decryption?

Thanks for looking at it! I've merged my additional proposal. `K` is removed, now. Does the Java part look ok? I'll ask for a hotspot review once the Java part is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28299#discussion_r2539714325

From valeriep at openjdk.org  Tue Nov 18 21:48:16 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 18 Nov 2025 21:48:16 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v3]
In-Reply-To: <4RdGgD3PA7s5RYgaZsHA-V2pgqh8BrP19FczkmVYDbM=.f9cb08ec-2fb7-4af6-9ad2-f232fb4a9004@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <-srlt_N0wyBwCwOmZTJBdGNFm66doGBHr6Yx83pqSpQ=.be8e4031-f542-49ad-8271-ac9a2c8b9128@github.com>
 <8NWK4oQBOjqg1Z7D-NsWuWn_ZhU9E6jWSWedJJQSJ08=.b0c9ef61-7880-4300-a90a-9b89d0a1ec8f@github.com>
 <4RdGgD3PA7s5RYgaZsHA-V2pgqh8BrP19FczkmVYDbM=.f9cb08ec-2fb7-4af6-9ad2-f232fb4a9004@github.com>
Message-ID: <tETKgz_8zGz5GA47XuiO6HDnWeBBRIrHywIV6GvCk7U=.de92ddd4-6590-4b6a-b5ba-ddb687131dc1@github.com>

On Tue, 18 Nov 2025 21:38:00 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 62:
>> 
>>> 60:     private int[] sessionKe = null; // key for encryption
>>> 61:     private int[] sessionKd = null; // preprocessed key for decryption
>>> 62:     private int[] K = null; // preprocessed key in case of decryption
>> 
>> I find the comment confusing as `K` is sometimes assigned with `sessionKe`, so it can't be used only for decryption?
>
> Thanks for looking at it! I've merged my additional proposal. `K` is removed, now. Does the Java part look ok? I'll ask for a hotspot review once the Java part is fine.

Java part looks fine to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28299#discussion_r2539716623

From weijun at openjdk.org  Wed Nov 19 00:02:33 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 19 Nov 2025 00:02:33 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v4]
In-Reply-To: <OggDZsb-SB866nDVpcifh8EcgiFO64uszj7Oti7zwkg=.4bc8495f-3c4c-4bd0-8684-28ca61028196@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
 <OggDZsb-SB866nDVpcifh8EcgiFO64uszj7Oti7zwkg=.4bc8495f-3c4c-4bd0-8684-28ca61028196@github.com>
Message-ID: <SzMC1cV0fkG1Y5GoGWML1xNblev3Z5anqqkh5oM5u14=.2e1771a8-2260-4787-ac88-32d326fff2c2@github.com>

On Thu, 13 Nov 2025 07:54:57 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This PR improves security warning when using JKS or JCEKS keystores.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed bugid from Compatibility.java test

src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java line 996:

> 994:                 + "keytool -importkeystore -srckeystore <keystore> "
> 995:                 + "-destkeystore <keystore> -deststoretype pkcs12");
> 996:     }

Currently the debug output has a long prefix containing timestamp etc. If the warning is separated on two lines, does it make sense to call `debug.println` twice so both lines have the prefix?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2539992152

From mdoerr at openjdk.org  Wed Nov 19 09:08:34 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 19 Nov 2025 09:08:34 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v3]
In-Reply-To: <tETKgz_8zGz5GA47XuiO6HDnWeBBRIrHywIV6GvCk7U=.de92ddd4-6590-4b6a-b5ba-ddb687131dc1@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <-srlt_N0wyBwCwOmZTJBdGNFm66doGBHr6Yx83pqSpQ=.be8e4031-f542-49ad-8271-ac9a2c8b9128@github.com>
 <8NWK4oQBOjqg1Z7D-NsWuWn_ZhU9E6jWSWedJJQSJ08=.b0c9ef61-7880-4300-a90a-9b89d0a1ec8f@github.com>
 <4RdGgD3PA7s5RYgaZsHA-V2pgqh8BrP19FczkmVYDbM=.f9cb08ec-2fb7-4af6-9ad2-f232fb4a9004@github.com>
 <tETKgz_8zGz5GA47XuiO6HDnWeBBRIrHywIV6GvCk7U=.de92ddd4-6590-4b6a-b5ba-ddb687131dc1@github.com>
Message-ID: <RedOqg6KTmusZUdOqfemlg8g5k9RbLh5PDGxwQsJrFs=.3c8f9cc2-828d-43db-a2aa-ea59e2cf84e4@github.com>

On Tue, 18 Nov 2025 21:40:01 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Thanks for looking at it! I've merged my additional proposal. `K` is removed, now. Does the Java part look ok? I'll ask for a hotspot review once the Java part is fine.
>
> Java part looks fine to me.

Thanks for reviewing!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28299#discussion_r2541140164

From mdoerr at openjdk.org  Wed Nov 19 09:13:42 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 19 Nov 2025 09:13:42 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v4]
In-Reply-To: <0HJnSUSQA8RuwnNxu-SiGvZTzHYLJ5kY0_B6lG2EbAQ=.10868fac-1516-4a80-b4e5-9ff14997ba01@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <0HJnSUSQA8RuwnNxu-SiGvZTzHYLJ5kY0_B6lG2EbAQ=.10868fac-1516-4a80-b4e5-9ff14997ba01@github.com>
Message-ID: <-IeLB8uRff2Hu6rXMg_C1kr1vF46RUzULxFjMastVE8=.1aa135cc-38b1-4c37-966c-59cc51d300f5@github.com>

On Tue, 18 Nov 2025 21:48:12 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove K from AES_Crypt

@vnkozlov: May I ask you to take a look at the C2 part? I had to adapt the library_call code to the new Java implementation which stores the key in "sessionKe" and "sessionKd", now. I think the hotspot part is also more comprehensive this way because it makes it clear which key is used for what.

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

PR Comment: https://git.openjdk.org/jdk/pull/28299#issuecomment-3551612586

From cushon at openjdk.org  Wed Nov 19 10:14:41 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 19 Nov 2025 10:14:41 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
Message-ID: <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>

> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
> 
> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
> 
> 
>     byte[] bytes = new byte[length];
>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>     return new String(bytes, charset);
> 
> 
> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
> 
> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
> 
> Benchmark results:
> 
> 
> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
> ToJavaStringTest.panama_readStringLength      20  avgt   30    4.654 ? 0.040  ns/op
> ToJavaStringTest.panama_readString...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28043/files
  - new: https://git.openjdk.org/jdk/pull/28043/files/3f6ee815..0593827f

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

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

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

From mcimadamore at openjdk.org  Wed Nov 19 14:48:30 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Nov 2025 14:48:30 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
Message-ID: <vSV8byzRclzZSYpj0NbWjmI40-JtMNgG5ZAFbQjHaik=.88ba6b44-f694-48da-bff5-41fb0494dcf4@github.com>

On Wed, 19 Nov 2025 10:14:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode

src/java.base/share/classes/java/lang/String.java line 2019:

> 2017:     }
> 2018: 
> 2019:     boolean bytesCompatible(Charset charset, int srcIndex, int numChars) {

Surprisingly here we don't do anything for the case where the string is UTF16 and the target charset is also UTF16?

src/java.base/share/classes/java/lang/String.java line 2030:

> 2028:     }
> 2029: 
> 2030:     void copyToSegmentRaw(MemorySegment segment, long offset, int srcIndex, int numChars) {

This method takes an index, expressed in chars, and uses that as a byte offset in a bulk copy operation. I don't think this is correct. E.g. if the string is UTF16 (and not LATIN1), there is a scaling factor to be applied?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2542331027
PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2542323659

From mcimadamore at openjdk.org  Wed Nov 19 14:48:32 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Nov 2025 14:48:32 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <vSV8byzRclzZSYpj0NbWjmI40-JtMNgG5ZAFbQjHaik=.88ba6b44-f694-48da-bff5-41fb0494dcf4@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
 <vSV8byzRclzZSYpj0NbWjmI40-JtMNgG5ZAFbQjHaik=.88ba6b44-f694-48da-bff5-41fb0494dcf4@github.com>
Message-ID: <snk1ibJWOo28bSfye1bh0eR2GcmPNAs1ofbjCYlcn-M=.289030e1-0b91-4ef3-990f-25757b872ff8@github.com>

On Wed, 19 Nov 2025 14:43:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode
>
> src/java.base/share/classes/java/lang/String.java line 2030:
> 
>> 2028:     }
>> 2029: 
>> 2030:     void copyToSegmentRaw(MemorySegment segment, long offset, int srcIndex, int numChars) {
> 
> This method takes an index, expressed in chars, and uses that as a byte offset in a bulk copy operation. I don't think this is correct. E.g. if the string is UTF16 (and not LATIN1), there is a scaling factor to be applied?

In other words, it seems to me that here we have hardwired the knowledge that we can only get here is the string is latin1. I don't think this was the original intent of this method -- however, if that's the case, we should also add an assertion to avoid misuse.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2542337230

From mcimadamore at openjdk.org  Wed Nov 19 14:51:35 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Nov 2025 14:51:35 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
Message-ID: <pG1eD15gcCzH2H-nKuLj76ngCFzcL8QI6KFeJ_0gLL4=.108b506f-99a7-4d94-a973-25c5c7e542f4@github.com>

On Wed, 19 Nov 2025 10:14:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 194:

> 192:         MemorySegment segment;
> 193:         if (StringSupport.bytesCompatible(str, charset, srcIndex, numChars)) {
> 194:             segment = allocateNoInit(numChars);

This also seems to rely on the fact that we end up here only for latin1 strings. Again, I don't think this is correct, but if it's deliberate, we should add an assertion check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2542352073

From mcimadamore at openjdk.org  Wed Nov 19 14:56:31 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Nov 2025 14:56:31 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
Message-ID: <98Nvh8i9sL6mKa_NPS72wQhnmr3juct9GzVu358lXu4=.0999db1b-806e-43b2-b77c-681c9e8d243f@github.com>

On Wed, 19 Nov 2025 10:14:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2649:

> 2647:      *
> 2648:      * @param src      the Java string to be written into this segment
> 2649:      * @param dstEncoding the charset used to {@linkplain Charset#newEncoder() encode}

I'm not sure we have a dependency on the charset being standard?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2542365995

From mcimadamore at openjdk.org  Wed Nov 19 15:06:46 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Nov 2025 15:06:46 GMT
Subject: RFR: 8369564: Provide a MemorySegment API to read strings with
 known lengths [v7]
In-Reply-To: <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
References: <HhiQNbBbkWHl4xwc2IqZKqp8TJQKnks93otNtQ4Vp8I=.41ae125b-5a84-4084-94b2-91f7ea1aa67f@github.com>
 <Fc3hPP-hCq_6RIsENgKDbDaIPKonmey90kC1QL3HyKs=.5fc6fe43-7413-4d46-87e4-ea4075a7bfff@github.com>
Message-ID: <0lOpR-lFysqowVFSM9SL6UGJEHp1cFpSfTlfDJyayek=.ff295fee-66c1-414e-8be1-7c20606c9ee4@github.com>

On Wed, 19 Nov 2025 10:14:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content.
>> 
>> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest
>> 
>> 
>>     byte[] bytes = new byte[length];
>>     MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
>>     return new String(bytes, charset);
>> 
>> 
>> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy.
>> 
>> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html)
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                                 (size)  Mode  Cnt    Score   Error  Units
>> ToJavaStringTest.jni_readString                5  avgt   30   55.339 ? 0.401  ns/op
>> ToJavaStringTest.jni_readString               20  avgt   30   59.887 ? 0.295  ns/op
>> ToJavaStringTest.jni_readString              100  avgt   30   84.288 ? 0.419  ns/op
>> ToJavaStringTest.jni_readString              200  avgt   30  119.275 ? 0.496  ns/op
>> ToJavaStringTest.jni_readString              451  avgt   30  193.106 ? 1.528  ns/op
>> ToJavaStringTest.panama_copyLength             5  avgt   30    7.348 ? 0.048  ns/op
>> ToJavaStringTest.panama_copyLength            20  avgt   30    7.440 ? 0.125  ns/op
>> ToJavaStringTest.panama_copyLength           100  avgt   30   11.766 ? 0.058  ns/op
>> ToJavaStringTest.panama_copyLength           200  avgt   30   16.096 ? 0.089  ns/op
>> ToJavaStringTest.panama_copyLength           451  avgt   30   25.844 ? 0.054  ns/op
>> ToJavaStringTest.panama_readString             5  avgt   30    5.857 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString            20  avgt   30    7.750 ? 0.046  ns/op
>> ToJavaStringTest.panama_readString           100  avgt   30   14.109 ? 0.187  ns/op
>> ToJavaStringTest.panama_readString           200  avgt   30   18.035 ? 0.130  ns/op
>> ToJavaStringTest.panama_readString           451  avgt   30   35.896 ? 0.227  ns/op
>> ToJavaStringTest.panama_readStringLength       5  avgt   30    4.565 ? 0.038  ns/op
>> ToJavaStringTest.panama_readStringLength      20...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a dstOffset parameter, stop using StringCharBuffer/CharsetEncoder::encode

Overall, looks good, but I think we should put some more care when going to char-based indices to byte array indices, esp. if we will optimize the UTF16 case in the future

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

PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3483251965

From weijun at openjdk.org  Wed Nov 19 15:19:09 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 19 Nov 2025 15:19:09 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: <vzKvikxwM-7s1KARalEBhseCJ7HWY8fUbj8kViUnLe0=.c30f5faf-db58-4b52-9ae7-5d6313752950@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>
 <GAinmnN4ihtCrHCj6gwglE7A65wy4x53nEIa9JOKYX8=.c49ada30-6dcc-4abb-8557-5e7ea3010da5@github.com>
 <vzKvikxwM-7s1KARalEBhseCJ7HWY8fUbj8kViUnLe0=.c30f5faf-db58-4b52-9ae7-5d6313752950@github.com>
Message-ID: <O6Fp0KrsWj-wmhY65fr_pei0glU91fmQBRqombxuqt4=.e9690c7a-50aa-41e0-ba41-0598154a432a@github.com>

On Tue, 18 Nov 2025 18:48:22 GMT, Nick Hall <duke at openjdk.org> wrote:

> Does that mean the code above should also catch the `UnsatisfiedLinkError`?

If we make `libkrb5` a required dependency and make sure your new native code is always compiled into JDK, this is a real error and we should fail loudly. Otherwise, we need to fallback to pure Java. I guess this is also the reason why it was not caught before.

I still think it should be a required dependency.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3553277926

From weijun at openjdk.org  Wed Nov 19 16:07:34 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 19 Nov 2025 16:07:34 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger [v3]
In-Reply-To: <FpAvU1fJcJACeVnk-RFF59WPJ4qEyn9Sg6tZODCFvMQ=.df34e19a-6a96-476b-b256-a24a5cf8be2e@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
 <FpAvU1fJcJACeVnk-RFF59WPJ4qEyn9Sg6tZODCFvMQ=.df34e19a-6a96-476b-b256-a24a5cf8be2e@github.com>
Message-ID: <T1Ur3UjV0saqgo6m9sCpfD0Rfis4hu5lpZCIjwLi6dk=.b919a1a2-fb25-4c8e-9e23-e96c6fa3b0aa@github.com>

On Tue, 18 Nov 2025 16:48:48 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> `SSLLogger` utilizes `System.Logger` if the `javax.net.debug` system property key value is empty. However, since that class doesn't implement `SSLogger`, it misses the advantage of highlighting the exact calling site for each log statement.  Having `SSLLogger `simply implement `System.Logger` fixes this
>> 
>> I've also taken this opportunity to refractor the `isOn` boolean in `SSLLogger`. Encapsulated that boolean in a new method which callers can now use. I also used `ForceInline` directory on that method. Thanks to @dfuch for suggestions on that front.
>> 
>> Also updated an existing unit testcase to test for the new functionality
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments from Daniel

Looks good.

I assume except for `SSLLogger` itself and the test change, everything else is just `s/isOn/isOn()/`, right? I quickly paged down and see no other significant changes.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28376#pullrequestreview-3483488425

From coffeys at openjdk.org  Wed Nov 19 16:07:34 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 19 Nov 2025 16:07:34 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger [v3]
In-Reply-To: <T1Ur3UjV0saqgo6m9sCpfD0Rfis4hu5lpZCIjwLi6dk=.b919a1a2-fb25-4c8e-9e23-e96c6fa3b0aa@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
 <FpAvU1fJcJACeVnk-RFF59WPJ4qEyn9Sg6tZODCFvMQ=.df34e19a-6a96-476b-b256-a24a5cf8be2e@github.com>
 <T1Ur3UjV0saqgo6m9sCpfD0Rfis4hu5lpZCIjwLi6dk=.b919a1a2-fb25-4c8e-9e23-e96c6fa3b0aa@github.com>
Message-ID: <yopvfKMHopmHKP9VAldTNtKLTVjk3Ta-4mHQqZo4KSw=.9576d425-190c-4802-896b-3fdade8aaf5b@github.com>

On Wed, 19 Nov 2025 15:48:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Looks good.
> 
> I assume except for `SSLLogger` itself and the test change, everything else is just `s/isOn/isOn()/`, right? I quickly paged down and see no other significant changes.

Thanks for the review. Yes, most changes are `s/isOn/isOn()/`

1 line addition to test case like Daniel noted. Useful to confirm that change is indeed having effect

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

PR Comment: https://git.openjdk.org/jdk/pull/28376#issuecomment-3553509576

From abarashev at openjdk.org  Wed Nov 19 17:39:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 19 Nov 2025 17:39:08 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints
Message-ID: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@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.

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

Commit messages:
 - 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=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370885
  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 ascarpino at openjdk.org  Wed Nov 19 18:13:20 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 19 Nov 2025 18:13:20 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v48]
In-Reply-To: <mM_j0c5SgKmR7pbb7CqQXvZ7KEdwS86zXilFBoaufhg=.03bdbf1d-8315-43f2-9368-52a2b4c4c96c@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <mM_j0c5SgKmR7pbb7CqQXvZ7KEdwS86zXilFBoaufhg=.03bdbf1d-8315-43f2-9368-52a2b4c4c96c@github.com>
Message-ID: <RuAMEiYxaDMc0x3HM5dr9DlvESumv1aX7YTYLtqZ_Nw=.652c6f56-5da3-452b-9a3f-acfcbd7ed8d0@github.com>

On Wed, 12 Nov 2025 12:42:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> <img alt="image" src="https://github.com/user-attachments/assets/df3b454d-2161-4036-9930-c4f84d887b31" />
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java style method names

Marked as reviewed by ascarpino (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18411#pullrequestreview-3484108161

From rhalade at openjdk.org  Wed Nov 19 19:04:37 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 19 Nov 2025 19:04:37 GMT
Subject: RFR: 8362894: PKCS12 KeyStore PBMAC1 interoperability testing
In-Reply-To: <vQ2xN_1fTfrUQKCDsrUDUhYOUc21Mpa_5Z9dvbRr9ZU=.e372c2e0-e7c4-4db4-a675-fa2a0c3625af@github.com>
References: <vQ2xN_1fTfrUQKCDsrUDUhYOUc21Mpa_5Z9dvbRr9ZU=.e372c2e0-e7c4-4db4-a675-fa2a0c3625af@github.com>
Message-ID: <TIBxDLFK2H5zrlMXqptrhW_0A6QjkvFUYjLsL-yOKgI=.3db2e7b2-3256-4efc-a3b5-01d5afeecbe2@github.com>

On Wed, 5 Nov 2025 12:43:25 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> With the integration of JDK-8343232, this PR updates the Keytool/OpenSSL interop test to include a test case using PBMAC1.

thanks for addressing this gap. Please update test `test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java` to include bug id 8343232 in @bug list.

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

PR Comment: https://git.openjdk.org/jdk/pull/28150#issuecomment-3554206425

From rhalade at openjdk.org  Wed Nov 19 19:05:11 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 19 Nov 2025 19:05:11 GMT
Subject: RFR: 8343316: Review and update tests using explicit provider
 names [v3]
In-Reply-To: <b1Erf4NUqIJ3Sz98gpuDj33REXFsoutyaYzEqf576Ow=.4f17fabc-cd1d-4cf4-b6ad-76af2b72d81a@github.com>
References: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>
 <b1Erf4NUqIJ3Sz98gpuDj33REXFsoutyaYzEqf576Ow=.4f17fabc-cd1d-4cf4-b6ad-76af2b72d81a@github.com>
Message-ID: <Ix7wtQsH4MtBHVvHDDdOfOEIkYPAXV8a0wcPn4jfa80=.c910d657-d05d-4e83-92f3-1438a8321ffd@github.com>

On Tue, 18 Nov 2025 12:26:17 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I updated a few crypto tests to remove the hard-coded provider name and use the `test.provider.name` property instead. These tests were missed while working on [JDK-8341927](https://bugs.openjdk.org/browse/JDK-8341927).
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected copyright years

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28273#pullrequestreview-3484299632

From mdonovan at openjdk.org  Wed Nov 19 19:08:40 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 19 Nov 2025 19:08:40 GMT
Subject: RFR: 8362894: PKCS12 KeyStore PBMAC1 interoperability testing [v2]
In-Reply-To: <vQ2xN_1fTfrUQKCDsrUDUhYOUc21Mpa_5Z9dvbRr9ZU=.e372c2e0-e7c4-4db4-a675-fa2a0c3625af@github.com>
References: <vQ2xN_1fTfrUQKCDsrUDUhYOUc21Mpa_5Z9dvbRr9ZU=.e372c2e0-e7c4-4db4-a675-fa2a0c3625af@github.com>
Message-ID: <2O7aI8v8MPmpxDMwatLJwFdF5v1JjbpX6XTbbR5n0yc=.0796dc79-d0ce-47a1-bb5a-05e40ede03b8@github.com>

> With the integration of JDK-8343232, this PR updates the Keytool/OpenSSL interop test to include a test case using PBMAC1.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  added bug id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28150/files
  - new: https://git.openjdk.org/jdk/pull/28150/files/5dd38697..dadded17

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

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

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

From rhalade at openjdk.org  Wed Nov 19 19:08:41 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 19 Nov 2025 19:08:41 GMT
Subject: RFR: 8362894: PKCS12 KeyStore PBMAC1 interoperability testing [v2]
In-Reply-To: <2O7aI8v8MPmpxDMwatLJwFdF5v1JjbpX6XTbbR5n0yc=.0796dc79-d0ce-47a1-bb5a-05e40ede03b8@github.com>
References: <vQ2xN_1fTfrUQKCDsrUDUhYOUc21Mpa_5Z9dvbRr9ZU=.e372c2e0-e7c4-4db4-a675-fa2a0c3625af@github.com>
 <2O7aI8v8MPmpxDMwatLJwFdF5v1JjbpX6XTbbR5n0yc=.0796dc79-d0ce-47a1-bb5a-05e40ede03b8@github.com>
Message-ID: <npKLP1u1JaYLCFdF7GS8TZmdOohddTSqe48TjuYdKDM=.d7320e01-c665-4292-ab2f-c5987acc2d9b@github.com>

On Wed, 19 Nov 2025 19:06:02 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> With the integration of JDK-8343232, this PR updates the Keytool/OpenSSL interop test to include a test case using PBMAC1.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added bug id

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28150#pullrequestreview-3484312467

From mdonovan at openjdk.org  Wed Nov 19 19:17:49 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 19 Nov 2025 19:17:49 GMT
Subject: Integrated: 8343316: Review and update tests using explicit provider
 names
In-Reply-To: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>
References: <XrOp93rGVGrmlcDUTLd_m9xdmhjxlVayzxerjstqP7M=.069752e5-ef52-492c-871c-40b3c997979a@github.com>
Message-ID: <_HVk_ctq_4uhmwA-II-_ijknuBF3TQ9ubfYn6G1rUr0=.4d93c9f7-6326-44f7-81e1-2b6b82cec31d@github.com>

On Wed, 12 Nov 2025 17:58:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I updated a few crypto tests to remove the hard-coded provider name and use the `test.provider.name` property instead. These tests were missed while working on [JDK-8341927](https://bugs.openjdk.org/browse/JDK-8341927).

This pull request has now been integrated.

Changeset: 223cc645
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/223cc6451860f10fe8095705da07aaf7e882188f
Stats:     34 lines in 4 files changed: 12 ins; 0 del; 22 mod

8343316: Review and update tests using explicit provider names

Reviewed-by: rhalade

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

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

From rhalade at openjdk.org  Wed Nov 19 19:46:54 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 19 Nov 2025 19:46:54 GMT
Subject: RFR: 8356544: Implement additional tests for ciphersuites disabled
 with wildcards
In-Reply-To: <je_VCMu-DDtmPzrrRawpZGSXmsPv6ttLD6-k4QORWVc=.e83e6d61-1494-4c28-88fa-8d8d202ce87d@github.com>
References: <je_VCMu-DDtmPzrrRawpZGSXmsPv6ttLD6-k4QORWVc=.e83e6d61-1494-4c28-88fa-8d8d202ce87d@github.com>
Message-ID: <58ROVlz34nQwubgtqfXVeOeVWDQtPV2qZRwedbrK_HU=.2b45a14c-4f5d-4845-b9a0-f842e92a7783@github.com>

On Mon, 27 Oct 2025 15:54:34 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR extends the tests from JDK-8341964 and verifies a TLS server (or client) will not negotiate a ciphersuite requested by the remote peer but disabled with a wildcard.

Changes requested by rhalade (Reviewer).

test/jdk/sun/security/ssl/CipherSuite/DisabledCipherSuitesNotNegotiated.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @library /test/lib

add @bug with 8341964

test/jdk/sun/security/ssl/CipherSuite/DisabledCipherSuitesNotNegotiated.java line 76:

> 74:                 try {
> 75:                     clientSocket.getInputStream().readAllBytes();
> 76:                     throw new Exception("The expected handshake exception was not thrown.");

can you suffix this message with server and client?

test/jdk/sun/security/ssl/CipherSuite/DisabledCipherSuitesNotNegotiated.java line 86:

> 84: 
> 85:     private static void runClient(boolean disableInClient, int portNumber) throws Exception {
> 86:         SSLContext ctx = SSLContext.getInstance("TLSv1.2");

I prefer to have the `TLSv1.2` defined as final constant at class level so it is clear that this test is only for TLSv1.2

test/jdk/sun/security/ssl/CipherSuite/DisabledCipherSuitesNotNegotiated.java line 104:

> 102: 
> 103:     public static void main(String [] args) throws Exception {
> 104:         if (args.length == 1) {

fail here if the test is called without any arguments.

test/jdk/sun/security/ssl/CipherSuite/DisabledCipherSuitesNotNegotiated.java line 150:

> 148:     }
> 149: 
> 150: }

missing line at end

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

PR Review: https://git.openjdk.org/jdk/pull/28003#pullrequestreview-3484306760
PR Review Comment: https://git.openjdk.org/jdk/pull/28003#discussion_r2543220505
PR Review Comment: https://git.openjdk.org/jdk/pull/28003#discussion_r2543298915
PR Review Comment: https://git.openjdk.org/jdk/pull/28003#discussion_r2543301078
PR Review Comment: https://git.openjdk.org/jdk/pull/28003#discussion_r2543302049
PR Review Comment: https://git.openjdk.org/jdk/pull/28003#discussion_r2543222718

From duke at openjdk.org  Wed Nov 19 19:51:57 2025
From: duke at openjdk.org (Nick Hall)
Date: Wed, 19 Nov 2025 19:51:57 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>
Message-ID: <Z1zy6H0YW05GUCWWgTmOcdLFz8Vi0qmKMP-_hpcXDUU=.aa338be4-76fe-47bf-8d2d-232d18cfb308@github.com>

On Tue, 18 Nov 2025 12:21:09 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up jtreg run/compile directives, attend to other review comments

There's prior art here for CUPS - this is a mandatory compile-time and run-time dependency.  I guess the difference with CUPS is that Java can't print without it, whereas JAAS _can_ auth using Kerberos without my code, it's just limited to a file ccache.

It turns out that this limitation actually works to our advantage.  The existing code will first try and use the pure Java code to acquire a file ccache using a series of hard-coded defaults:

     * 1. KRB5CCNAME (bare file name without FILE:)
     * 2. /tmp/krb5cc_<uid> on unix systems
     * 3. <user.home>/krb5cc_<user.name>
     * 4. <user.home>/krb5cc (if can't get <user.name>)

(I'm not sure of the provenance of 3 and 4, but 1 and 2 are reasonable)

It then checks that the crypto is something it can handle.

If the code successfully finds a supported ccache, it will succeed _whether the new native lib is loadable or not_.  If it does not find a supported ccache this way, it will then try and load the native lib (and potentially fail with an `UnsatisfiedLinkError`) at this point.

(FWIW, I've tested this locally by temporarily making the system libkrb5 library inaccessible, then running a test with a regular FILE: ccache, and it worked as above.)

Assuming we did build it in by default, I suspect most people using FILE: ccaches will not even get to the native library load - and anyone trying to use unsupported ccache types/crypto with an older Java version would have got an error anyway, it's just that now this might be an `UnsatisfiedLinkError` instead of a `LoginException`.

I imagine this code was written this way for similar reasons to the discussion we're having here, on whichever of Windows/MacOS this was first introduced.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3554366847

From abarashev at openjdk.org  Wed Nov 19 20:22:24 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 19 Nov 2025 20:22:24 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v48]
In-Reply-To: <mM_j0c5SgKmR7pbb7CqQXvZ7KEdwS86zXilFBoaufhg=.03bdbf1d-8315-43f2-9368-52a2b4c4c96c@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <mM_j0c5SgKmR7pbb7CqQXvZ7KEdwS86zXilFBoaufhg=.03bdbf1d-8315-43f2-9368-52a2b4c4c96c@github.com>
Message-ID: <e4_KgwATJ0NvNNSIvv90qfdpB7ZmBit9nX0rK-oFz5U=.003bd735-468c-4618-a065-cae099dba778@github.com>

On Wed, 12 Nov 2025 12:42:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> <img alt="image" src="https://github.com/user-attachments/assets/df3b454d-2161-4036-9930-c4f84d887b31" />
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java style method names

LGTM

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

Marked as reviewed by abarashev (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18411#pullrequestreview-3484587568

From mullan at openjdk.org  Wed Nov 19 21:31:07 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 19 Nov 2025 21:31:07 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v48]
In-Reply-To: <mM_j0c5SgKmR7pbb7CqQXvZ7KEdwS86zXilFBoaufhg=.03bdbf1d-8315-43f2-9368-52a2b4c4c96c@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <mM_j0c5SgKmR7pbb7CqQXvZ7KEdwS86zXilFBoaufhg=.03bdbf1d-8315-43f2-9368-52a2b4c4c96c@github.com>
Message-ID: <MeNz88VrY8vwPM1muwzEv-j4P_8xUSFp1IBAy1z25zw=.f0cb7936-5ce4-4991-aaf7-ef664927792b@github.com>

On Wed, 12 Nov 2025 12:42:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> <img alt="image" src="https://github.com/user-attachments/assets/df3b454d-2161-4036-9930-c4f84d887b31" />
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java style method names

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18411#pullrequestreview-3484811859

From skuksenko at openjdk.org  Wed Nov 19 21:54:40 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Wed, 19 Nov 2025 21:54:40 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
 [v2]
In-Reply-To: <mzpPdK3E-jTbpaq-DfKQRGmc3WkHx8scm58ck2rpmBQ=.86b07f98-9464-494e-91a8-ccb843c57431@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
 <mzpPdK3E-jTbpaq-DfKQRGmc3WkHx8scm58ck2rpmBQ=.86b07f98-9464-494e-91a8-ccb843c57431@github.com>
Message-ID: <ISh_-trCqZ1D6chCaTQM93utbzuhyFV8gtJYYjcs6N0=.a601fd77-e9c8-459b-9527-c66fd74f7fb4@github.com>

On Mon, 17 Nov 2025 23:35:44 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> - New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
>>    - `SignatureBench.MLDSA` is 1.2x-2.2x faster
>>    - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
>> - AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
>>   - `SignatureBench.MLDSA` is upto 5% faster, never slower
>> 
>> Note on intrinsic:
>> - The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
>> - Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2
>> 
>> Tests and benchmarks:
>> - Added a fuzz test to ensure Java and intrinsic produces exactly same result
>> - Added benchmark to measure the performance of intrinsic itself
>> 
>> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
>> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
>> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
>> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"
>
> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - whitespace
>  - address first comments

What is the reason to add a new microbenchmark?
We already have enough micros covering MLDSA:

org.openjdk.bench.javax.crypto.full.KeyPairGeneratorBench.MLDSA.generateKeyPair
org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA.sign
org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA.verify
org.openjdk.bench.javax.crypto.small.KeyPairGeneratorBench.MLDSA.generateKeyPair
org.openjdk.bench.javax.crypto.small.SignatureBench.MLDSA.sign
org.openjdk.bench.javax.crypto.small.SignatureBench.MLDSA.verify

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

PR Comment: https://git.openjdk.org/jdk/pull/28136#issuecomment-3554770437

From vpaprotski at openjdk.org  Wed Nov 19 22:03:09 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 19 Nov 2025 22:03:09 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
 [v2]
In-Reply-To: <ISh_-trCqZ1D6chCaTQM93utbzuhyFV8gtJYYjcs6N0=.a601fd77-e9c8-459b-9527-c66fd74f7fb4@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
 <mzpPdK3E-jTbpaq-DfKQRGmc3WkHx8scm58ck2rpmBQ=.86b07f98-9464-494e-91a8-ccb843c57431@github.com>
 <ISh_-trCqZ1D6chCaTQM93utbzuhyFV8gtJYYjcs6N0=.a601fd77-e9c8-459b-9527-c66fd74f7fb4@github.com>
Message-ID: <LmXEMMWDEt2cxbnGrvnCf0634pBK5gOAEcvkopE2hY8=.6191991b-f1ab-4a9a-b96d-95258769bcca@github.com>

On Wed, 19 Nov 2025 21:51:32 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> What is the reason to add a new microbenchmark? We already have enough micros covering MLDSA:
> 
> org.openjdk.bench.javax.crypto.full.KeyPairGeneratorBench.MLDSA.generateKeyPair org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA.sign org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA.verify org.openjdk.bench.javax.crypto.small.KeyPairGeneratorBench.MLDSA.generateKeyPair org.openjdk.bench.javax.crypto.small.SignatureBench.MLDSA.sign org.openjdk.bench.javax.crypto.small.SignatureBench.MLDSA.verify

I can definitely remove it, got no strong attachment to it.. I did find it useful during development and thought it might be useful during review to verify performance.. but the usefulness of it beyond is indeed debatable.

You might notice its a lot more 'granular'; it measures the performance of the intrinsics themselves, not the ("10-level deep") "wrappers". That said, those "wrappers" is what actual user will see and what we should be measuring. 

This new benchmark is only useful to another intrinsic developer.. (but it should already be usable by other platforms not just Intel?)

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

PR Comment: https://git.openjdk.org/jdk/pull/28136#issuecomment-3554793447

From skuksenko at openjdk.org  Wed Nov 19 22:46:00 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Wed, 19 Nov 2025 22:46:00 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
 [v2]
In-Reply-To: <LmXEMMWDEt2cxbnGrvnCf0634pBK5gOAEcvkopE2hY8=.6191991b-f1ab-4a9a-b96d-95258769bcca@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
 <mzpPdK3E-jTbpaq-DfKQRGmc3WkHx8scm58ck2rpmBQ=.86b07f98-9464-494e-91a8-ccb843c57431@github.com>
 <ISh_-trCqZ1D6chCaTQM93utbzuhyFV8gtJYYjcs6N0=.a601fd77-e9c8-459b-9527-c66fd74f7fb4@github.com>
 <LmXEMMWDEt2cxbnGrvnCf0634pBK5gOAEcvkopE2hY8=.6191991b-f1ab-4a9a-b96d-95258769bcca@github.com>
Message-ID: <uhxj2hdqykG7yecwrS7bT9E96D7yfS9AbaydQ0HrXgM=.03a7c1fd-2f6d-4ad3-aedb-c44ba116b8c3@github.com>

On Wed, 19 Nov 2025 21:59:03 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> > What is the reason to add a new microbenchmark? We already have enough micros covering MLDSA:
> > org.openjdk.bench.javax.crypto.full.KeyPairGeneratorBench.MLDSA.generateKeyPair org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA.sign org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA.verify org.openjdk.bench.javax.crypto.small.KeyPairGeneratorBench.MLDSA.generateKeyPair org.openjdk.bench.javax.crypto.small.SignatureBench.MLDSA.sign org.openjdk.bench.javax.crypto.small.SignatureBench.MLDSA.verify
> 
> I can definitely remove it, got no strong attachment to it.. I did find it useful during development and thought it might be useful during review to verify performance.. but the usefulness of it beyond is indeed debatable.
> 
> You might notice its a lot more 'granular'; it measures the performance of the intrinsics themselves, not the ("10-level deep") "wrappers". That said, those "wrappers" is what actual user will see and what we should be measuring.
> 
> This new benchmark is only useful to another intrinsic developer.. (but it should already be usable by other platforms not just Intel?)

I understand your reasons.  The question is whether you'll need the microbenchmark in the future. If no (or probably no), please remove the micro. 
If needed, please move it from the "org.openjdk.bench.javax.crypto.full" package to "org.openjdk.bench.javax.crypto". It is supposed to have only public API micros in packages "small" and "full"

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

PR Comment: https://git.openjdk.org/jdk/pull/28136#issuecomment-3554914771

From jiangli at openjdk.org  Thu Nov 20 04:59:20 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Nov 2025 04:59:20 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v2]
In-Reply-To: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
Message-ID: <At8kmcmDpaPcrjddF7kZKGsQA5OjPDqGG6v6hN_qg2E=.60adcc90-4b7f-456f-bce3-f029a6f6c1c3@github.com>

> Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 
> 
> Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!

Jiangli Zhou has updated the pull request incrementally with four additional commits since the last revision:

 - Address shipilev coments:
   - Replace time-bound loop with an iteration of three runs.
   - Add encrypt part and check to make sure the encrypted message is the same as the original.
 - Address shipilev's comments:
   - Rename test to TestGCMSplitBound.java
   - Change test range to [SPLIT_LEN - 300; SPLIT_LEN + 300].
 - Stylistic change: '256' to '16 * 16'.
 - Fix indentation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28363/files
  - new: https://git.openjdk.org/jdk/pull/28363/files/338a99d0..f1e7291b

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

  Stats: 249 lines in 3 files changed: 135 ins; 113 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28363.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28363/head:pull/28363

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

From jiangli at openjdk.org  Thu Nov 20 05:06:58 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Nov 2025 05:06:58 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v3]
In-Reply-To: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
Message-ID: <wZ2NUDH7x5GsfxHuAxyMzq9sChUTGW3IMjKB4e-Pwk4=.76a8939b-a53a-4186-87dd-688b3332de78@github.com>

> Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 
> 
> Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Fix Whitespace error.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28363/files
  - new: https://git.openjdk.org/jdk/pull/28363/files/f1e7291b..528b1b47

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

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

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

From jiangli at openjdk.org  Thu Nov 20 05:06:58 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Nov 2025 05:06:58 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v3]
In-Reply-To: <Vx1My0nkw2LYZ3KROxyhFCTfiV-6LTcB-8b5o1hsc9g=.c2805316-3c6e-4236-b938-c708eb35be08@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
 <Vx1My0nkw2LYZ3KROxyhFCTfiV-6LTcB-8b5o1hsc9g=.c2805316-3c6e-4236-b938-c708eb35be08@github.com>
Message-ID: <RUsYAij2_Wi2DLz2Wm_JLVA4rPj_BL-9wUk7azY0PVM=.fe0dadd5-bad8-49c6-a29a-607419e0d564@github.com>

On Tue, 18 Nov 2025 08:33:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Whitespace error.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 3530:
> 
>> 3528:   __ bind(MESG_BELOW_32_BLKS);
>> 3529:   __ subl(len, 16 * 16);
>> 3530:   __ cmpl(len, 256);
> 
> From the stylistic logic, this should be written as `16 * 16`, to match the surrounding `subl` and `addl`.

Thanks for the detailed review, @shipilev! Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2544340100

From jiangli at openjdk.org  Thu Nov 20 05:06:59 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Nov 2025 05:06:59 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v3]
In-Reply-To: <uygPZR0JaXYGUkOoKX1-Zi0e-dbp64H6W63trUDLfBM=.2a27b0e2-35f9-424b-9f83-149bf58236d0@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
 <uygPZR0JaXYGUkOoKX1-Zi0e-dbp64H6W63trUDLfBM=.2a27b0e2-35f9-424b-9f83-149bf58236d0@github.com>
Message-ID: <QowCo5q5k_E3MLe15xtunjCrX3bILgmUyL3WoAS89Ck=.22021c83-8b92-4610-a5a2-31c993c5609e@github.com>

On Tue, 18 Nov 2025 06:17:30 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Whitespace error.
>
> test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 41:
> 
>> 39: public class TestAesGcmIntrinsic {
>> 40: 
>> 41:   static final SecureRandom SECURE_RANDOM = newDefaultSecureRandom();
> 
> Drive-by comment: Java code should use 4x whitespace indentation.

@TobiHartmann, thanks! Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2544338893

From jiangli at openjdk.org  Thu Nov 20 05:12:24 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Nov 2025 05:12:24 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v3]
In-Reply-To: <Vx1My0nkw2LYZ3KROxyhFCTfiV-6LTcB-8b5o1hsc9g=.c2805316-3c6e-4236-b938-c708eb35be08@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
 <Vx1My0nkw2LYZ3KROxyhFCTfiV-6LTcB-8b5o1hsc9g=.c2805316-3c6e-4236-b938-c708eb35be08@github.com>
Message-ID: <zcQXkgyWrwyfWoTLo62dQ8Vd-C5p4fybNEgMVaG5JPo=.ed168faf-f862-49ee-bfed-912d12b5fab1@github.com>

On Tue, 18 Nov 2025 08:53:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Whitespace error.
>
> test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 39:
> 
>> 37: import javax.crypto.spec.SecretKeySpec;
>> 38: 
>> 39: public class TestAesGcmIntrinsic {
> 
> This sounds like `TestGCMSplitBound` or some such; it is not a generic test for AES/GCM intrinsic.

I renamed to TestAesGcmIntrinsic name, when converting the original test into the jtreg test. `TestGCMSplitBound` SGTM. Changed.

> test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 93:
> 
>> 91:       }
>> 92:     }
>> 93:     for (int messageSize = SPLIT_LEN; messageSize < SPLIT_LEN + 300; messageSize++) {
> 
> `[SPLIT_LEN - 300; SPLIT_LEN + 300]` for completeness, perhaps?

Done.

> test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 96:
> 
>> 94:       byte[] message = randBytes(messageSize);
>> 95:       try {
>> 96:         byte[] ciphertext = gcmEncrypt(key, message, aad);
> 
> I believe it makes sense to check that round-trip is successful, e.g. that `decrypt(encrypt(message)) == message`. Currently we implicitly rely on exceptions being thrown from the incorrectly executing code, which is IMO too weak -- in the boundary conditions like these, there might be bugs that _do not_ manifest in visible exceptions, and just the encryption is subtly broken.

That's a good idea. I added decrypt part and the check as suggested.

> test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 109:
> 
>> 107:     TestAesGcmIntrinsic test = new TestAesGcmIntrinsic();
>> 108:     long startTime = System.currentTimeMillis();
>> 109:     while (System.currentTimeMillis() - startTime < 60 * 1000) {
> 
> I get that you want a stress test. But time-limiting puts the test into weird condition: it can have different number of iterations, depending on auxiliary load on the machine. These tests are running in parallel with lots of other tests, so it is not uncommon. Do you even need to repeat `jitFunc()` call multiple times? Looks like it traverses the interesting configurations in one go?

I did some testing today. For 200 runs, removing the time-limited loop, there is 89 runs out of 200 fail. So I changed to use an iteration of three runs, all 200 runs fail without the fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2544352236
PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2544352547
PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2544348398
PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2544346000

From jiangli at openjdk.org  Thu Nov 20 05:12:25 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Nov 2025 05:12:25 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v3]
In-Reply-To: <zcQXkgyWrwyfWoTLo62dQ8Vd-C5p4fybNEgMVaG5JPo=.ed168faf-f862-49ee-bfed-912d12b5fab1@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
 <Vx1My0nkw2LYZ3KROxyhFCTfiV-6LTcB-8b5o1hsc9g=.c2805316-3c6e-4236-b938-c708eb35be08@github.com>
 <zcQXkgyWrwyfWoTLo62dQ8Vd-C5p4fybNEgMVaG5JPo=.ed168faf-f862-49ee-bfed-912d12b5fab1@github.com>
Message-ID: <osVEvShHyGy1aZQtaQUB7geq7JOJ4_XBSZUaUTgkJ1M=.fc8f0aee-48d5-4a8b-8be3-9221c20eadde@github.com>

On Thu, 20 Nov 2025 05:06:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 96:
>> 
>>> 94:       byte[] message = randBytes(messageSize);
>>> 95:       try {
>>> 96:         byte[] ciphertext = gcmEncrypt(key, message, aad);
>> 
>> I believe it makes sense to check that round-trip is successful, e.g. that `decrypt(encrypt(message)) == message`. Currently we implicitly rely on exceptions being thrown from the incorrectly executing code, which is IMO too weak -- in the boundary conditions like these, there might be bugs that _do not_ manifest in visible exceptions, and just the encryption is subtly broken.
>
> That's a good idea. I added decrypt part and the check as suggested.

With the changes, there were more common parts in the test. I moved common code into helper methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2544350223

From jiangli at openjdk.org  Thu Nov 20 05:16:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Nov 2025 05:16:56 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v3]
In-Reply-To: <Vx1My0nkw2LYZ3KROxyhFCTfiV-6LTcB-8b5o1hsc9g=.c2805316-3c6e-4236-b938-c708eb35be08@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
 <Vx1My0nkw2LYZ3KROxyhFCTfiV-6LTcB-8b5o1hsc9g=.c2805316-3c6e-4236-b938-c708eb35be08@github.com>
Message-ID: <E4MHQ1QCLhekWzmWuTbTO_uDUXvtRcpllT2WBYraZMs=.c2dc308d-c1ea-4f8e-9272-8f0bd9f76abb@github.com>

On Tue, 18 Nov 2025 08:57:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Whitespace error.
>
> test/jdk/com/sun/crypto/provider/Cipher/AES/TestAesGcmIntrinsic.java line 41:
> 
>> 39: public class TestAesGcmIntrinsic {
>> 40: 
>> 41:   static final SecureRandom SECURE_RANDOM = newDefaultSecureRandom();
> 
> Do you really need a `SecureRandom` here? `Random RANDOM = Utils.getRandomInstance();` gets you the pre-seeded random instance, which can be used to repeatably reproduce failures.

I kept the `SecureRandom` without changing. I think that could be more related to what the original reproducible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2544361801

From coffeys at openjdk.org  Thu Nov 20 07:33:18 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 20 Nov 2025 07:33:18 GMT
Subject: RFR: 8372004: Have SSLLogger implement System.Logger [v3]
In-Reply-To: <FpAvU1fJcJACeVnk-RFF59WPJ4qEyn9Sg6tZODCFvMQ=.df34e19a-6a96-476b-b256-a24a5cf8be2e@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
 <FpAvU1fJcJACeVnk-RFF59WPJ4qEyn9Sg6tZODCFvMQ=.df34e19a-6a96-476b-b256-a24a5cf8be2e@github.com>
Message-ID: <b_fj4VTjkVKBR0F68EKUO5f4mSmpdO65x1XAxIo_XKo=.1974b428-dc63-4ba7-bfe4-571e5d6cb793@github.com>

On Tue, 18 Nov 2025 16:48:48 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> `SSLLogger` utilizes `System.Logger` if the `javax.net.debug` system property key value is empty. However, since that class doesn't implement `SSLogger`, it misses the advantage of highlighting the exact calling site for each log statement.  Having `SSLLogger `simply implement `System.Logger` fixes this
>> 
>> I've also taken this opportunity to refractor the `isOn` boolean in `SSLLogger`. Encapsulated that boolean in a new method which callers can now use. I also used `ForceInline` directory on that method. Thanks to @dfuch for suggestions on that front.
>> 
>> Also updated an existing unit testcase to test for the new functionality
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments from Daniel

Thanks for the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/28376#issuecomment-3556351553

From coffeys at openjdk.org  Thu Nov 20 07:34:52 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 20 Nov 2025 07:34:52 GMT
Subject: Integrated: 8372004: Have SSLLogger implement System.Logger
In-Reply-To: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
References: <-hp5LP_NxTIKnFM8XkcvA-z239PGKtNeuGVZ1gjl3Sw=.185229ed-ff58-4fa6-8c30-fca1eb3a156c@github.com>
Message-ID: <DpUHLqxSD42XXA89ZHMcstjQ68xkU0c1-kZN8Tn6u18=.b1fb6660-e20d-4a13-8c81-c49a268ce0e4@github.com>

On Tue, 18 Nov 2025 15:50:42 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> `SSLLogger` utilizes `System.Logger` if the `javax.net.debug` system property key value is empty. However, since that class doesn't implement `SSLogger`, it misses the advantage of highlighting the exact calling site for each log statement.  Having `SSLLogger `simply implement `System.Logger` fixes this
> 
> I've also taken this opportunity to refractor the `isOn` boolean in `SSLLogger`. Encapsulated that boolean in a new method which callers can now use. I also used `ForceInline` directory on that method. Thanks to @dfuch for suggestions on that front.
> 
> Also updated an existing unit testcase to test for the new functionality

This pull request has now been integrated.

Changeset: 852141b9
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/852141b9d42ada168a008aea63045deddca29190
Stats:     840 lines in 80 files changed: 43 ins; 42 del; 755 mod

8372004: Have SSLLogger implement System.Logger

Reviewed-by: dfuchs, weijun

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

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

From dfuchs at openjdk.org  Thu Nov 20 12:26:21 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:21 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v2]
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <fbZzaZTDoy8CE5Q-391sOVBezopxpDa7ggDCKJ2R3po=.cac468b3-953b-491f-8bb5-05b3222db78b@github.com>

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

Daniel Fuchs 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 'SelectorManagerVT-8372159' into ConnectionCloseLock-8372198
 - 8372198: Avoid closing PlainHttpConnection while holding a lock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28421/files
  - new: https://git.openjdk.org/jdk/pull/28421/files/177e7ee3..97ce3737

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

  Stats: 19751 lines in 348 files changed: 10987 ins; 5712 del; 3052 mod
  Patch: https://git.openjdk.org/jdk/pull/28421.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28421/head:pull/28421

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

From dfuchs at openjdk.org  Thu Nov 20 12:26:22 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:22 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <BEkaPOGOa8LRlqic4jsZvlx97AR8RVfNhjk5_1Kvips=.741bab98-7b90-4f2c-aadc-c93d62650091@github.com>

On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

Something went wrong when I tried to merge the main PR branch in the dependent PR branch. I'm going to withdraw this PR and start again.

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

PR Comment: https://git.openjdk.org/jdk/pull/28421#issuecomment-3557752299

From dfuchs at openjdk.org  Thu Nov 20 12:26:23 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:23 GMT
Subject: Withdrawn: 8372198: Avoid closing PlainHttpConnection while holding a
 lock
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <S8TUGJh8rmGEbyRwrMCP7SaPKA6HJG8O_HHX17gFyDw=.2eb7031f-a01d-42d1-8efc-1b49466b48dc@github.com>

On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu Nov 20 14:21:20 2025
From: duke at openjdk.org (Neha Joshi)
Date: Thu, 20 Nov 2025 14:21:20 GMT
Subject: RFR: 8362658: sun/security/ssl/SSLEngineImpl/* tests duplicate jvm
 flags
Message-ID: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>

In this PR we have updated the code to remove the duplicate call and ensure JVM flags are added only once.

### ISSUE :- 
In the test case --> ProcessTools.createTestJavaProcessBuilder(Utils.addTestJavaOpts("SSLEngineKeyLimit", "p", args[1], args[2]));
    
-> Before executing ProcessTools.createTestJavaProcessBuilder() we are calling  ---> Utils.addTestJavaOpts() which internally call prependTestJavaOpts();

>   public static String[] addTestJavaOpts(String... userArgs) {
>         return prependTestJavaOpts(userArgs);
>     }

-> Then again inside ProcessTools.createTestJavaProcessBuilder() method we are calling Utils.prependTestJavaOpts()

> public static ProcessBuilder createTestJavaProcessBuilder(String... command) {
>         return createJavaProcessBuilder(Utils.prependTestJavaOpts(command));
>     }


Calling Utils.prependTestJavaOpts() twice leads to duplicate JVM flags (This method call-> getTestJavaOpts() the main reason for duplication and below is the implementation for the same. )

> public static String[] getTestJavaOpts() {
>         List<String> opts = new ArrayList<String>();
>         Collections.addAll(opts, safeSplitString(VM_OPTIONS));
>         Collections.addAll(opts, safeSplitString(JAVA_OPTIONS));
>         return opts.toArray(new String[0]);
>     }

Contributed-by: @Korov 
https://github.com/openjdk/jdk/pull/26404

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

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

Commit messages:
 - JDK-8362658 : Added back the space.
 - Merge branch 'openjdk:master' into JDK-8362658/Open/Duplicate_JVM_flags
 - JDK-8362658 : Updated copyright and removed unused import.
 - JDK-8362658 : Updated code to remove duplicate jvm flags.

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

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

From weijun at openjdk.org  Thu Nov 20 15:20:36 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 20 Nov 2025 15:20:36 GMT
Subject: Integrated: 8325448: Hybrid Public Key Encryption
In-Reply-To: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
Message-ID: <L7YfilP8Z1BydIYjrf4dCATiC89BVlaY0zW9ItWhH9A=.3d465427-be0a-46b1-a38b-30076ea875f8@github.com>

On Wed, 20 Mar 2024 20:43:04 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> <img alt="image" src="https://github.com/user-attachments/assets/df3b454d-2161-4036-9930-c4f84d887b31" />

This pull request has now been integrated.

Changeset: 45a2fd37
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45a2fd37f0ebda35789006b4e607422f7c369017
Stats:     2205 lines in 12 files changed: 1975 ins; 85 del; 145 mod

8325448: Hybrid Public Key Encryption

Reviewed-by: mullan, ascarpino, abarashev

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

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

From mdonovan at openjdk.org  Thu Nov 20 16:39:54 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 20 Nov 2025 16:39:54 GMT
Subject: RFR: 8362658: sun/security/ssl/SSLEngineImpl/* tests duplicate jvm
 flags
In-Reply-To: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
References: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
Message-ID: <RoHVYrF8505LwfbrOnF4Qj9USJMMrHya1hmWay9eQaE=.16c69228-e421-4991-98cb-32749e68ba4b@github.com>

On Thu, 20 Nov 2025 13:05:44 GMT, Neha Joshi <duke at openjdk.org> wrote:

> In this PR we have updated the code to remove the duplicate call and ensure JVM flags are added only once.
> 
> ### ISSUE :- 
> In the test case --> ProcessTools.createTestJavaProcessBuilder(Utils.addTestJavaOpts("SSLEngineKeyLimit", "p", args[1], args[2]));
>     
> -> Before executing ProcessTools.createTestJavaProcessBuilder() we are calling  ---> Utils.addTestJavaOpts() which internally call prependTestJavaOpts();
> 
>>   public static String[] addTestJavaOpts(String... userArgs) {
>>         return prependTestJavaOpts(userArgs);
>>     }
> 
> -> Then again inside ProcessTools.createTestJavaProcessBuilder() method we are calling Utils.prependTestJavaOpts()
> 
>> public static ProcessBuilder createTestJavaProcessBuilder(String... command) {
>>         return createJavaProcessBuilder(Utils.prependTestJavaOpts(command));
>>     }
> 
> 
> Calling Utils.prependTestJavaOpts() twice leads to duplicate JVM flags (This method call-> getTestJavaOpts() the main reason for duplication and below is the implementation for the same. )
> 
>> public static String[] getTestJavaOpts() {
>>         List<String> opts = new ArrayList<String>();
>>         Collections.addAll(opts, safeSplitString(VM_OPTIONS));
>>         Collections.addAll(opts, safeSplitString(JAVA_OPTIONS));
>>         return opts.toArray(new String[0]);
>>     }
> 
> Contributed-by: @Korov 
> https://github.com/openjdk/jdk/pull/26404
> 
> https://bugs.openjdk.org/browse/JDK-8362658

test/jdk/sun/security/ssl/SSLEngineImpl/SSLEngineKeyLimit.java line 120:

> 118:                     System.getProperty("test.java.opts"));
> 119: 
> 120:             ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder("SSLEngineKeyLimit", "p", args[1], args[2]);

Looks good to me, but try not to overstep the 80 character line-width

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28428#discussion_r2546792171

From duke at openjdk.org  Thu Nov 20 16:50:14 2025
From: duke at openjdk.org (Neha Joshi)
Date: Thu, 20 Nov 2025 16:50:14 GMT
Subject: RFR: 8362658: sun/security/ssl/SSLEngineImpl/* tests duplicate jvm
 flags [v2]
In-Reply-To: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
References: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
Message-ID: <Dc6dUv7eiMYw8qComOE5veYyjskRRFi6k-lFw2kABrc=.4b1945eb-5199-4b67-869e-75133fb342ec@github.com>

> In this PR we have updated the code to remove the duplicate call and ensure JVM flags are added only once.
> 
> ### ISSUE :- 
> In the test case --> ProcessTools.createTestJavaProcessBuilder(Utils.addTestJavaOpts("SSLEngineKeyLimit", "p", args[1], args[2]));
>     
> -> Before executing ProcessTools.createTestJavaProcessBuilder() we are calling  ---> Utils.addTestJavaOpts() which internally call prependTestJavaOpts();
> 
>>   public static String[] addTestJavaOpts(String... userArgs) {
>>         return prependTestJavaOpts(userArgs);
>>     }
> 
> -> Then again inside ProcessTools.createTestJavaProcessBuilder() method we are calling Utils.prependTestJavaOpts()
> 
>> public static ProcessBuilder createTestJavaProcessBuilder(String... command) {
>>         return createJavaProcessBuilder(Utils.prependTestJavaOpts(command));
>>     }
> 
> 
> Calling Utils.prependTestJavaOpts() twice leads to duplicate JVM flags (This method call-> getTestJavaOpts() the main reason for duplication and below is the implementation for the same. )
> 
>> public static String[] getTestJavaOpts() {
>>         List<String> opts = new ArrayList<String>();
>>         Collections.addAll(opts, safeSplitString(VM_OPTIONS));
>>         Collections.addAll(opts, safeSplitString(JAVA_OPTIONS));
>>         return opts.toArray(new String[0]);
>>     }
> 
> Contributed-by: @Korov 
> https://github.com/openjdk/jdk/pull/26404
> 
> https://bugs.openjdk.org/browse/JDK-8362658

Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8362658 : Reformat code to comply with 80-character line length limit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28428/files
  - new: https://git.openjdk.org/jdk/pull/28428/files/3b6c8d4a..60bc1d76

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

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

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

From duke at openjdk.org  Thu Nov 20 16:50:17 2025
From: duke at openjdk.org (Neha Joshi)
Date: Thu, 20 Nov 2025 16:50:17 GMT
Subject: RFR: 8362658: sun/security/ssl/SSLEngineImpl/* tests duplicate jvm
 flags [v2]
In-Reply-To: <RoHVYrF8505LwfbrOnF4Qj9USJMMrHya1hmWay9eQaE=.16c69228-e421-4991-98cb-32749e68ba4b@github.com>
References: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
 <RoHVYrF8505LwfbrOnF4Qj9USJMMrHya1hmWay9eQaE=.16c69228-e421-4991-98cb-32749e68ba4b@github.com>
Message-ID: <Q4uBlmSgRkuFL0hrkLGwEThXPJY_TponYvh7y_WCJr8=.e40374ca-b351-4830-9828-211e43d2a10d@github.com>

On Thu, 20 Nov 2025 16:36:29 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8362658 : Reformat code to comply with 80-character line length limit
>
> test/jdk/sun/security/ssl/SSLEngineImpl/SSLEngineKeyLimit.java line 120:
> 
>> 118:                     System.getProperty("test.java.opts"));
>> 119: 
>> 120:             ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder("SSLEngineKeyLimit", "p", args[1], args[2]);
> 
> Looks good to me, but try not to overstep the 80 character line-width

I have updated the code .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28428#discussion_r2546830635

From mdonovan at openjdk.org  Thu Nov 20 16:53:52 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 20 Nov 2025 16:53:52 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints
In-Reply-To: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
Message-ID: <c4rWfW4ChGNp8Wzvvba3BXvPJRqYEph3TO1GXq-iqo8=.7dfff585-48c0-44d2-9cf9-b03f5fbbd4de@github.com>

On Wed, 19 Nov 2025 17:26:25 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

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

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 751:

> 749: 
> 750:                 // Primary NIST Suite B curves
> 751:                 SECP256_R1,

Just curious why you use the '_' instead of just SECP256R1?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28397#discussion_r2546828854

From duke at openjdk.org  Thu Nov 20 16:56:53 2025
From: duke at openjdk.org (Neha Joshi)
Date: Thu, 20 Nov 2025 16:56:53 GMT
Subject: RFR: 8362658: sun/security/ssl/SSLEngineImpl/* tests duplicate jvm
 flags [v3]
In-Reply-To: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
References: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
Message-ID: <AIJsq22-FFJSTlQR79KsY_8tptAbtdTtqEM1Ggj-N70=.219565b8-cb49-4682-9602-5647bd899ecc@github.com>

> In this PR we have updated the code to remove the duplicate call and ensure JVM flags are added only once.
> 
> ### ISSUE :- 
> In the test case --> ProcessTools.createTestJavaProcessBuilder(Utils.addTestJavaOpts("SSLEngineKeyLimit", "p", args[1], args[2]));
>     
> -> Before executing ProcessTools.createTestJavaProcessBuilder() we are calling  ---> Utils.addTestJavaOpts() which internally call prependTestJavaOpts();
> 
>>   public static String[] addTestJavaOpts(String... userArgs) {
>>         return prependTestJavaOpts(userArgs);
>>     }
> 
> -> Then again inside ProcessTools.createTestJavaProcessBuilder() method we are calling Utils.prependTestJavaOpts()
> 
>> public static ProcessBuilder createTestJavaProcessBuilder(String... command) {
>>         return createJavaProcessBuilder(Utils.prependTestJavaOpts(command));
>>     }
> 
> 
> Calling Utils.prependTestJavaOpts() twice leads to duplicate JVM flags (This method call-> getTestJavaOpts() the main reason for duplication and below is the implementation for the same. )
> 
>> public static String[] getTestJavaOpts() {
>>         List<String> opts = new ArrayList<String>();
>>         Collections.addAll(opts, safeSplitString(VM_OPTIONS));
>>         Collections.addAll(opts, safeSplitString(JAVA_OPTIONS));
>>         return opts.toArray(new String[0]);
>>     }
> 
> Contributed-by: @Korov 
> https://github.com/openjdk/jdk/pull/26404
> 
> https://bugs.openjdk.org/browse/JDK-8362658

Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8362658 : Reformat code to comply with 80-character line length limit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28428/files
  - new: https://git.openjdk.org/jdk/pull/28428/files/60bc1d76..a0cc39e9

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

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

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

From abarashev at openjdk.org  Thu Nov 20 17:14:58 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 20 Nov 2025 17:14:58 GMT
Subject: RFR: 8370885: Default namedGroups values are not being filtered
 against algorithm constraints
In-Reply-To: <c4rWfW4ChGNp8Wzvvba3BXvPJRqYEph3TO1GXq-iqo8=.7dfff585-48c0-44d2-9cf9-b03f5fbbd4de@github.com>
References: <ZOkUaAh3IYaJp62axcK9vTyWueXFuLESOsJbvNFdRUY=.b0153d89-5217-400f-98a9-620d348f58ee@github.com>
 <c4rWfW4ChGNp8Wzvvba3BXvPJRqYEph3TO1GXq-iqo8=.7dfff585-48c0-44d2-9cf9-b03f5fbbd4de@github.com>
Message-ID: <jOAQFhfJ2ppAy5ZG4a9Iddtd5Qv4Qh3bZ2DemdAw470=.c3c6a454-1a8f-49e3-8c9d-5c1a0b758eae@github.com>

On Thu, 20 Nov 2025 16:46:21 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> NamedGroup.SupportedGroups.namedGroups values are not being filtered against algorithm constraints, unlike other SSLParameters returned by SSLConfiguration#getSSLParameters() call. Those are the values being displayed to the user with "java -XshowSettings:security:tls" command.
>> 
>> Also making changes to avoid needless default group names lookup while we are touching this file.
>
> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 751:
> 
>> 749: 
>> 750:                 // Primary NIST Suite B curves
>> 751:                 SECP256_R1,
> 
> Just curious why you use the '_' instead of just SECP256R1?

I actually don't know, the enums were in this form starting with the first version of this file. I just moved the default values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28397#discussion_r2546920882

From mdonovan at openjdk.org  Thu Nov 20 17:17:06 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 20 Nov 2025 17:17:06 GMT
Subject: RFR: 8367326: Refactor PEM API tests requiring PEMRecord usage
In-Reply-To: <2Ow4JVXCRsN-a3SauMcH2lR-HTP-S8e_oNN4T3fxMg8=.7f14fabc-1fa8-4053-a588-c91701734856@github.com>
References: <2Ow4JVXCRsN-a3SauMcH2lR-HTP-S8e_oNN4T3fxMg8=.7f14fabc-1fa8-4053-a588-c91701734856@github.com>
Message-ID: <JUoStF_psxSmZfddLObkQ0HtCkHk4wppRs3FgpUxy-k=.0f41251f-8ff8-4281-b5c2-8c924c9e8458@github.com>

On Mon, 17 Nov 2025 16:56:03 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Changed to use PEM API: 
> * test/jdk/sun/security/validator/PKIXValAndRevCheckTests.java
> * test/jdk/sun/security/rsa/pss/PSSKeyCompatibility.java
> * test/jdk/sun/security/pkcs11/rsa/TestKeyFactory.java

test/jdk/sun/security/rsa/TestKeyFactory.java line 237:

> 235: 
> 236:     private static void test(KeyFactory kf, Key key) throws Exception {
> 237:         if (!key.getAlgorithm().equals("RSA")) {

I know you didn't add this if-statement, but it's weird that it (and the one in `testKey()`) exists. This is a test for RSA keys and the main method explicitly creates an RSA key pair generator. It seems to me that if this method is suddenly getting  a non-RSA key, that's something we'd like to know in the form of a test failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28356#discussion_r2546865150

From mdonovan at openjdk.org  Thu Nov 20 18:14:54 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 20 Nov 2025 18:14:54 GMT
Subject: Integrated: 8362894: PKCS12 KeyStore PBMAC1 interoperability testing
In-Reply-To: <vQ2xN_1fTfrUQKCDsrUDUhYOUc21Mpa_5Z9dvbRr9ZU=.e372c2e0-e7c4-4db4-a675-fa2a0c3625af@github.com>
References: <vQ2xN_1fTfrUQKCDsrUDUhYOUc21Mpa_5Z9dvbRr9ZU=.e372c2e0-e7c4-4db4-a675-fa2a0c3625af@github.com>
Message-ID: <yD8OojeiV9YsC-RQkNocIn35FUkvlYAwwig4xfUK8dU=.bbd9a376-ece3-42ae-8e12-8440fa12eed4@github.com>

On Wed, 5 Nov 2025 12:43:25 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> With the integration of JDK-8343232, this PR updates the Keytool/OpenSSL interop test to include a test case using PBMAC1.

This pull request has now been integrated.

Changeset: b3acc484
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b3acc4841f6d9c8fd484df68fd2882dab0aa1788
Stats:     33 lines in 3 files changed: 32 ins; 0 del; 1 mod

8362894: PKCS12 KeyStore PBMAC1 interoperability testing

Reviewed-by: rhalade

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

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

From shade at openjdk.org  Thu Nov 20 19:42:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Nov 2025 19:42:03 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v3]
In-Reply-To: <wZ2NUDH7x5GsfxHuAxyMzq9sChUTGW3IMjKB4e-Pwk4=.76a8939b-a53a-4186-87dd-688b3332de78@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
 <wZ2NUDH7x5GsfxHuAxyMzq9sChUTGW3IMjKB4e-Pwk4=.76a8939b-a53a-4186-87dd-688b3332de78@github.com>
Message-ID: <d8uGv7nwpQd4fzozwSd08eo7sUTuFmSPzqHYSkxle8A=.df61756a-8a56-4293-bad1-3ee2c1ef3b69@github.com>

On Thu, 20 Nov 2025 05:06:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 
>> 
>> Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Whitespace error.

test/jdk/com/sun/crypto/provider/Cipher/AES/TestGCMSplitBound.java line 59:

> 57:     private static final int TAG_SIZE_IN_BYTES = 16;
> 58: 
> 59:     private Cipher getCipher(final byte[] key, final byte[] aad, byte[] nonce)

Suggestion:

    private Cipher getCipher(final byte[] key, final byte[] aad, final byte[] nonce)

test/jdk/com/sun/crypto/provider/Cipher/AES/TestGCMSplitBound.java line 65:

> 63:             new GCMParameterSpec(8 * TAG_SIZE_IN_BYTES, nonce, 0, nonce.length);
> 64:         Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
> 65:         cipher.init(Cipher.ENCRYPT_MODE, keySpec, params);

Er. This is used from `gcmDecrypt`? How does it work without `Cipher.DECRYPT_MODE`?

test/jdk/com/sun/crypto/provider/Cipher/AES/TestGCMSplitBound.java line 89:

> 87:       System.arraycopy(ciphertext, 0, nonce, 0, IV_SIZE_IN_BYTES);
> 88:       Cipher cipher = getCipher(key, aad, nonce);
> 89:       return cipher.doFinal(ciphertext, IV_SIZE_IN_BYTES, ciphertext.length - IV_SIZE_IN_BYTES);

Indenting is still 2-space here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2547113559
PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2547438961
PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2547112755

From jiangli at openjdk.org  Thu Nov 20 20:03:32 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Nov 2025 20:03:32 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v4]
In-Reply-To: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
Message-ID: <YynKn-IeH4t1oBoQ8U9jEqU2YtqkFsc5lbhf3Qgv_R4=.954f8637-7453-4900-816b-bc39bca20157@github.com>

> Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 
> 
> Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28363/files
  - new: https://git.openjdk.org/jdk/pull/28363/files/528b1b47..e99a441b

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

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

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

From jiangli at openjdk.org  Thu Nov 20 20:03:35 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Nov 2025 20:03:35 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v3]
In-Reply-To: <d8uGv7nwpQd4fzozwSd08eo7sUTuFmSPzqHYSkxle8A=.df61756a-8a56-4293-bad1-3ee2c1ef3b69@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
 <wZ2NUDH7x5GsfxHuAxyMzq9sChUTGW3IMjKB4e-Pwk4=.76a8939b-a53a-4186-87dd-688b3332de78@github.com>
 <d8uGv7nwpQd4fzozwSd08eo7sUTuFmSPzqHYSkxle8A=.df61756a-8a56-4293-bad1-3ee2c1ef3b69@github.com>
Message-ID: <K6wSZH29PANE_zz3CJiGUTiuRhz0srgkZN8xyS-1Y90=.d1bb8cce-c01e-42f7-b831-fcaa9bf0b5f8@github.com>

On Thu, 20 Nov 2025 18:08:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Whitespace error.
>
> test/jdk/com/sun/crypto/provider/Cipher/AES/TestGCMSplitBound.java line 89:
> 
>> 87:       System.arraycopy(ciphertext, 0, nonce, 0, IV_SIZE_IN_BYTES);
>> 88:       Cipher cipher = getCipher(key, aad, nonce);
>> 89:       return cipher.doFinal(ciphertext, IV_SIZE_IN_BYTES, ciphertext.length - IV_SIZE_IN_BYTES);
> 
> Indenting is still 2-space here.

Indeed. Fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2547495799

From jiangli at openjdk.org  Thu Nov 20 20:10:00 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Nov 2025 20:10:00 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v5]
In-Reply-To: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
Message-ID: <05tqW1f2I7vfUwOz5JmZLKK7ztECI4GCbzhzHH3ktKo=.106c1ad2-5d95-4fa0-a79e-e6a2751fadb4@github.com>

> Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 
> 
> Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/com/sun/crypto/provider/Cipher/AES/TestGCMSplitBound.java
  
  Applied, thanks.
  
  Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28363/files
  - new: https://git.openjdk.org/jdk/pull/28363/files/e99a441b..54fbf2b1

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

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

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

From sviswanathan at openjdk.org  Thu Nov 20 21:34:56 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 20 Nov 2025 21:34:56 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
 [v2]
In-Reply-To: <mzpPdK3E-jTbpaq-DfKQRGmc3WkHx8scm58ck2rpmBQ=.86b07f98-9464-494e-91a8-ccb843c57431@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
 <mzpPdK3E-jTbpaq-DfKQRGmc3WkHx8scm58ck2rpmBQ=.86b07f98-9464-494e-91a8-ccb843c57431@github.com>
Message-ID: <VwOfiPJyp6T_o2_5mlKPx0zvL-1msC7hQts1O_8IwL4=.d9188b3d-bd8f-46e2-8963-b874b33d6dc5@github.com>

On Mon, 17 Nov 2025 23:35:44 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> - New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
>>    - `SignatureBench.MLDSA` is 1.2x-2.2x faster
>>    - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
>> - AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
>>   - `SignatureBench.MLDSA` is upto 5% faster, never slower
>> 
>> Note on intrinsic:
>> - The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
>> - Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2
>> 
>> Tests and benchmarks:
>> - Added a fuzz test to ensure Java and intrinsic produces exactly same result
>> - Added benchmark to measure the performance of intrinsic itself
>> 
>> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
>> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
>> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
>> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"
>
> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - whitespace
>  - address first comments

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1283:

> 1281:     // r1 = r1 & quotient; // copy 0 or keep as is, using EqMsk as filter
> 1282:     for (int i = 0; i < regCnt; i++) {
> 1283:       // FIXME: replace with void evmovdqul(Address dst, KRegister mask, XMMRegister src, bool merge, int vector_len);?

Is the fixme a leftover?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2547729185

From vpaprotski at openjdk.org  Thu Nov 20 22:55:07 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 20 Nov 2025 22:55:07 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
 [v3]
In-Reply-To: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
Message-ID: <p0oIu_xLOpWGWbqsOn6U2HFesqwhpQWM-zwN1PNtlAU=.7407188e-02ba-4cbd-86a7-b215e0fee819@github.com>

> - New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
>    - `SignatureBench.MLDSA` is 1.2x-2.2x faster
>    - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
> - AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
>   - `SignatureBench.MLDSA` is upto 5% faster, never slower
> 
> Note on intrinsic:
> - The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
> - Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2
> 
> Tests and benchmarks:
> - Added a fuzz test to ensure Java and intrinsic produces exactly same result
> - Added benchmark to measure the performance of intrinsic itself
> 
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  next set of comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28136/files
  - new: https://git.openjdk.org/jdk/pull/28136/files/e9133401..b04f4f0d

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

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

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

From weijun at openjdk.org  Thu Nov 20 23:05:43 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 20 Nov 2025 23:05:43 GMT
Subject: RFR: 8371383: Test
 sun/security/tools/jarsigner/DefaultOptions.java failed due to
 CertificateNotYetValidException [v2]
In-Reply-To: <YtsuCvZB-UD5q3X3l5ttONj81fCkOvPykPHptODyBZM=.0fc346d9-5993-4af7-a4f1-a96327f0bdb6@github.com>
References: <bjzOva7DVF2_u5kSfMtgFy1Pw_fJ33sMNch3KNgq0p8=.f6abfa5d-023a-472b-ab49-d32ae2968cf3@github.com>
 <YtsuCvZB-UD5q3X3l5ttONj81fCkOvPykPHptODyBZM=.0fc346d9-5993-4af7-a4f1-a96327f0bdb6@github.com>
Message-ID: <xM8V6BOycoAJ0VuIgVYCy1D7Kcw41utSYJlqSJxZLR0=.e4791ce1-a4a5-4102-a7d8-724958c66632@github.com>

On Fri, 7 Nov 2025 15:14:34 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The `DefaultOptions.java` test may fail as the current system time is before the signing certificate NotBefore time, when jarsigner tool validates it in `CertificateValidity.valid()`. Please review the fix in this test to avoid such intermittent timing problem. Thanks.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update with Mikhail's comments

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28186#pullrequestreview-3490410465

From sviswanathan at openjdk.org  Thu Nov 20 23:09:54 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 20 Nov 2025 23:09:54 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
 [v3]
In-Reply-To: <p0oIu_xLOpWGWbqsOn6U2HFesqwhpQWM-zwN1PNtlAU=.7407188e-02ba-4cbd-86a7-b215e0fee819@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
 <p0oIu_xLOpWGWbqsOn6U2HFesqwhpQWM-zwN1PNtlAU=.7407188e-02ba-4cbd-86a7-b215e0fee819@github.com>
Message-ID: <OCUgLu8GObF-jodqL1fW0A9vKRRZ60MtZqz7iMKIZ2g=.ab9bad30-50cb-4c92-97cc-2587cb2fe2c9@github.com>

On Thu, 20 Nov 2025 22:55:07 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> - New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
>>    - `SignatureBench.MLDSA` is 1.2x-2.2x faster
>>    - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
>> - AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
>>   - `SignatureBench.MLDSA` is upto 5% faster, never slower
>> 
>> Note on intrinsic:
>> - The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
>> - Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2
>> 
>> Tests and benchmarks:
>> - Added a fuzz test to ensure Java and intrinsic produces exactly same result
>> - Added benchmark to measure the performance of intrinsic itself
>> 
>> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
>> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
>> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
>> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   next set of comments

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28136#pullrequestreview-3490441448

From hchao at openjdk.org  Thu Nov 20 23:15:16 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 20 Nov 2025 23:15:16 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v5]
In-Reply-To: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
Message-ID: <18r4Fq-WvHk4CBeoama0ATFXRiPNeQAt49nfJVufP2U=.ba980f7e-6235-4445-8a49-a5cfa3b02bf3@github.com>

> This PR improves security warning when using JKS or JCEKS keystores.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  separate debug.println output

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27624/files
  - new: https://git.openjdk.org/jdk/pull/27624/files/af301060..9f3d6ca4

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

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

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

From hchao at openjdk.org  Thu Nov 20 23:15:18 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 20 Nov 2025 23:15:18 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v4]
In-Reply-To: <SzMC1cV0fkG1Y5GoGWML1xNblev3Z5anqqkh5oM5u14=.2e1771a8-2260-4787-ac88-32d326fff2c2@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
 <OggDZsb-SB866nDVpcifh8EcgiFO64uszj7Oti7zwkg=.4bc8495f-3c4c-4bd0-8684-28ca61028196@github.com>
 <SzMC1cV0fkG1Y5GoGWML1xNblev3Z5anqqkh5oM5u14=.2e1771a8-2260-4787-ac88-32d326fff2c2@github.com>
Message-ID: <DiNbYenlwMEiNM2I-1sj0EiIboPe99Gf741gXiY7Pcs=.a5e18f0e-5e56-4fd8-8eca-7e0843053059@github.com>

On Tue, 18 Nov 2025 23:59:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed bugid from Compatibility.java test
>
> src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java line 996:
> 
>> 994:                 + "keytool -importkeystore -srckeystore <keystore> "
>> 995:                 + "-destkeystore <keystore> -deststoretype pkcs12");
>> 996:     }
> 
> Currently the debug output has a long prefix containing timestamp etc. If the warning is separated on two lines, does it make sense to call `debug.println` twice so both lines have the prefix?

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2548004556

From vpaprotski at openjdk.org  Thu Nov 20 23:17:36 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 20 Nov 2025 23:17:36 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
 [v2]
In-Reply-To: <uhxj2hdqykG7yecwrS7bT9E96D7yfS9AbaydQ0HrXgM=.03a7c1fd-2f6d-4ad3-aedb-c44ba116b8c3@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
 <mzpPdK3E-jTbpaq-DfKQRGmc3WkHx8scm58ck2rpmBQ=.86b07f98-9464-494e-91a8-ccb843c57431@github.com>
 <ISh_-trCqZ1D6chCaTQM93utbzuhyFV8gtJYYjcs6N0=.a601fd77-e9c8-459b-9527-c66fd74f7fb4@github.com>
 <LmXEMMWDEt2cxbnGrvnCf0634pBK5gOAEcvkopE2hY8=.6191991b-f1ab-4a9a-b96d-95258769bcca@github.com>
 <uhxj2hdqykG7yecwrS7bT9E96D7yfS9AbaydQ0HrXgM=.03a7c1fd-2f6d-4ad3-aedb-c44ba116b8c3@github.com>
Message-ID: <-NP71XXG0bisxVHds8O-uXhLZqbnVLijJoJDwVq2ZBk=.2478c442-fc34-4ba0-9811-1f910ee3ee36@github.com>

On Wed, 19 Nov 2025 22:40:41 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> I understand your reasons. The question is whether you'll need the microbenchmark in the future. If no (or probably no), please remove the micro. If needed, please move it from the "org.openjdk.bench.javax.crypto.full" package to "org.openjdk.bench.javax.crypto". It is supposed to have only public API micros in packages "small" and "full"

@kuksenko I decided to just remove it. If anyone wants it back, its in my git history (I usually keep my branches after merge..)

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

PR Comment: https://git.openjdk.org/jdk/pull/28136#issuecomment-3560569194

From vpaprotski at openjdk.org  Thu Nov 20 23:17:39 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 20 Nov 2025 23:17:39 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
 [v2]
In-Reply-To: <VwOfiPJyp6T_o2_5mlKPx0zvL-1msC7hQts1O_8IwL4=.d9188b3d-bd8f-46e2-8963-b874b33d6dc5@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
 <mzpPdK3E-jTbpaq-DfKQRGmc3WkHx8scm58ck2rpmBQ=.86b07f98-9464-494e-91a8-ccb843c57431@github.com>
 <VwOfiPJyp6T_o2_5mlKPx0zvL-1msC7hQts1O_8IwL4=.d9188b3d-bd8f-46e2-8963-b874b33d6dc5@github.com>
Message-ID: <FWZ32sCfAcWfB7oYesUyX_uTOLnGuHxdSTErKgkvYeg=.1cd3f36a-aace-457b-b989-7e6e22526486@github.com>

On Thu, 20 Nov 2025 21:31:31 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - whitespace
>>  - address first comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1283:
> 
>> 1281:     // r1 = r1 & quotient; // copy 0 or keep as is, using EqMsk as filter
>> 1282:     for (int i = 0; i < regCnt; i++) {
>> 1283:       // FIXME: replace with void evmovdqul(Address dst, KRegister mask, XMMRegister src, bool merge, int vector_len);?
> 
> Is the fixme a leftover?

Yes. Removed. (I think I was considering merging this instruction with the storeXmm, but there really isnt a good way to do that)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28136#discussion_r2548005781

From duke at openjdk.org  Thu Nov 20 23:33:56 2025
From: duke at openjdk.org (duke)
Date: Thu, 20 Nov 2025 23:33:56 GMT
Subject: Withdrawn: 8328046: Need to keep leading zeros in TlsPremasterSecret
 of TLS1.3 DHKeyAgreement
In-Reply-To: <HFMfI-Mpd5KEUXNZ6qhyHs8UFRLDbZFBA1qvoWpQLqI=.c36c897d-6af8-4bc5-be99-fdcee492887d@github.com>
References: <HFMfI-Mpd5KEUXNZ6qhyHs8UFRLDbZFBA1qvoWpQLqI=.c36c897d-6af8-4bc5-be99-fdcee492887d@github.com>
Message-ID: <rTStKE9bhUKD-bFBt-qWAc4CkBoOHtIXDFeTNbsDi-4=.128b69b6-9299-47fc-95ec-615660fa6fc4@github.com>

On Wed, 17 Sep 2025 12:15:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> TLS 1.3 changed the way it generates the FFDHE shared secret. In TLS 1.2, the leading zeroes in the shared secret were stripped, and in TLS 1.3 the leading zeroes are preserved.
> 
> Thanks to the recent work in [JDK-8189441](https://bugs.openjdk.org/browse/JDK-8189441), we now have a new algorithm name `Generic` that can be used to generate a shared secret with the leading zeroes preserved.
> 
> This PR changes the TLS 1.3 handshake to use the new algorithm name. It also fixes a bug in PKCS11 Generic key derivation, and updates the existing tests to verify that the Generic algorithm doesn't strip leading zeroes.
> 
> I didn't add any tests to verify the correctness of the handshake. This can be verified using tlsfuzzer, see JBS for details.
> 
> Tier1-3 tests continue to pass. The `TestLeadingZeroesP11.java` test fails before the `P11KeyAgreement.java` changes, passes after.

This pull request has been closed without being integrated.

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

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

From kvn at openjdk.org  Thu Nov 20 23:42:49 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 20 Nov 2025 23:42:49 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v41]
In-Reply-To: <6X0yTDTtiqFsDrBW0tIcdAhq8zRXK6psy-gfHlH2PNE=.fb7a392e-b677-4511-a216-280b07792b99@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <b3RfdJx-hraCC8yjMkKtGsAS1RYFaNQOL_PLiQeCkKc=.7c34bb12-b395-498c-8335-8a53346135c5@github.com>
 <6X0yTDTtiqFsDrBW0tIcdAhq8zRXK6psy-gfHlH2PNE=.fb7a392e-b677-4511-a216-280b07792b99@github.com>
Message-ID: <WwDGIwWdneWhgLov45Vex-ELbr5e-ZoawGjEj5L1ghs=.9f1bfb3c-aaa3-456f-beef-9e87441e93c4@github.com>

On Tue, 2 Sep 2025 17:03:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cannot reset with withMethods
>
> New commit pushed. The `with` methods can no longer be used to "reset" a field to its default value, for example, calling `withInfo(new byte[0])` to remove the non-default info or `withAuthKey(null)` to revert to `mode_base`.
> 
> Reasons:
> 1. Allowing a default value might hide unintended empty user input.
> 2. It's hard to manage all the fields in an `HPKEParameterSpec` object and reuse it back and forth.

@wangweij  The test `com/sun/crypto/provider/Cipher/HPKE/KAT9180.java` is failing in [GHA testing](https://productionresultssa0.blob.core.windows.net/actions-results/32e65b6c-b1ac-48ff-a803-144e2ad596be/workflow-job-run-06ad5898-c5e3-548c-848e-37a2014b4ffd/logs/job/job-logs.txt?rsct=text%2Fplain&se=2025-11-20T23%3A41%3A13Z&sig=qlrh66IgmPSB1Z6ZmXgzp6BUJxGuJQN9Irn%2BJ6O%2B5AI%3D&ske=2025-11-21T09%3A10%3A09Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2025-11-20T21%3A10%3A09Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2025-11-05&sp=r&spr=https&sr=b&st=2025-11-20T23%3A31%3A08Z&sv=2025-11-05). I don't see you switched on GHA for this PR.

2025-11-20T17:09:45.5295330Z STDERR:
2025-11-20T17:09:45.5295892Z java.io.IOException: Cannot find the artifact rfc9180-test-vectors
2025-11-20T17:09:45.5296776Z 	at jdk.test.lib.artifacts.ArtifactResolver.fetchOne(ArtifactResolver.java:100)
2025-11-20T17:09:45.5298008Z 	at KAT9180.main(KAT9180.java:70)
2025-11-20T17:09:45.5298884Z 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
2025-11-20T17:09:45.5299927Z 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
2025-11-20T17:09:45.5300843Z 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
2025-11-20T17:09:45.5301722Z 	at java.base/java.lang.Thread.run(Thread.java:1516)
2025-11-20T17:09:45.5303159Z Caused by: jdk.test.lib.artifacts.ArtifactResolverException: Couldn't automatically resolve dependency for rfc9180-test-vectors
2025-11-20T17:09:45.5304417Z Please specify the location using jdk.test.lib.artifacts.rfc9180-test-vectors
2025-11-20T17:09:45.5305650Z 	at jdk.test.lib.artifacts.DefaultArtifactManager.resolve(DefaultArtifactManager.java:39)
2025-11-20T17:09:45.5306788Z 	at jdk.test.lib.artifacts.DefaultArtifactManager.resolve(DefaultArtifactManager.java:32)
2025-11-20T17:09:45.5307844Z 	at jdk.test.lib.artifacts.ArtifactResolver.resolve(ArtifactResolver.java:61)
2025-11-20T17:09:45.5308800Z 	at jdk.test.lib.artifacts.ArtifactResolver.fetchOne(ArtifactResolver.java:96)
2025-11-20T17:09:45.5309491Z 	... 5 more

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

PR Comment: https://git.openjdk.org/jdk/pull/18411#issuecomment-3560656178

From vlivanov at openjdk.org  Thu Nov 20 23:43:30 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 20 Nov 2025 23:43:30 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
 [v2]
In-Reply-To: <-NP71XXG0bisxVHds8O-uXhLZqbnVLijJoJDwVq2ZBk=.2478c442-fc34-4ba0-9811-1f910ee3ee36@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
 <mzpPdK3E-jTbpaq-DfKQRGmc3WkHx8scm58ck2rpmBQ=.86b07f98-9464-494e-91a8-ccb843c57431@github.com>
 <ISh_-trCqZ1D6chCaTQM93utbzuhyFV8gtJYYjcs6N0=.a601fd77-e9c8-459b-9527-c66fd74f7fb4@github.com>
 <LmXEMMWDEt2cxbnGrvnCf0634pBK5gOAEcvkopE2hY8=.6191991b-f1ab-4a9a-b96d-95258769bcca@github.com>
 <uhxj2hdqykG7yecwrS7bT9E96D7yfS9AbaydQ0HrXgM=.03a7c1fd-2f6d-4ad3-aedb-c44ba116b8c3@github.com>
 <-NP71XXG0bisxVHds8O-uXhLZqbnVLijJoJDwVq2ZBk=.2478c442-fc34-4ba0-9811-1f910ee3ee36@github.com>
Message-ID: <CynaaRv2Rd88-M6dqNmaBZRzof8iwhupQAFsu4bgy88=.a9ee5935-bce7-4dc7-b13d-8da43f1d8731@github.com>

On Thu, 20 Nov 2025 23:13:41 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> If anyone wants it back, its in my git history (I usually keep my branches after merge..)

You could put a comment with the link into JBS issue to make it easier to discover later. (Or just attach the source file there.)

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

PR Comment: https://git.openjdk.org/jdk/pull/28136#issuecomment-3560656214

From hchao at openjdk.org  Fri Nov 21 00:08:27 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 21 Nov 2025 00:08:27 GMT
Subject: Integrated: 8371383: Test
 sun/security/tools/jarsigner/DefaultOptions.java failed due to
 CertificateNotYetValidException
In-Reply-To: <bjzOva7DVF2_u5kSfMtgFy1Pw_fJ33sMNch3KNgq0p8=.f6abfa5d-023a-472b-ab49-d32ae2968cf3@github.com>
References: <bjzOva7DVF2_u5kSfMtgFy1Pw_fJ33sMNch3KNgq0p8=.f6abfa5d-023a-472b-ab49-d32ae2968cf3@github.com>
Message-ID: <SaRZyumE-A5sKp_tFD1QD2aIm2klvdLqyEWQuMu9DXs=.d2bcacae-ed67-4bc3-a790-e27601d990b3@github.com>

On Fri, 7 Nov 2025 05:55:34 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> The `DefaultOptions.java` test may fail as the current system time is before the signing certificate NotBefore time, when jarsigner tool validates it in `CertificateValidity.valid()`. Please review the fix in this test to avoid such intermittent timing problem. Thanks.

This pull request has now been integrated.

Changeset: 0972ba68
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0972ba681cdc81b77e9b4353db8ee835216d242e
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8371383: Test sun/security/tools/jarsigner/DefaultOptions.java failed due to CertificateNotYetValidException

Reviewed-by: weijun

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

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

From jiangli at openjdk.org  Fri Nov 21 00:14:20 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Nov 2025 00:14:20 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v6]
In-Reply-To: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
Message-ID: <uEYB-A8cEPydvKjtpQNDzs3mWHwBCf_tTtXYawTH7oU=.e5fe5f1d-30ab-452b-a94b-ff70f5d6a7d7@github.com>

> Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 
> 
> Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!

Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8371864' of ssh://github.com/jianglizhou/jdk into JDK-8371864
 - Use Cipher.DECRYPT_MODE for gcmDecrypt.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28363/files
  - new: https://git.openjdk.org/jdk/pull/28363/files/54fbf2b1..8617ab4c

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

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

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

From jiangli at openjdk.org  Fri Nov 21 00:18:00 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Nov 2025 00:18:00 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v3]
In-Reply-To: <d8uGv7nwpQd4fzozwSd08eo7sUTuFmSPzqHYSkxle8A=.df61756a-8a56-4293-bad1-3ee2c1ef3b69@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
 <wZ2NUDH7x5GsfxHuAxyMzq9sChUTGW3IMjKB4e-Pwk4=.76a8939b-a53a-4186-87dd-688b3332de78@github.com>
 <d8uGv7nwpQd4fzozwSd08eo7sUTuFmSPzqHYSkxle8A=.df61756a-8a56-4293-bad1-3ee2c1ef3b69@github.com>
Message-ID: <WgRJOfuKobP5fbFKi8NX9v83SEN9BnRk1WHZFL6Es44=.ab734229-e0b0-4657-91d6-a0d1a7ed4c05@github.com>

On Thu, 20 Nov 2025 19:37:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Whitespace error.
>
> test/jdk/com/sun/crypto/provider/Cipher/AES/TestGCMSplitBound.java line 65:
> 
>> 63:             new GCMParameterSpec(8 * TAG_SIZE_IN_BYTES, nonce, 0, nonce.length);
>> 64:         Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
>> 65:         cipher.init(Cipher.ENCRYPT_MODE, keySpec, params);
> 
> Er. This is used from `gcmDecrypt`? How does it work without `Cipher.DECRYPT_MODE`?

Good catch. Interestingly the test passed for me on my local machine. Fixed to use Cipher.DECRYPT_MODE when doing gcmDecrypt.

Also an interesting new finding, with the decrypted message verification, I see there are 2 failures out of 200 runs with AVX512. I'm filing a new issue on the specifically, so it can be investigated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28363#discussion_r2548112676

From weijun at openjdk.org  Fri Nov 21 00:44:02 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 21 Nov 2025 00:44:02 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v5]
In-Reply-To: <18r4Fq-WvHk4CBeoama0ATFXRiPNeQAt49nfJVufP2U=.ba980f7e-6235-4445-8a49-a5cfa3b02bf3@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
 <18r4Fq-WvHk4CBeoama0ATFXRiPNeQAt49nfJVufP2U=.ba980f7e-6235-4445-8a49-a5cfa3b02bf3@github.com>
Message-ID: <33xBC6LRdfCqYwBGKJFAILnZgqxsH1VErLHuV539eok=.07f89eec-83ff-45e7-a4f8-bd424abef0e6@github.com>

On Thu, 20 Nov 2025 23:15:16 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This PR improves security warning when using JKS or JCEKS keystores.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separate debug.println output

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27624#pullrequestreview-3490671200

From hchao at openjdk.org  Fri Nov 21 01:14:47 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 21 Nov 2025 01:14:47 GMT
Subject: Integrated: 8353749: Improve security warning when using JKS or JCEKS
 keystores
In-Reply-To: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
Message-ID: <GnPFoY6xhVGCoFRILTeRvXLEGtORjTIQNVkyKezk8I4=.f624329c-7833-4cad-9cf3-8a1b8587ebcd@github.com>

On Fri, 3 Oct 2025 16:26:13 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This PR improves security warning when using JKS or JCEKS keystores.

This pull request has now been integrated.

Changeset: c2ea75b8
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2ea75b81f74ff586fdd9c51168e8f4c7a7b2a6a
Stats:     319 lines in 9 files changed: 298 ins; 0 del; 21 mod

8353749: Improve security warning when using JKS or JCEKS keystores

Reviewed-by: weijun

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

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

From jiangli at openjdk.org  Fri Nov 21 01:31:39 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Nov 2025 01:31:39 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v7]
In-Reply-To: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
Message-ID: <gvxaARdApdqwLQcJTEI9XHbeKlup-8hQCPEKy0a4hCw=.5089cf98-e17a-48b2-981e-7ace6e49980f@github.com>

> Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 
> 
> Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Change to just create a byte array for 'nonce' without generating random data in gcmDecrypt. Suggested by AI.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28363/files
  - new: https://git.openjdk.org/jdk/pull/28363/files/8617ab4c..d26d0ee9

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

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

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

From rhalade at openjdk.org  Fri Nov 21 02:58:44 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 21 Nov 2025 02:58:44 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap
In-Reply-To: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
Message-ID: <M1w4JInUlIBAhEA4bi2-6fy0njJoUb56PtugDHSUbcg=.3658a6c5-db9b-46e4-ad6c-2b7b639f2c13@github.com>

On Thu, 16 Oct 2025 13:52:58 GMT, Neha Joshi <duke at openjdk.org> wrote:

> This PR contain changes to handle skipped exception for below test cases. 
> 
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27847#pullrequestreview-3490993749

From rhalade at openjdk.org  Fri Nov 21 03:15:53 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 21 Nov 2025 03:15:53 GMT
Subject: RFR: 8370942: test/jdk/java/security/Provider/NewInstance.java and
 /test/jdk/java/security/cert/CertStore/NoLDAP.java may skip without notifying
 [v6]
In-Reply-To: <-83ry1l8Rnw6JkZS_FRz5JVZMyzBluwkBQQ6eyLLIpQ=.b0eb3aaf-36cf-41af-a7fc-a4be363df579@github.com>
References: <7rUm5aB2NK9qyu1Utc2tW1mthmnQCrIBr0r08G6aOgQ=.26c62e6e-d4e2-4b62-8e8c-9a9113a82bc8@github.com>
 <-83ry1l8Rnw6JkZS_FRz5JVZMyzBluwkBQQ6eyLLIpQ=.b0eb3aaf-36cf-41af-a7fc-a4be363df579@github.com>
Message-ID: <5HQ3uTFn1y3i1NI99d_TB4KwB_bvI3ixkX6_y0aKuBA=.461fad3a-bb77-412e-9b79-fc7b4e5f72fa@github.com>

On Tue, 4 Nov 2025 15:29:32 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> This PR contain changes to handle skipped exception for below test cases.
>> 
>> -> test/jdk/java/security/cert/CertStore/NoLDAP.java
>> -> test/jdk/java/security/Provider/NewInstance.java
>> 
>> 
>> https://bugs.openjdk.org/browse/JDK-8370942
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8370942 : Updated skip exception message.

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28112#pullrequestreview-3491014264

From rhalade at openjdk.org  Fri Nov 21 03:26:01 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 21 Nov 2025 03:26:01 GMT
Subject: RFR: 8362658: sun/security/ssl/SSLEngineImpl/* tests duplicate jvm
 flags [v3]
In-Reply-To: <AIJsq22-FFJSTlQR79KsY_8tptAbtdTtqEM1Ggj-N70=.219565b8-cb49-4682-9602-5647bd899ecc@github.com>
References: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
 <AIJsq22-FFJSTlQR79KsY_8tptAbtdTtqEM1Ggj-N70=.219565b8-cb49-4682-9602-5647bd899ecc@github.com>
Message-ID: <AIKiayJXpfQ6bLl4GHqLA1vm5s3f-AWiSwuxHxum8UU=.06854059-38bb-42a8-a8da-482a2f605a33@github.com>

On Thu, 20 Nov 2025 16:56:53 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> In this PR we have updated the code to remove the duplicate call and ensure JVM flags are added only once.
>> 
>> ### ISSUE :- 
>> In the test case --> ProcessTools.createTestJavaProcessBuilder(Utils.addTestJavaOpts("SSLEngineKeyLimit", "p", args[1], args[2]));
>>     
>> -> Before executing ProcessTools.createTestJavaProcessBuilder() we are calling  ---> Utils.addTestJavaOpts() which internally call prependTestJavaOpts();
>> 
>>>   public static String[] addTestJavaOpts(String... userArgs) {
>>>         return prependTestJavaOpts(userArgs);
>>>     }
>> 
>> -> Then again inside ProcessTools.createTestJavaProcessBuilder() method we are calling Utils.prependTestJavaOpts()
>> 
>>> public static ProcessBuilder createTestJavaProcessBuilder(String... command) {
>>>         return createJavaProcessBuilder(Utils.prependTestJavaOpts(command));
>>>     }
>> 
>> 
>> Calling Utils.prependTestJavaOpts() twice leads to duplicate JVM flags (This method call-> getTestJavaOpts() the main reason for duplication and below is the implementation for the same. )
>> 
>>> public static String[] getTestJavaOpts() {
>>>         List<String> opts = new ArrayList<String>();
>>>         Collections.addAll(opts, safeSplitString(VM_OPTIONS));
>>>         Collections.addAll(opts, safeSplitString(JAVA_OPTIONS));
>>>         return opts.toArray(new String[0]);
>>>     }
>> 
>> Contributed-by: @Korov 
>> https://github.com/openjdk/jdk/pull/26404
>> 
>> https://bugs.openjdk.org/browse/JDK-8362658
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8362658 : Reformat code to comply with 80-character line length limit

LGTM. Also include an update to remove tests from ProblemList at https://github.com/openjdk/jdk/blob/master/test/jdk/ProblemList-jvmti-stress-agent.txt#L31

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

PR Comment: https://git.openjdk.org/jdk/pull/28428#issuecomment-3561156055