From djelinski at openjdk.org  Tue Jul  1 07:34:06 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 1 Jul 2025 07:34:06 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <zfAyPC-xmCsYT0LtOlVqaJN17hgFb8DZhWUP1rwbSWM=.571fc63f-d165-40b6-b374-d2ab743058f0@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <zfAyPC-xmCsYT0LtOlVqaJN17hgFb8DZhWUP1rwbSWM=.571fc63f-d165-40b6-b374-d2ab743058f0@github.com>
Message-ID: <VZ6AgfVBnh4Yx_Mu0CHn84G6gBJriDp0W6XBasxcBKU=.c4404433-31b0-4dae-a159-554440309ff2@github.com>

On Thu, 26 Jun 2025 17:34:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java line 49:
> 
>> 47:     static final ExtensionConsumer chOnLoadConsumer =
>> 48:             new CHKeyShareConsumer();
>> 49:     static final HandshakeAbsence chOnTradeAbsence =
> 
> Could we fix that one in mainline to remove this file from the PR?

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

> src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line 61:
> 
>> 59:     static final HandshakeConsumer chOnTradeConsumer =
>> 60:             new CHPreSharedKeyUpdate();
>> 61:     static final HandshakeAbsence chOnTradeAbsence =
> 
> Could we bring this change to mainline to remove this file from this PR?

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

> src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.java line 50:
> 
>> 48:     static final ExtensionConsumer chOnLoadConsumer =
>> 49:             new CHSupportedGroupsConsumer();
>> 50:     static final HandshakeAbsence chOnTradeAbsence =
> 
> Another one that could disappear if we fixed that typo in mainline first.
> @djelinski would you be willing to do that?

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

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2176646140
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2176645611
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2176645272

From djelinski at openjdk.org  Tue Jul  1 08:06:23 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 1 Jul 2025 08:06:23 GMT
Subject: RFR: 8361125: Fix typo in onTradAbsence
Message-ID: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>

Fix typo in `onTrad(e)Absence`

Tier1-3 tests continue to pass.

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

Commit messages:
 - Fix onTradAbsence typo

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

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

From myankelevich at openjdk.org  Tue Jul  1 10:02:01 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 1 Jul 2025 10:02:01 GMT
Subject: RFR: 8359340: KRB5 tests should protect themselves against random
 proxy selection
Message-ID: <Lrsnw9-J8YW-5-tkUGqnGVa4RskrKneeizXXpKZZlro=.b6b0e4cc-06fd-46af-8017-84a450c184e3@github.com>

1. KRB5 tests is now always selecting NO_PROXY. 
2. test cleanup

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

Commit messages:
 - 8359340: KRB5 tests should protect themselves against random proxy selection
 - Merge branch 'master' into JDK-8359340
 - test cleanup

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

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

From djelinski at openjdk.org  Tue Jul  1 11:16:58 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 1 Jul 2025 11:16:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <2uIlI67ZuXY_FGElLjUN1wcwoPSdVrQACgyVF7AEbfk=.624e0472-4a35-4c9a-aec8-cc02e28d5632@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/http3/frames/FramesDecoder.java line 143:

> 141:      * This method doesn't try to do any decoding.
> 142:      */
> 143:     public Http3Frame peek() {

This method is unused. I'll remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2177297533

From mullan at openjdk.org  Tue Jul  1 12:58:40 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 1 Jul 2025 12:58:40 GMT
Subject: RFR: 8361125: Fix typo in onTradAbsence
In-Reply-To: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
References: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
Message-ID: <sFEG2GtQd5lRB6Eoz25zCJIprWMNyUhVj627rhyNDmM=.27305195-dccc-4b49-aaed-765232a5f858@github.com>

On Tue, 1 Jul 2025 07:29:58 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix typo in `onTrad(e)Absence`
> 
> Tier1-3 tests continue to pass.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26059#pullrequestreview-2975331150

From shade at openjdk.org  Tue Jul  1 15:55:43 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 1 Jul 2025 15:55:43 GMT
Subject: RFR: 8361125: Fix typo in onTradAbsence
In-Reply-To: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
References: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
Message-ID: <qhaBNGLEIdYVupg1M6YHNPutOiYtvuVw6uZYJPkX1Z8=.bd85e065-e75a-4926-a0d4-63426c62ed70@github.com>

On Tue, 1 Jul 2025 07:29:58 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix typo in `onTrad(e)Absence`
> 
> Tier1-3 tests continue to pass.

Looks fine and trivial.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26059#pullrequestreview-2976035310

From hchao at openjdk.org  Tue Jul  1 16:26:39 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 1 Jul 2025 16:26:39 GMT
Subject: RFR: 8361125: Fix typo in onTradAbsence
In-Reply-To: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
References: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
Message-ID: <roSD1z8atwZ31rbPsZ7o3NnL-cREXS6XZ6B6Ztgw6IA=.33918dfa-d9f3-409e-92c9-629e3c5f713a@github.com>

On Tue, 1 Jul 2025 07:29:58 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix typo in `onTrad(e)Absence`
> 
> Tier1-3 tests continue to pass.

nit: copyright year update in a few files.

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

PR Comment: https://git.openjdk.org/jdk/pull/26059#issuecomment-3024725905

From djelinski at openjdk.org  Tue Jul  1 19:14:21 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 1 Jul 2025 19:14:21 GMT
Subject: RFR: 8361125: Fix typo in onTradAbsence [v2]
In-Reply-To: <sFEG2GtQd5lRB6Eoz25zCJIprWMNyUhVj627rhyNDmM=.27305195-dccc-4b49-aaed-765232a5f858@github.com>
References: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
 <sFEG2GtQd5lRB6Eoz25zCJIprWMNyUhVj627rhyNDmM=.27305195-dccc-4b49-aaed-765232a5f858@github.com>
Message-ID: <nVEOQs0IuRgRXzTJlwGOdcL52M1Zr0-Hz-3tZcrPI3o=.3383cec7-bf1c-40f8-98ab-078b095cbf3c@github.com>

On Tue, 1 Jul 2025 12:56:09 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright update
>
> Marked as reviewed by mullan (Reviewer).

Thanks @seanjmullan @shipilev @haimaychao for the reviews! Copyright updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/26059#issuecomment-3025216145

From djelinski at openjdk.org  Tue Jul  1 19:14:21 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 1 Jul 2025 19:14:21 GMT
Subject: RFR: 8361125: Fix typo in onTradAbsence [v2]
In-Reply-To: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
References: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
Message-ID: <0hYdxxsa1CU1MWyFPOefAvQNN5xxELmlAgWIhnL1nX4=.317e7b01-a6d7-4ab2-a654-fe5ca437c408@github.com>

> Fix typo in `onTrad(e)Absence`
> 
> Tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Copyright update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26059/files
  - new: https://git.openjdk.org/jdk/pull/26059/files/86ad1d74..47c43bcd

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

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

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

From hchao at openjdk.org  Tue Jul  1 19:22:44 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 1 Jul 2025 19:22:44 GMT
Subject: RFR: 8361125: Fix typo in onTradAbsence [v2]
In-Reply-To: <0hYdxxsa1CU1MWyFPOefAvQNN5xxELmlAgWIhnL1nX4=.317e7b01-a6d7-4ab2-a654-fe5ca437c408@github.com>
References: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
 <0hYdxxsa1CU1MWyFPOefAvQNN5xxELmlAgWIhnL1nX4=.317e7b01-a6d7-4ab2-a654-fe5ca437c408@github.com>
Message-ID: <CONy_8LmPCMgfVufq9b0kIqx4JcOLbPI4DZyawDJPJA=.f3d63a63-7c37-408e-bb58-91072c8a67c7@github.com>

On Tue, 1 Jul 2025 19:14:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Fix typo in `onTrad(e)Absence`
>> 
>> Tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Changes look good.

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

Marked as reviewed by hchao (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26059#pullrequestreview-2976690828

From djelinski at openjdk.org  Tue Jul  1 19:22:45 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 1 Jul 2025 19:22:45 GMT
Subject: RFR: 8361125: Fix typo in onTradAbsence [v2]
In-Reply-To: <0hYdxxsa1CU1MWyFPOefAvQNN5xxELmlAgWIhnL1nX4=.317e7b01-a6d7-4ab2-a654-fe5ca437c408@github.com>
References: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
 <0hYdxxsa1CU1MWyFPOefAvQNN5xxELmlAgWIhnL1nX4=.317e7b01-a6d7-4ab2-a654-fe5ca437c408@github.com>
Message-ID: <deRXHdALsbZhSpJNUQo-goBUtQuXycN0WzTroZUgYig=.7c3af9df-1719-4d20-b482-a2fe287813eb@github.com>

On Tue, 1 Jul 2025 19:14:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Fix typo in `onTrad(e)Absence`
>> 
>> Tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Thanks for the re-review!

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

PR Comment: https://git.openjdk.org/jdk/pull/26059#issuecomment-3025235897

From djelinski at openjdk.org  Tue Jul  1 19:22:45 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 1 Jul 2025 19:22:45 GMT
Subject: Integrated: 8361125: Fix typo in onTradAbsence
In-Reply-To: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
References: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
Message-ID: <MHk3kFD2CbuYX16aex7GfofwcQul-2_6y77LXMLHzYU=.5a83be12-4b65-4885-803a-d842645fdeb9@github.com>

On Tue, 1 Jul 2025 07:29:58 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix typo in `onTrad(e)Absence`
> 
> Tier1-3 tests continue to pass.

This pull request has now been integrated.

Changeset: e9a62d79
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9a62d79cdc43e5eb141f1d47624d0f6fe05989d
Stats:     9 lines in 4 files changed: 0 ins; 0 del; 9 mod

8361125: Fix typo in onTradAbsence

Reviewed-by: hchao, mullan, shade

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

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

From djelinski at openjdk.org  Tue Jul  1 19:53:57 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 1 Jul 2025 19:53:57 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <3UR7O_cfQFPcsz5GseXURHT9KVC6pUFSxa_KsNLtYNY=.d579b776-0eee-467b-b993-c1341b2dcb19@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/http3/streams/UniStreamPair.java line 87:

> 85:     private final CompletableFuture<QuicStreamWriter> streamWriterCF;
> 86:     // a queue of ByteBuffers submitted for writing.
> 87:     // might be null if not used. Only used in QueuingStreamPair.

It seems to be true. I'll see if I can move it to QueuingStreamPair.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2178413151

From djelinski at openjdk.org  Tue Jul  1 20:09:55 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 1 Jul 2025 20:09:55 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <3lbVW_vZLe7AqGQprT2k4Xa0gOwgsxzBfGmlwcPHtsQ=.abb14e6f-d7ef-4f36-a420-219dde365b52@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/http3/streams/UniStreamPair.java line 99:

> 97:     // The QuicStreamReader for the peer control stream
> 98:     volatile QuicStreamReader peerReader;
> 99:     private final CompletableFuture<QuicStreamReader> streamReaderCF;

Unused

src/java.net.http/share/classes/jdk/internal/net/http/http3/streams/UniStreamPair.java line 246:

> 244:      *  type has been read off the remote initiated stream}
> 245:      */
> 246:     public final CompletableFuture<QuicStreamReader> futureReceiverStreamReader() {

Unused

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2178431502
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2178432294

From mullan at openjdk.org  Tue Jul  1 22:45:45 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 1 Jul 2025 22:45:45 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v4]
In-Reply-To: <csaGYiAvuo8piw9ApqbvyR0evzMIVDrwvyjXndwW8IE=.1fee2f3c-00f0-439b-aa80-6b68bf7cd16a@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
 <csaGYiAvuo8piw9ApqbvyR0evzMIVDrwvyjXndwW8IE=.1fee2f3c-00f0-439b-aa80-6b68bf7cd16a@github.com>
Message-ID: <s6NjijNyto4s2fSGs41ObChg1ljsG2U1oj2678WRfjo=.55cd5a6f-b1f6-4ccd-aafa-505574064ef7@github.com>

On Wed, 18 Jun 2025 06:27:13 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
>> "algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.
>> 
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test per 2nd round of Mikhail's review comments.

src/java.base/share/classes/javax/crypto/Cipher.java line 470:

> 468:             // Algorithm only
> 469:             Transform tr = new Transform(parts[0], "", null, null);
> 470:             return Collections.singletonList(tr);

Or `List.of(tr)`.

src/java.base/share/classes/javax/crypto/Cipher.java line 479:

> 477:             list.add(new Transform(parts[0], "//" + parts[2], parts[1], null));
> 478:             list.add(new Transform(parts[0], "", parts[1], parts[2]));
> 479:             return list;

Does this need to be immutable or does it not matter?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2178673434
PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2178675369

From mpowers at openjdk.org  Wed Jul  2 00:01:14 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 2 Jul 2025 00:01:14 GMT
Subject: RFR: 8350711: [JMH] test Signatures.RSASSAPSS failed for 2 threads
 config
Message-ID: <HPS1QCDFce7qjbhsadlRNl8BZY3WObFgLj7LQfEqb_M=.5d5a6d44-7d65-4cb4-b699-bdd764657a26@github.com>

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

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

Commit messages:
 - second iteration
 - first iteration

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

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

From mpowers at openjdk.org  Wed Jul  2 00:01:14 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 2 Jul 2025 00:01:14 GMT
Subject: RFR: 8350711: [JMH] test Signatures.RSASSAPSS failed for 2 threads
 config
In-Reply-To: <HPS1QCDFce7qjbhsadlRNl8BZY3WObFgLj7LQfEqb_M=.5d5a6d44-7d65-4cb4-b699-bdd764657a26@github.com>
References: <HPS1QCDFce7qjbhsadlRNl8BZY3WObFgLj7LQfEqb_M=.5d5a6d44-7d65-4cb4-b699-bdd764657a26@github.com>
Message-ID: <OO_SYrib0TuM-gYUcJAu9Az8lWw13OoLhzkeLOBg_hU=.297b2117-fbea-4b2b-ae9e-04432f324e93@github.com>

On Tue, 1 Jul 2025 23:56:45 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

Tested with 10 threads.

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

PR Comment: https://git.openjdk.org/jdk/pull/26081#issuecomment-3025876188

From valeriep at openjdk.org  Wed Jul  2 02:38:40 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 2 Jul 2025 02:38:40 GMT
Subject: RFR: 8360146: Add system/security property to disable RSAES-PKCS-v1_5
 padding
Message-ID: <EXrq0Zpumxt6UtcDv0wfzl2r8eKDXpapYf68vFw1tYg=.3176f98a-7278-4334-97ac-b2e4d62e02f6@github.com>

This PR adds a security property "jdk.crypto.supportPKCS1Padding". By default, this property is not set. 
However, if this security property "jdk.crypto.supportPKCS1Padding" is set to "false", existing JDK providers, e.g. SunJCE, SunPKCS11, and SunMSCAPI providers. will not provide the RSA w/ PKCS1Padding cipher implementation.
This security property can help users in checking their usage on RSA w/ PKCS1Padding cipher and facilitate the disabling of this particular cipher if so desired.

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

Commit messages:
 - minor wording changes in java.security property description
 - 8360146: Add system/security property to disable RSAES-PKCS-v1_5 padding

Changes: https://git.openjdk.org/jdk/pull/26084/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26084&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360146
  Stats: 227 lines in 7 files changed: 206 ins; 1 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/26084.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26084/head:pull/26084

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

From valeriep at openjdk.org  Wed Jul  2 07:44:43 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 2 Jul 2025 07:44:43 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v4]
In-Reply-To: <s6NjijNyto4s2fSGs41ObChg1ljsG2U1oj2678WRfjo=.55cd5a6f-b1f6-4ccd-aafa-505574064ef7@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
 <csaGYiAvuo8piw9ApqbvyR0evzMIVDrwvyjXndwW8IE=.1fee2f3c-00f0-439b-aa80-6b68bf7cd16a@github.com>
 <s6NjijNyto4s2fSGs41ObChg1ljsG2U1oj2678WRfjo=.55cd5a6f-b1f6-4ccd-aafa-505574064ef7@github.com>
Message-ID: <YQmhxzR5w7ObFBKSbo38QpaHdiuPNIPCMPh1q0GvmgA=.e01ac292-9b2d-48dd-a553-7235808b9e1c@github.com>

On Tue, 1 Jul 2025 22:42:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated test per 2nd round of Mikhail's review comments.
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 479:
> 
>> 477:             list.add(new Transform(parts[0], "//" + parts[2], parts[1], null));
>> 478:             list.add(new Transform(parts[0], "", parts[1], parts[2]));
>> 479:             return list;
> 
> Does this need to be immutable or does it not matter?

It's only used internally within the Cipher class, so I don't think it matters, but we can use the `List.of()` to construct it as well for consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2179357215

From djelinski at openjdk.org  Wed Jul  2 07:51:01 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 2 Jul 2025 07:51:01 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <FmP9p94joz0UZx-X4ijp-ssEuOP5866kdRKiu1scKH8=.994d9c2d-781f-481f-930b-18c4a5cc1621@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <FmP9p94joz0UZx-X4ijp-ssEuOP5866kdRKiu1scKH8=.994d9c2d-781f-481f-930b-18c4a5cc1621@github.com>
Message-ID: <uRSzkyhm2D_k01pbaWu6AMNNsjGxZcEb-UpW1pK7o2A=.69facb94-d35f-4867-af93-8769cd986288@github.com>

On Fri, 27 Jun 2025 13:21:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 224:
> 
>> 222:             // TODO in future, when QuicTLSEngine might become a public exported interface
>> 223:             // we should have a method on javax.net.ssl.X509ExtendedKeyManager that
>> 224:             // takes QuicTLSEngine.
> 
> Suggestion:
> 
>             // TODO in future, if QuicTLSEngine ever becomes a public exported interface
>             // we might have a method on javax.net.ssl.X509ExtendedKeyManager that
>             // takes QuicTLSEngine.

Maybe we could stop guessing the future, and use this instead:
Suggestion:

            // TODO add a method on javax.net.ssl.X509ExtendedKeyManager that
            // takes QuicTLSEngine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2179367158

From valeriep at openjdk.org  Wed Jul  2 16:31:55 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 2 Jul 2025 16:31:55 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v5]
In-Reply-To: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
Message-ID: <zzm5e8W08GPoWK93cMpB534fcClwhaG8xwevIM9zIYs=.7db01acb-5359-4667-849c-8ad1149787fc@github.com>

> Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
> "algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.
> 
> 
> Thanks in advance for the review~

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Updated to use List.of() per Sean's comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25808/files
  - new: https://git.openjdk.org/jdk/pull/25808/files/7d9e36b8..def1f55b

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

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

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

From rriggs at openjdk.org  Wed Jul  2 17:55:39 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 2 Jul 2025 17:55:39 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage [v2]
In-Reply-To: <XTYzDh-pUL6Sm7YMGHUHhe3FnsmbGcCn3Nx1bbLgw_Y=.62028d71-2795-4048-a81d-5e989226e71f@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
 <XTYzDh-pUL6Sm7YMGHUHhe3FnsmbGcCn3Nx1bbLgw_Y=.62028d71-2795-4048-a81d-5e989226e71f@github.com>
Message-ID: <swh2zG0bffob5diAXKz2PwTBTinQP9yqWWmZbJVsmCQ=.636d9307-bbb4-467f-9e0d-fbfacbef141f@github.com>

On Mon, 30 Jun 2025 17:45:23 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
>> The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
>> So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357915: SecureRandom nextLong memory usage

The suggestion in the issue was to switch to RandomGenerator.nextLong() can you provide an explanation as to why that is not an acceptable solution.  It would avoid any allocation.  Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/26005#issuecomment-3021443543

From rhalade at openjdk.org  Wed Jul  2 17:55:40 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 2 Jul 2025 17:55:40 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage [v2]
In-Reply-To: <XTYzDh-pUL6Sm7YMGHUHhe3FnsmbGcCn3Nx1bbLgw_Y=.62028d71-2795-4048-a81d-5e989226e71f@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
 <XTYzDh-pUL6Sm7YMGHUHhe3FnsmbGcCn3Nx1bbLgw_Y=.62028d71-2795-4048-a81d-5e989226e71f@github.com>
Message-ID: <wVXySaSocgoERALTBRRRaEnTTvr9r1v4zTbB4M6BI8k=.2d3b5a92-37ba-4cc2-b68c-401b6fa3da4f@github.com>

On Mon, 30 Jun 2025 17:45:23 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
>> The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
>> So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357915: SecureRandom nextLong memory usage

@koushikthirupattur can you please add a regression test to provide coverage for `nextLong`?

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

PR Comment: https://git.openjdk.org/jdk/pull/26005#issuecomment-3028809682

From mullan at openjdk.org  Wed Jul  2 19:21:39 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 2 Jul 2025 19:21:39 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v5]
In-Reply-To: <zzm5e8W08GPoWK93cMpB534fcClwhaG8xwevIM9zIYs=.7db01acb-5359-4667-849c-8ad1149787fc@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
 <zzm5e8W08GPoWK93cMpB534fcClwhaG8xwevIM9zIYs=.7db01acb-5359-4667-849c-8ad1149787fc@github.com>
Message-ID: <w1J7w8qRocat6z98je-Ay58Qlx-ir1TNA7LgJTSeT_8=.8d6083e1-9a51-4b59-9846-20701aab19fb@github.com>

On Wed, 2 Jul 2025 16:31:55 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
>> "algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.
>> 
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to use List.of() per Sean's comment.

test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 27:

> 25: /*
> 26:  * @test
> 27:  * @bug 8358159 8359388

I think we should remove 8358159 from the bug line, as this is clearly not testing that bugfix anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2180810305

From wetmore at openjdk.org  Thu Jul  3 00:02:44 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 3 Jul 2025 00:02:44 GMT
Subject: RFR: 8156715: TrustStoreManager does not buffer keystore input
 stream [v2]
In-Reply-To: <LMZrzYmTNsm2A2N5hs9Ewu2h0ixU-XCjvKF3ilGEnuM=.b438014a-e9cc-4300-887c-11b21de8cfad@github.com>
References: <H8j7rQiom6jkCI3Ip9xon_oQEj8EQ5FSj9_hHTzDZ1o=.dbac4207-2c66-4fd0-b9fa-2968c1b7d9ee@github.com>
 <LMZrzYmTNsm2A2N5hs9Ewu2h0ixU-XCjvKF3ilGEnuM=.b438014a-e9cc-4300-887c-11b21de8cfad@github.com>
Message-ID: <akwfAbcTwhNXCdHM4OvUqx6m6wPu-LrTTwZgVkp5yn0=.86b6b0e4-5d45-430c-9e02-27d37dc54074@github.com>

On Mon, 23 Jun 2025 19:00:51 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Wrap the FileInputStream into a BufferedInputStream which reduces the number of actual file reads when loading a key store.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

LGTM.  (too late for push)

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

PR Review: https://git.openjdk.org/jdk/pull/25920#pullrequestreview-2980970401

From duke at openjdk.org  Thu Jul  3 03:44:43 2025
From: duke at openjdk.org (duke)
Date: Thu, 3 Jul 2025 03:44:43 GMT
Subject: Withdrawn: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to
 java test
In-Reply-To: <xLs-5ELobHMgCFIm_lQMF_ax6c8EeyIpCS-HQPGCBVc=.47737b0f-9d47-4472-9777-7af5c6de76ff@github.com>
References: <xLs-5ELobHMgCFIm_lQMF_ax6c8EeyIpCS-HQPGCBVc=.47737b0f-9d47-4472-9777-7af5c6de76ff@github.com>
Message-ID: <QfGaRWhnKSND1i7pmY6p_KP9K7-4pE2R1bzpZRkVhUA=.bf47efcd-a2e3-4797-a52d-b7e8e7f7af26@github.com>

On Wed, 12 Feb 2025 17:28:45 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Moved the sh file logic to jtreg java test.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu Jul  3 05:23:46 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 3 Jul 2025 05:23:46 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage [v2]
In-Reply-To: <swh2zG0bffob5diAXKz2PwTBTinQP9yqWWmZbJVsmCQ=.636d9307-bbb4-467f-9e0d-fbfacbef141f@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
 <XTYzDh-pUL6Sm7YMGHUHhe3FnsmbGcCn3Nx1bbLgw_Y=.62028d71-2795-4048-a81d-5e989226e71f@github.com>
 <swh2zG0bffob5diAXKz2PwTBTinQP9yqWWmZbJVsmCQ=.636d9307-bbb4-467f-9e0d-fbfacbef141f@github.com>
Message-ID: <BW5RW1ufd7j3Roqts_KakqGEZpIvXDKmdZdtrdSBmhg=.45fa52ee-0d30-409d-9ad7-a9e0658fc9f1@github.com>

On Tue, 1 Jul 2025 02:02:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The suggestion in the issue was to switch to RandomGenerator.nextLong() can you provide an explanation as to why that is not an acceptable solution. It would avoid any allocation. Thanks

As per our offline discussion, I am keeping this change of overriding nextlong() in secure random. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26005#issuecomment-3030784772

From duke at openjdk.org  Thu Jul  3 05:38:39 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 3 Jul 2025 05:38:39 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage [v2]
In-Reply-To: <BW5RW1ufd7j3Roqts_KakqGEZpIvXDKmdZdtrdSBmhg=.45fa52ee-0d30-409d-9ad7-a9e0658fc9f1@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
 <XTYzDh-pUL6Sm7YMGHUHhe3FnsmbGcCn3Nx1bbLgw_Y=.62028d71-2795-4048-a81d-5e989226e71f@github.com>
 <swh2zG0bffob5diAXKz2PwTBTinQP9yqWWmZbJVsmCQ=.636d9307-bbb4-467f-9e0d-fbfacbef141f@github.com>
 <BW5RW1ufd7j3Roqts_KakqGEZpIvXDKmdZdtrdSBmhg=.45fa52ee-0d30-409d-9ad7-a9e0658fc9f1@github.com>
Message-ID: <QCaXiLo13lcUfWYYlwf0coOIg5g-xMrrEl-9NpDyzx8=.0c7c5f64-1fde-4cfa-aed3-f202efbb98a5@github.com>

On Thu, 3 Jul 2025 05:19:42 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The suggestion in the issue was to switch to RandomGenerator.nextLong() can you provide an explanation as to why that is not an acceptable solution.  It would avoid any allocation.  Thanks
>
>> The suggestion in the issue was to switch to RandomGenerator.nextLong() can you provide an explanation as to why that is not an acceptable solution. It would avoid any allocation. Thanks
> 
> As per our offline discussion, I am keeping this change of overriding nextlong() in secure random. Thanks!

> @koushikthirupattur can you please add a regression test to provide coverage for `nextLong`?

Sure, we can add one for coverage but I wanted to learn if we really need a regression test in this case as there is no behavior change to test against and this fix only improves internal memory allocation in `SecureRandom.nextLong()`. Let me know.

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

PR Comment: https://git.openjdk.org/jdk/pull/26005#issuecomment-3030845683

From duke at openjdk.org  Thu Jul  3 16:38:49 2025
From: duke at openjdk.org (duke)
Date: Thu, 3 Jul 2025 16:38:49 GMT
Subject: Withdrawn: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid
In-Reply-To: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
Message-ID: <w8Hh_WMxsvQd-F3tZOd84fu8jVEL0fQP3MUGnZFxydA=.17d2cf18-0d97-4f05-aeed-fa24b8fe571f@github.com>

On Wed, 5 Feb 2025 17:39:42 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> * fully automated the test
> * removed the race condition
> * client on a thread and server on a thread options are now run together automatically

This pull request has been closed without being integrated.

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

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

From wetmore at openjdk.org  Thu Jul  3 21:05:40 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 3 Jul 2025 21:05:40 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage [v2]
In-Reply-To: <XTYzDh-pUL6Sm7YMGHUHhe3FnsmbGcCn3Nx1bbLgw_Y=.62028d71-2795-4048-a81d-5e989226e71f@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
 <XTYzDh-pUL6Sm7YMGHUHhe3FnsmbGcCn3Nx1bbLgw_Y=.62028d71-2795-4048-a81d-5e989226e71f@github.com>
Message-ID: <2qdXupnUhyE45XPmY_YfbzKeXNPkyZObg1YX0EmZU0w=.cebba186-97ea-42ba-a924-09d43438edf8@github.com>

On Mon, 30 Jun 2025 17:45:23 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
>> The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
>> So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357915: SecureRandom nextLong memory usage

`SecureRandom.nextDouble()` does the same thing, are you (or the submitter) worried about that?

Otherwise looks ok.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26005#pullrequestreview-2984527845

From wetmore at openjdk.org  Thu Jul  3 21:05:40 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 3 Jul 2025 21:05:40 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage [v2]
In-Reply-To: <QFzldRJRMuylnXQZRJeHSE-r41yOJh4_KsU8Glfhfmo=.0a535a6f-b5d1-4e51-a61e-e734cf319b26@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
 <kpTRhT_FL1iU7hyev_smBN_LOhFt6SbaWEjCg9D2PvU=.a1987172-af6b-4a62-900a-f5233ae73477@github.com>
 <j4ks7N1RH212yItVdCB-k_jrU-Knp-4XMj2SgPSDP94=.db0a67cc-8979-4d3f-9c7a-cd014014424f@github.com>
 <QFzldRJRMuylnXQZRJeHSE-r41yOJh4_KsU8Glfhfmo=.0a535a6f-b5d1-4e51-a61e-e734cf319b26@github.com>
Message-ID: <tkmba9q_kBYwLPBFcvBA28jXb3vLbZRkeZRSgbG5kCc=.e488c754-73ac-47c8-aae8-692ca5d19955@github.com>

On Mon, 30 Jun 2025 15:20:33 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This won't appear in the list of methods declared by `SecureRandom`. An analogy is [`ConcurrentHashMap::forEach(BiConsumer)`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html#methods-inherited-from-class-java.util.concurrent.ConcurrentMap): this method is [overridden in `ConcurrentHashMap`](https://github.com/openjdk/jdk/blob/jdk24/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L1613) but is described by Javadoc as "Methods declared in interface java.util.concurrent.ConcurrentMap".
>> 
>> Since this method won't appear, we don't need an `@inheritDoc` tag.
>
> I don't know, that seems less obvious to me, as I can't tell if the class is overriding the method or not.

`@inheritDoc` sounds good to me.

This is better than using `ByteBuffer.getLong()`, which uses the current byte ordering instead of big endian.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26005#discussion_r2183672363

From wetmore at openjdk.org  Thu Jul  3 21:13:45 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 3 Jul 2025 21:13:45 GMT
Subject: RFR: 8361125: Fix typo in onTradAbsence [v2]
In-Reply-To: <0hYdxxsa1CU1MWyFPOefAvQNN5xxELmlAgWIhnL1nX4=.317e7b01-a6d7-4ab2-a654-fe5ca437c408@github.com>
References: <wIMjZo1u10LDAN1lmtVpgjzD1reRVrIC6l8GOfElr48=.d039b93d-70fe-4f4d-92a0-d954dfc9d93c@github.com>
 <0hYdxxsa1CU1MWyFPOefAvQNN5xxELmlAgWIhnL1nX4=.317e7b01-a6d7-4ab2-a654-fe5ca437c408@github.com>
Message-ID: <E7DLPAf1s0OTOeH5A-ZrYlDbZJW55r1JX2tJ96PUjT0=.a322c0a2-fb77-413c-b968-e74413e733ff@github.com>

On Tue, 1 Jul 2025 19:14:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Fix typo in `onTrad(e)Absence`
>> 
>> Tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

A little late, but LGTM also.

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

PR Review: https://git.openjdk.org/jdk/pull/26059#pullrequestreview-2984705051

From djelinski at openjdk.org  Fri Jul  4 09:50:52 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 4 Jul 2025 09:50:52 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <uRSzkyhm2D_k01pbaWu6AMNNsjGxZcEb-UpW1pK7o2A=.69facb94-d35f-4867-af93-8769cd986288@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <FmP9p94joz0UZx-X4ijp-ssEuOP5866kdRKiu1scKH8=.994d9c2d-781f-481f-930b-18c4a5cc1621@github.com>
 <uRSzkyhm2D_k01pbaWu6AMNNsjGxZcEb-UpW1pK7o2A=.69facb94-d35f-4867-af93-8769cd986288@github.com>
Message-ID: <M9Emj44W8uptXRtEHwyL9LVfFpQVtpFuNM4c-Nw-UoM=.be6ca8bb-826d-41d8-b032-4328418775a6@github.com>

On Wed, 2 Jul 2025 07:47:31 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 224:
>> 
>>> 222:             // TODO in future, when QuicTLSEngine might become a public exported interface
>>> 223:             // we should have a method on javax.net.ssl.X509ExtendedKeyManager that
>>> 224:             // takes QuicTLSEngine.
>> 
>> Suggestion:
>> 
>>             // TODO in future, if QuicTLSEngine ever becomes a public exported interface
>>             // we might have a method on javax.net.ssl.X509ExtendedKeyManager that
>>             // takes QuicTLSEngine.
>
> Maybe we could stop guessing the future, and use this instead:
> Suggestion:
> 
>             // TODO add a method on javax.net.ssl.X509ExtendedKeyManager that
>             // takes QuicTLSEngine.

Removed speculations about the future

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2184893641

From mbalao at openjdk.org  Fri Jul  4 15:53:00 2025
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 4 Jul 2025 15:53:00 GMT
Subject: RFR: 8315487: Security Providers Filter [v24]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <UxZRnDAfPFl5PQpeEsH4RJCfDkuxeF3w_Ur972suYes=.5528c308-d47f-49a1-854c-a0fcc0a3a69f@github.com>

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge openjdk:master into martinuy:JDK-8315487
   
   Conflicts
   =========
   
   src/java.base/share/classes/javax/crypto/Cipher.java
   Caused by JDK-8358159 (3ff83ec49e561c44dd99508364b8ba068274b63a), which
   did something similar to what we had done for this proposal. Resolved by
   keeping JDK-8358159 changes.
   
   src/java.base/share/conf/security/java.security
   Caused by JDK-8298420 (bb2c80c0e9923385e0b6243c0ebff9afef208470), which
   added content at the end. Trivially resolved.
 - 8315487: Security Providers Filter
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes: https://git.openjdk.org/jdk/pull/15539/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=23
  Stats: 3702 lines in 43 files changed: 3308 ins; 89 del; 305 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

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

From mbalao at openjdk.org  Sat Jul  5 17:51:05 2025
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 5 Jul 2025 17:51:05 GMT
Subject: RFR: 8315487: Security Providers Filter [v25]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <encTRRjaK1uc8hFEsP5X8ag6S67a7YO10vfVApOir3o=.37efc516-475b-47be-80c4-234056e417dc@github.com>

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  Fix bad conflict resolution
  
  Due to our changes, AlgorithmDecomposer::getTransformationTokens returns
  an array which does not always have three elements, so the code from
  JDK-8358159 (3ff83ec49e561c44dd99508364b8ba068274b63a) needs adjustment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15539/files
  - new: https://git.openjdk.org/jdk/pull/15539/files/1b2ad21a..aa2bb3f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=23-24

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

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

From dfuchs at openjdk.org  Mon Jul  7 09:51:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Jul 2025 09:51:32 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v10]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <ClKLGAkhleLM-G6MbjUEcX0_Y8vQD6UcJc67yxBeFdk=.70554fcf-8f8e-488c-874e-76ba7372843b@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 545 commits:

 - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
 - merge latest changes from master branch
 - http3: fix typo in UniStreamPair.java
 - WriterQueue may leak before the constructor completes
 - Limit the number of retries in H3UserInfoTest
 - Implement IntReader
 - Remove dispatchers field
 - http3: when looking for a connection in the pool, prefer advertised connections for ANY
 - http3: fix Http3PendingConnections::removeCompleted to take into account the case where the Http3Connection was created with an AltService, but we don't have it because the handshake failed
 - Use default timeout in BasicHttp3Test
 - ... and 535 more: https://git.openjdk.org/jdk/compare/5cf349c3...9d67d4a6

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=09
  Stats: 105147 lines in 470 files changed: 102317 ins; 1335 del; 1495 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From mbalao at openjdk.org  Mon Jul  7 13:43:05 2025
From: mbalao at openjdk.org (Martin Balao)
Date: Mon, 7 Jul 2025 13:43:05 GMT
Subject: RFR: 8315487: Security Providers Filter [v26]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <7dZi_VnU4k_oq3tgu19AhYmmPOvkhpLaVJz8B-A2OKY=.5851d984-256e-4c2d-816a-fe69921c6621@github.com>

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

Martin Balao has updated the pull request incrementally with three additional commits since the last revision:

 - Add missing @implNote to Security::getAlgorithms
   
   Create a jdk.security.providers.filter @implNote for
   java.security.Security::getAlgorithms, explaining that this method is
   NOT affected by the filter.
   
   NOTE: we could have modified the method to stop using the Provider
   Hashtable and start to be affected by the filter, but we think this
   is unnecessary, given the method doesn't look to be widely used.
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - Address review comment 2
   
   Create a jdk.security.providers.filter @implNote for:
    ? java.security.Security::getProviders(String)
    ? java.security.Security::getProviders(java.util.Map<String,String>)
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - Address review comment 1
   
   Add a java.security.Provider.Service link in the 'services' mention of
   the jdk.security.providers.filter @implNote.
   
   NOTE: instead of the first mention in each API, we preferred to add it
   everywhere in order to simplify the criteria.
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15539/files
  - new: https://git.openjdk.org/jdk/pull/15539/files/aa2bb3f2..f3a190d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=24-25

  Stats: 334 lines in 32 files changed: 125 ins; 0 del; 209 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

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

From fferrari at openjdk.org  Mon Jul  7 13:43:06 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Mon, 7 Jul 2025 13:43:06 GMT
Subject: RFR: 8315487: Security Providers Filter [v23]
In-Reply-To: <W7HG7cN_W33gisSku8n_mEecODOIipX9coNKF67_nWA=.3ca2853a-0f57-4d1a-adf0-96db2f69efb7@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
 <pgzoxuhBfcidmYjTbIXafrm3NA3HPefOc6xyeJ7CagA=.4f5513c3-beac-4ee3-9779-a63eb5ca478c@github.com>
 <W7HG7cN_W33gisSku8n_mEecODOIipX9coNKF67_nWA=.3ca2853a-0f57-4d1a-adf0-96db2f69efb7@github.com>
Message-ID: <pTeNTvGE0u8COxGakW9uX-CNRPWCsNJXQTGbNH-6WRw=.2b8b4f35-2ec4-4679-a672-8947cdfa147e@github.com>

On Fri, 6 Jun 2025 17:35:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 1268 commits:
>> 
>>  - 8315487: Security Providers Filter
>>    
>>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8356126: Duplication handling and optimization of CaptureCallState
>>    
>>    Reviewed-by: jvernee
>>  - 8332934: Do loop with continue with subsequent switch leads to incorrect stack maps
>>    
>>    Reviewed-by: vromero
>>  - 8354461: Update tests to disable streaming output for attach tools
>>    
>>    Reviewed-by: sspitsyn, cjplummer
>>  - 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty
>>    
>>    Reviewed-by: ccheung, shade, kvn
>>  - 8356318: Unexpected VerifyError in AOT training run
>>    
>>    Reviewed-by: shade, kvn
>>  - 8356025: Provide a PrintVMInfoAtExit diagnostic switch
>>    
>>    Reviewed-by: mbaesken, jsikstro
>>  - 8347004: vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java fails with CDS disabled
>>    
>>    Reviewed-by: coleenp
>>  - 8354443: [Graal] crash after deopt in TestG1BarrierGeneration.java
>>    
>>    Reviewed-by: dnsimon, yzheng
>>  - 8355775: Improve symbolic sharing in dynamic constant pool entries
>>    
>>    Reviewed-by: asotona
>>  - ... and 1258 more: https://git.openjdk.org/jdk/compare/8c09d40d...37d3f23a
>
> src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java line 162:
> 
>> 160:      * {@link System#getProperty(String) System} and
>> 161:      * {@link Security#getProperty(String) Security} properties determine
>> 162:      * which services are enabled. A service that is not enabled by the
> 
> In these and other APIs, I think it would be useful to link to `java.security.Provider.Service` when mentioning "services" since this is the first mention of that term in this API.

Addressed in 59d82288d5ccc01f2d807be1638dcbc6d167b132.

> src/java.base/share/classes/java/security/Security.java line 387:
> 
>> 385:      * algorithm and provider. Search is case-insensitive.
>> 386:      */
>> 387:     private static Provider.Service findService(String type, String algo,
> 
> You need to add a similar implementation note about the `jdk.security.providers.filter` property to the `getProviders(String)` method since it can affect what providers are returned.

Addressed in c59bbeabbca16c70c7945bb80ce3e8b3ee9967c8. Please also check f3a190d6a8f0fc3a448f5a33457ef639396e9076.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15539#discussion_r2190144209
PR Review Comment: https://git.openjdk.org/jdk/pull/15539#discussion_r2190144295

From valeriep at openjdk.org  Mon Jul  7 21:08:55 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 7 Jul 2025 21:08:55 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v6]
In-Reply-To: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
Message-ID: <4In1pO91W7mzS_8tmJyrWRjNGKo6YWtJF3Y6DwGptro=.6a71a1f0-630a-4ee1-9d78-21b7c474cad9@github.com>

> Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
> "algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.
> 
> 
> Thanks in advance for the review~

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Remove bug id 8358159 from the test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25808/files
  - new: https://git.openjdk.org/jdk/pull/25808/files/def1f55b..a02eef2f

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

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

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

From valeriep at openjdk.org  Mon Jul  7 21:08:55 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 7 Jul 2025 21:08:55 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v5]
In-Reply-To: <w1J7w8qRocat6z98je-Ay58Qlx-ir1TNA7LgJTSeT_8=.8d6083e1-9a51-4b59-9846-20701aab19fb@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
 <zzm5e8W08GPoWK93cMpB534fcClwhaG8xwevIM9zIYs=.7db01acb-5359-4667-849c-8ad1149787fc@github.com>
 <w1J7w8qRocat6z98je-Ay58Qlx-ir1TNA7LgJTSeT_8=.8d6083e1-9a51-4b59-9846-20701aab19fb@github.com>
Message-ID: <qWUcrkOKfHhxZekTTB0iHp8HpoDt2RDXp6aX-aTxsSE=.c9887e62-911f-4045-8933-ee2ed4471a1c@github.com>

On Wed, 2 Jul 2025 19:19:10 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated to use List.of() per Sean's comment.
>
> test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 27:
> 
>> 25: /*
>> 26:  * @test
>> 27:  * @bug 8358159 8359388
> 
> I think we should remove 8358159 from the bug line, as this is clearly not testing that bugfix anymore.

Yes, good point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2191011128

From mullan at openjdk.org  Mon Jul  7 21:26:38 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 7 Jul 2025 21:26:38 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v6]
In-Reply-To: <4In1pO91W7mzS_8tmJyrWRjNGKo6YWtJF3Y6DwGptro=.6a71a1f0-630a-4ee1-9d78-21b7c474cad9@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
 <4In1pO91W7mzS_8tmJyrWRjNGKo6YWtJF3Y6DwGptro=.6a71a1f0-630a-4ee1-9d78-21b7c474cad9@github.com>
Message-ID: <hYop9n6HvjZ6hHeMU2op6Si9nK2wN15y3PVA7en5DJs=.cb659ebb-120e-4e0a-9be5-162615ab8d21@github.com>

On Mon, 7 Jul 2025 21:08:55 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
>> "algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.
>> 
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove bug id 8358159 from the test.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25808#pullrequestreview-2995307901

From valeriep at openjdk.org  Mon Jul  7 23:38:44 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 7 Jul 2025 23:38:44 GMT
Subject: Integrated: 8359388: Stricter checking for cipher transformations
In-Reply-To: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
Message-ID: <ApEfTD8zyHIIH0is4pYNfaLlsAhcfsjr35VbzAlVRXI=.a80e9960-40c8-482a-8cbe-16a43cf8f511@github.com>

On Fri, 13 Jun 2025 17:32:12 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
> "algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.
> 
> 
> Thanks in advance for the review~

This pull request has now been integrated.

Changeset: ec7c6be6
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec7c6be6a9e84c8cd2077fea07930592ddd13669
Stats:     100 lines in 2 files changed: 45 ins; 15 del; 40 mod

8359388: Stricter checking for cipher transformations

Reviewed-by: mullan

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

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

From jwaters at openjdk.org  Tue Jul  8 01:30:08 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 8 Jul 2025 01:30:08 GMT
Subject: Integrated: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <-TK5ziYVLfu1MOHf70wFHbnT7bhXhOq0mXLI4HOphJE=.37fea4b0-0383-4e9d-baf6-60f437ac92d1@github.com>

On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did

This pull request has now been integrated.

Changeset: 563a3358
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/563a3358f6f1ecff816318cbb32376487365c1fa
Stats:     8 lines in 4 files changed: 2 ins; 3 del; 3 mod

8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage

Reviewed-by: cjplummer, asemenyuk, almatvee

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

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

From jpai at openjdk.org  Tue Jul  8 05:16:39 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Jul 2025 05:16:39 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms
In-Reply-To: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
Message-ID: <84bqpOT-0Mvgqr3173feXu3KGIdl3RIFMK9Kxrr3w1Q=.2bf8673e-1bc1-4c7f-a01a-f2ff51f9cc48@github.com>

On Thu, 3 Apr 2025 18:47:43 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

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

Hello Matthew, In recent times we have been adding more of these configuration debugging into the -XshowSettings option. I'm unusure to what extent this option should be advertized or used for gathering such details of the runtime. Would this be more suitable to be done as a `jcmd` command? Something like a `jcmd <pid> VM.security_configuration`? To me, that feels like a more natural place to be adding support for details like these. More so because I think it's very rare for applications to be launching the JVM with the `-XshowSettings` option.

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3047385294

From dfuchs at openjdk.org  Tue Jul  8 14:04:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 8 Jul 2025 14:04:56 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:

 - merge latest changes from master branch
 - http3: fix new HttpHeadersBuilder constructor
 - qpack - optimize processing of decoder instruction exceptions
 - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
 - Avoid speculating about the future in TODOs
 - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
 - merge latest changes from master branch
 - http3: fix typo in UniStreamPair.java
 - WriterQueue may leak before the constructor completes
 - Limit the number of retries in H3UserInfoTest
 - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=10
  Stats: 105048 lines in 471 files changed: 102218 ins; 1335 del; 1495 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From myankelevich at openjdk.org  Tue Jul  8 16:19:48 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 8 Jul 2025 16:19:48 GMT
Subject: RFR: 8346962: Test CRLReadTimeout.java fails with -Xcomp by fstdebug
 build
Message-ID: <XypAv7wbNnEp0U3BPGMPR6Wm4pW0fZl8YyvUqWNOk3U=.57ce041c-e4f2-40ec-86da-ae035afe4037@github.com>

- Adjusted timings to prevent timeouts with `Fastdebug` and `-Xcomp`
- Split tests into parallel runs, reducing execution time by almost three-fold
- Replaced wildcard imports
- Specified the loopback address

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

Commit messages:
 - 8346962: Test CRLReadTimeout.java fails with -Xcomp by fstdebug build

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

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

From duke at openjdk.org  Tue Jul  8 17:50:42 2025
From: duke at openjdk.org (duke)
Date: Tue, 8 Jul 2025 17:50:42 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage [v2]
In-Reply-To: <XTYzDh-pUL6Sm7YMGHUHhe3FnsmbGcCn3Nx1bbLgw_Y=.62028d71-2795-4048-a81d-5e989226e71f@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
 <XTYzDh-pUL6Sm7YMGHUHhe3FnsmbGcCn3Nx1bbLgw_Y=.62028d71-2795-4048-a81d-5e989226e71f@github.com>
Message-ID: <37WsPDJCGpeVY3paRzkCZeckG6KJzWvNrV40pnFVr6A=.d84a81d2-03bb-4308-916a-d0bd48c124ac@github.com>

On Mon, 30 Jun 2025 17:45:23 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
>> The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
>> So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357915: SecureRandom nextLong memory usage

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26005#issuecomment-3049806984

From duke at openjdk.org  Tue Jul  8 18:27:45 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Tue, 8 Jul 2025 18:27:45 GMT
Subject: Integrated: 8357915: SecureRandom nextLong memory usage
In-Reply-To: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
Message-ID: <QOGRLQdz42AvEh3d5GCwQLWaFzVM2oziDHTs5XYuxoA=.16a5424d-3389-4003-acbd-3e6cb03b44e3@github.com>

On Thu, 26 Jun 2025 18:00:21 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
> The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
> So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.

This pull request has now been integrated.

Changeset: 91df7978
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91df7978799e5a24a73d8e1ae344e532e572f2dd
Stats:     11 lines in 1 file changed: 11 ins; 0 del; 0 mod

8357915: SecureRandom nextLong memory usage

Reviewed-by: wetmore

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

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

From wetmore at openjdk.org  Tue Jul  8 23:21:21 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 8 Jul 2025 23:21:21 GMT
Subject: RFR: 8353925: Remove Sun Microsystems JCE Code Signing Root CA
Message-ID: <pEZrRxMDnJoKJJ3-zSIZivTMKMukmi_Il6HDHUpwacg=.0279b8aa-a04f-4875-b696-124d486acbe5@github.com>

No longer trust certificates issued by the old Sun Microsystems JCE Certificate Authority.

Test runs include `tier1,tier2`, and JCK tests:

    jck:api/java_security
    jck:api/javax_crypto
    jck:api/javax_net
    jck:api/javax_security
    jck:api/org_ietf
    jck:api/javax_xml/crypto  

This PR is just a resigning of some existing jar files.

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

Commit messages:
 - Correct permissions on the jar files
 - 8353925: Remove Sun Microsystems JCE Code Signing Root CA

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

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

From syan at openjdk.org  Wed Jul  9 02:54:44 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 9 Jul 2025 02:54:44 GMT
Subject: RFR: 8346962: Test CRLReadTimeout.java fails with -Xcomp by
 fstdebug build
In-Reply-To: <XypAv7wbNnEp0U3BPGMPR6Wm4pW0fZl8YyvUqWNOk3U=.57ce041c-e4f2-40ec-86da-ae035afe4037@github.com>
References: <XypAv7wbNnEp0U3BPGMPR6Wm4pW0fZl8YyvUqWNOk3U=.57ce041c-e4f2-40ec-86da-ae035afe4037@github.com>
Message-ID: <RjdQPm8PtAjBTiBxbuFssDgpiRVl2ihn14pppIJ3dYQ=.3bc6d1d7-45c6-4464-badc-cbe7871b0c73@github.com>

On Tue, 8 Jul 2025 16:15:49 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> - Adjusted timings to prevent timeouts with `Fastdebug` and `-Xcomp`
> - Split tests into parallel runs, reducing execution time by almost three-fold
> - Replaced wildcard imports
> - Specified the loopback address
> - Enabled logs for easier debugging

test/jdk/sun/security/x509/URICertStore/CRLReadTimeout.java line 42:

> 40:  *          java.base/sun.security.util
> 41:  * @library /test/lib
> 42:  * @run main/othervm -Djava.security.debug=certpath -Dcom.sun.security.crl.readtimeout=1s

What's the difference between `-Dcom.sun.security.crl.readtimeout=1s` and `-Dcom.sun.security.crl.readtimeout=1`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26195#discussion_r2193898319

From myankelevich at openjdk.org  Wed Jul  9 08:49:44 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 9 Jul 2025 08:49:44 GMT
Subject: RFR: 8346962: Test CRLReadTimeout.java fails with -Xcomp by
 fstdebug build
In-Reply-To: <RjdQPm8PtAjBTiBxbuFssDgpiRVl2ihn14pppIJ3dYQ=.3bc6d1d7-45c6-4464-badc-cbe7871b0c73@github.com>
References: <XypAv7wbNnEp0U3BPGMPR6Wm4pW0fZl8YyvUqWNOk3U=.57ce041c-e4f2-40ec-86da-ae035afe4037@github.com>
 <RjdQPm8PtAjBTiBxbuFssDgpiRVl2ihn14pppIJ3dYQ=.3bc6d1d7-45c6-4464-badc-cbe7871b0c73@github.com>
Message-ID: <NhtPOeoG0W61_MD257X6h4691Y3I569JK1a4r6GJ8y0=.938ac3c8-92c2-42c1-8508-160d53ff72d2@github.com>

On Wed, 9 Jul 2025 02:51:54 GMT, SendaoYan <syan at openjdk.org> wrote:

>> - Adjusted timings to prevent timeouts with `Fastdebug` and `-Xcomp`
>> - Split tests into parallel runs, reducing execution time by almost three-fold
>> - Replaced wildcard imports
>> - Specified the loopback address
>> - Enabled logs for easier debugging
>
> test/jdk/sun/security/x509/URICertStore/CRLReadTimeout.java line 42:
> 
>> 40:  *          java.base/sun.security.util
>> 41:  * @library /test/lib
>> 42:  * @run main/othervm -Djava.security.debug=certpath -Dcom.sun.security.crl.readtimeout=1s
> 
> What's the difference between `-Dcom.sun.security.crl.readtimeout=1s` and `-Dcom.sun.security.crl.readtimeout=1`

Read timeout is in milliseconds by default. One is 1ms and another 1s

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26195#discussion_r2194436270

From mullan at openjdk.org  Thu Jul 10 13:45:41 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Jul 2025 13:45:41 GMT
Subject: RFR: 8353925: Remove Sun Microsystems JCE Code Signing Root CA
In-Reply-To: <pEZrRxMDnJoKJJ3-zSIZivTMKMukmi_Il6HDHUpwacg=.0279b8aa-a04f-4875-b696-124d486acbe5@github.com>
References: <pEZrRxMDnJoKJJ3-zSIZivTMKMukmi_Il6HDHUpwacg=.0279b8aa-a04f-4875-b696-124d486acbe5@github.com>
Message-ID: <y_SI6KX0fn9MxH47PN9RJfH3Rcxer4ykxit8rpkuAT4=.c99dd839-7c2b-4342-b06e-2d883ca46092@github.com>

On Tue, 8 Jul 2025 22:57:49 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> No longer trust certificates issued by the old Sun Microsystems JCE Certificate Authority.
> 
> Test runs include `tier1,tier2`, and JCK tests:
> 
>     jck:api/java_security
>     jck:api/javax_crypto
>     jck:api/javax_net
>     jck:api/javax_security
>     jck:api/org_ietf
>     jck:api/javax_xml/crypto  
> 
> This PR is just a resigning of some existing jar files.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26205#pullrequestreview-3005758509

From mullan at openjdk.org  Thu Jul 10 14:24:42 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Jul 2025 14:24:42 GMT
Subject: RFR: 8358451: SunJCE PBEKey impl should throw
 IllegalStateException when getEncoded() is called [v3]
In-Reply-To: <T04UTKAFdqTYdlcfuZlFsBsOma4EATnPl7xTseW9aFk=.0f876a4c-d890-40a6-a564-263e1c966ed6@github.com>
References: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
 <T04UTKAFdqTYdlcfuZlFsBsOma4EATnPl7xTseW9aFk=.0f876a4c-d890-40a6-a564-263e1c966ed6@github.com>
Message-ID: <ZhTN-qFL8Ml3QyqnP2oqfL9iy4S8AsKRG09SyJ4yN-s=.cf07883f-98d2-4b24-8b12-816933a0e7ca@github.com>

On Fri, 27 Jun 2025 23:11:53 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Update the `PBEKey` class of the SunJCE provider which override the `javax.security.auth.Destroyable` interface to 
>> 
>> 1. throw `IllegalStateException` if `getEncoded()` is called after key is destroyed
>> 2. serialization of such destroyed `PBEKey` object will lead to exception. 
>>  
>> Also update the `PBEKeyFactory` class of the SunJCE provider to check for destroyed keys and throw exceptions per the method javadoc.
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change "key" to "Key" in exception messages.

src/java.base/share/classes/javax/crypto/SecretKeyFactory.java line 375:

> 373:      * (e.g., the given key has an algorithm or format not supported by this
> 374:      * secret key factory).
> 375:      * @exception IllegalStateException if the given key is already destroyed.

This only checks if the key is destroyed when passed in. What if it is destroyed while the operation is in progress? It may or may not succeed depending on when the key is destroyed. I think we probably need to say something about that, maybe: "This exception may also be thrown if the given key is destroyed while this operation is in progress."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25632#discussion_r2197881542

From myankelevich at openjdk.org  Thu Jul 10 16:08:49 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 10 Jul 2025 16:08:49 GMT
Subject: RFR: 8360979: Remove use of Thread.stop in krb5/auto/KDC.java
Message-ID: <FHSH5gC8z3Z32jxCflPNSxWCieoW3A88ZK05j6hqhjU=.b82ac2e8-3a9d-4cf8-aed8-3372f9ebdc78@github.com>

Replaced Thread::stop to Thread::interrupt

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

Commit messages:
 - JDK-8360979: Remove use of Thread.stop in krb5/auto/KDC.java

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

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

From valeriep at openjdk.org  Thu Jul 10 22:06:38 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 10 Jul 2025 22:06:38 GMT
Subject: RFR: 8353925: Remove Sun Microsystems JCE Code Signing Root CA
In-Reply-To: <pEZrRxMDnJoKJJ3-zSIZivTMKMukmi_Il6HDHUpwacg=.0279b8aa-a04f-4875-b696-124d486acbe5@github.com>
References: <pEZrRxMDnJoKJJ3-zSIZivTMKMukmi_Il6HDHUpwacg=.0279b8aa-a04f-4875-b696-124d486acbe5@github.com>
Message-ID: <QpO002XZbcVuFbHCjqKgDAdjaukRQ3JQEj5AeKs9F00=.f2b47417-8e04-43dd-9400-aa22e7013450@github.com>

On Tue, 8 Jul 2025 22:57:49 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> No longer trust certificates issued by the old Sun Microsystems JCE Certificate Authority.
> 
> Test runs include `tier1,tier2`, and JCK tests:
> 
>     jck:api/java_security
>     jck:api/javax_crypto
>     jck:api/javax_net
>     jck:api/javax_security
>     jck:api/org_ietf
>     jck:api/javax_xml/crypto  
> 
> This PR is just a resigning of some existing jar files.

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26205#pullrequestreview-3007535540

From mbalao at openjdk.org  Fri Jul 11 18:21:35 2025
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 11 Jul 2025 18:21:35 GMT
Subject: RFR: 8315487: Security Providers Filter [v27]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <SLRF6WEvV3terzvr9h8KTD6jHWo_l7hbNBaGEsZxM7A=.d885d294-4c11-4d89-9a7d-7ec66a762a8f@github.com>

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

Martin Balao 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 openjdk:master into martinuy:JDK-8315487
   
   Conflicts
   =========
   
   src/java.base/share/classes/javax/crypto/Cipher.java
   Caused by JDK-8359388 (ec7c6be6a9e84c8cd2077fea07930592ddd13669).
   Resolved by adding JDK-8359388 new checks on our codebase (we need
   the checks separated from splitting).
 - Add missing @implNote to Security::getAlgorithms
   
   Create a jdk.security.providers.filter @implNote for
   java.security.Security::getAlgorithms, explaining that this method is
   NOT affected by the filter.
   
   NOTE: we could have modified the method to stop using the Provider
   Hashtable and start to be affected by the filter, but we think this
   is unnecessary, given the method doesn't look to be widely used.
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - Address review comment 2
   
   Create a jdk.security.providers.filter @implNote for:
    ? java.security.Security::getProviders(String)
    ? java.security.Security::getProviders(java.util.Map<String,String>)
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - Address review comment 1
   
   Add a java.security.Provider.Service link in the 'services' mention of
   the jdk.security.providers.filter @implNote.
   
   NOTE: instead of the first mention in each API, we preferred to add it
   everywhere in order to simplify the criteria.
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - Fix bad conflict resolution
   
   Due to our changes, AlgorithmDecomposer::getTransformationTokens returns
   an array which does not always have three elements, so the code from
   JDK-8358159 (3ff83ec49e561c44dd99508364b8ba068274b63a) needs adjustment.
 - Merge openjdk:master into martinuy:JDK-8315487
   
   Conflicts
   =========
   
   src/java.base/share/classes/javax/crypto/Cipher.java
   Caused by JDK-8358159 (3ff83ec49e561c44dd99508364b8ba068274b63a), which
   did something similar to what we had done for this proposal. Resolved by
   keeping JDK-8358159 changes.
   
   src/java.base/share/conf/security/java.security
   Caused by JDK-8298420 (bb2c80c0e9923385e0b6243c0ebff9afef208470), which
   added content at the end. Trivially resolved.
 - 8315487: Security Providers Filter
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes: https://git.openjdk.org/jdk/pull/15539/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=26
  Stats: 3829 lines in 43 files changed: 3429 ins; 93 del; 307 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

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