From jpai at openjdk.org  Tue Jul  1 07:31:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Jul 2025 07:31:45 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v3]
In-Reply-To: <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
Message-ID: <9emDG6j2YwGq9q_uNha4OikutXt4gQ9CB8gw4_LllVQ=.296775c8-b81a-447b-bd0b-cbff2adbaef7@github.com>

On Mon, 16 Jun 2025 08:04:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
>> 
>> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
>> 
>> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
>> 
>> I've run this change around a 1000 times and haven't seen it fail.
>> 
>> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change to test's log message

I have been running some experiments to make this test fail more consistently by introducing artificial delays at the right places. So far i haven't managed to make it fail. So I'm going to take a step back and re-review my theory about why this is failing. I will get back to this once I have additional details to share.

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

PR Comment: https://git.openjdk.org/jdk/pull/25820#issuecomment-3022281189

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 jpai at openjdk.org  Tue Jul  1 07:52:42 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Jul 2025 07:52:42 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v3]
In-Reply-To: <9emDG6j2YwGq9q_uNha4OikutXt4gQ9CB8gw4_LllVQ=.296775c8-b81a-447b-bd0b-cbff2adbaef7@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
 <9emDG6j2YwGq9q_uNha4OikutXt4gQ9CB8gw4_LllVQ=.296775c8-b81a-447b-bd0b-cbff2adbaef7@github.com>
Message-ID: <8M6nc-rjI2OGXTNYZ_Vr_IkB22iL4gCIj2Ni0CEfmAk=.c3511118-2cda-4c6b-b3ab-6e41094c6702@github.com>

On Tue, 1 Jul 2025 07:28:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I have been running some experiments to make this test fail more consistently by introducing artificial delays at the right places. So far i haven't managed to make it fail. So I'm going to take a step back and re-review my theory about why this is failing. I will get back to this once I have additional details to share.

Spoke a minute or so soon. I have now managed to reproduce this issue with an artificial delay in closing the `FileInputStream` in the test's `FileServerHandler`. It now matches the reason that I noted in the JBS issue's comment https://bugs.openjdk.org/browse/JDK-8359477?focusedId=14789850&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14789850

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

PR Comment: https://git.openjdk.org/jdk/pull/25820#issuecomment-3022372810

From jpai at openjdk.org  Tue Jul  1 09:31:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Jul 2025 09:31:15 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v4]
In-Reply-To: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
Message-ID: <Btf-FNAv9QhUHm183WW0P2eyExVHexDpv22ssaiV34c=.f415a60e-587b-4f5e-99c7-81ec81d1a79c@github.com>

> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
> 
> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
> 
> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
> 
> I've run this change around a 1000 times and haven't seen it fail.
> 
> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).

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

 - use ExecutorService.close() instead of ExecutorService.shutdown() to wait for the server side handlers to complete execution
 - use try-with-resource in test's FileServerHandler
 - Revert "8359477: com/sun/net/httpserver/Test12.java appears to have a temp file race"
   
   This reverts commit a0f8fc806e1682ef909cb7b4a449be855072fe48.
 - merge latest master branch changes
 - minor change to test's log message
 - add a log message in the test
 - 8359477: com/sun/net/httpserver/Test12.java appears to have a temp file race
 - 8359477: general cleanup of the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25820/files
  - new: https://git.openjdk.org/jdk/pull/25820/files/42b86dee..7f03aa43

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

  Stats: 21265 lines in 805 files changed: 9166 ins; 7793 del; 4306 mod
  Patch: https://git.openjdk.org/jdk/pull/25820.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25820/head:pull/25820

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

From jpai at openjdk.org  Tue Jul  1 09:36:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Jul 2025 09:36:45 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v4]
In-Reply-To: <Btf-FNAv9QhUHm183WW0P2eyExVHexDpv22ssaiV34c=.f415a60e-587b-4f5e-99c7-81ec81d1a79c@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <Btf-FNAv9QhUHm183WW0P2eyExVHexDpv22ssaiV34c=.f415a60e-587b-4f5e-99c7-81ec81d1a79c@github.com>
Message-ID: <4QVjomzAiiiLlRQy3rP_wsRw9f7wMpLCoJFgFf9wv8c=.49dc881f-9733-4482-af42-f07097de1592@github.com>

On Tue, 1 Jul 2025 09:31:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
>> 
>> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
>> 
>> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
>> 
>> I've run this change around a 1000 times and haven't seen it fail.
>> 
>> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - use ExecutorService.close() instead of ExecutorService.shutdown() to wait for the server side handlers to complete execution
>  - use try-with-resource in test's FileServerHandler
>  - Revert "8359477: com/sun/net/httpserver/Test12.java appears to have a temp file race"
>    
>    This reverts commit a0f8fc806e1682ef909cb7b4a449be855072fe48.
>  - merge latest master branch changes
>  - minor change to test's log message
>  - add a log message in the test
>  - 8359477: com/sun/net/httpserver/Test12.java appears to have a temp file race
>  - 8359477: general cleanup of the test

The PR is now ready for review. When I opened this PR a few weeks back I had removed the calls to `Files.delete(...)` in order to not introduce bigger changes to the test to co-ordinate the file deletion. However, Volkan's suggested approach of calling `ExecutorService.close()` to ensure that the server side handlers complete execution before deleting the files is a clean and straightforward way to address this issue. So i have re-introduced the Files.delete(...) calls and replaced the use of `ExecutorService.shutdown()` with `ExecutorService.close()` in the test. That's the real fix in this PR, the rest of the changes are clean ups to use newer constructs like try-with-resources.

With the current changes in this PR, I have run the test around a 1000 times and haven't seen it fail. Plus, I've also run the test with an aritifcial slowdown in the `FileServerHandler` and the test itself and I could reproduce the issue consistently without the proposed changes. It no longer reproduces even with artificial delays after the proposed changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25820#issuecomment-3022992439

From dfuchs at openjdk.org  Tue Jul  1 09:56:45 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Jul 2025 09:56:45 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v4]
In-Reply-To: <Btf-FNAv9QhUHm183WW0P2eyExVHexDpv22ssaiV34c=.f415a60e-587b-4f5e-99c7-81ec81d1a79c@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <Btf-FNAv9QhUHm183WW0P2eyExVHexDpv22ssaiV34c=.f415a60e-587b-4f5e-99c7-81ec81d1a79c@github.com>
Message-ID: <mA3Cf08ZhqpiAVVG7dMVm3t2k0iKDjOcV8YrIlw7D7k=.447f3157-13ee-496d-80b0-5aca2228281a@github.com>

On Tue, 1 Jul 2025 09:31:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
>> 
>> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
>> 
>> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
>> 
>> I've run this change around a 1000 times and haven't seen it fail.
>> 
>> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - use ExecutorService.close() instead of ExecutorService.shutdown() to wait for the server side handlers to complete execution
>  - use try-with-resource in test's FileServerHandler
>  - Revert "8359477: com/sun/net/httpserver/Test12.java appears to have a temp file race"
>    
>    This reverts commit a0f8fc806e1682ef909cb7b4a449be855072fe48.
>  - merge latest master branch changes
>  - minor change to test's log message
>  - add a log message in the test
>  - 8359477: com/sun/net/httpserver/Test12.java appears to have a temp file race
>  - 8359477: general cleanup of the test

test/jdk/com/sun/net/httpserver/Test12.java line 66:

> 64:         Path smallFilePath = createTempFileOfSize(TEMP_FILE_PREFIX, null, 23);
> 65:         Path largeFilePath = createTempFileOfSize(TEMP_FILE_PREFIX, null, 2730088);
> 66:         try (final ExecutorService executor = Executors.newCachedThreadPool()) {

I would not use try-with-resources here: I don't think we should close the executor before closing the servers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2177073217

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 jpai at openjdk.org  Tue Jul  1 11:25:32 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Jul 2025 11:25:32 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v5]
In-Reply-To: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
Message-ID: <PLJVQTUJ85LmR5Tg4HLBDBz1SfBDzrZLImHnspstnwg=.ad3932cb-8c3a-4f23-ab69-d0efb313eba2@github.com>

> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
> 
> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
> 
> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
> 
> I've run this change around a 1000 times and haven't seen it fail.
> 
> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Daniel's review - don't use try-with-resource for Executor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25820/files
  - new: https://git.openjdk.org/jdk/pull/25820/files/7f03aa43..a461506c

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

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

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

From jpai at openjdk.org  Tue Jul  1 11:25:36 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Jul 2025 11:25:36 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v4]
In-Reply-To: <mA3Cf08ZhqpiAVVG7dMVm3t2k0iKDjOcV8YrIlw7D7k=.447f3157-13ee-496d-80b0-5aca2228281a@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <Btf-FNAv9QhUHm183WW0P2eyExVHexDpv22ssaiV34c=.f415a60e-587b-4f5e-99c7-81ec81d1a79c@github.com>
 <mA3Cf08ZhqpiAVVG7dMVm3t2k0iKDjOcV8YrIlw7D7k=.447f3157-13ee-496d-80b0-5aca2228281a@github.com>
Message-ID: <knfuoNr0xgfAKoLe20QU08dueXHA1nIAiJ3btkVl7XM=.4b835f0a-b817-4738-b417-a7a2fe85099e@github.com>

On Tue, 1 Jul 2025 09:54:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - use ExecutorService.close() instead of ExecutorService.shutdown() to wait for the server side handlers to complete execution
>>  - use try-with-resource in test's FileServerHandler
>>  - Revert "8359477: com/sun/net/httpserver/Test12.java appears to have a temp file race"
>>    
>>    This reverts commit a0f8fc806e1682ef909cb7b4a449be855072fe48.
>>  - merge latest master branch changes
>>  - minor change to test's log message
>>  - add a log message in the test
>>  - 8359477: com/sun/net/httpserver/Test12.java appears to have a temp file race
>>  - 8359477: general cleanup of the test
>
> test/jdk/com/sun/net/httpserver/Test12.java line 66:
> 
>> 64:         Path smallFilePath = createTempFileOfSize(TEMP_FILE_PREFIX, null, 23);
>> 65:         Path largeFilePath = createTempFileOfSize(TEMP_FILE_PREFIX, null, 2730088);
>> 66:         try (final ExecutorService executor = Executors.newCachedThreadPool()) {
> 
> I would not use try-with-resources here: I don't think we should close the executor before closing the servers.

I've updated the PR to close the Executor after the servers have been closed. I'm guessing the suggestion was mostly as a precaution than what this test currently does?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2177320230

From jpai at openjdk.org  Tue Jul  1 12:43:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Jul 2025 12:43:58 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v6]
In-Reply-To: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
Message-ID: <f1K-VOnzLFr_JdGr15eEB6ctqHGHoahRlCvB0wLnLaA=.eff58f33-7579-4c69-93b2-9c8dd0a7a29e@github.com>

> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
> 
> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
> 
> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
> 
> I've run this change around a 1000 times and haven't seen it fail.
> 
> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  copyright year update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25820/files
  - new: https://git.openjdk.org/jdk/pull/25820/files/a461506c..5843685c

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

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

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

From msheppar at openjdk.org  Tue Jul  1 12:43:58 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 1 Jul 2025 12:43:58 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v5]
In-Reply-To: <PLJVQTUJ85LmR5Tg4HLBDBz1SfBDzrZLImHnspstnwg=.ad3932cb-8c3a-4f23-ab69-d0efb313eba2@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <PLJVQTUJ85LmR5Tg4HLBDBz1SfBDzrZLImHnspstnwg=.ad3932cb-8c3a-4f23-ab69-d0efb313eba2@github.com>
Message-ID: <q4xHm45oQe1Z1QanVHb-JzHppFGYJuF88_C2XzSZwaM=.0edbde62-58dc-4c5f-8a68-1913b84dbe75@github.com>

On Tue, 1 Jul 2025 11:25:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
>> 
>> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
>> 
>> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
>> 
>> I've run this change around a 1000 times and haven't seen it fail.
>> 
>> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - don't use try-with-resource for Executor

the ubiquitous copyright update for FileServerHandler.java ;-)

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

PR Comment: https://git.openjdk.org/jdk/pull/25820#issuecomment-3023843441

From jpai at openjdk.org  Tue Jul  1 12:43:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Jul 2025 12:43:58 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v5]
In-Reply-To: <PLJVQTUJ85LmR5Tg4HLBDBz1SfBDzrZLImHnspstnwg=.ad3932cb-8c3a-4f23-ab69-d0efb313eba2@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <PLJVQTUJ85LmR5Tg4HLBDBz1SfBDzrZLImHnspstnwg=.ad3932cb-8c3a-4f23-ab69-d0efb313eba2@github.com>
Message-ID: <R1_B3QoNuGEkpI7Vp8JV9fnBZuxSYUMYlCH5lBQmA7g=.c46fe451-fe90-4e4c-914c-9977357e8211@github.com>

On Tue, 1 Jul 2025 11:25:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
>> 
>> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
>> 
>> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
>> 
>> I've run this change around a 1000 times and haven't seen it fail.
>> 
>> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - don't use try-with-resource for Executor

Thank you Mark, I missed that one :)

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

PR Comment: https://git.openjdk.org/jdk/pull/25820#issuecomment-3023853117

From dfuchs at openjdk.org  Tue Jul  1 14:23:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Jul 2025 14:23:47 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v6]
In-Reply-To: <f1K-VOnzLFr_JdGr15eEB6ctqHGHoahRlCvB0wLnLaA=.eff58f33-7579-4c69-93b2-9c8dd0a7a29e@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <f1K-VOnzLFr_JdGr15eEB6ctqHGHoahRlCvB0wLnLaA=.eff58f33-7579-4c69-93b2-9c8dd0a7a29e@github.com>
Message-ID: <Jwi2RzZnA5GhCIuoI3rI6C9R1HKsyNWVtSkaf63wdgQ=.6b644652-0ead-4c56-a943-26caf61e53a9@github.com>

On Tue, 1 Jul 2025 12:43:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
>> 
>> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
>> 
>> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
>> 
>> I've run this change around a 1000 times and haven't seen it fail.
>> 
>> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year update

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25820#pullrequestreview-2975680977

From dfuchs at openjdk.org  Tue Jul  1 14:23:48 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Jul 2025 14:23:48 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v4]
In-Reply-To: <knfuoNr0xgfAKoLe20QU08dueXHA1nIAiJ3btkVl7XM=.4b835f0a-b817-4738-b417-a7a2fe85099e@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <Btf-FNAv9QhUHm183WW0P2eyExVHexDpv22ssaiV34c=.f415a60e-587b-4f5e-99c7-81ec81d1a79c@github.com>
 <mA3Cf08ZhqpiAVVG7dMVm3t2k0iKDjOcV8YrIlw7D7k=.447f3157-13ee-496d-80b0-5aca2228281a@github.com>
 <knfuoNr0xgfAKoLe20QU08dueXHA1nIAiJ3btkVl7XM=.4b835f0a-b817-4738-b417-a7a2fe85099e@github.com>
Message-ID: <bK8SVwb_EYwxaK0fe2cj7vMXRkZxubv0iOCyrnOMOAE=.e314eb24-a156-4650-a1f1-828b86868fd7@github.com>

On Tue, 1 Jul 2025 11:21:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/com/sun/net/httpserver/Test12.java line 66:
>> 
>>> 64:         Path smallFilePath = createTempFileOfSize(TEMP_FILE_PREFIX, null, 23);
>>> 65:         Path largeFilePath = createTempFileOfSize(TEMP_FILE_PREFIX, null, 2730088);
>>> 66:         try (final ExecutorService executor = Executors.newCachedThreadPool()) {
>> 
>> I would not use try-with-resources here: I don't think we should close the executor before closing the servers.
>
> I've updated the PR to close the Executor after the servers have been closed. I'm guessing the suggestion was mostly as a precaution than what this test currently does?

Yes. stopping the server first ensures that the dispatcher's thread has exited, so there should be nothing submitting tasks to the executor past this point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2177738506

From jpai at openjdk.org  Tue Jul  1 15:35:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Jul 2025 15:35:50 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v6]
In-Reply-To: <f1K-VOnzLFr_JdGr15eEB6ctqHGHoahRlCvB0wLnLaA=.eff58f33-7579-4c69-93b2-9c8dd0a7a29e@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <f1K-VOnzLFr_JdGr15eEB6ctqHGHoahRlCvB0wLnLaA=.eff58f33-7579-4c69-93b2-9c8dd0a7a29e@github.com>
Message-ID: <H4m0Hq7Lim7p03yCaEEcWcaOenHqfxI27JjvucYI2-E=.e3a3f685-7ee9-4b7d-88a3-0bd9a178eaa7@github.com>

On Tue, 1 Jul 2025 12:43:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
>> 
>> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
>> 
>> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
>> 
>> I've run this change around a 1000 times and haven't seen it fail.
>> 
>> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year update

Thank you everyone for the inputs and reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25820#issuecomment-3024533528

From jpai at openjdk.org  Tue Jul  1 15:35:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Jul 2025 15:35:51 GMT
Subject: Integrated: 8359477: com/sun/net/httpserver/Test12.java appears to
 have a temp file race
In-Reply-To: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
Message-ID: <kDeNQLCwgrjzp4Fu0RTplILEL_PwKdc0xghTKmo2Im0=.bc81e463-681e-4b86-a639-19328af59fa2@github.com>

On Mon, 16 Jun 2025 07:22:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
> 
> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
> 
> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
> 
> I've run this change around a 1000 times and haven't seen it fail.
> 
> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).

This pull request has now been integrated.

Changeset: e1681c48
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1681c48287bcce6c8f617d9c0c25354dd62870a
Stats:     152 lines in 2 files changed: 46 ins; 68 del; 38 mod

8359477: com/sun/net/httpserver/Test12.java appears to have a temp file race

Reviewed-by: dfuchs, vyazici

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

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

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 bpb at openjdk.org  Tue Jul  1 23:26:42 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Jul 2025 23:26:42 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v15]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <ufWpflFhdrPm4cpC-J2_5GYBXqeZoNnOd7NWZMLCc5U=.e2abe1f8-1f0c-4e54-8fbc-9c493cd99887@github.com>

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

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - ... and 5 more: https://git.openjdk.org/jdk/compare/9d518b32...ffa3c469

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=14
  Stats: 1539 lines in 93 files changed: 774 ins; 668 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From jpai at openjdk.org  Wed Jul  2 06:19:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Jul 2025 06:19:58 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed [v3]
In-Reply-To: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
Message-ID: <koIQUz9ucMMcrCH0VU-cREodLeT70exhencgmRWdVUc=.cb08d655-8887-4ef8-92fd-66c0d245fb82@github.com>

> Can I please get a review of this change which updates the `jdk.internal.net.http.HttpConnection` to keep track of the origin server for which the `HttpConnection` was constructed? This addresses https://bugs.openjdk.org/browse/JDK-8361060.
> 
> This is an internal implementation change which will allow other parts of the JDK's HttpClient implementation to use the origin server information. An example of such usage is the alternate services that are going to be supported in the JDK's HttpClient upcoming implementation for HTTP/3.
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.

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

 - Daniel's review - store Origin.host as lower case for DNS hostnames
 - merge latest from master branch
 - SNI server names can now be derived from the Origin instance
 - strip the square brackets from URI's host when constructing an Origin
 - support only lower case http and https literals for scheme in Origin
 - add new line
 - 8361060: Keep track of the origin server against which a jdk.internal.net.http.HttpConnection was constructed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26041/files
  - new: https://git.openjdk.org/jdk/pull/26041/files/c8825e0c..b2ba49ce

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

  Stats: 1417 lines in 83 files changed: 749 ins; 347 del; 321 mod
  Patch: https://git.openjdk.org/jdk/pull/26041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26041/head:pull/26041

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

From dfuchs at openjdk.org  Wed Jul  2 07:44:44 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Jul 2025 07:44:44 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed [v3]
In-Reply-To: <koIQUz9ucMMcrCH0VU-cREodLeT70exhencgmRWdVUc=.cb08d655-8887-4ef8-92fd-66c0d245fb82@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
 <koIQUz9ucMMcrCH0VU-cREodLeT70exhencgmRWdVUc=.cb08d655-8887-4ef8-92fd-66c0d245fb82@github.com>
Message-ID: <upxa-zl9Ws8PH4AX-V0DVRbrbYbDg5qP5XNJOaY9FR4=.629a8cf0-bed7-45ed-8ba4-bd7d164c7e99@github.com>

On Wed, 2 Jul 2025 06:19:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the `jdk.internal.net.http.HttpConnection` to keep track of the origin server for which the `HttpConnection` was constructed? This addresses https://bugs.openjdk.org/browse/JDK-8361060.
>> 
>> This is an internal implementation change which will allow other parts of the JDK's HttpClient implementation to use the origin server information. An example of such usage is the alternate services that are going to be supported in the JDK's HttpClient upcoming implementation for HTTP/3.
>> 
>> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Daniel's review - store Origin.host as lower case for DNS hostnames
>  - merge latest from master branch
>  - SNI server names can now be derived from the Origin instance
>  - strip the square brackets from URI's host when constructing an Origin
>  - support only lower case http and https literals for scheme in Origin
>  - add new line
>  - 8361060: Keep track of the origin server against which a jdk.internal.net.http.HttpConnection was constructed

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26041#pullrequestreview-2978091775

From jpai at openjdk.org  Wed Jul  2 07:44:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Jul 2025 07:44:45 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed [v2]
In-Reply-To: <S4HMmrGf5u7Q-oZHDCihlN5Acu3ws_NAbfL4kA71zWE=.f3d4992d-db58-4783-8d9e-cd735a07b44e@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
 <5A_SpOuvlXtTWrMOvuCA48FSlJ0j8mwUZFtF4CYogaQ=.1152a6c6-3a7f-47aa-b09c-c33a0c8dc53b@github.com>
 <S4HMmrGf5u7Q-oZHDCihlN5Acu3ws_NAbfL4kA71zWE=.f3d4992d-db58-4783-8d9e-cd735a07b44e@github.com>
Message-ID: <HDVpKtaRvd9xnlNz0w2n-SzQhj9DjEsvZ_bEVsptsyg=.03b20258-574e-4968-a862-67a8cf496977@github.com>

On Mon, 30 Jun 2025 15:41:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I wonder if we should lower case the host returned by getHost() too (when not a literal address).

Done. The PR has been updated with this change. tier1, tier2 and tier3 test pass with this change. Given the kind of code we added in this `Origin` class, I'm now considering introducing a test for this class' behaviour. I'll update this PR shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/26041#issuecomment-3026798595

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 dfuchs at openjdk.org  Wed Jul  2 08:43:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Jul 2025 08:43:13 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be simplified
Message-ID: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>

The PlainHttpConnection::connectAsync method implements a retry logic that will call connect() again if connect() throws the first time. This will not work, as the channel is closed when connect() throws. That logic should be removed. Reconnection should only be attempted at a higher level (MultiExchange).

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

Commit messages:
 - 8361249: PlainHttpConnection connection logic can be simplified

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

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

From jpai at openjdk.org  Wed Jul  2 12:45:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Jul 2025 12:45:59 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed [v4]
In-Reply-To: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
Message-ID: <WbEHJyFqk3qGRVIDl29fwpVjeun9jTh0FHpe2kAmjtg=.37bf15fd-d500-4240-b11d-bc3146ac5188@github.com>

> Can I please get a review of this change which updates the `jdk.internal.net.http.HttpConnection` to keep track of the origin server for which the `HttpConnection` was constructed? This addresses https://bugs.openjdk.org/browse/JDK-8361060.
> 
> This is an internal implementation change which will allow other parts of the JDK's HttpClient implementation to use the origin server information. An example of such usage is the alternate services that are going to be supported in the JDK's HttpClient upcoming implementation for HTTP/3.
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  add a test for jdk.internal.net.http.Origin

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26041/files
  - new: https://git.openjdk.org/jdk/pull/26041/files/b2ba49ce..711840f3

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

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

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

From jpai at openjdk.org  Wed Jul  2 12:46:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Jul 2025 12:46:00 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed [v3]
In-Reply-To: <koIQUz9ucMMcrCH0VU-cREodLeT70exhencgmRWdVUc=.cb08d655-8887-4ef8-92fd-66c0d245fb82@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
 <koIQUz9ucMMcrCH0VU-cREodLeT70exhencgmRWdVUc=.cb08d655-8887-4ef8-92fd-66c0d245fb82@github.com>
Message-ID: <-kAOLGhaGTLlDuS49RU63bG-1eRjtiBD9DUFBhvKOgY=.1e5b22a1-d67e-489b-98d7-083eca0ba521@github.com>

On Wed, 2 Jul 2025 06:19:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the `jdk.internal.net.http.HttpConnection` to keep track of the origin server for which the `HttpConnection` was constructed? This addresses https://bugs.openjdk.org/browse/JDK-8361060.
>> 
>> This is an internal implementation change which will allow other parts of the JDK's HttpClient implementation to use the origin server information. An example of such usage is the alternate services that are going to be supported in the JDK's HttpClient upcoming implementation for HTTP/3.
>> 
>> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Daniel's review - store Origin.host as lower case for DNS hostnames
>  - merge latest from master branch
>  - SNI server names can now be derived from the Origin instance
>  - strip the square brackets from URI's host when constructing an Origin
>  - support only lower case http and https literals for scheme in Origin
>  - add new line
>  - 8361060: Keep track of the origin server against which a jdk.internal.net.http.HttpConnection was constructed

I've updated the PR to include a test for the `Origin` class. No other changes. The test passes with these changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26041#issuecomment-3027734499

From dfuchs at openjdk.org  Thu Jul  3 09:30:41 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Jul 2025 09:30:41 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed [v4]
In-Reply-To: <WbEHJyFqk3qGRVIDl29fwpVjeun9jTh0FHpe2kAmjtg=.37bf15fd-d500-4240-b11d-bc3146ac5188@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
 <WbEHJyFqk3qGRVIDl29fwpVjeun9jTh0FHpe2kAmjtg=.37bf15fd-d500-4240-b11d-bc3146ac5188@github.com>
Message-ID: <CNu_nQufkBNtRJj_f6QxcD2LLFc4eYxkRYOYFouwQNQ=.e63a4dc8-74d9-4df7-986c-b904566035e7@github.com>

On Wed, 2 Jul 2025 12:45:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the `jdk.internal.net.http.HttpConnection` to keep track of the origin server for which the `HttpConnection` was constructed? This addresses https://bugs.openjdk.org/browse/JDK-8361060.
>> 
>> This is an internal implementation change which will allow other parts of the JDK's HttpClient implementation to use the origin server information. An example of such usage is the alternate services that are going to be supported in the JDK's HttpClient upcoming implementation for HTTP/3.
>> 
>> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a test for jdk.internal.net.http.Origin

LGTM. Thanks for adding the test!

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26041#pullrequestreview-2982440126

From jpai at openjdk.org  Thu Jul  3 09:34:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Jul 2025 09:34:50 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed [v4]
In-Reply-To: <WbEHJyFqk3qGRVIDl29fwpVjeun9jTh0FHpe2kAmjtg=.37bf15fd-d500-4240-b11d-bc3146ac5188@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
 <WbEHJyFqk3qGRVIDl29fwpVjeun9jTh0FHpe2kAmjtg=.37bf15fd-d500-4240-b11d-bc3146ac5188@github.com>
Message-ID: <kNgk5tuI40YtUBgMvxmiA2x3jcQkLZclCi_a4jYnPwU=.a8c02e9e-e438-48ce-b6c1-06c59e24ff07@github.com>

On Wed, 2 Jul 2025 12:45:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the `jdk.internal.net.http.HttpConnection` to keep track of the origin server for which the `HttpConnection` was constructed? This addresses https://bugs.openjdk.org/browse/JDK-8361060.
>> 
>> This is an internal implementation change which will allow other parts of the JDK's HttpClient implementation to use the origin server information. An example of such usage is the alternate services that are going to be supported in the JDK's HttpClient upcoming implementation for HTTP/3.
>> 
>> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a test for jdk.internal.net.http.Origin

Thank you Daniel for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26041#issuecomment-3031565434

From jpai at openjdk.org  Thu Jul  3 09:34:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Jul 2025 09:34:52 GMT
Subject: Integrated: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed
In-Reply-To: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
Message-ID: <MXJGrLy1pGf79cxHcaN41w7kHPhWIUVvQF25GLKqmU0=.deca93bb-e8aa-4093-aa01-94071e80c7f2@github.com>

On Mon, 30 Jun 2025 11:07:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which updates the `jdk.internal.net.http.HttpConnection` to keep track of the origin server for which the `HttpConnection` was constructed? This addresses https://bugs.openjdk.org/browse/JDK-8361060.
> 
> This is an internal implementation change which will allow other parts of the JDK's HttpClient implementation to use the origin server information. An example of such usage is the alternate services that are going to be supported in the JDK's HttpClient upcoming implementation for HTTP/3.
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.

This pull request has now been integrated.

Changeset: 1be29bd7
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1be29bd725a4642b841c60c19f2f7f689a360831
Stats:     480 lines in 11 files changed: 391 ins; 64 del; 25 mod

8361060: Keep track of the origin server against which a jdk.internal.net.http.HttpConnection was constructed

Reviewed-by: dfuchs

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

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

From vyazici at openjdk.org  Thu Jul  3 10:56:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 3 Jul 2025 10:56:46 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be
 simplified
In-Reply-To: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
Message-ID: <N9GQE5PFzQbd3ZhpkVmTrk21JO6O53hLNHfoIdraF8U=.1a396c7d-40e9-4816-b015-f1b6505e2378@github.com>

On Wed, 2 Jul 2025 08:37:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The PlainHttpConnection::connectAsync method implements a retry logic that will call connect() again if connect() throws the first time. This will not work, as the channel is closed when connect() throws. That logic should be removed. Reconnection should only be attempted at a higher level (MultiExchange).

src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java line 1:

> 1: /*

Shouldn't we remove the following too?

1. The `unsuccessfulAttempts` field
2. `jdk.internal.net.http.common.TimeSource` import

src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java line 232:

> 230:         }
> 231:         return cf.thenApply((state)->{
> 232:             if (debug.on()) debug.log("%s: %s", label(), state);

AFAICT, this is the only place where a `ConnectState` is _read_. Alternatively, we can remove the `ConnectState` enum and add `debug.log()` statements where `ConnectState` were assigned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26087#discussion_r2182475581
PR Review Comment: https://git.openjdk.org/jdk/pull/26087#discussion_r2182483092

From dfuchs at openjdk.org  Thu Jul  3 12:59:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Jul 2025 12:59:40 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be
 simplified
In-Reply-To: <N9GQE5PFzQbd3ZhpkVmTrk21JO6O53hLNHfoIdraF8U=.1a396c7d-40e9-4816-b015-f1b6505e2378@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
 <N9GQE5PFzQbd3ZhpkVmTrk21JO6O53hLNHfoIdraF8U=.1a396c7d-40e9-4816-b015-f1b6505e2378@github.com>
Message-ID: <mseqA20KZebcv0huVuLTxJrmZ7e-2BUbwlsuvoh1Z4E=.8388a086-660b-43b0-933d-9a551a6538b2@github.com>

On Thu, 3 Jul 2025 10:49:21 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> The PlainHttpConnection::connectAsync method implements a retry logic that will call connect() again if connect() throws the first time. This will not work, as the channel is closed when connect() throws. That logic should be removed. Reconnection should only be attempted at a higher level (MultiExchange).
>
> src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java line 1:
> 
>> 1: /*
> 
> Shouldn't we remove the following too?
> 
> 1. The `unsuccessfulAttempts` field
> 2. `jdk.internal.net.http.common.TimeSource` import

Good point.

> src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java line 232:
> 
>> 230:         }
>> 231:         return cf.thenApply((state)->{
>> 232:             if (debug.on()) debug.log("%s: %s", label(), state);
> 
> AFAICT, this is the only place where a `ConnectState` is _read_. Alternatively, we can remove the `ConnectState` enum and add `debug.log()` statements where `ConnectState` were assigned.

I know. I hesitated and eventually decided to keep it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26087#discussion_r2182716896
PR Review Comment: https://git.openjdk.org/jdk/pull/26087#discussion_r2182718272

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 vyazici at openjdk.org  Thu Jul  3 20:30:16 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 3 Jul 2025 20:30:16 GMT
Subject: RFR: 8361337: java/net/URLPermission/nstest/LookupTest.java should
 open connections with NO_PROXY
Message-ID: <9WjED6h2N7Hs1QOSAqkttl1TTm3l-5a0m_e6Em7YFD8=.f42b7917-4827-4437-a988-6cbdb284d59b@github.com>

Explicitly use `NO_PROXY` in `LookupTest` to avoid test failures on environments where proxy is configured. Updated test run results on various platforms are attached to the ticket.

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

Commit messages:
 - Configure system-wide `NO_PROXY`

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

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

From jpai at openjdk.org  Fri Jul  4 01:54:42 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Jul 2025 01:54:42 GMT
Subject: RFR: 8361337: java/net/URLPermission/nstest/LookupTest.java should
 open connections with NO_PROXY
In-Reply-To: <9WjED6h2N7Hs1QOSAqkttl1TTm3l-5a0m_e6Em7YFD8=.f42b7917-4827-4437-a988-6cbdb284d59b@github.com>
References: <9WjED6h2N7Hs1QOSAqkttl1TTm3l-5a0m_e6Em7YFD8=.f42b7917-4827-4437-a988-6cbdb284d59b@github.com>
Message-ID: <lr-F-FwxMWDGlD8YawqX1wEk-Bi2vT-UA6Ag_AI-90E=.89875354-eb3c-40a6-8b4e-b177a5177c30@github.com>

On Thu, 3 Jul 2025 20:25:13 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Explicitly use `NO_PROXY` in `LookupTest` to avoid test failures on environments where proxy is configured. Updated test run results on various platforms are attached to the ticket.

test/jdk/java/net/URLPermission/nstest/LookupTest.java line 108:

> 106: 
> 107:     private static void configureSystemWideNoProxy() {
> 108:         ProxySelector.setDefault(new ProxySelector() {

Hello Volkan, `ProxySelector.setDefault(ProxySelector.of(null))` allows you to disable proxy without requiring the code to provide a `ProxySelector` implementation. Maybe that could be used here? That might also mean you won't need a separate `configureSystemWideNoProxy()` method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26120#discussion_r2184121699

From dfuchs at openjdk.org  Fri Jul  4 07:45:39 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Jul 2025 07:45:39 GMT
Subject: RFR: 8361337: java/net/URLPermission/nstest/LookupTest.java should
 open connections with NO_PROXY
In-Reply-To: <9WjED6h2N7Hs1QOSAqkttl1TTm3l-5a0m_e6Em7YFD8=.f42b7917-4827-4437-a988-6cbdb284d59b@github.com>
References: <9WjED6h2N7Hs1QOSAqkttl1TTm3l-5a0m_e6Em7YFD8=.f42b7917-4827-4437-a988-6cbdb284d59b@github.com>
Message-ID: <5C5aT7aQczsUBTLQla3Zrv_E-3PwlCq896Rq1PUe-Uk=.32ce3e09-c398-42ba-824b-c7099a7c9526@github.com>

On Thu, 3 Jul 2025 20:25:13 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Explicitly use `NO_PROXY` in `LookupTest` to avoid test failures on environments where proxy is configured. Updated test run results on various platforms are attached to the ticket.

Sorry about that.  It looks like we can withdraw this PR and close this bug as a duplicate of [JDK-8166359](https://bugs.openjdk.org/browse/JDK-8166359).  The failure I observed which prompted me to look at this test was actually observed on JDK 8. When I looked at this test in mainline, I looked at the call that calls URL.openConnection() and at the main method - I didn't see the line that sets the default ProxySelector to null in the test method, and assume the fix was needed in mainline too. But it appears that it's already fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26120#issuecomment-3034855970

From dfuchs at openjdk.org  Fri Jul  4 08:30:01 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Jul 2025 08:30:01 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be
 simplified [v2]
In-Reply-To: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
Message-ID: <0oZhsDM416zjr6jjooQq_lVdOME9qxUemlVkuWpr8TU=.90abc784-6275-4c18-9661-41d66b2b3a45@github.com>

> The PlainHttpConnection::connectAsync method implements a retry logic that will call connect() again if connect() throws the first time. This will not work, as the channel is closed when connect() throws. That logic should be removed. Reconnection should only be attempted at a higher level (MultiExchange).

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26087/files
  - new: https://git.openjdk.org/jdk/pull/26087/files/58c78e57..a63206df

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

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

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

From dfuchs at openjdk.org  Fri Jul  4 08:34:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Jul 2025 08:34:52 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be
 simplified [v3]
In-Reply-To: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
Message-ID: <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>

> The PlainHttpConnection::connectAsync method implements a retry logic that will call connect() again if connect() throws the first time. This will not work, as the channel is closed when connect() throws. That logic should be removed. Reconnection should only be attempted at a higher level (MultiExchange).

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26087/files
  - new: https://git.openjdk.org/jdk/pull/26087/files/a63206df..12ba2924

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

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

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

From dfuchs at openjdk.org  Fri Jul  4 08:34:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Jul 2025 08:34:53 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be
 simplified [v3]
In-Reply-To: <mseqA20KZebcv0huVuLTxJrmZ7e-2BUbwlsuvoh1Z4E=.8388a086-660b-43b0-933d-9a551a6538b2@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
 <N9GQE5PFzQbd3ZhpkVmTrk21JO6O53hLNHfoIdraF8U=.1a396c7d-40e9-4816-b015-f1b6505e2378@github.com>
 <mseqA20KZebcv0huVuLTxJrmZ7e-2BUbwlsuvoh1Z4E=.8388a086-660b-43b0-933d-9a551a6538b2@github.com>
Message-ID: <30ssA_NIcu71eM9Y-3101xNAETCGjqX5g_qml9q80SE=.02e2b0c0-8260-4e03-8518-0fb6e7ab08c3@github.com>

On Thu, 3 Jul 2025 12:56:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java line 1:
>> 
>>> 1: /*
>> 
>> Shouldn't we remove the following too?
>> 
>> 1. The `unsuccessfulAttempts` field
>> 2. `jdk.internal.net.http.common.TimeSource` import
>
> Good point.

Done.

>> src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java line 232:
>> 
>>> 230:         }
>>> 231:         return cf.thenApply((state)->{
>>> 232:             if (debug.on()) debug.log("%s: %s", label(), state);
>> 
>> AFAICT, this is the only place where a `ConnectState` is _read_. Alternatively, we can remove the `ConnectState` enum and add `debug.log()` statements where `ConnectState` were assigned.
>
> I know. I hesitated and eventually decided to keep it.

Now removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26087#discussion_r2184725364
PR Review Comment: https://git.openjdk.org/jdk/pull/26087#discussion_r2184732569

From djelinski at openjdk.org  Fri Jul  4 09:07:41 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 4 Jul 2025 09:07:41 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be
 simplified [v3]
In-Reply-To: <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
 <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>
Message-ID: <wsP4Mthi5PCdfG1s8eEbRpZJdxcXNqQ5NrtDhTODBRA=.73ac6274-bdbe-4036-a472-dec6b7c62222@github.com>

On Fri, 4 Jul 2025 08:34:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The PlainHttpConnection::connectAsync method implements a retry logic that will call connect() again if connect() throws the first time. This will not work, as the channel is closed when connect() throws. That logic should be removed. Reconnection should only be attempted at a higher level (MultiExchange).
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26087#pullrequestreview-2986194754

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 vyazici at openjdk.org  Fri Jul  4 11:19:39 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 4 Jul 2025 11:19:39 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be
 simplified [v3]
In-Reply-To: <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
 <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>
Message-ID: <Ft9Ysse1pL_goXO3-xSyKjGTot1mZenmCh2IyIMG1i0=.d8ec4675-bf04-4fbb-ba90-74f276f6adbc@github.com>

On Fri, 4 Jul 2025 08:34:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The PlainHttpConnection::connectAsync method implements a retry logic that will call connect() again if connect() throws the first time. This will not work, as the channel is closed when connect() throws. That logic should be removed. Reconnection should only be attempted at a higher level (MultiExchange).
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26087#pullrequestreview-2986730094

From vyazici at openjdk.org  Fri Jul  4 11:29:43 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 4 Jul 2025 11:29:43 GMT
Subject: Withdrawn: 8361337: java/net/URLPermission/nstest/LookupTest.java
 should open connections with NO_PROXY
In-Reply-To: <9WjED6h2N7Hs1QOSAqkttl1TTm3l-5a0m_e6Em7YFD8=.f42b7917-4827-4437-a988-6cbdb284d59b@github.com>
References: <9WjED6h2N7Hs1QOSAqkttl1TTm3l-5a0m_e6Em7YFD8=.f42b7917-4827-4437-a988-6cbdb284d59b@github.com>
Message-ID: <ntY0BBICF1KH-OndKWO7A19sENl9PQSl7IAmgGCmUfU=.78f84236-8998-4564-b760-f73d1617916a@github.com>

On Thu, 3 Jul 2025 20:25:13 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Explicitly use `NO_PROXY` in `LookupTest` to avoid test failures on environments where proxy is configured. Updated test run results on various platforms are attached to the ticket.

This pull request has been closed without being integrated.

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

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

From michaelm at openjdk.org  Fri Jul  4 13:10:40 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 4 Jul 2025 13:10:40 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be
 simplified [v3]
In-Reply-To: <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
 <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>
Message-ID: <e7k1bPiB4vJleiX-OskpC_e9bd39z9SnbxMREVXwgTM=.94f393bd-4690-41ae-b7f6-a7737757419a@github.com>

On Fri, 4 Jul 2025 08:34:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The PlainHttpConnection::connectAsync method implements a retry logic that will call connect() again if connect() throws the first time. This will not work, as the channel is closed when connect() throws. That logic should be removed. Reconnection should only be attempted at a higher level (MultiExchange).
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

I think this code was added to deal with https://bugs.openjdk.org/browse/JDK-8256459. Did the change not fix that problem?

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

PR Comment: https://git.openjdk.org/jdk/pull/26087#issuecomment-3036234987

From dfuchs at openjdk.org  Fri Jul  4 13:45:39 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Jul 2025 13:45:39 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be
 simplified [v3]
In-Reply-To: <e7k1bPiB4vJleiX-OskpC_e9bd39z9SnbxMREVXwgTM=.94f393bd-4690-41ae-b7f6-a7737757419a@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
 <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>
 <e7k1bPiB4vJleiX-OskpC_e9bd39z9SnbxMREVXwgTM=.94f393bd-4690-41ae-b7f6-a7737757419a@github.com>
Message-ID: <brlHMMLt2dkwENcByhtYKbSMsM4peLgbc_EdrKSmO9w=.b62e1099-b458-4006-bb06-d7aeab4e7563@github.com>

On Fri, 4 Jul 2025 13:08:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>I think this code was added to deal with https://bugs.openjdk.org/browse/JDK-8256459. Did the change not fix that problem? Or did that change include the changes to MultiExchange you mention above?

The change did not include changes to the multi exchange but it included changes to the tests themselves.
I fail to see how calling connect() again on the same channel could have solved the issue: I verified by code inspection that the channel is closed when connect() fails - and calling connect() again simply generates a ClosedChannelException.

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

PR Comment: https://git.openjdk.org/jdk/pull/26087#issuecomment-3036323261

From michaelm at openjdk.org  Fri Jul  4 15:18:37 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 4 Jul 2025 15:18:37 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be
 simplified [v3]
In-Reply-To: <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
 <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>
Message-ID: <d1F109DW3tQ7AvDueighrLa_7WtQfw_CJ5My5WvKbis=.3594c640-dd7f-43b4-9969-338e685148cf@github.com>

On Fri, 4 Jul 2025 08:34:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The PlainHttpConnection::connectAsync method implements a retry logic that will call connect() again if connect() throws the first time. This will not work, as the channel is closed when connect() throws. That logic should be removed. Reconnection should only be attempted at a higher level (MultiExchange).
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by michaelm (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26087#pullrequestreview-2987637089

From jpai at openjdk.org  Mon Jul  7 07:07:39 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Jul 2025 07:07:39 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be
 simplified [v3]
In-Reply-To: <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
 <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>
Message-ID: <OFXrXzR5pjq84o5BbXh2CAj7wPbKH84E0nVwkQqvIvU=.acfeeffe-3cc0-4d8c-a2bb-81b7e96dafc1@github.com>

On Fri, 4 Jul 2025 08:34:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The PlainHttpConnection::connectAsync method implements a retry logic that will call connect() again if connect() throws the first time. This will not work, as the channel is closed when connect() throws. That logic should be removed. Reconnection should only be attempted at a higher level (MultiExchange).
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Hello Daniel, the changes look good to me. I went back and looked at the original issue where this code was introduced and you are right that this very likely wasn't necessary. The removal of the `ConnectionState` altogether, also makes this much more simpler.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26087#pullrequestreview-2992441833

From vyazici at openjdk.org  Mon Jul  7 07:39:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Jul 2025 07:39:20 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel method
Message-ID: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>

Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:

> The file channel will not be closed upon completion. The caller is
> expected to manage the life cycle of the channel, and close it
> appropriately when not needed anymore.

### Implementation notes

- `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
- `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

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

Commit messages:
 - Add `HttpRequest.BodyPublishers::ofFileChannel` along with tests

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

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

From dfuchs at openjdk.org  Mon Jul  7 08:24:45 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Jul 2025 08:24:45 GMT
Subject: RFR: 8361249: PlainHttpConnection connection logic can be
 simplified [v3]
In-Reply-To: <wsP4Mthi5PCdfG1s8eEbRpZJdxcXNqQ5NrtDhTODBRA=.73ac6274-bdbe-4036-a472-dec6b7c62222@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
 <eVL4p7I5LI1ErLsaplfDW5bTSsdy_lEx6veqfuiccqQ=.0bcc0462-9f46-4ca5-af3f-96fdd617325d@github.com>
 <wsP4Mthi5PCdfG1s8eEbRpZJdxcXNqQ5NrtDhTODBRA=.73ac6274-bdbe-4036-a472-dec6b7c62222@github.com>
Message-ID: <aTIazto4XKpjY_AdmOrpoiatyrJM1zfCVxYLsTSUHWU=.a5c8f591-dcef-4619-b24d-43263bc4de12@github.com>

On Fri, 4 Jul 2025 09:04:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> Marked as reviewed by djelinski (Reviewer).

Thanks @djelinski @jaikiran @Michael-Mc-Mahon @vy for the reviews! I will integrate now.

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

PR Comment: https://git.openjdk.org/jdk/pull/26087#issuecomment-3043943719

From dfuchs at openjdk.org  Mon Jul  7 08:24:46 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Jul 2025 08:24:46 GMT
Subject: Integrated: 8361249: PlainHttpConnection connection logic can be
 simplified
In-Reply-To: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
References: <ExPX7NmUC0-08MuJCQ9zQvHK1GsSrQ6Mo5BIUzum_uk=.80e30f00-9221-4c50-be3e-753fd7abb23b@github.com>
Message-ID: <kLGSVcvAxh9JegU6OIydo-B-OkycOzGrD-AYN_hFBvc=.41b0c1ed-a6e1-49c4-a6e5-5066a41207a4@github.com>

On Wed, 2 Jul 2025 08:37:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The PlainHttpConnection::connectAsync method implements a retry logic that will call connect() again if connect() throws the first time. This will not work, as the channel is closed when connect() throws. That logic should be removed. Reconnection should only be attempted at a higher level (MultiExchange).

This pull request has now been integrated.

Changeset: 8ad48368
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ad48368838588846324550c455c66ae86f1226b
Stats:     60 lines in 1 file changed: 2 ins; 52 del; 6 mod

8361249: PlainHttpConnection connection logic can be simplified

Reviewed-by: djelinski, vyazici, michaelm, jpai

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

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

From dfuchs at openjdk.org  Mon Jul  7 08:47:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Jul 2025 08:47:40 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <yiJVLH2Q8O8HaY17LQQCv5LKt8Ze7cul3XmpLPHT69s=.6f1b8d87-4a13-4ad6-991c-770fa44bc772@github.com>

On Mon, 7 Jul 2025 07:33:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

src/java.net.http/share/classes/java/net/http/HttpRequest.java line 739:

> 737:          * @param channel a file channel
> 738:          * @param offset the offset of the first byte
> 739:          * @param length the number of bytes to use

I'd suggest to say something like:
> the number of bytes to send

or
> the number of bytes to read from the file channel

src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 488:

> 486:             ByteBuffer buffer = Utils.BUFSIZE > remaining
> 487:                     ? Utils.getBufferWithAtMost((int) remaining)
> 488:                     : Utils.getBuffer();

I suggest to change `Utils.getBufferWithAtMost` to take a long instead of an int, and replace the ternary operator here with simply:

ByteBuffer buffer = Utils.getBufferWithAtMost(remaining);

src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 386:

> 384:      * @throws IllegalArgumentException if {@code capacity < 0}
> 385:      */
> 386:     public static ByteBuffer getBufferWithAtMost(int maxCapacity) {

Suggestion:

    public static ByteBuffer getBufferWithAtMost(long maxCapacity) {


We could accept `long` here.

src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 392:

> 390:                     "capacity < 0: (%s < 0)".formatted(maxCapacity));
> 391:         }
> 392:         int effectiveCapacity = Math.clamp(maxCapacity, 0, BUFSIZE);

Suggestion:

        int effectiveCapacity = (int) Math.min(maxCapacity, (long) BUFSIZE);

Use Math.min(long,long) - since BUFZIZE is an int we can safely cast back to int. No need to clamp at 0 since we verified maxCapacity >= 0

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2189357089
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2189371496
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2189386033
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2189383920

From dfuchs at openjdk.org  Mon Jul  7 08:47:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Jul 2025 08:47:40 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method
In-Reply-To: <yiJVLH2Q8O8HaY17LQQCv5LKt8Ze7cul3XmpLPHT69s=.6f1b8d87-4a13-4ad6-991c-770fa44bc772@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <yiJVLH2Q8O8HaY17LQQCv5LKt8Ze7cul3XmpLPHT69s=.6f1b8d87-4a13-4ad6-991c-770fa44bc772@github.com>
Message-ID: <ToxK9BHZLtnwco99Ie8MdNQhavzrAj1PmGtz7n9dzg8=.db30c9b3-cee4-4e5a-8283-65f7ebbe11c3@github.com>

On Mon, 7 Jul 2025 08:29:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 739:
> 
>> 737:          * @param channel a file channel
>> 738:          * @param offset the offset of the first byte
>> 739:          * @param length the number of bytes to use
> 
> I'd suggest to say something like:
>> the number of bytes to send
> 
> or
>> the number of bytes to read from the file channel

It might be also useful to specify what happens if length is zero or negative. Either here or in the `@throws` below if an exception is going to be thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2189360176

From vyazici at openjdk.org  Mon Jul  7 09:32:33 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Jul 2025 09:32:33 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v2]
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <6WB4eKx3ZvooH-P60TuaJp8q3f3X2AcdZsXf6EtYfgs=.0f137df4-f3cc-463a-92e1-17d19fa26259@github.com>

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

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

  Implement review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/bdeb999b..0eda56f1

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

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

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

From vyazici at openjdk.org  Mon Jul  7 09:32:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Jul 2025 09:32:34 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v2]
In-Reply-To: <ToxK9BHZLtnwco99Ie8MdNQhavzrAj1PmGtz7n9dzg8=.db30c9b3-cee4-4e5a-8283-65f7ebbe11c3@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <yiJVLH2Q8O8HaY17LQQCv5LKt8Ze7cul3XmpLPHT69s=.6f1b8d87-4a13-4ad6-991c-770fa44bc772@github.com>
 <ToxK9BHZLtnwco99Ie8MdNQhavzrAj1PmGtz7n9dzg8=.db30c9b3-cee4-4e5a-8283-65f7ebbe11c3@github.com>
Message-ID: <yDGsBWswqgJ1hUl38YXl9DkeUsUTVfKmqKm_9Nbnj_M=.d1c56d11-fde6-4e1c-9fdc-56a545a7c166@github.com>

On Mon, 7 Jul 2025 08:31:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 739:
>> 
>>> 737:          * @param channel a file channel
>>> 738:          * @param offset the offset of the first byte
>>> 739:          * @param length the number of bytes to use
>> 
>> I'd suggest to say something like:
>>> the number of bytes to send
>> 
>> or
>>> the number of bytes to read from the file channel
>
> It might be also useful to specify what happens if length is zero or negative. Either here or in the `@throws` below if an exception is going to be thrown.

1. Improved the wording as suggested in 0eda56f18a2
2. There is already a `@throws IndexOutOfBoundsException` warning against invalid bounds specification

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2189486769

From vyazici at openjdk.org  Mon Jul  7 09:32:36 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Jul 2025 09:32:36 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v2]
In-Reply-To: <yiJVLH2Q8O8HaY17LQQCv5LKt8Ze7cul3XmpLPHT69s=.6f1b8d87-4a13-4ad6-991c-770fa44bc772@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <yiJVLH2Q8O8HaY17LQQCv5LKt8Ze7cul3XmpLPHT69s=.6f1b8d87-4a13-4ad6-991c-770fa44bc772@github.com>
Message-ID: <OpDlJUzI2h1EPS1iM6o5cl0QqW_y7qvsPb3rT_8v990=.91368ebf-87cf-474b-9d6c-1ef6158b28d0@github.com>

On Mon, 7 Jul 2025 08:36:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement review feedback
>
> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 488:
> 
>> 486:             ByteBuffer buffer = Utils.BUFSIZE > remaining
>> 487:                     ? Utils.getBufferWithAtMost((int) remaining)
>> 488:                     : Utils.getBuffer();
> 
> I suggest to change `Utils.getBufferWithAtMost` to take a long instead of an int, and replace the ternary operator here with simply:
> 
> ByteBuffer buffer = Utils.getBufferWithAtMost(remaining);

Implemented in 0eda56f18a2.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 386:
> 
>> 384:      * @throws IllegalArgumentException if {@code capacity < 0}
>> 385:      */
>> 386:     public static ByteBuffer getBufferWithAtMost(int maxCapacity) {
> 
> Suggestion:
> 
>     public static ByteBuffer getBufferWithAtMost(long maxCapacity) {
> 
> 
> We could accept `long` here.

Implemented in 0eda56f18a2.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 392:
> 
>> 390:                     "capacity < 0: (%s < 0)".formatted(maxCapacity));
>> 391:         }
>> 392:         int effectiveCapacity = Math.clamp(maxCapacity, 0, BUFSIZE);
> 
> Suggestion:
> 
>         int effectiveCapacity = (int) Math.min(maxCapacity, (long) BUFSIZE);
> 
> Use Math.min(long,long) - since BUFZIZE is an int we can safely cast back to int. No need to clamp at 0 since we verified maxCapacity >= 0

Implemented in 0eda56f18a2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2189487270
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2189487509
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2189487815

From dfuchs at openjdk.org  Mon Jul  7 09:48:45 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Jul 2025 09:48:45 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v2]
In-Reply-To: <6WB4eKx3ZvooH-P60TuaJp8q3f3X2AcdZsXf6EtYfgs=.0f137df4-f3cc-463a-92e1-17d19fa26259@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <6WB4eKx3ZvooH-P60TuaJp8q3f3X2AcdZsXf6EtYfgs=.0f137df4-f3cc-463a-92e1-17d19fa26259@github.com>
Message-ID: <UYcynxuE1j1ZdvbFgJbxIJ6n_JJdn5SQYvux7OHWhXA=.d93576f2-cf07-4301-9179-2d4f7b26a5bd@github.com>

On Mon, 7 Jul 2025 09:32:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback

src/java.net.http/share/classes/java/net/http/HttpRequest.java line 743:

> 741:          * @throws IndexOutOfBoundsException if the specified byte range is
> 742:          * found to be out of bounds compared with the size of the file
> 743:          * referred by the channel

So we accept length = 0 (OK though not very useful?) and we reject length < 0 (which is good). Maybe we should say:
Suggestion:

         * @throws IndexOutOfBoundsException if the specified byte range is
         * found to be {@linkplain Objects.checkFromIndexSize(long, long, long) out of bounds}
         * compared with the size of the file referred by the channel

to clarify that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2189525585

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 vyazici at openjdk.org  Mon Jul  7 10:41:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Jul 2025 10:41:58 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v3]
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

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

  Improve docs on `IndexOutOfBoundsException` thrown
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/0eda56f1..3af61c5f

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

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

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

From duke at openjdk.org  Mon Jul  7 15:40:50 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 7 Jul 2025 15:40:50 GMT
Subject: RFR: 8361188: Test
 java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X
Message-ID: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>

Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase.

Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file.

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

Depends on: https://git.openjdk.org/jdk/pull/25971

Commit messages:
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'openjdk:master' into jdk-8361188
 - Removes test from Problem List
 - Returns false if component is null, in the case of embedded frame

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

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

From jwaters at openjdk.org  Tue Jul  8 01:32:52 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 8 Jul 2025 01:32:52 GMT
Subject: RFR: 8342868: Errors related to unused code on Windows after
 8339120 in core libs [v2]
In-Reply-To: <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
Message-ID: <rfLuoC6GYaQTru1_jqseSC266NbVP4Kxe2J6FikGXeQ=.97a3a13d-4f90-41f4-b210-a0080351cc06@github.com>

On Thu, 31 Oct 2024 05:43:11 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
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the got local

Sorry for waiting so long. It's become clear that I won't be able to get awt and accessibility up to speed for a long time, so I will go ahead with this one first

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

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-3047051283

From jwaters at openjdk.org  Tue Jul  8 01:32:52 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 8 Jul 2025 01:32:52 GMT
Subject: Integrated: 8342868: Errors related to unused code on Windows after
 8339120 in core libs
In-Reply-To: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
Message-ID: <BiH2aLfK4drXAlv019OG10zJ7EVuyuXLB-U6VpprXkw=.d9de799f-7607-4ff2-b033-5614fdda16f7@github.com>

On Wed, 23 Oct 2024 04:40:50 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: bbc5c98b
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bbc5c98b144014a0423d666f74c4a5a15b08a7c2
Stats:     19 lines in 4 files changed: 9 ins; 0 del; 10 mod

8342868: Errors related to unused code on Windows after 8339120 in core libs

Reviewed-by: naoto, jlu

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

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

From dholmes at openjdk.org  Tue Jul  8 01:51:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 01:51:47 GMT
Subject: RFR: 8342868: Errors related to unused code on Windows after
 8339120 in core libs [v2]
In-Reply-To: <rfLuoC6GYaQTru1_jqseSC266NbVP4Kxe2J6FikGXeQ=.97a3a13d-4f90-41f4-b210-a0080351cc06@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
 <rfLuoC6GYaQTru1_jqseSC266NbVP4Kxe2J6FikGXeQ=.97a3a13d-4f90-41f4-b210-a0080351cc06@github.com>
Message-ID: <lZLJ957P7sONaS2DMlqED9bApOqJk3jhx910dFjSdTs=.09ca21d0-f864-4f7e-b48b-a0c9c39cebef@github.com>

On Tue, 8 Jul 2025 01:28:04 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the got local
>
> Sorry for waiting so long. It's become clear that I won't be able to get awt and accessibility up to speed for a long time, so I will go ahead with this one first

@TheShermanTanker the commented out code really should have been deleted, not just left commented out. Please file anpther JBS issue to have this cleaned up so it is not forgotten. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-3047084740

From jpai at openjdk.org  Tue Jul  8 04:22:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Jul 2025 04:22:48 GMT
Subject: RFR: 8342868: Errors related to unused code on Windows after
 8339120 in core libs [v2]
In-Reply-To: <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
Message-ID: <AL7IdqZqHz7sM-oppG4NW7umIRhri6uP6EHbCiC3f8c=.9a16c98f-f47a-488c-83cf-cbefa6f4b206@github.com>

On Thu, 31 Oct 2024 05:43:11 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
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the got local

> Since your change was applied there have been 3762 commits pushed to the master branch

It's usually risky to be integrating a PR which is so far behind the master branch, without first merging the latest changes and running the tier tests. In this case it hasn't caused any failures in the tier testing so far.

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

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-3047304336

From jwaters at openjdk.org  Tue Jul  8 11:30:53 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 8 Jul 2025 11:30:53 GMT
Subject: RFR: 8342868: Errors related to unused code on Windows after
 8339120 in core libs [v2]
In-Reply-To: <AL7IdqZqHz7sM-oppG4NW7umIRhri6uP6EHbCiC3f8c=.9a16c98f-f47a-488c-83cf-cbefa6f4b206@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
 <AL7IdqZqHz7sM-oppG4NW7umIRhri6uP6EHbCiC3f8c=.9a16c98f-f47a-488c-83cf-cbefa6f4b206@github.com>
Message-ID: <WVnsaTB9LG9tXyWUvvwkTJwB_tURy3D8emcDgm6MLYc=.20d504a2-5f0b-4ba9-83ad-58dd8bacf2f5@github.com>

On Tue, 8 Jul 2025 04:20:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > Since your change was applied there have been 3762 commits pushed to the master branch
> 
> It's usually risky to be integrating a PR which is so far behind the master branch, without first merging the latest changes and running the tier tests. In this case it hasn't caused any failures in the tier testing so far.

I'll keep that in mind next time I'm submitting another Pull Request. Fortunately in this case the code touched was dead code and in an area that isn't touched often, so shouldn't cause major issues

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

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-3048519346

From jwaters at openjdk.org  Tue Jul  8 11:36:01 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 8 Jul 2025 11:36:01 GMT
Subject: RFR: 8342868: Errors related to unused code on Windows after
 8339120 in core libs [v2]
In-Reply-To: <lZLJ957P7sONaS2DMlqED9bApOqJk3jhx910dFjSdTs=.09ca21d0-f864-4f7e-b48b-a0c9c39cebef@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
 <rfLuoC6GYaQTru1_jqseSC266NbVP4Kxe2J6FikGXeQ=.97a3a13d-4f90-41f4-b210-a0080351cc06@github.com>
 <lZLJ957P7sONaS2DMlqED9bApOqJk3jhx910dFjSdTs=.09ca21d0-f864-4f7e-b48b-a0c9c39cebef@github.com>
Message-ID: <wbmC__Bvok7OvAVrLnNhrdyEHS4w2MGwbBT3GVhKwls=.a2c90515-9d50-4e76-b18b-94018f35fa33@github.com>

On Tue, 8 Jul 2025 01:49:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sorry for waiting so long. It's become clear that I won't be able to get awt and accessibility up to speed for a long time, so I will go ahead with this one first
>
> @TheShermanTanker the commented out code really should have been deleted, not just left commented out. Please file anpther JBS issue to have this cleaned up so it is not forgotten. Thanks.

@dholmes-ora Sorry about that. Here's the issue as was requested: https://bugs.openjdk.org/browse/JDK-8361593

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

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-3048532200

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 dclarke at openjdk.org  Tue Jul  8 14:33:04 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Tue, 8 Jul 2025 14:33:04 GMT
Subject: RFR: 8352502: Response message is null if expect 100 assertion
 fails with non 100 [v2]
In-Reply-To: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
References: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
Message-ID: <VCqeIyWA9eWOGHq3B3k6oETnePJJ9WjBo34zOsGn_hA=.c73b3bbb-c119-4245-b97b-d1479b10cc00@github.com>

> Currently if a request has set Expect-Continue and receives a non 100 response the `responseMessage` wouldn't be set.
> 
> This PR sets `responseMessage`, it also updates `getResponseMessage` to check if the message has already been set. This should match the way that `responseCode` is currently handled.
> 
> I also added a test to cover some possible responses.

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

 - removed unneeded library
 - more cleanup
 - moved test, implemented feedback
 - merged master into branch
 - implementing comments
 - Response Message could be null

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25999/files
  - new: https://git.openjdk.org/jdk/pull/25999/files/10563157..d6f27780

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

  Stats: 113948 lines in 2239 files changed: 68346 ins; 28980 del; 16622 mod
  Patch: https://git.openjdk.org/jdk/pull/25999.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25999/head:pull/25999

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

From dfuchs at openjdk.org  Tue Jul  8 14:42:42 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 8 Jul 2025 14:42:42 GMT
Subject: RFR: 8352502: Response message is null if expect 100 assertion
 fails with non 100 [v2]
In-Reply-To: <VCqeIyWA9eWOGHq3B3k6oETnePJJ9WjBo34zOsGn_hA=.c73b3bbb-c119-4245-b97b-d1479b10cc00@github.com>
References: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
 <VCqeIyWA9eWOGHq3B3k6oETnePJJ9WjBo34zOsGn_hA=.c73b3bbb-c119-4245-b97b-d1479b10cc00@github.com>
Message-ID: <N7NnUpUDcTKVVEDCMrpehGWFhToReIXTfOxfdCikleM=.1be55e9d-4af2-4b2e-a979-fa96fa982734@github.com>

On Tue, 8 Jul 2025 14:33:04 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently if a request has set Expect-Continue and receives a non 100 response the `responseMessage` wouldn't be set.
>> 
>> This PR sets `responseMessage`, it also updates `getResponseMessage` to check if the message has already been set. This should match the way that `responseCode` is currently handled.
>> 
>> I also added a test to cover some possible responses.
>
> Darragh Clarke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - removed unneeded library
>  - more cleanup
>  - moved test, implemented feedback
>  - merged master into branch
>  - implementing comments
>  - Response Message could be null

I believe this looks good. Please make sure the test is stable over all supported platforms before integrating.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25999#pullrequestreview-2997964242

From dfuchs at openjdk.org  Tue Jul  8 14:51:43 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 8 Jul 2025 14:51:43 GMT
Subject: RFR: 8352502: Response message is null if expect 100 assertion
 fails with non 100 [v2]
In-Reply-To: <VCqeIyWA9eWOGHq3B3k6oETnePJJ9WjBo34zOsGn_hA=.c73b3bbb-c119-4245-b97b-d1479b10cc00@github.com>
References: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
 <VCqeIyWA9eWOGHq3B3k6oETnePJJ9WjBo34zOsGn_hA=.c73b3bbb-c119-4245-b97b-d1479b10cc00@github.com>
Message-ID: <VZAEr0ykZUc34-0zYd3DNe-b8RsK5ln4Hz7sCSXPRAM=.63ea028d-976c-4c93-a5d4-3ddbb65e5a1e@github.com>

On Tue, 8 Jul 2025 14:33:04 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently if a request has set Expect-Continue and receives a non 100 response the `responseMessage` wouldn't be set.
>> 
>> This PR sets `responseMessage`, it also updates `getResponseMessage` to check if the message has already been set. This should match the way that `responseCode` is currently handled.
>> 
>> I also added a test to cover some possible responses.
>
> Darragh Clarke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - removed unneeded library
>  - more cleanup
>  - moved test, implemented feedback
>  - merged master into branch
>  - implementing comments
>  - Response Message could be null

Changes requested by dfuchs (Reviewer).

test/jdk/java/net/HttpURLConnection/HttpUrlConnectionExpectContinueResponseMessageTest.java line 177:

> 175:                 .loopback()
> 176:                 .port(control.serverSocket.getLocalPort())
> 177:                 .toURL();

It could be good to add some salt to the URL path here, and verify the path on the server side, to weed out any random connections that could be made to our server by other processes.

You'd need to have validated the path before assigning control.acceptingSocket, and just close the accepted socket (or better send something like a 500 response before closing the socket) if the path doesn't match the expectation.

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

PR Review: https://git.openjdk.org/jdk/pull/25999#pullrequestreview-2997999954
PR Review Comment: https://git.openjdk.org/jdk/pull/25999#discussion_r2192736405

From dclarke at openjdk.org  Thu Jul 10 13:28:26 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Thu, 10 Jul 2025 13:28:26 GMT
Subject: RFR: 8352502: Response message is null if expect 100 assertion
 fails with non 100 [v3]
In-Reply-To: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
References: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
Message-ID: <irAM7GphyMXZ5917QklArwZwvx7bTxb2-t0O0BHcp6Y=.d18d1a4a-bed5-4b4f-bc44-9e3d3cfd739c@github.com>

> Currently if a request has set Expect-Continue and receives a non 100 response the `responseMessage` wouldn't be set.
> 
> This PR sets `responseMessage`, it also updates `getResponseMessage` to check if the message has already been set. This should match the way that `responseCode` is currently handled.
> 
> I also added a test to cover some possible responses.

Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:

  adding salting and path verification to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25999/files
  - new: https://git.openjdk.org/jdk/pull/25999/files/d6f27780..0d826d75

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

  Stats: 79 lines in 1 file changed: 33 ins; 24 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/25999.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25999/head:pull/25999

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

From dclarke at openjdk.org  Thu Jul 10 13:28:28 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Thu, 10 Jul 2025 13:28:28 GMT
Subject: RFR: 8352502: Response message is null if expect 100 assertion
 fails with non 100 [v2]
In-Reply-To: <VCqeIyWA9eWOGHq3B3k6oETnePJJ9WjBo34zOsGn_hA=.c73b3bbb-c119-4245-b97b-d1479b10cc00@github.com>
References: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
 <VCqeIyWA9eWOGHq3B3k6oETnePJJ9WjBo34zOsGn_hA=.c73b3bbb-c119-4245-b97b-d1479b10cc00@github.com>
Message-ID: <C-0TVFYrXRoHIHmZc2qBhinD--yjUwjIjJcWkVBQ5mY=.7196ea6e-b11b-4ddc-a220-667abaa17ec6@github.com>

On Tue, 8 Jul 2025 14:33:04 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently if a request has set Expect-Continue and receives a non 100 response the `responseMessage` wouldn't be set.
>> 
>> This PR sets `responseMessage`, it also updates `getResponseMessage` to check if the message has already been set. This should match the way that `responseCode` is currently handled.
>> 
>> I also added a test to cover some possible responses.
>
> Darragh Clarke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - removed unneeded library
>  - more cleanup
>  - moved test, implemented feedback
>  - merged master into branch
>  - implementing comments
>  - Response Message could be null

I added salting to the test and some handling on the serverSocket to check for it.
I may have overcomplicated the rewrite to include that change so feel free to request more changes

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

PR Comment: https://git.openjdk.org/jdk/pull/25999#issuecomment-3057455458

From egahlin at openjdk.org  Fri Jul 11 09:34:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 11 Jul 2025 09:34:04 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events
Message-ID: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>

Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).

Testing: tier1, tier2 + jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Cleanup and socket adapters
 - Use switch expression
 - Revert accidental move
 - Fix whitespace
 - Initial

Changes: https://git.openjdk.org/jdk/pull/26211/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26211&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361639
  Stats: 375 lines in 6 files changed: 358 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26211.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26211/head:pull/26211

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

From alanb at openjdk.org  Fri Jul 11 09:34:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 11 Jul 2025 09:34:04 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
Message-ID: <MV4RYfuS8-dFDAe7y7a-M9B3Dr8fHq4clqMDWWcMg60=.66456e63-9fc8-494c-8641-5e2ade4975bd@github.com>

On Wed, 9 Jul 2025 05:49:30 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).
> 
> Testing: tier1, tier2 + jdk/jdk/jfr
> 
> Thanks
> Erik

test/jdk/jdk/jfr/event/io/TestIOTopFrame.java line 74:

> 72:         testFileRead();
> 73:         testSocketStreams();
> 74:         testSocketChannels();

The other case is the socket adaptor, as in SocketChannel::socket.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26211#discussion_r2195672061

From egahlin at openjdk.org  Fri Jul 11 09:34:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 11 Jul 2025 09:34:04 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <MV4RYfuS8-dFDAe7y7a-M9B3Dr8fHq4clqMDWWcMg60=.66456e63-9fc8-494c-8641-5e2ade4975bd@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
 <MV4RYfuS8-dFDAe7y7a-M9B3Dr8fHq4clqMDWWcMg60=.66456e63-9fc8-494c-8641-5e2ade4975bd@github.com>
Message-ID: <_pYZlNrH5axGeFZQrBzLb69rU55YsqlrMW5abLBJ-zU=.2e64c02e-eeab-4cd2-8caf-9d32b55ada89@github.com>

On Wed, 9 Jul 2025 17:59:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).
>> 
>> Testing: tier1, tier2 + jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> test/jdk/jdk/jfr/event/io/TestIOTopFrame.java line 74:
> 
>> 72:         testFileRead();
>> 73:         testSocketStreams();
>> 74:         testSocketChannels();
> 
> The other case is the socket adaptor, as in SocketChannel::socket.

I added support for adapters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26211#discussion_r2200197667