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

From mgronlun at openjdk.org  Mon Jul 14 17:13:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 14 Jul 2025 17:13:40 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: <VKhafG65tsvM-yVACtNDZQ8qtlzcXCaoMu3THp629YM=.b13560e8-8fff-4f75-bf9a-63fc04bbe7b7@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

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26211#pullrequestreview-3017130373

From mullan at openjdk.org  Mon Jul 14 19:24:51 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 14 Jul 2025 19:24:51 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal
Message-ID: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>

`SocketPermission` should be deprecated for removal as has already been done for many other `Permission` subclasses. However, `CodeSource.implies()` has specification dependencies on `SocketPermission` which requires additional changes to decouple those dependencies. 

This change deprecates `SocketPermission`for removal and removes the dependency on `SocketPermission` from `CodeSource.implies` by copying the relevant conditions from `SocketPermission.implies`. Additional test cases for `CodeSource.implies` were also added to check that the behavior is consistent.

Note that we may also eventually deprecate `CodeSource.implies` for removal but that requires more investigation.

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

Commit messages:
 - Initial revision.

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

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

From mullan at openjdk.org  Mon Jul 14 20:04:21 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 14 Jul 2025 20:04:21 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal [v2]
In-Reply-To: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
Message-ID: <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>

> `SocketPermission` should be deprecated for removal as has already been done for many other `Permission` subclasses. However, `CodeSource.implies()` has specification dependencies on `SocketPermission` which requires additional changes to decouple those dependencies. 
> 
> This change deprecates `SocketPermission`for removal and removes the dependency on `SocketPermission` from `CodeSource.implies` by copying the relevant conditions from `SocketPermission.implies`. Additional test cases for `CodeSource.implies` were also added to check that the behavior is consistent.
> 
> Note that we may also eventually deprecate `CodeSource.implies` for removal but that requires more investigation.

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  Add @SuppressWarnings("removal") to SocketPermissionCollection.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26300/files
  - new: https://git.openjdk.org/jdk/pull/26300/files/593cab32..0f8c2635

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

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

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

From duke at openjdk.org  Tue Jul 15 12:20:52 2025
From: duke at openjdk.org (ayush)
Date: Tue, 15 Jul 2025 12:20:52 GMT
Subject: RFR: 8361423: Add IPSupport::printPlatformSupport to
 java/net/NetworkInterface/IPv4Only.java
Message-ID: <1Xf_CvxGu7V6gvORFp2wID-N9likuBpwW2IMg2EwY2s=.bcef3082-4a24-43ea-8ae8-b7502afebd3b@github.com>

This is part of a series of diagnostic output updates to java.net tests to assist in the analysis of failures in IPv6 only environments
for Linux there is not IPv4 configuration but the IPv4 stack remains enabled
For macOS, and windows the IPv4 stacks are disabled, and IPv4 configuration removed

add IPSupport::printPlatformSupport(System.out);

to the start of main

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

Commit messages:
 - 8361423: Add IPSupport::printPlatformSupport to java/net/NetworkInterface/IPv4Only.java
 - 8361423: Add IPSupport::printPlatformSupport to java/net/NetworkInterface/IPv4Only.java

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

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

From myankelevich at openjdk.org  Tue Jul 15 12:20:53 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 15 Jul 2025 12:20:53 GMT
Subject: RFR: 8361423: Add IPSupport::printPlatformSupport to
 java/net/NetworkInterface/IPv4Only.java
In-Reply-To: <1Xf_CvxGu7V6gvORFp2wID-N9likuBpwW2IMg2EwY2s=.bcef3082-4a24-43ea-8ae8-b7502afebd3b@github.com>
References: <1Xf_CvxGu7V6gvORFp2wID-N9likuBpwW2IMg2EwY2s=.bcef3082-4a24-43ea-8ae8-b7502afebd3b@github.com>
Message-ID: <UtLA5I-DS-L_ZPCoVY-UQmw36_AX6fshMkgWbA3r9Po=.50f23eb5-ba92-4448-8112-a4da656a4e43@github.com>

On Fri, 11 Jul 2025 13:39:33 GMT, ayush <duke at openjdk.org> wrote:

> This is part of a series of diagnostic output updates to java.net tests to assist in the analysis of failures in IPv6 only environments
> for Linux there is not IPv4 configuration but the IPv4 stack remains enabled
> For macOS, and windows the IPv4 stacks are disabled, and IPv4 configuration removed
> 
> add IPSupport::printPlatformSupport(System.out);
> 
> to the start of main

test/jdk/java/net/NetworkInterface/IPv4Only.java line 35:

> 33: import java.util.*;
> 34: import jdk.test.lib.net.IPSupport;
> 35: 

Please add a `2025` to the copyright at the top:


 * Copyright (c) 2010, 2025, Oracle and/or its affiliates. All rights reserved.

test/jdk/java/net/NetworkInterface/IPv4Only.java line 35:

> 33: import java.util.*;
> 34: import jdk.test.lib.net.IPSupport;
> 35: 

Minor: Could you please change the wildcard imports to explicit ones

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26265#discussion_r2200815013
PR Review Comment: https://git.openjdk.org/jdk/pull/26265#discussion_r2200816692

From alanb at openjdk.org  Tue Jul 15 13:40:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 13:40:40 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: <PssjHDEO4S_0nt2Fp7ScTVnXy0d29UV_6nTUCMD9znk=.05236d63-32ab-46d5-acbc-64997ffa654f@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

src/jdk.jfr/share/classes/jdk/jfr/events/FileReadEvent.java line 44:

> 42:               "java.io.DataInputStream",
> 43:               "java.io.FileInputStream",
> 44:               "java.io.InputStream",

Do you have any stack traces handy that could be pasted into the JBS issue or the PR so that it's clear why InputStream and Data*Stream frames are filtered?

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

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

From egahlin at openjdk.org  Tue Jul 15 17:45:42 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 17:45:42 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <PssjHDEO4S_0nt2Fp7ScTVnXy0d29UV_6nTUCMD9znk=.05236d63-32ab-46d5-acbc-64997ffa654f@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
 <PssjHDEO4S_0nt2Fp7ScTVnXy0d29UV_6nTUCMD9znk=.05236d63-32ab-46d5-acbc-64997ffa654f@github.com>
Message-ID: <hL-E9pYQLno41aDU1wj1ndSGNM3-A6-47XDEz9-op34=.c548f6ce-c37b-492e-8ab8-ccd6f55bd3e9@github.com>

On Tue, 15 Jul 2025 13:38:28 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
>
> src/jdk.jfr/share/classes/jdk/jfr/events/FileReadEvent.java line 44:
> 
>> 42:               "java.io.DataInputStream",
>> 43:               "java.io.FileInputStream",
>> 44:               "java.io.InputStream",
> 
> Do you have any stack traces handy that could be pasted into the JBS issue or the PR so that it's clear why InputStream and Data*Stream frames are filtered?

It's DataInputStream::readUTF(DataInput in), used by RandomAccessFile::readUTF(), and InputStream::readNBytes(byte[], int, int), which is not overridden by FileInputStream. (FileRead)

DataOutputStream::writeUTF(DataOutput) used by RandomAccessFile::writeUTF (FileWrite)

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

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

From bchristi at openjdk.org  Wed Jul 16 03:55:40 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 16 Jul 2025 03:55:40 GMT
Subject: [jdk25] RFR: Merge 121f5a72e4c23919b3a3b474cc3f1ac29ec611af
Message-ID: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>

This brings in cpu25_07 changes.

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

Commit messages:
 - 8360147: Better Glyph drawing redux
 - 8355884: [macos] java/awt/Frame/I18NTitle.java fails on MacOS
 - 8350991: Improve HTTP client header handling
 - 8349594: Enhance TLS protocol support
 - 8349584: Improve compiler processing
 - 8349111: Enhance Swing supports
 - 8348989: Better Glyph drawing
 - 8349551: Failures in tests after JDK-8345625
 - 8345625: Better HTTP connections

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/26340/files
  Stats: 358 lines in 21 files changed: 275 ins; 24 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/26340.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26340/head:pull/26340

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

From jpai at openjdk.org  Wed Jul 16 03:55:41 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Jul 2025 03:55:41 GMT
Subject: [jdk25] RFR: Merge 121f5a72e4c23919b3a3b474cc3f1ac29ec611af
In-Reply-To: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>
References: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>
Message-ID: <nvn1ZliZRR8fplYKXC38vFilKzhXAmycocPnIBxDDBw=.7bc6cab6-fc78-41bf-ad9a-86cdbc31203f@github.com>

On Wed, 16 Jul 2025 03:40:43 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu25_07 changes.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26340#pullrequestreview-3023001849

From bchristi at openjdk.org  Wed Jul 16 04:01:42 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 16 Jul 2025 04:01:42 GMT
Subject: [jdk25] RFR: Merge 121f5a72e4c23919b3a3b474cc3f1ac29ec611af [v2]
In-Reply-To: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>
References: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>
Message-ID: <nH6hdD3c0GqgCzQxqgSM_robxNcIlvyRkT0leb2wn78=.8a5a29bc-30c1-4d4d-82b6-38192a31382a@github.com>

> This brings in cpu25_07 changes.

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26340/files
  - new: https://git.openjdk.org/jdk/pull/26340/files/121f5a72..121f5a72

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

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

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

From bchristi at openjdk.org  Wed Jul 16 04:01:43 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 16 Jul 2025 04:01:43 GMT
Subject: [jdk25] Integrated: Merge 121f5a72e4c23919b3a3b474cc3f1ac29ec611af
In-Reply-To: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>
References: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>
Message-ID: <emulA1MVUDYTK86j2qQxYLyNQMZIpNWh_hMCkD-6CiI=.856646b1-9e5a-414e-9ff4-a4db440a5c44@github.com>

On Wed, 16 Jul 2025 03:40:43 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu25_07 changes.

This pull request has now been integrated.

Changeset: 0e6bf005
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e6bf0055057fae844748a300551549553f59f03
Stats:     358 lines in 21 files changed: 275 ins; 24 del; 59 mod

Merge

Reviewed-by: jpai

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

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

From aturbanov at openjdk.org  Wed Jul 16 14:45:48 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 16 Jul 2025 14:45:48 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: <J1pdn5vHMo3xXv_4_FAjWdRl-tv16Dp5b28nDKRWEyU=.34f38fa5-3665-4794-a8e5-2713dbe0db16@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 227:

> 225:             sc.read(buffers[0]); // 1
> 226:             sc.read(buffers); // 2
> 227:             try (InputStream is = sc.socket().getInputStream();) {

Suggestion:

            try (InputStream is = sc.socket().getInputStream()) {

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

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

From alanb at openjdk.org  Wed Jul 16 16:53:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Jul 2025 16:53:40 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: <nOZt5eJe5yAZAsJx-vQi1N1DMpcLYieFc-IlQn3fXJY=.687e25c4-20a9-4cef-a360-e15703ddbf99@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 88:

> 86:     }
> 87: 
> 88:     private static void testFileRead() throws Exception {

In addition to java.io, there will be FileRead/FileWrite events recorded for the stream/channels created with Files.newXXX methods.

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

> 198:             fc.read(buffers[0]); // 19
> 199:             if (fc.read(buffers) < 1) { // 20
> 200:                 throw new Exception("Expected som bytes to be read");

som -> some

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

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

From jpai at openjdk.org  Thu Jul 17 09:03:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 09:03:53 GMT
Subject: RFR: 8361423: Add IPSupport::printPlatformSupport to
 java/net/NetworkInterface/IPv4Only.java
In-Reply-To: <1Xf_CvxGu7V6gvORFp2wID-N9likuBpwW2IMg2EwY2s=.bcef3082-4a24-43ea-8ae8-b7502afebd3b@github.com>
References: <1Xf_CvxGu7V6gvORFp2wID-N9likuBpwW2IMg2EwY2s=.bcef3082-4a24-43ea-8ae8-b7502afebd3b@github.com>
Message-ID: <1XP0Ylk-v6tvwCNpfOfRM1ttUJhSEBEyL4z-UcRLEaw=.1175d3ef-895e-468d-8f81-c3968bc9465d@github.com>

On Fri, 11 Jul 2025 13:39:33 GMT, ayush <duke at openjdk.org> wrote:

> This is part of a series of diagnostic output updates to java.net tests to assist in the analysis of failures in IPv6 only environments
> for Linux there is not IPv4 configuration but the IPv4 stack remains enabled
> For macOS, and windows the IPv4 stacks are disabled, and IPv4 configuration removed
> 
> add IPSupport::printPlatformSupport(System.out);
> 
> to the start of main

This test-only change to add a diagnostic log looks fine to me. Before integrating, please run this test in our CI, with your changes to make sure it continues to work as expected.

test/jdk/java/net/NetworkInterface/IPv4Only.java line 52:

> 50:                 while (addrs.hasMoreElements()) {
> 51:                    InetAddress hostAddr = addrs.nextElement();
> 52:                    if ( hostAddr instanceof Inet6Address){

Hello Ayush, while you are changing this, you can additionally format that line as follows:

if (hostAddr instanceof Inet6Address) {

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26265#pullrequestreview-3028609324
PR Review Comment: https://git.openjdk.org/jdk/pull/26265#discussion_r2212761988

From egahlin at openjdk.org  Thu Jul 17 10:24:34 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 17 Jul 2025 10:24:34 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events [v2]
In-Reply-To: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
Message-ID: <sA9lAAJUKvrqB6NBjJIumVn6gK2coCQ2Vl6j1EJXeEg=.87dbae14-2625-44ba-8470-1b4b6f833ba9@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

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Add support for Files.newXXX + typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26211/files
  - new: https://git.openjdk.org/jdk/pull/26211/files/eded9cdc..4b60c7a9

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

  Stats: 69 lines in 3 files changed: 43 ins; 4 del; 22 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 mgronlun at openjdk.org  Thu Jul 17 10:30:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 17 Jul 2025 10:30:51 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events [v2]
In-Reply-To: <sA9lAAJUKvrqB6NBjJIumVn6gK2coCQ2Vl6j1EJXeEg=.87dbae14-2625-44ba-8470-1b4b6f833ba9@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
 <sA9lAAJUKvrqB6NBjJIumVn6gK2coCQ2Vl6j1EJXeEg=.87dbae14-2625-44ba-8470-1b4b6f833ba9@github.com>
Message-ID: <HLg-4zPcobtTQT2XJTHwwNnulnf8Cd60Yi92T82nP1g=.748d576f-32a8-4e4a-9dfb-1ec2b0bb63b5@github.com>

On Thu, 17 Jul 2025 10:24:34 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
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for Files.newXXX + typos

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26211#pullrequestreview-3028927441

From egahlin at openjdk.org  Thu Jul 17 10:37:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 17 Jul 2025 10:37:52 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events [v2]
In-Reply-To: <nOZt5eJe5yAZAsJx-vQi1N1DMpcLYieFc-IlQn3fXJY=.687e25c4-20a9-4cef-a360-e15703ddbf99@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
 <nOZt5eJe5yAZAsJx-vQi1N1DMpcLYieFc-IlQn3fXJY=.687e25c4-20a9-4cef-a360-e15703ddbf99@github.com>
Message-ID: <qm0hfjUjsPXGvYMcKaBmyAOVGA7YPUHAjs5ZYtuvtWw=.6814203c-d2d7-438a-bf99-9479003e413f@github.com>

On Wed, 16 Jul 2025 16:51:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for Files.newXXX + typos
>
> test/jdk/jdk/jfr/event/io/TestIOTopFrame.java line 88:
> 
>> 86:     }
>> 87: 
>> 88:     private static void testFileRead() throws Exception {
> 
> In addition to java.io, there will be FileRead/FileWrite events recorded for the stream/channels created with Files.newXXX methods.

I added support for Files.newByteChannel, Files.newInputStream and Files.newOutputStream.

I did try to implement it for Files.newBufferedWriter and Files.newBufferedReader, but I didn't want to filter out BufferedReader and BufferedWriter, since they might be used in application stack frames, so I did not include them in the test.

Given that RDP2 begins today, I think this is the best that can be done for JDK 25. We can revisit other top frames later, perhaps with some other mechanism. I filed an issue for this: https://bugs.openjdk.org/browse/JDK-8362491

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

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

From egahlin at openjdk.org  Thu Jul 17 11:23:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 17 Jul 2025 11:23:55 GMT
Subject: Integrated: 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: <yyZSoeo1R8vRJmfLDYG3HExWpVxUvYerKg_2beFWmXQ=.d037255b-137e-4e8f-92e2-8fb05f7879aa@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

This pull request has now been integrated.

Changeset: 1a6cbe42
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a6cbe421facab0de1c7162f2762258664338814
Stats:     414 lines in 6 files changed: 397 ins; 12 del; 5 mod

8361639: JFR: Incorrect top frame for I/O events

Reviewed-by: mgronlun

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

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

From djelinski at openjdk.org  Thu Jul 17 12:34:14 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 17 Jul 2025 12:34:14 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
Message-ID: <BfmSxWK_QlU_xRgeDJ42C6CBn0PAgzINJ57MQG8JMPE=.6ccb4260-d3a5-4295-a09c-efb1f2add293@github.com>

On Tue, 8 Jul 2025 14:04:56 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 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

src/java.net.http/share/classes/jdk/internal/net/http/AltSvcProcessor.java line 164:

> 162:             // serialized form of an origin (defined in section 6.2 of RFC-6454)
> 163:             try {
> 164:                 origin = Origin.fromASCIISerializedForm(frame.getOrigin());

Do we check if the origin is authoritative before processing the alt service? I don't see that here

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 419:

> 417:                 .thenApply((eimpl) -> {synchronized (Exchange.this) {exchImpl = eimpl;}
> 418:                     checkCancelled(); return eimpl; })
> 419:                 .thenApply(Function.identity());

Suggestion:

                .copy();

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

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

From jpai at openjdk.org  Thu Jul 17 12:35:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 12:35:51 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal [v2]
In-Reply-To: <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
 <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
Message-ID: <BJlWEFuZL5nnDOr81nfrm-fuguV0SimqQsHFNFZAB5U=.173c29aa-f2d0-486c-b96a-95c140a5c844@github.com>

On Mon, 14 Jul 2025 20:04:21 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> `SocketPermission` should be deprecated for removal as has already been done for many other `Permission` subclasses. However, `CodeSource.implies()` has specification dependencies on `SocketPermission` which requires additional changes to decouple those dependencies. 
>> 
>> This change deprecates `SocketPermission`for removal and removes the dependency on `SocketPermission` from `CodeSource.implies` by copying the relevant conditions from `SocketPermission.implies`. Additional test cases for `CodeSource.implies` were also added to check that the behavior is consistent.
>> 
>> Note that we may also eventually deprecate `CodeSource.implies` for removal but that requires more investigation.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SuppressWarnings("removal") to SocketPermissionCollection.

src/java.base/share/classes/java/security/CodeSource.java line 287:

> 285:      *           one of <i>codesource</i>'s IP addresses or this object's
> 286:      *           canonical host name must equal <i>codesource</i>'s canonical
> 287:      *           host name.

Hello Sean, the original text in `SocketPermission.implies()` lists these 2 rules separately, as follows:

>
> <li>If this object was not initialized with a single IP address, and one of this object's IP addresses equals one of <i>p</i>'s IP addresses.
>
> <li>If this canonical name equals <i>p</i>'s canonical name.

Given that we state at the beginning of this text that `the following checks are made in order:`, do you think we should continue to list these 2 rules separately, in that order, instead of combining them into one, like what's being proposed here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26300#discussion_r2213215820

From jpai at openjdk.org  Thu Jul 17 12:43:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 12:43:48 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal [v2]
In-Reply-To: <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
 <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
Message-ID: <fAI4BOOA-WNSmbl3S292LBAXc3VatC1_dTmRICp1ytw=.95ec3340-ae27-4f45-8ada-8c8296492f60@github.com>

On Mon, 14 Jul 2025 20:04:21 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> `SocketPermission` should be deprecated for removal as has already been done for many other `Permission` subclasses. However, `CodeSource.implies()` has specification dependencies on `SocketPermission` which requires additional changes to decouple those dependencies. 
>> 
>> This change deprecates `SocketPermission`for removal and removes the dependency on `SocketPermission` from `CodeSource.implies` by copying the relevant conditions from `SocketPermission.implies`. Additional test cases for `CodeSource.implies` were also added to check that the behavior is consistent.
>> 
>> Note that we may also eventually deprecate `CodeSource.implies` for removal but that requires more investigation.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SuppressWarnings("removal") to SocketPermissionCollection.

test/jdk/java/security/CodeSource/Implies.java line 65:

> 63:         thisURL = new URL("http", ia.getHostAddress(), "file");
> 64:         thatURL = new URL("http", ia.getHostName(), "file");
> 65:         // ip address should imply host name with same ip address

The specification speaks about IP addresses, specifically:

> If this object was initialized with a single IP address and one of <i>p</i>'s IP addresses is equal to this object's IP address.

So is this test for implying a IP address against a host name valid?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26300#discussion_r2213240050

From jpai at openjdk.org  Thu Jul 17 12:46:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 12:46:53 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal [v2]
In-Reply-To: <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
 <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
Message-ID: <ZQw3qJ8mMH71eERwVcj9n4b67kojmT0jxFcKE6kCquM=.66e54d35-b0c1-4d9f-b0ba-422946183a84@github.com>

On Mon, 14 Jul 2025 20:04:21 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> `SocketPermission` should be deprecated for removal as has already been done for many other `Permission` subclasses. However, `CodeSource.implies()` has specification dependencies on `SocketPermission` which requires additional changes to decouple those dependencies. 
>> 
>> This change deprecates `SocketPermission`for removal and removes the dependency on `SocketPermission` from `CodeSource.implies` by copying the relevant conditions from `SocketPermission.implies`. Additional test cases for `CodeSource.implies` were also added to check that the behavior is consistent.
>> 
>> Note that we may also eventually deprecate `CodeSource.implies` for removal but that requires more investigation.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SuppressWarnings("removal") to SocketPermissionCollection.

On a related note, I did a brief search for SocketPermission usages in the JDK and while doing so, I noticed that there's a `sun.security.util.SecurityConstants` class which has a lot of leftover unused security permission related constants. Maybe that can be cleaned up as a separate task?

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

PR Comment: https://git.openjdk.org/jdk/pull/26300#issuecomment-3083933894

From jpai at openjdk.org  Thu Jul 17 13:17:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 13:17:51 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v3]
In-Reply-To: <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
Message-ID: <ohu5a2u8ZZhfQ10L36403vNfD-IHeiwdsUaW3VZvTPs=.fead2198-d525-4d74-9afb-b62237ea4894@github.com>

On Mon, 7 Jul 2025 10:41: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.
>
> 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>

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

> 745:         public static BodyPublisher ofFileChannel(FileChannel channel, long offset, long length) {
> 746:             Objects.requireNonNull(channel, "channel");
> 747:             return new RequestPublishers.FileChannelPublisher(channel, offset, length);

Hello Volkan, I see that the constructor of `FileChannelPublisher` attempts to determine the file size of the channel and if an `IOException` is thrown then it gets propagated as  `UncheckedIOException`. I think an alternate approach and perhaps a better one would be to specify in this new method's documentation that the `FileChannel`'s size will be first determined by this method to verify that the given `offset` and the `length` are within bounds of that size. That then allows us to add a throws clause to this method which we merely propagate from the call of `FileChannel.size()`.

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

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

From liach at openjdk.org  Thu Jul 17 13:22:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 13:22:49 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v3]
In-Reply-To: <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
Message-ID: <o76taPgSm6Bxxb_A5tvTXCpmHfnvQzWz7jOyrQIfKOs=.325f3e06-1be8-42a6-b647-ea6b452f14c3@github.com>

On Mon, 7 Jul 2025 10:41: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.
>
> 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>

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

> 742:          * found to be {@linkplain Objects.checkFromIndexSize(long, long, long) out of bounds}
> 743:          * compared with the size of the file referred by the channel
> 744:          */

Please add a `@since 26` tag.

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

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

From jpai at openjdk.org  Thu Jul 17 13:22:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 13:22:50 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v3]
In-Reply-To: <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
Message-ID: <zMR25zTb2PDyv6HWDsWwbMptx5c3iNrQLiGjtft-tw4=.eb9f444f-2afb-44e1-ad93-e93aa7ee4d90@github.com>

On Mon, 7 Jul 2025 10:41: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.
>
> 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>

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

> 744:          */
> 745:         public static BodyPublisher ofFileChannel(FileChannel channel, long offset, long length) {
> 746:             Objects.requireNonNull(channel, "channel");

The method's javadoc should have a `@throws NullPointerException if channel is null`. Unless that's covered by a wider statement about null parameters some place else? I couldn't find it in this class.

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

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

From jpai at openjdk.org  Thu Jul 17 13:26:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 13:26:51 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v3]
In-Reply-To: <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
Message-ID: <PzN-0oF2eBYIZ0NQ3v3LaaC_XZng1YYmQ43GfR2hMa4=.32855813-7812-4c5c-8bdf-49f7ab21ed62@github.com>

On Mon, 7 Jul 2025 10:41: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.
>
> 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>

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

> 431:             this.channel = Objects.requireNonNull(channel, "channel");
> 432:             long fileSize = fileSize(channel);
> 433:             Objects.checkFromIndexSize(offset, length, fileSize);

My preference would be to move these file size determination and the offset/length bounds check to the call site of this constructor. That way it's much more visible at the place where this behaviour is specified (by the public API).

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

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

From jpai at openjdk.org  Thu Jul 17 13:37:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 13:37:48 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v3]
In-Reply-To: <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
Message-ID: <yaiLesVo-befZc1QXmlnMTxT8d1b4L5WZheIkRulTIs=.7204fe08-e15a-4497-8f2d-19111f116316@github.com>

On Mon, 7 Jul 2025 10:41: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.
>
> 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>

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

> 474: 
> 475:         @Override
> 476:         public synchronized boolean hasNext() {

In context of the synchronizations in this class, does a single instance of `FileChannelIterator` gets accessed concurrently? I haven't fully grasped the publisher/subscriber model through which this `FileChannelIterator` instance would be handed out and how that then ends up as a `BodyPublisher` that's accessed by the application.

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

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

From jpai at openjdk.org  Thu Jul 17 13:42:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 13:42:48 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v3]
In-Reply-To: <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
Message-ID: <5o5PaESG-QTQh6zjcoDDMEgSkogNRUwx-r0oXid2XCk=.00f82773-52ec-4508-8f23-54b60eef51a6@github.com>

On Mon, 7 Jul 2025 10:41: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.
>
> 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>

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

> 490:                 if (readLength < 0) {
> 491:                     // We *must* throw to signal that the request needs to be cancelled.
> 492:                     // Otherwise, the server will continue waiting data.

The comment itself is a good idea but i think we should leave out the reference to a "server" from this comment. Perhaps something like: "Throw to signal that the request needs to be cancelled"?

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

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

From jpai at openjdk.org  Thu Jul 17 13:49:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 13:49:50 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v3]
In-Reply-To: <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
Message-ID: <F4DFI2E6JlJjadJXhZKyZtBqGG5GyfSFnTeijNr6cBI=.487e9218-6f71-4705-844c-b1f65ea912da@github.com>

On Mon, 7 Jul 2025 10:41: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.
>
> 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>

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

> 488:                 int readLength = channel.read(buffer, position);
> 489:                 // Short-circuit if `read()` has failed, e.g., due to file content being changed in the meantime
> 490:                 if (readLength < 0) {

The `FileChannel.read(ByteBuffer, position)` API states:

> If the given position is greater than or equal to the file's current size then no bytes are read.

I think we might have to consider the situation where the underlying file's size has reduced and this position is now past that size and the `read()` call returning 0. Would that then end up in a situation where we have a "never ending" BodyPublisher, which publishes nothing but hasn't terminated either?

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

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

From mullan at openjdk.org  Thu Jul 17 13:55:49 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 17 Jul 2025 13:55:49 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal [v2]
In-Reply-To: <ZQw3qJ8mMH71eERwVcj9n4b67kojmT0jxFcKE6kCquM=.66e54d35-b0c1-4d9f-b0ba-422946183a84@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
 <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
 <ZQw3qJ8mMH71eERwVcj9n4b67kojmT0jxFcKE6kCquM=.66e54d35-b0c1-4d9f-b0ba-422946183a84@github.com>
Message-ID: <vY5_XIKkqCkkzFFJodNsnm8ZB7T0a7IP5gGwUkHhO9E=.201ac2fc-cd8b-479a-b283-e649a5d907bf@github.com>

On Thu, 17 Jul 2025 12:43:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> On a related note, I did a brief search for SocketPermission usages in the JDK and while doing so, I noticed that there's a `sun.security.util.SecurityConstants` class which has a lot of leftover unused security permission related constants. Maybe that can be cleaned up as a separate task?

Right, but the constants are still used in the relevant permission classes. I think it is fine to leave them for now and remove them when the permission classes are removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26300#issuecomment-3084169452

From jpai at openjdk.org  Thu Jul 17 13:58:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 13:58:49 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v3]
In-Reply-To: <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
Message-ID: <h0aJ84E-iZJtmDL_LB4zI4cn0z3N7SyRZZVRzcoXguw=.3be6e67d-8ec4-4c42-944c-26cf81c4d92f@github.com>

On Mon, 7 Jul 2025 10:41: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.
>
> 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>

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

> 721: 
> 722:         /**
> 723:          * {@return a request body publisher whose body is the {@code length}

I think some of the text in this javadoc would need changes/clarifications. I haven't added any review comments for it yet and will come to it later once we have settled on the rest of the review.

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

> 370: 
> 371:     /**
> 372:      * {@return a new {@link ByteBuffer} instance of configured capacity for the HTTP Client}

I think instead of saying "configured capacity" we should say "instance of {@link BUFSIZE} ...". This is an internal class so it should be OK to link to this constant even if the constant itself isn't documented. Linking to `BUFSIZE` makes it clear and easier to find what the actual capacity is.

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

> 382:      *
> 383:      * @param maxCapacity a buffer capacity, in bytes
> 384:      * @throws IllegalArgumentException if {@code capacity < 0}

Typo - should have been `if {@code maxCapacity < 0}`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2213422566
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2213413211
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2213416215

From mullan at openjdk.org  Thu Jul 17 14:02:51 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 17 Jul 2025 14:02:51 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal [v2]
In-Reply-To: <fAI4BOOA-WNSmbl3S292LBAXc3VatC1_dTmRICp1ytw=.95ec3340-ae27-4f45-8ada-8c8296492f60@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
 <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
 <fAI4BOOA-WNSmbl3S292LBAXc3VatC1_dTmRICp1ytw=.95ec3340-ae27-4f45-8ada-8c8296492f60@github.com>
Message-ID: <h4Bqo1v-0cm1E5wuVUk-OUWTObuuSV0GwYMXXGaazew=.64d7be49-3381-41f6-a301-a74d54426fb8@github.com>

On Thu, 17 Jul 2025 12:41:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @SuppressWarnings("removal") to SocketPermissionCollection.
>
> test/jdk/java/security/CodeSource/Implies.java line 65:
> 
>> 63:         thisURL = new URL("http", ia.getHostAddress(), "file");
>> 64:         thatURL = new URL("http", ia.getHostName(), "file");
>> 65:         // ip address should imply host name with same ip address
> 
> The specification speaks about IP addresses, specifically:
> 
>> If this object was initialized with a single IP address and one of <i>p</i>'s IP addresses is equal to this object's IP address.
> 
> So is this test for implying a IP address against a host name valid?

Yes, it is checking that [the locations specified as ip address and hostname are the same](https://github.com/openjdk/jdk/blob/5ed72775a775d6c96be6de7d9540dc0a80cdd67b/src/java.base/share/classes/java/security/CodeSource.java#L398). This isn't testing any of the `SocketPermission` rules, but I thought it would be useful to add it as a test as I didn't find any existing `CodeSource` tests that checked for that condition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26300#discussion_r2213432753

From jpai at openjdk.org  Thu Jul 17 14:08:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 14:08:50 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal [v2]
In-Reply-To: <h4Bqo1v-0cm1E5wuVUk-OUWTObuuSV0GwYMXXGaazew=.64d7be49-3381-41f6-a301-a74d54426fb8@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
 <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
 <fAI4BOOA-WNSmbl3S292LBAXc3VatC1_dTmRICp1ytw=.95ec3340-ae27-4f45-8ada-8c8296492f60@github.com>
 <h4Bqo1v-0cm1E5wuVUk-OUWTObuuSV0GwYMXXGaazew=.64d7be49-3381-41f6-a301-a74d54426fb8@github.com>
Message-ID: <XwcLBuoCtyjNbTSBqUUJHwU5ZCsK2Vng7BLz5dGPqD8=.fa088051-ff8f-4c64-883b-458b7a84527b@github.com>

On Thu, 17 Jul 2025 13:59:52 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> test/jdk/java/security/CodeSource/Implies.java line 65:
>> 
>>> 63:         thisURL = new URL("http", ia.getHostAddress(), "file");
>>> 64:         thatURL = new URL("http", ia.getHostName(), "file");
>>> 65:         // ip address should imply host name with same ip address
>> 
>> The specification speaks about IP addresses, specifically:
>> 
>>> If this object was initialized with a single IP address and one of <i>p</i>'s IP addresses is equal to this object's IP address.
>> 
>> So is this test for implying a IP address against a host name valid?
>
> Yes, it is checking that [the locations specified as ip address and hostname are the same](https://github.com/openjdk/jdk/blob/5ed72775a775d6c96be6de7d9540dc0a80cdd67b/src/java.base/share/classes/java/security/CodeSource.java#L398). This isn't testing any of the `SocketPermission` rules, but I thought it would be useful to add it as a test as I didn't find any existing `CodeSource` tests that checked for that condition.

I see. Looks fine to me then. I hadn't paid attention that this behaviour is from the `CodeSource's` existing specification rather than from what it was borrowing from `SocketPermission`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26300#discussion_r2213448987

From mullan at openjdk.org  Thu Jul 17 14:11:49 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 17 Jul 2025 14:11:49 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal [v2]
In-Reply-To: <BJlWEFuZL5nnDOr81nfrm-fuguV0SimqQsHFNFZAB5U=.173c29aa-f2d0-486c-b96a-95c140a5c844@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
 <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
 <BJlWEFuZL5nnDOr81nfrm-fuguV0SimqQsHFNFZAB5U=.173c29aa-f2d0-486c-b96a-95c140a5c844@github.com>
Message-ID: <Ec8QJBzJyesX0y5cjRNO_7r1qrtdxRr9CqM6bXMt5yo=.d66412f7-80b2-433c-b85e-068e6595a232@github.com>

On Thu, 17 Jul 2025 12:33:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @SuppressWarnings("removal") to SocketPermissionCollection.
>
> src/java.base/share/classes/java/security/CodeSource.java line 287:
> 
>> 285:      *           one of <i>codesource</i>'s IP addresses or this object's
>> 286:      *           canonical host name must equal <i>codesource</i>'s canonical
>> 287:      *           host name.
> 
> Hello Sean, the original text in `SocketPermission.implies()` lists these 2 rules separately, as follows:
> 
>>
>> <li>If this object was not initialized with a single IP address, and one of this object's IP addresses equals one of <i>p</i>'s IP addresses.
>>
>> <li>If this canonical name equals <i>p</i>'s canonical name.
> 
> Given that we state at the beginning of this text that `the following checks are made in order:`, do you think we should continue to list these 2 rules separately, in that order, instead of combining them into one, like what's being proposed here?

> Hello Sean, the original text in `SocketPermission.implies()` lists these 2 rules separately, as follows:
> 
> > <li>If this object was not initialized with a single IP address, and one of this object's IP addresses equals one of p's IP addresses.
> > <li>If this canonical name equals p's canonical name.
> 
> Given that we state at the beginning of this text that `the following checks are made in order:`, do you think we should continue to list these 2 rules separately, in that order, instead of combining them into one, like what's being proposed here?

This one was a little tricky. `CodeSource.implies` states the following at the beginning:

"More specifically, this method makes the following checks. If any fail, it returns false. If they all succeed, it returns true."

That logic made sense prior to this fix because the rule said:

"If this object's host (getLocation().getHost()) is not null, then the SocketPermission constructed with this object's host must imply the SocketPermission constructed with codesource's host."

But if I just copy over the relevant conditions as-is from `SocketPermission.implies`, the last two conditions are not logically the same:

- If this object was not initialized with a single IP address, and one of this object's IP addresses equals one of p's IP addresses.
- If this canonical name equals p's canonical name. 

If the first condition fails above, it doesn't bail out and return false, instead it checks the last condition. So this is why I combined those two conditions and added an "or".

Let me know if this makes sense or if you think there is a better way to word this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26300#discussion_r2213455927

From jpai at openjdk.org  Thu Jul 17 16:13:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 16:13:48 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal [v2]
In-Reply-To: <Ec8QJBzJyesX0y5cjRNO_7r1qrtdxRr9CqM6bXMt5yo=.d66412f7-80b2-433c-b85e-068e6595a232@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
 <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
 <BJlWEFuZL5nnDOr81nfrm-fuguV0SimqQsHFNFZAB5U=.173c29aa-f2d0-486c-b96a-95c140a5c844@github.com>
 <Ec8QJBzJyesX0y5cjRNO_7r1qrtdxRr9CqM6bXMt5yo=.d66412f7-80b2-433c-b85e-068e6595a232@github.com>
Message-ID: <JzHfl4_XXXLZWwPannZxdZbL_koFzhg9vVvULMajaSY=.a59616d9-dfd5-43a1-8326-ed9319e29e83@github.com>

On Thu, 17 Jul 2025 14:08:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/CodeSource.java line 287:
>> 
>>> 285:      *           one of <i>codesource</i>'s IP addresses or this object's
>>> 286:      *           canonical host name must equal <i>codesource</i>'s canonical
>>> 287:      *           host name.
>> 
>> Hello Sean, the original text in `SocketPermission.implies()` lists these 2 rules separately, as follows:
>> 
>>>
>>> <li>If this object was not initialized with a single IP address, and one of this object's IP addresses equals one of <i>p</i>'s IP addresses.
>>>
>>> <li>If this canonical name equals <i>p</i>'s canonical name.
>> 
>> Given that we state at the beginning of this text that `the following checks are made in order:`, do you think we should continue to list these 2 rules separately, in that order, instead of combining them into one, like what's being proposed here?
>
>> Hello Sean, the original text in `SocketPermission.implies()` lists these 2 rules separately, as follows:
>> 
>> > <li>If this object was not initialized with a single IP address, and one of this object's IP addresses equals one of p's IP addresses.
>> > <li>If this canonical name equals p's canonical name.
>> 
>> Given that we state at the beginning of this text that `the following checks are made in order:`, do you think we should continue to list these 2 rules separately, in that order, instead of combining them into one, like what's being proposed here?
> 
> This one was a little tricky. `CodeSource.implies` states the following at the beginning:
> 
> "More specifically, this method makes the following checks. If any fail, it returns false. If they all succeed, it returns true."
> 
> That logic made sense prior to this fix because the rule said:
> 
> "If this object's host (getLocation().getHost()) is not null, then the SocketPermission constructed with this object's host must imply the SocketPermission constructed with codesource's host."
> 
> But if I just copy over the relevant conditions as-is from `SocketPermission.implies`, the last two conditions are not logically the same:
> 
> - If this object was not initialized with a single IP address, and one of this object's IP addresses equals one of p's IP addresses.
> - If this canonical name equals p's canonical name. 
> 
> If the first condition fails above, it doesn't bail out and return false, instead it checks the last condition. So this is why I combined those two conditions and added an "or".
> 
> Let me know if this makes sense or if you think there is a better way to word this.

After you mentioned this detail, I read this doc in its entirety. Would something like the following be a bit more clear:



*     <li>  If this object's host (getLocation().getHost()) is not null,
*           then the following checks are made in that order and if any
*           of these checks are satisfied, then return true:
*           <ol>
*           <li> If this object's host was initialized with a single IP
*           address then one of <i>codesource</i>'s IP addresses must be
*           equal to this object's IP address.
*           <li> If this object's host is a wildcard domain (such as
*           *.example.com), then <i>codesource</i>'s canonical host name
*           (the name without any preceding *) must end with this object's
*           canonical host name. For example, *.example.com implies
*           *.foo.example.com.
*           <li> If this object's host was not initialized with a single
*           IP address, then one of this object's IP addresses must equal
*           one of <i>codesource</i>'s IP addresses.
*           <li> This object's canonical host name must equal <i>codesource</i>'s
*           canonical host name.




Also note that, in the above text I used `<ol>` instead of `<ul>` to show the ordering intent. However, if the use of `<ul>` was intentional for better rendering, then that's fine too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26300#discussion_r2213764079

From mullan at openjdk.org  Thu Jul 17 16:58:47 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 17 Jul 2025 16:58:47 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal [v2]
In-Reply-To: <JzHfl4_XXXLZWwPannZxdZbL_koFzhg9vVvULMajaSY=.a59616d9-dfd5-43a1-8326-ed9319e29e83@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
 <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
 <BJlWEFuZL5nnDOr81nfrm-fuguV0SimqQsHFNFZAB5U=.173c29aa-f2d0-486c-b96a-95c140a5c844@github.com>
 <Ec8QJBzJyesX0y5cjRNO_7r1qrtdxRr9CqM6bXMt5yo=.d66412f7-80b2-433c-b85e-068e6595a232@github.com>
 <JzHfl4_XXXLZWwPannZxdZbL_koFzhg9vVvULMajaSY=.a59616d9-dfd5-43a1-8326-ed9319e29e83@github.com>
Message-ID: <rQ6Sr0sBT5Ltm5nfotD5UbDdwem_k9ZWrLh60Gq0tdY=.e0d00000-f207-4068-964c-eb3b789ca5f5@github.com>

On Thu, 17 Jul 2025 16:11:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> Hello Sean, the original text in `SocketPermission.implies()` lists these 2 rules separately, as follows:
>>> 
>>> > <li>If this object was not initialized with a single IP address, and one of this object's IP addresses equals one of p's IP addresses.
>>> > <li>If this canonical name equals p's canonical name.
>>> 
>>> Given that we state at the beginning of this text that `the following checks are made in order:`, do you think we should continue to list these 2 rules separately, in that order, instead of combining them into one, like what's being proposed here?
>> 
>> This one was a little tricky. `CodeSource.implies` states the following at the beginning:
>> 
>> "More specifically, this method makes the following checks. If any fail, it returns false. If they all succeed, it returns true."
>> 
>> That logic made sense prior to this fix because the rule said:
>> 
>> "If this object's host (getLocation().getHost()) is not null, then the SocketPermission constructed with this object's host must imply the SocketPermission constructed with codesource's host."
>> 
>> But if I just copy over the relevant conditions as-is from `SocketPermission.implies`, the last two conditions are not logically the same:
>> 
>> - If this object was not initialized with a single IP address, and one of this object's IP addresses equals one of p's IP addresses.
>> - If this canonical name equals p's canonical name. 
>> 
>> If the first condition fails above, it doesn't bail out and return false, instead it checks the last condition. So this is why I combined those two conditions and added an "or".
>> 
>> Let me know if this makes sense or if you think there is a better way to word this.
>
> After you mentioned this detail, I read this doc in its entirety. Would something like the following be a bit more clear:
> 
> 
> 
> *     <li>  If this object's host (getLocation().getHost()) is not null,
> *           then the following checks are made in that order and if any
> *           of these checks are satisfied, then return true:
> *           <ol>
> *           <li> If this object's host was initialized with a single IP
> *           address then one of <i>codesource</i>'s IP addresses must be
> *           equal to this object's IP address.
> *           <li> If this object's host is a wildcard domain (such as
> *           *.example.com), then <i>codesource</i>'s canonical host name
> *           (the name without any preceding *) must end with this object's
> *           canonical host name. For example, *.example.com implies
> *           *.foo.example.com.
> *           <li> If this object's host was not initialized with a single
> *           IP address, then one of this object's IP addresses must equal
> *           one of <i>codesource</i>'s IP addresses.
> *           <li> This object's canonical host name must equal <i>codesource</i>'s
> *           canonical host name.
> 
> 
> 
> 
> Also note that, in the above text I used `<ol>` instead of `<ul>` to show the ordering intent. However, if the use of `<ul>` was intentional for better rendering, then that's fine too.

It's not the same logic. Even if the checks above pass, `implies()` does not return true yet, it still has to process the rules after that. I think you could say "... and if any of these checks are not satisfied, then return false" but that is somewhat redundant with the first sentence of `implies()`: "More specifically, this method makes the following checks. If any fail, it returns false. If they all succeed, it returns true."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26300#discussion_r2213851416

From vyazici at openjdk.org  Fri Jul 18 09:44:35 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 18 Jul 2025 09:44:35 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
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: <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@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 six additional commits since the last revision:

 - Fix typo in `Utils::getBufferWithAtMost` Javadoc
 - Link to `BUFSIZE` in `Utils::getBuffer` Javadoc
 - Improve wording for signaling request cancellation
 - Remove synchronization for `FileChannelIterator`
 - Improve exception handling and documentation for `ofFileChannel`
 - Add `@since 26` to `ofFileChannel`

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

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

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

  Stats: 28 lines in 3 files changed: 9 ins; 9 del; 10 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  Fri Jul 18 09:44:36 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 18 Jul 2025 09:44:36 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v3]
In-Reply-To: <o76taPgSm6Bxxb_A5tvTXCpmHfnvQzWz7jOyrQIfKOs=.325f3e06-1be8-42a6-b647-ea6b452f14c3@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
 <o76taPgSm6Bxxb_A5tvTXCpmHfnvQzWz7jOyrQIfKOs=.325f3e06-1be8-42a6-b647-ea6b452f14c3@github.com>
Message-ID: <QhFgFC4_myBCi-rnP1m4M4p19n6XcAyl3SvspT06FC8=.3b223a9e-e57d-4836-bd1f-5710a980473a@github.com>

On Mon, 7 Jul 2025 12:31:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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>
>
> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 744:
> 
>> 742:          * found to be {@linkplain Objects.checkFromIndexSize(long, long, long) out of bounds}
>> 743:          * compared with the size of the file referred by the channel
>> 744:          */
> 
> Please add a `@since 26` tag.

Added in 4a9e303bfcc.

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

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

From vyazici at openjdk.org  Fri Jul 18 09:44:37 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 18 Jul 2025 09:44:37 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v3]
In-Reply-To: <zMR25zTb2PDyv6HWDsWwbMptx5c3iNrQLiGjtft-tw4=.eb9f444f-2afb-44e1-ad93-e93aa7ee4d90@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
 <zMR25zTb2PDyv6HWDsWwbMptx5c3iNrQLiGjtft-tw4=.eb9f444f-2afb-44e1-ad93-e93aa7ee4d90@github.com>
Message-ID: <0boA0eAhv1IQ5ROnfk8ziNu1tM8dQQsRXy2zg7lG_yM=.15168421-68e0-491c-a17a-3bbaaea927cd@github.com>

On Thu, 17 Jul 2025 13:18:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> 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>
>
> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 746:
> 
>> 744:          */
>> 745:         public static BodyPublisher ofFileChannel(FileChannel channel, long offset, long length) {
>> 746:             Objects.requireNonNull(channel, "channel");
> 
> The method's javadoc should have a `@throws NullPointerException if channel is null`. Unless that's covered by a wider statement about null parameters some place else? I couldn't find it in this class.

Implemented in 8f66a32ec8b.

> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 747:
> 
>> 745:         public static BodyPublisher ofFileChannel(FileChannel channel, long offset, long length) {
>> 746:             Objects.requireNonNull(channel, "channel");
>> 747:             return new RequestPublishers.FileChannelPublisher(channel, offset, length);
> 
> Hello Volkan, I see that the constructor of `FileChannelPublisher` attempts to determine the file size of the channel and if an `IOException` is thrown then it gets propagated as  `UncheckedIOException`. I think an alternate approach and perhaps a better one would be to specify in this new method's documentation that the `FileChannel`'s size will be first determined by this method to verify that the given `offset` and the `length` are within bounds of that size. That then allows us to add a throws clause to this method which we merely propagate from the call of `FileChannel.size()`.

Changed as suggested in 8f66a32ec8b.

> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 433:
> 
>> 431:             this.channel = Objects.requireNonNull(channel, "channel");
>> 432:             long fileSize = fileSize(channel);
>> 433:             Objects.checkFromIndexSize(offset, length, fileSize);
> 
> My preference would be to move these file size determination and the offset/length bounds check to the call site of this constructor. That way it's much more visible at the place where this behaviour is specified (by the public API).

My motivation for keeping these checks at the `FileChannelPublisher::new` was

1. `FilePublisher` in the same file follows this convention too
2. Even though `jdk.internal.net.http` is not exported, the class is `public`. I wanted to ensure `FileChannelPublisher::new` doesn't accept invalid input

@jaikiran, given these,

1. Do you still prefer me moving the checks to the `ofFileChannel`?
2. If yes, do you also want me to duplicate the checks in `FileChannelPublisher::new` too?

> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 476:
> 
>> 474: 
>> 475:         @Override
>> 476:         public synchronized boolean hasNext() {
> 
> In context of the synchronizations in this class, does a single instance of `FileChannelIterator` gets accessed concurrently? I haven't fully grasped the publisher/subscriber model through which this `FileChannelIterator` instance would be handed out and how that then ends up as a `BodyPublisher` that's accessed by the application.

[Reactive Streams Specification for JVM](https://github.com/reactive-streams/reactive-streams-jvm) states the following:

> #### Publisher
> ...
> `onSubscribe`, `onNext`, `onError` and `onComplete` signaled to a `Subscriber` MUST be signaled _serially_
> ...
> #### Subscriber
> ...
> A `Subscriber` MUST ensure that all calls on its `Subscription`'s request and cancel methods are performed _serially_

Thus we indeed don't need synchronization in our publishers and subscribers. In fact, I explicitly investigated this concern for #23096, where we eventually dropped the synchronization for `LimitingSubscriber`, and this approach was blessed by @viktorklang-ora back then. The reason I opted for synchronization in `FileChannelIterator` was:

1. `StreamIterator` (located in the same class, and used for `ofFile()`) was synchronized too and I wanted to stick to the present convention
2. `PullPublisher` (which `StreamIterator`, `FileChannelIterator`, etc. instances are passed to _per subscription_) operates using a `SequentialScheduler`, and the _scheduler_ in the name made me more skeptical about concurrency implications

But giving this a second thought, I agree that we should not implement redundant synchronization. I've removed synchronization for `FileChannelIterator` in b114fe9598e.

> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 490:
> 
>> 488:                 int readLength = channel.read(buffer, position);
>> 489:                 // Short-circuit if `read()` has failed, e.g., due to file content being changed in the meantime
>> 490:                 if (readLength < 0) {
> 
> The `FileChannel.read(ByteBuffer, position)` API states:
> 
>> If the given position is greater than or equal to the file's current size then no bytes are read.
> 
> I think we might have to consider the situation where the underlying file's size has reduced and this position is now past that size and the `read()` call returning 0. Would that then end up in a situation where we have a "never ending" BodyPublisher, which publishes nothing but hasn't terminated either?

The `FileChannel.read(ByteBuffer, position)` API further states the following:

> [Method returns] The number of bytes read, possibly zero, or `-1` if the given position is greater than or equal to the file's current size

That is, the case you're describing is indicated by the `-1` return value, which we check in the next line. Plus, we already have a test for precisely the scenario that you're describing: `testFileModificationDuringPublisherRead`.

> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 492:
> 
>> 490:                 if (readLength < 0) {
>> 491:                     // We *must* throw to signal that the request needs to be cancelled.
>> 492:                     // Otherwise, the server will continue waiting data.
> 
> The comment itself is a good idea but i think we should leave out the reference to a "server" from this comment. Perhaps something like: "Throw to signal that the request needs to be cancelled"?

Changed as suggested in 183da9d0235.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 372:
> 
>> 370: 
>> 371:     /**
>> 372:      * {@return a new {@link ByteBuffer} instance of configured capacity for the HTTP Client}
> 
> I think instead of saying "configured capacity" we should say "instance of {@link BUFSIZE} ...". This is an internal class so it should be OK to link to this constant even if the constant itself isn't documented. Linking to `BUFSIZE` makes it clear and easier to find what the actual capacity is.

Changed as requested in eacd5da23bb.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 384:
> 
>> 382:      *
>> 383:      * @param maxCapacity a buffer capacity, in bytes
>> 384:      * @throws IllegalArgumentException if {@code capacity < 0}
> 
> Typo - should have been `if {@code maxCapacity < 0}`

Fixed in da69840639e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2215596609
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2215596735
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2215596298
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2215596074
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2215595182
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2215595719
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2215594742
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2215594608

From jpai at openjdk.org  Fri Jul 18 14:39:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 18 Jul 2025 14:39:53 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal [v2]
In-Reply-To: <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
 <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
Message-ID: <51tx_ofVJ7uXLJnGMGV2Kq7Sc_oaGJrwcsRfSh5vaAM=.52255735-7aa8-495d-a50c-6760d7a8c401@github.com>

On Mon, 14 Jul 2025 20:04:21 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> `SocketPermission` should be deprecated for removal as has already been done for many other `Permission` subclasses. However, `CodeSource.implies()` has specification dependencies on `SocketPermission` which requires additional changes to decouple those dependencies. 
>> 
>> This change deprecates `SocketPermission`for removal and removes the dependency on `SocketPermission` from `CodeSource.implies` by copying the relevant conditions from `SocketPermission.implies`. Additional test cases for `CodeSource.implies` were also added to check that the behavior is consistent.
>> 
>> Note that we may also eventually deprecate `CodeSource.implies` for removal but that requires more investigation.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SuppressWarnings("removal") to SocketPermissionCollection.

Looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26300#pullrequestreview-3033794781

From jpai at openjdk.org  Fri Jul 18 14:39:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 18 Jul 2025 14:39:53 GMT
Subject: RFR: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal [v2]
In-Reply-To: <rQ6Sr0sBT5Ltm5nfotD5UbDdwem_k9ZWrLh60Gq0tdY=.e0d00000-f207-4068-964c-eb3b789ca5f5@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
 <iw82AAfieJJR7VNBiiFIRFB6q1BITewe3PzczOghdW4=.b15c8a36-47c1-4423-96b6-98d231027dfc@github.com>
 <BJlWEFuZL5nnDOr81nfrm-fuguV0SimqQsHFNFZAB5U=.173c29aa-f2d0-486c-b96a-95c140a5c844@github.com>
 <Ec8QJBzJyesX0y5cjRNO_7r1qrtdxRr9CqM6bXMt5yo=.d66412f7-80b2-433c-b85e-068e6595a232@github.com>
 <JzHfl4_XXXLZWwPannZxdZbL_koFzhg9vVvULMajaSY=.a59616d9-dfd5-43a1-8326-ed9319e29e83@github.com>
 <rQ6Sr0sBT5Ltm5nfotD5UbDdwem_k9ZWrLh60Gq0tdY=.e0d00000-f207-4068-964c-eb3b789ca5f5@github.com>
Message-ID: <JR-lpvVPYeJAH2fngiuC--oHuBXWDKbQ4DI7BSCOJMM=.b3b4893e-4fe8-43b0-a1aa-d20741aed6c8@github.com>

On Thu, 17 Jul 2025 16:55:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> After you mentioned this detail, I read this doc in its entirety. Would something like the following be a bit more clear:
>> 
>> 
>> 
>> *     <li>  If this object's host (getLocation().getHost()) is not null,
>> *           then the following checks are made in that order and if any
>> *           of these checks are satisfied, then return true:
>> *           <ol>
>> *           <li> If this object's host was initialized with a single IP
>> *           address then one of <i>codesource</i>'s IP addresses must be
>> *           equal to this object's IP address.
>> *           <li> If this object's host is a wildcard domain (such as
>> *           *.example.com), then <i>codesource</i>'s canonical host name
>> *           (the name without any preceding *) must end with this object's
>> *           canonical host name. For example, *.example.com implies
>> *           *.foo.example.com.
>> *           <li> If this object's host was not initialized with a single
>> *           IP address, then one of this object's IP addresses must equal
>> *           one of <i>codesource</i>'s IP addresses.
>> *           <li> This object's canonical host name must equal <i>codesource</i>'s
>> *           canonical host name.
>> 
>> 
>> 
>> 
>> Also note that, in the above text I used `<ol>` instead of `<ul>` to show the ordering intent. However, if the use of `<ul>` was intentional for better rendering, then that's fine too.
>
> It's not the same logic. Even if the checks above pass, `implies()` does not return true yet, it still has to process the rules after that. I think you could say "... and if any of these checks are not satisfied, then return false" but that is somewhat redundant with the first sentence of `implies()`: "More specifically, this method makes the following checks. If any fail, it returns false. If they all succeed, it returns true."

Hello Sean, i gave it some more thought about the wording and I can't think of anything that's more easier to read or explain. So I think what you have here is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26300#discussion_r2216205621

From abarashev at openjdk.org  Mon Jul 21 16:23:03 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 21 Jul 2025 16:23:03 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v12]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <Oe3rsEWIo25dMDMKEnaQdPVxCYpDTQS06j5DZmzsL3g=.79a01e35-9574-4050-aac2-943ae6c978d7@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

Artur Barashev 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 26 additional commits since the last revision:

 - Merge branch 'master' into JDK-8353113
 - Add more unit test cases. Some code tweaks.
 - Update unit tests. Some code refactoring.
 - Update system property name in one more test
 - Remove a couple of empty lines
 - Make certificate checking toggle specific to SunX509. Update issue number.
 - Add more unit tests. Some code refactoring and adjustments.
 - Support certificate checks in SunX509 key manager
 - Address some review comments
 - Merge branch 'master' into JDK-8353113
 - ... and 16 more: https://git.openjdk.org/jdk/compare/2966b576...5626eb9d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/3edca307..5626eb9d

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

  Stats: 99740 lines in 2588 files changed: 64291 ins; 21247 del; 14202 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From duke at openjdk.org  Tue Jul 22 10:47:44 2025
From: duke at openjdk.org (Ayush Rigal)
Date: Tue, 22 Jul 2025 10:47:44 GMT
Subject: RFR: 8361423: Add IPSupport::printPlatformSupport to
 java/net/NetworkInterface/IPv4Only.java [v2]
In-Reply-To: <1Xf_CvxGu7V6gvORFp2wID-N9likuBpwW2IMg2EwY2s=.bcef3082-4a24-43ea-8ae8-b7502afebd3b@github.com>
References: <1Xf_CvxGu7V6gvORFp2wID-N9likuBpwW2IMg2EwY2s=.bcef3082-4a24-43ea-8ae8-b7502afebd3b@github.com>
Message-ID: <fcpvW0vQGVP_3ZaVuOebT47Q4JDaLkf4u3VdXRJA-Ig=.7fac7075-a333-441a-9178-6f579618debb@github.com>

> This is part of a series of diagnostic output updates to java.net tests to assist in the analysis of failures in IPv6 only environments
> for Linux there is not IPv4 configuration but the IPv4 stack remains enabled
> For macOS, and windows the IPv4 stacks are disabled, and IPv4 configuration removed
> 
> add IPSupport::printPlatformSupport(System.out);
> 
> to the start of main

Ayush Rigal has updated the pull request incrementally with one additional commit since the last revision:

  8361423: Add IPSupport::printPlatformSupport to java/net/NetworkInterface/IPv4Only.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26265/files
  - new: https://git.openjdk.org/jdk/pull/26265/files/45272937..c688e550

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

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

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

From jpai at openjdk.org  Tue Jul 22 11:12:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Jul 2025 11:12:26 GMT
Subject: RFR: 8361423: Add IPSupport::printPlatformSupport to
 java/net/NetworkInterface/IPv4Only.java [v2]
In-Reply-To: <fcpvW0vQGVP_3ZaVuOebT47Q4JDaLkf4u3VdXRJA-Ig=.7fac7075-a333-441a-9178-6f579618debb@github.com>
References: <1Xf_CvxGu7V6gvORFp2wID-N9likuBpwW2IMg2EwY2s=.bcef3082-4a24-43ea-8ae8-b7502afebd3b@github.com>
 <fcpvW0vQGVP_3ZaVuOebT47Q4JDaLkf4u3VdXRJA-Ig=.7fac7075-a333-441a-9178-6f579618debb@github.com>
Message-ID: <2bE81U_0yexL-sEaanSEedBenDy3Qg_kf6ESrqr-Big=.59cc9ff5-8e0f-4806-95ea-918221d0ab03@github.com>

On Tue, 22 Jul 2025 10:47:44 GMT, Ayush Rigal <duke at openjdk.org> wrote:

>> This is part of a series of diagnostic output updates to java.net tests to assist in the analysis of failures in IPv6 only environments
>> for Linux there is not IPv4 configuration but the IPv4 stack remains enabled
>> For macOS, and windows the IPv4 stacks are disabled, and IPv4 configuration removed
>> 
>> add IPSupport::printPlatformSupport(System.out);
>> 
>> to the start of main
>
> Ayush Rigal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361423: Add IPSupport::printPlatformSupport to java/net/NetworkInterface/IPv4Only.java

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26265#pullrequestreview-3042512231

From jpai at openjdk.org  Tue Jul 22 11:18:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Jul 2025 11:18:26 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
Message-ID: <J7EfK38kHRwyYifsMZnZ0i7rpOLE5OH-AuxosP20e1E=.29881f9a-b935-45fc-9a0d-28943f906013@github.com>

On Fri, 18 Jul 2025 09:44:35 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 six additional commits since the last revision:
> 
>  - Fix typo in `Utils::getBufferWithAtMost` Javadoc
>  - Link to `BUFSIZE` in `Utils::getBuffer` Javadoc
>  - Improve wording for signaling request cancellation
>  - Remove synchronization for `FileChannelIterator`
>  - Improve exception handling and documentation for `ofFileChannel`
>  - Add `@since 26` to `ofFileChannel`

Thank you for the updates - the implementation changes look good to me. I'll focus on the test and the API javadoc text next.

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

PR Comment: https://git.openjdk.org/jdk/pull/26155#issuecomment-3102280239

From jpai at openjdk.org  Tue Jul 22 11:18:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Jul 2025 11:18:27 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v3]
In-Reply-To: <0boA0eAhv1IQ5ROnfk8ziNu1tM8dQQsRXy2zg7lG_yM=.15168421-68e0-491c-a17a-3bbaaea927cd@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <wJ4X_8ECdQzGDyUP1-GXGz-RVaYAQKuTXD1XkDHqPxI=.2622af54-9d0c-435e-88b2-631feb38baaa@github.com>
 <zMR25zTb2PDyv6HWDsWwbMptx5c3iNrQLiGjtft-tw4=.eb9f444f-2afb-44e1-ad93-e93aa7ee4d90@github.com>
 <0boA0eAhv1IQ5ROnfk8ziNu1tM8dQQsRXy2zg7lG_yM=.15168421-68e0-491c-a17a-3bbaaea927cd@github.com>
Message-ID: <WWJlTrDOo5DJHABLTNlN-q8PD6H-GKUaQwncpP64Hr0=.3da7044d-cdb8-4656-b594-220223c73c63@github.com>

On Fri, 18 Jul 2025 09:40:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 433:
>> 
>>> 431:             this.channel = Objects.requireNonNull(channel, "channel");
>>> 432:             long fileSize = fileSize(channel);
>>> 433:             Objects.checkFromIndexSize(offset, length, fileSize);
>> 
>> My preference would be to move these file size determination and the offset/length bounds check to the call site of this constructor. That way it's much more visible at the place where this behaviour is specified (by the public API).
>
> My motivation for keeping these checks at the `FileChannelPublisher::new` was
> 
> 1. `FilePublisher` in the same file follows this convention too
> 2. Even though `jdk.internal.net.http` is not exported, the class is `public`. I wanted to ensure `FileChannelPublisher::new` doesn't accept invalid input
> 
> @jaikiran, given these,
> 
> 1. Do you still prefer me moving the checks to the `ofFileChannel`?
> 2. If yes, do you also want me to duplicate the checks in `FileChannelPublisher::new` too?

Hello Volkan, given what you note, what you currently have is fine.

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

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

From mullan at openjdk.org  Tue Jul 22 15:28:33 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Jul 2025 15:28:33 GMT
Subject: Integrated: 8356557: Update CodeSource::implies API documentation and
 deprecate java.net.SocketPermission class for removal
In-Reply-To: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
References: <A4HRCGgz8mR1H1AA-7StTu4M_fZNtPw5hV-JvClqlW0=.8b5e7895-88a4-4fdc-a811-0ceee0621a1b@github.com>
Message-ID: <HPkLqHrk4aAMwpcd6R81kp94SLcgH-jKhTemugeVz6k=.47128695-81dc-4ee7-b42a-bbb6c900cc53@github.com>

On Mon, 14 Jul 2025 19:19:47 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> `SocketPermission` should be deprecated for removal as has already been done for many other `Permission` subclasses. However, `CodeSource.implies()` has specification dependencies on `SocketPermission` which requires additional changes to decouple those dependencies. 
> 
> This change deprecates `SocketPermission`for removal and removes the dependency on `SocketPermission` from `CodeSource.implies` by copying the relevant conditions from `SocketPermission.implies`. Additional test cases for `CodeSource.implies` were also added to check that the behavior is consistent.
> 
> Note that we may also eventually deprecate `CodeSource.implies` for removal but that requires more investigation.

This pull request has now been integrated.

Changeset: d714b5d3
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d714b5d3dad58f7f6550d7a95fdc2b3f964a4129
Stats:     60 lines in 3 files changed: 52 ins; 1 del; 7 mod

8356557: Update CodeSource::implies API documentation and deprecate java.net.SocketPermission class for removal

Reviewed-by: jpai

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

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

From duke at openjdk.org  Tue Jul 22 20:04:03 2025
From: duke at openjdk.org (duke)
Date: Tue, 22 Jul 2025 20:04:03 GMT
Subject: Withdrawn: 8325766: Review seclibs tests for cert expiry
In-Reply-To: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
Message-ID: <2cbDusr0fWixjhBO7zr2702Ow20XDD29fmL2NqU3Cjo=.1cfecd0d-5b7a-4f10-8a52-39ad310743a9@github.com>

On Wed, 19 Feb 2025 15:48:10 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
> 
> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)

This pull request has been closed without being integrated.

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

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

From djelinski at openjdk.org  Wed Jul 23 11:04:17 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 23 Jul 2025 11:04:17 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
Message-ID: <vr9dbhdfhe_CZkHcwTIY8AaPWVzOmKsthRIuvnvdUFU=.b8c6b4bd-1c52-4371-838a-d9d0d271c8f2@github.com>

On Tue, 8 Jul 2025 14:04:56 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 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

test/jdk/java/net/httpclient/AsFileDownloadTest.java line 453:

> 451: 
> 452:         @Override
> 453:         public void handle(HttpTestExchange t) throws IOException {

this is almost an exact copy of the method above.

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

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

From abarashev at openjdk.org  Wed Jul 23 21:20:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 23 Jul 2025 21:20:49 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v13]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <vTn5PanuJeRPJaHjkNOEoUqwIcbRyIJ7Z2EypeOCQdg=.2b0d1321-4033-44e8-abe5-7ea79a22b51a@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update system property name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/5626eb9d..eb972544

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

  Stats: 13 lines in 8 files changed: 1 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From djelinski at openjdk.org  Thu Jul 24 12:25:14 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Jul 2025 12:25:14 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
Message-ID: <4kAWa2wgbihXfl3lGOhZJ3sNAFh3RwlPMRT9ZeQpYiY=.68e72d2f-3477-4f01-a4da-4e88ecedd3ed@github.com>

On Tue, 8 Jul 2025 14:04:56 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 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

test/jdk/java/net/httpclient/http3/BadCipherSuiteErrorTest.java line 59:

> 57:  * causing hang problems
> 58:  */
> 59: public class BadCipherSuiteErrorTest implements HttpServerAdapters {

This test overlaps with H3QuicTLSConnection test. Any reason to keep them separate?

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

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

From syan at openjdk.org  Thu Jul 24 13:08:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 24 Jul 2025 13:08:03 GMT
Subject: RFR: 8362855: Test java/net/ipv6tests/TcpTest.java should report
 SkippedException when there no ia4addr  or ia6addr
Message-ID: <L2nfMGcnwUSvQaERDSsVzhNsHah-OrgpIX907tkqCeU=.f80218f6-df3c-40c9-b1f6-7dd8d4e892c4@github.com>

Hi all,

I think the test java/net/ipv6tests/TcpTest.java should report jtreg.SkippedException when there no IPV4 addresses or no IPV6 addresses, rather than just print a messge and then report test run passes.

Change has been verified locally, both enable ipv6 and disable ipv6 on linux. When enable ipv6, test run passes; when disable ipv6, test report jtreg.SkippedException as expected. Test-fix only, no risk.

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

Commit messages:
 - 8362855: Test java/net/ipv6tests/TcpTest.java should report SkippedException when there no ia4addr or ia6addr

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

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

From duke at openjdk.org  Thu Jul 24 14:36:56 2025
From: duke at openjdk.org (duke)
Date: Thu, 24 Jul 2025 14:36:56 GMT
Subject: RFR: 8361423: Add IPSupport::printPlatformSupport to
 java/net/NetworkInterface/IPv4Only.java [v2]
In-Reply-To: <fcpvW0vQGVP_3ZaVuOebT47Q4JDaLkf4u3VdXRJA-Ig=.7fac7075-a333-441a-9178-6f579618debb@github.com>
References: <1Xf_CvxGu7V6gvORFp2wID-N9likuBpwW2IMg2EwY2s=.bcef3082-4a24-43ea-8ae8-b7502afebd3b@github.com>
 <fcpvW0vQGVP_3ZaVuOebT47Q4JDaLkf4u3VdXRJA-Ig=.7fac7075-a333-441a-9178-6f579618debb@github.com>
Message-ID: <CBUdFEInjK-QHVua4fTpjN8OiHauv_lrMG9e8Uy8XBs=.756c79fd-4dab-4b3a-a8b9-3625d7791500@github.com>

On Tue, 22 Jul 2025 10:47:44 GMT, Ayush Rigal <duke at openjdk.org> wrote:

>> This is part of a series of diagnostic output updates to java.net tests to assist in the analysis of failures in IPv6 only environments
>> for Linux there is not IPv4 configuration but the IPv4 stack remains enabled
>> For macOS, and windows the IPv4 stacks are disabled, and IPv4 configuration removed
>> 
>> add IPSupport::printPlatformSupport(System.out);
>> 
>> to the start of main
>
> Ayush Rigal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361423: Add IPSupport::printPlatformSupport to java/net/NetworkInterface/IPv4Only.java

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26265#issuecomment-3113714101

From duke at openjdk.org  Thu Jul 24 15:00:01 2025
From: duke at openjdk.org (Ayush Rigal)
Date: Thu, 24 Jul 2025 15:00:01 GMT
Subject: Integrated: 8361423: Add IPSupport::printPlatformSupport to
 java/net/NetworkInterface/IPv4Only.java
In-Reply-To: <1Xf_CvxGu7V6gvORFp2wID-N9likuBpwW2IMg2EwY2s=.bcef3082-4a24-43ea-8ae8-b7502afebd3b@github.com>
References: <1Xf_CvxGu7V6gvORFp2wID-N9likuBpwW2IMg2EwY2s=.bcef3082-4a24-43ea-8ae8-b7502afebd3b@github.com>
Message-ID: <5pCRx-G1RlU0O6P1qnrELLqrzRZpUXpnLD56_yaPadE=.ee515cf5-65e7-4772-aabb-21a2fca2cf03@github.com>

On Fri, 11 Jul 2025 13:39:33 GMT, Ayush Rigal <duke at openjdk.org> wrote:

> This is part of a series of diagnostic output updates to java.net tests to assist in the analysis of failures in IPv6 only environments
> for Linux there is not IPv4 configuration but the IPv4 stack remains enabled
> For macOS, and windows the IPv4 stacks are disabled, and IPv4 configuration removed
> 
> add IPSupport::printPlatformSupport(System.out);
> 
> to the start of main

This pull request has now been integrated.

Changeset: 2f1aed2a
Author:    Ayush Rigal <ayush.rigal at oracle.com>
Committer: Mark Sheppard <msheppar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f1aed2a165259a873636792cff7c9de4e1f334e
Stats:     11 lines in 1 file changed: 7 ins; 1 del; 3 mod

8361423: Add IPSupport::printPlatformSupport to java/net/NetworkInterface/IPv4Only.java

Reviewed-by: jpai

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

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

From djelinski at openjdk.org  Thu Jul 24 15:23:15 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Jul 2025 15:23:15 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
Message-ID: <rjOdFLUipPEg5WANViULncjttCDE1vafjjR0wzhi4HE=.55628aae-59c2-4d50-848a-771154bcd45c@github.com>

On Tue, 8 Jul 2025 14:04:56 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 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

test/jdk/java/net/httpclient/http3/H3SimpleTest.java line 47:

> 45: /*
> 46:  * @test
> 47:  * @summary Basic test to verify HTTP3 requests from HttpClient with security manager enabled

nothing in this test references the security manager.

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

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

From djelinski at openjdk.org  Thu Jul 24 19:37:16 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Jul 2025 19:37:16 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
Message-ID: <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>

On Tue, 8 Jul 2025 14:04:56 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 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

test/jdk/java/net/httpclient/http3/H3StreamLimitReachedTest.java line 94:

> 92: import static org.testng.Assert.assertFalse;
> 93: 
> 94: public class H3StreamLimitReachedTest implements HttpServerAdapters {

This test seems to duplicate the checks in `StreamLimitTest`.

test/jdk/java/net/httpclient/http3/H3UnsupportedSSLParametersTest.java line 42:

> 40:  * @run junit H3UnsupportedSSLParametersTest
> 41:  */
> 42: public class H3UnsupportedSSLParametersTest {

This test overlaps with H3QuicTLSConnection. Any reason we shouldn't merge them?

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/ThrowingConsumer.java line 26:

> 24: 
> 25: @FunctionalInterface
> 26: public interface ThrowingConsumer<T, X extends Throwable> {

This interface is only implemented by Http2Handler. We should remove it.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2RedirectHandler.java line 61:

> 59:     }
> 60: 
> 61:     protected byte[] getResponseBytes() {

this method doesn't appear to be overridden anywhere. Should we revert these changes?

test/jdk/jdk/internal/net/http/quic/packets/QuicPacketNumbersTest.java line 33:

> 31:  * @modules java.net.http/jdk.internal.net.http.quic.packets
> 32:  */
> 33: public class QuicPacketNumbersTest {

This test covers the same functions as `quic/PacketNumbersTest.java`; can we remove one?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2228940118
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2228863718
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2229069373
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2229083738
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2229397818

From jpai at openjdk.org  Fri Jul 25 07:32:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Jul 2025 07:32:56 GMT
Subject: RFR: 8362855: Test java/net/ipv6tests/TcpTest.java should report
 SkippedException when there no ia4addr  or ia6addr
In-Reply-To: <L2nfMGcnwUSvQaERDSsVzhNsHah-OrgpIX907tkqCeU=.f80218f6-df3c-40c9-b1f6-7dd8d4e892c4@github.com>
References: <L2nfMGcnwUSvQaERDSsVzhNsHah-OrgpIX907tkqCeU=.f80218f6-df3c-40c9-b1f6-7dd8d4e892c4@github.com>
Message-ID: <z4eWN7QkVlwQdBYXRa4pmwhct3to5kzOAd6ta5_GnU8=.91a0934c-e2b8-467f-a426-de2b7e9d5d52@github.com>

On Thu, 24 Jul 2025 13:02:41 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> I think the test java/net/ipv6tests/TcpTest.java should report jtreg.SkippedException when there no IPV4 addresses or no IPV6 addresses, rather than just print a messge and then report test run passes.
> 
> Change has been verified locally, both enable ipv6 and disable ipv6 on linux. When enable ipv6, test run passes; when disable ipv6, test report jtreg.SkippedException as expected. Test-fix only, no risk.

test/jdk/java/net/ipv6tests/TcpTest.java line 68:

> 66:         checkDebug(args);
> 67:         if (ia4addr == null) {
> 68:             throw new SkippedException("No IPV4 addresses: exiting test");

Hello @sendaoYan, isn't an `import jtreg.SkippedException;` required for this change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26459#discussion_r2230378636

From syan at openjdk.org  Fri Jul 25 07:37:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 25 Jul 2025 07:37:54 GMT
Subject: RFR: 8362855: Test java/net/ipv6tests/TcpTest.java should report
 SkippedException when there no ia4addr  or ia6addr
In-Reply-To: <z4eWN7QkVlwQdBYXRa4pmwhct3to5kzOAd6ta5_GnU8=.91a0934c-e2b8-467f-a426-de2b7e9d5d52@github.com>
References: <L2nfMGcnwUSvQaERDSsVzhNsHah-OrgpIX907tkqCeU=.f80218f6-df3c-40c9-b1f6-7dd8d4e892c4@github.com>
 <z4eWN7QkVlwQdBYXRa4pmwhct3to5kzOAd6ta5_GnU8=.91a0934c-e2b8-467f-a426-de2b7e9d5d52@github.com>
Message-ID: <Ef_wF2CHjhrlUZ51AAnrls7arKEnxUX5vpTDmQStLMs=.94c6f798-ffa0-4cf8-9744-396d86a840ba@github.com>

On Fri, 25 Jul 2025 07:30:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi all,
>> 
>> I think the test java/net/ipv6tests/TcpTest.java should report jtreg.SkippedException when there no IPV4 addresses or no IPV6 addresses, rather than just print a messge and then report test run passes.
>> 
>> Change has been verified locally, both enable ipv6 and disable ipv6 on linux. When enable ipv6, test run passes; when disable ipv6, test report jtreg.SkippedException as expected. Test-fix only, no risk.
>
> test/jdk/java/net/ipv6tests/TcpTest.java line 68:
> 
>> 66:         checkDebug(args);
>> 67:         if (ia4addr == null) {
>> 68:             throw new SkippedException("No IPV4 addresses: exiting test");
> 
> Hello @sendaoYan, isn't an `import jtreg.SkippedException;` required for this change?

This change require `import jtreg.SkippedException`, it's already import at line 42.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26459#discussion_r2230389672

From jpai at openjdk.org  Fri Jul 25 07:41:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Jul 2025 07:41:55 GMT
Subject: RFR: 8362855: Test java/net/ipv6tests/TcpTest.java should report
 SkippedException when there no ia4addr  or ia6addr
In-Reply-To: <L2nfMGcnwUSvQaERDSsVzhNsHah-OrgpIX907tkqCeU=.f80218f6-df3c-40c9-b1f6-7dd8d4e892c4@github.com>
References: <L2nfMGcnwUSvQaERDSsVzhNsHah-OrgpIX907tkqCeU=.f80218f6-df3c-40c9-b1f6-7dd8d4e892c4@github.com>
Message-ID: <hl_oq6R_VmIVfEx6pjTcoWYI8lcjwZNOOoNeVORhkx8=.f2ed010f-6cc1-42d6-90b0-ae8b509b81f2@github.com>

On Thu, 24 Jul 2025 13:02:41 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> I think the test java/net/ipv6tests/TcpTest.java should report jtreg.SkippedException when there no IPV4 addresses or no IPV6 addresses, rather than just print a messge and then report test run passes.
> 
> Change has been verified locally, both enable ipv6 and disable ipv6 on linux. When enable ipv6, test run passes; when disable ipv6, test report jtreg.SkippedException as expected. Test-fix only, no risk.

This looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26459#pullrequestreview-3054437113

From jpai at openjdk.org  Fri Jul 25 07:41:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Jul 2025 07:41:57 GMT
Subject: RFR: 8362855: Test java/net/ipv6tests/TcpTest.java should report
 SkippedException when there no ia4addr  or ia6addr
In-Reply-To: <Ef_wF2CHjhrlUZ51AAnrls7arKEnxUX5vpTDmQStLMs=.94c6f798-ffa0-4cf8-9744-396d86a840ba@github.com>
References: <L2nfMGcnwUSvQaERDSsVzhNsHah-OrgpIX907tkqCeU=.f80218f6-df3c-40c9-b1f6-7dd8d4e892c4@github.com>
 <z4eWN7QkVlwQdBYXRa4pmwhct3to5kzOAd6ta5_GnU8=.91a0934c-e2b8-467f-a426-de2b7e9d5d52@github.com>
 <Ef_wF2CHjhrlUZ51AAnrls7arKEnxUX5vpTDmQStLMs=.94c6f798-ffa0-4cf8-9744-396d86a840ba@github.com>
Message-ID: <46uqe3GP-jXzoX7RKFuE2QcOwrmQPWzYiYDpCmBbhfw=.336a7127-0104-4f59-b01f-630842aa4e89@github.com>

On Fri, 25 Jul 2025 07:35:40 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/net/ipv6tests/TcpTest.java line 68:
>> 
>>> 66:         checkDebug(args);
>>> 67:         if (ia4addr == null) {
>>> 68:             throw new SkippedException("No IPV4 addresses: exiting test");
>> 
>> Hello @sendaoYan, isn't an `import jtreg.SkippedException;` required for this change?
>
> This change require `import jtreg.SkippedException`, it's already import at line 42.

You are right - i missed that in my review.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26459#discussion_r2230396558

From jpai at openjdk.org  Fri Jul 25 08:02:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Jul 2025 08:02:48 GMT
Subject: RFR: 8358048: java/net/httpclient/HttpsTunnelAuthTest.java incorrectly
 calls Thread::stop
Message-ID: <uQkldj3skZplaJWGxCjyNqRzO3B05aHsf23TKhJiISc=.2b79ded6-9463-4528-965a-a092932287ea@github.com>

Can I please get a review of this test-only change which fixes an accidental use of `Thread.stop()`? This addresses https://bugs.openjdk.org/browse/JDK-8358048.

The test during it's termination attempts to close the `ProxyServer` and invokes `ProxyServer.stop()`. The `ProxyServer` does not have a `stop()` method of its own but since the `ProxyServer` is a `java.lang.Thread`, calling `stop()` on the `ProxyServer` ends up calling the `Thread.stop()`. The use of `stop()` in this test is accidental and the test should have used `ProxyServer.close()`.

The commit in this PR fixes the issue by removing the use of `ProxyServer.stop()`. The test continues to pass with this change.

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

Commit messages:
 - 8358048: java/net/httpclient/HttpsTunnelAuthTest.java incorrectly calls Thread::stop

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

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

From djelinski at openjdk.org  Fri Jul 25 09:00:53 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 25 Jul 2025 09:00:53 GMT
Subject: RFR: 8358048: java/net/httpclient/HttpsTunnelAuthTest.java
 incorrectly calls Thread::stop
In-Reply-To: <uQkldj3skZplaJWGxCjyNqRzO3B05aHsf23TKhJiISc=.2b79ded6-9463-4528-965a-a092932287ea@github.com>
References: <uQkldj3skZplaJWGxCjyNqRzO3B05aHsf23TKhJiISc=.2b79ded6-9463-4528-965a-a092932287ea@github.com>
Message-ID: <2mDIZL45m3aktOcSyTN838HToQa-nEqrJICHJD5Pa8s=.3aeede78-83f1-4849-91a1-724576fb5ded@github.com>

On Fri, 25 Jul 2025 07:56:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which fixes an accidental use of `Thread.stop()`? This addresses https://bugs.openjdk.org/browse/JDK-8358048.
> 
> The test during it's termination attempts to close the `ProxyServer` and invokes `ProxyServer.stop()`. The `ProxyServer` does not have a `stop()` method of its own but since the `ProxyServer` is a `java.lang.Thread`, calling `stop()` on the `ProxyServer` ends up calling the `Thread.stop()`. The use of `stop()` in this test is accidental and the test should have used `ProxyServer.close()`.
> 
> The commit in this PR fixes the issue by removing the use of `ProxyServer.stop()`. The test continues to pass with this change.

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26473#pullrequestreview-3054654568

From alanb at openjdk.org  Fri Jul 25 11:08:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Jul 2025 11:08:58 GMT
Subject: RFR: 8358048: java/net/httpclient/HttpsTunnelAuthTest.java
 incorrectly calls Thread::stop
In-Reply-To: <uQkldj3skZplaJWGxCjyNqRzO3B05aHsf23TKhJiISc=.2b79ded6-9463-4528-965a-a092932287ea@github.com>
References: <uQkldj3skZplaJWGxCjyNqRzO3B05aHsf23TKhJiISc=.2b79ded6-9463-4528-965a-a092932287ea@github.com>
Message-ID: <SfjzBRPh7tJkVglttWYvLbuTWKR3N0ERhRuW4QGaf4U=.869f8a9e-f7e7-452b-911f-60a5e84293ea@github.com>

On Fri, 25 Jul 2025 07:56:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which fixes an accidental use of `Thread.stop()`? This addresses https://bugs.openjdk.org/browse/JDK-8358048.
> 
> The test during it's termination attempts to close the `ProxyServer` and invokes `ProxyServer.stop()`. The `ProxyServer` does not have a `stop()` method of its own but since the `ProxyServer` is a `java.lang.Thread`, calling `stop()` on the `ProxyServer` ends up calling the `Thread.stop()`. The use of `stop()` in this test is accidental and the test should have used `ProxyServer.close()`.
> 
> The commit in this PR fixes the issue by removing the use of `ProxyServer.stop()`. The test continues to pass with this change.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26473#pullrequestreview-3055008220

From alanb at openjdk.org  Fri Jul 25 13:05:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Jul 2025 13:05:54 GMT
Subject: RFR: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX
In-Reply-To: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
References: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
Message-ID: <ZIU439kTDPLFd6VdQZfR7kPFhsfFHnJksKvgtsfUtlE=.85826fbb-7a24-4d42-bc88-046427e28079@github.com>

On Fri, 25 Jul 2025 12:08:38 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
> An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
> because that file was renamed, and webrev doesn't show the diffs side by side.
> The effect of this change is to restore the method to pretty much what it was before, but taking account
> of the changed categorisation of exceptions.
> 
> A test is not included since this was caught by an existing regression test.
> 
> Thanks,
> Michael

test/jdk/java/nio/channels/SocketChannel/OpenLeak.java line 25:

> 23: 
> 24: /* @test
> 25:  * @bug 6548464 8362581

I think you can drop this change to the test, it only accidentally uncovered this issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26478#discussion_r2231034209

From michaelm at openjdk.org  Fri Jul 25 14:26:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Jul 2025 14:26:39 GMT
Subject: RFR: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX [v2]
In-Reply-To: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
References: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
Message-ID: <Mr_xzU2Zk0wBiNY7NV-bCa4j66OhcKuLxLJnIixeOvs=.ae351bb7-1759-4188-a199-d9900eab7a64@github.com>

> Hi,
> 
> This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
> An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
> because that file was renamed, and webrev doesn't show the diffs side by side.
> The effect of this change is to restore the method to pretty much what it was before, but taking account
> of the changed categorisation of exceptions.
> 
> A test is not included since this was caught by an existing regression test.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  revert test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26478/files
  - new: https://git.openjdk.org/jdk/pull/26478/files/45cb3a46..c9a05bd6

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

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

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

From jpai at openjdk.org  Fri Jul 25 14:53:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Jul 2025 14:53:55 GMT
Subject: RFR: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX [v2]
In-Reply-To: <Mr_xzU2Zk0wBiNY7NV-bCa4j66OhcKuLxLJnIixeOvs=.ae351bb7-1759-4188-a199-d9900eab7a64@github.com>
References: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
 <Mr_xzU2Zk0wBiNY7NV-bCa4j66OhcKuLxLJnIixeOvs=.ae351bb7-1759-4188-a199-d9900eab7a64@github.com>
Message-ID: <Mep5Cl1hYAFcAOGsSTskcwO9Ir6oTn8pJLbVF3vYzTk=.63366235-5f2a-42e7-b3d3-d3eef1731abd@github.com>

On Fri, 25 Jul 2025 14:26:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
>> An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
>> because that file was renamed, and webrev doesn't show the diffs side by side.
>> The effect of this change is to restore the method to pretty much what it was before, but taking account
>> of the changed categorisation of exceptions.
>> 
>> A test is not included since this was caught by an existing regression test.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert test change

This looks good to me. I've verified that with this change, the timing for the test methods in `test/jdk/java/nio/channels/SocketChannel/OpenLeak.java` drops back to the same duration that was there before the changes that were done in https://bugs.openjdk.org/browse/JDK-8348986

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26478#pullrequestreview-3055757642

From alanb at openjdk.org  Fri Jul 25 15:56:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Jul 2025 15:56:03 GMT
Subject: RFR: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX [v2]
In-Reply-To: <Mr_xzU2Zk0wBiNY7NV-bCa4j66OhcKuLxLJnIixeOvs=.ae351bb7-1759-4188-a199-d9900eab7a64@github.com>
References: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
 <Mr_xzU2Zk0wBiNY7NV-bCa4j66OhcKuLxLJnIixeOvs=.ae351bb7-1759-4188-a199-d9900eab7a64@github.com>
Message-ID: <QVenageCTzGFgjkWLclqZpq7-SfY-uMiQ_Lr6PQY8Tg=.c5664d37-5714-4fb3-9862-2acbf03ef629@github.com>

On Fri, 25 Jul 2025 14:26:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
>> An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
>> because that file was renamed, and webrev doesn't show the diffs side by side.
>> The effect of this change is to restore the method to pretty much what it was before, but taking account
>> of the changed categorisation of exceptions.
>> 
>> A test is not included since this was caught by an existing regression test.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert test change

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26478#pullrequestreview-3056015950

From abarashev at openjdk.org  Fri Jul 25 16:32:39 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Jul 2025 16:32:39 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs
Message-ID: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>

Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.

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

Commit messages:
 - 8209992: Align SSLSocket and SSLEngine Javadocs

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

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

From vyazici at openjdk.org  Fri Jul 25 17:10:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 25 Jul 2025 17:10:54 GMT
Subject: RFR: 8358048: java/net/httpclient/HttpsTunnelAuthTest.java
 incorrectly calls Thread::stop
In-Reply-To: <uQkldj3skZplaJWGxCjyNqRzO3B05aHsf23TKhJiISc=.2b79ded6-9463-4528-965a-a092932287ea@github.com>
References: <uQkldj3skZplaJWGxCjyNqRzO3B05aHsf23TKhJiISc=.2b79ded6-9463-4528-965a-a092932287ea@github.com>
Message-ID: <-KJtG6Ecz0-BfG7Ic87-Kv_yg62JT07oVayYXVaMHmA=.55ac6765-86c6-43a9-80c7-8b3dbbceeea4@github.com>

On Fri, 25 Jul 2025 07:56:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which fixes an accidental use of `Thread.stop()`? This addresses https://bugs.openjdk.org/browse/JDK-8358048.
> 
> The test during it's termination attempts to close the `ProxyServer` and invokes `ProxyServer.stop()`. The `ProxyServer` does not have a `stop()` method of its own but since the `ProxyServer` is a `java.lang.Thread`, calling `stop()` on the `ProxyServer` ends up calling the `Thread.stop()`. The use of `stop()` in this test is accidental and the test should have used `ProxyServer.close()`.
> 
> The commit in this PR fixes the issue by removing the use of `ProxyServer.stop()`. The test continues to pass with this change.

Given `HttpTestServer` implements `AutoCloseable`, does a follow-up issue to change `ProxyServer` from `extends Thread implements Closeable` to `implements AutoCloseable` make sense? This can simplify several existing use sites terminating these resources, and avoid unintended `Thread` method invocations as was in this case.

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

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26473#pullrequestreview-3056221592

From wetmore at openjdk.org  Fri Jul 25 20:15:53 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 25 Jul 2025 20:15:53 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs
In-Reply-To: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
Message-ID: <Udx6-zMLyoaFv5e3G2RBPiREZ5OaZRH1q-dHSyCIz5w=.dc833ed0-a793-4502-bb93-7fcdf8278bbe@github.com>

On Fri, 25 Jul 2025 16:27:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.

The renegotiation wording should probably updated in both the SSLSocket/SSLEngine section.  As was pointed out, TLSv1.3 is not a full renegotiation.

You could soften some of the wording with something like (needs wordsmithing):

    The behavior of this method is protocol- and possibly implementation- dependent:  For 
    example, in TLSv1.2 and earlier could do X, and in TLSv1.3 calling this method would do
    Y.

I think the submitter was also asking for a similar layout/wording between the two, while highlighting the differences where needed.  This would make the learning curve a bit smaller.

This probably will need a CSR.

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

PR Review: https://git.openjdk.org/jdk/pull/26484#pullrequestreview-3056681817

From jpai at openjdk.org  Sat Jul 26 02:20:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 26 Jul 2025 02:20:08 GMT
Subject: RFR: 8358048: java/net/httpclient/HttpsTunnelAuthTest.java
 incorrectly calls Thread::stop
In-Reply-To: <uQkldj3skZplaJWGxCjyNqRzO3B05aHsf23TKhJiISc=.2b79ded6-9463-4528-965a-a092932287ea@github.com>
References: <uQkldj3skZplaJWGxCjyNqRzO3B05aHsf23TKhJiISc=.2b79ded6-9463-4528-965a-a092932287ea@github.com>
Message-ID: <WV-qOCBw5P3IETyYwgM9Rot-743k2Q7Cb-hAjcEWtew=.25e44b3e-39d4-4770-bfbc-69390d556c63@github.com>

On Fri, 25 Jul 2025 07:56:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which fixes an accidental use of `Thread.stop()`? This addresses https://bugs.openjdk.org/browse/JDK-8358048.
> 
> The test during it's termination attempts to close the `ProxyServer` and invokes `ProxyServer.stop()`. The `ProxyServer` does not have a `stop()` method of its own but since the `ProxyServer` is a `java.lang.Thread`, calling `stop()` on the `ProxyServer` ends up calling the `Thread.stop()`. The use of `stop()` in this test is accidental and the test should have used `ProxyServer.close()`.
> 
> The commit in this PR fixes the issue by removing the use of `ProxyServer.stop()`. The test continues to pass with this change.

Hello Volkan,

> does a follow-up issue to change ProxyServer from extends Thread implements Closeable to implements AutoCloseable make sense?

Yes, changing the ProxyServer to stop extending from Thread would be a good thing.

Thank you all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26473#issuecomment-3121002127
PR Comment: https://git.openjdk.org/jdk/pull/26473#issuecomment-3121002435

From jpai at openjdk.org  Sat Jul 26 02:20:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 26 Jul 2025 02:20:08 GMT
Subject: Integrated: 8358048: java/net/httpclient/HttpsTunnelAuthTest.java
 incorrectly calls Thread::stop
In-Reply-To: <uQkldj3skZplaJWGxCjyNqRzO3B05aHsf23TKhJiISc=.2b79ded6-9463-4528-965a-a092932287ea@github.com>
References: <uQkldj3skZplaJWGxCjyNqRzO3B05aHsf23TKhJiISc=.2b79ded6-9463-4528-965a-a092932287ea@github.com>
Message-ID: <KDdK-OZHxGGolxsFHWqVrVXJcW-zrnGDoLl-MIqudH0=.7038334f-e1ba-44c2-9225-331a9f98c7ff@github.com>

On Fri, 25 Jul 2025 07:56:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which fixes an accidental use of `Thread.stop()`? This addresses https://bugs.openjdk.org/browse/JDK-8358048.
> 
> The test during it's termination attempts to close the `ProxyServer` and invokes `ProxyServer.stop()`. The `ProxyServer` does not have a `stop()` method of its own but since the `ProxyServer` is a `java.lang.Thread`, calling `stop()` on the `ProxyServer` ends up calling the `Thread.stop()`. The use of `stop()` in this test is accidental and the test should have used `ProxyServer.close()`.
> 
> The commit in this PR fixes the issue by removing the use of `ProxyServer.stop()`. The test continues to pass with this change.

This pull request has now been integrated.

Changeset: d288ca28
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d288ca28be7bfba3abe9f54cefbe53e73c25707e
Stats:     6 lines in 1 file changed: 1 ins; 1 del; 4 mod

8358048: java/net/httpclient/HttpsTunnelAuthTest.java incorrectly calls Thread::stop

Reviewed-by: djelinski, alanb, vyazici

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

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

From jpai at openjdk.org  Sat Jul 26 09:17:36 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 26 Jul 2025 09:17:36 GMT
Subject: RFR: 8360981: Remove use of Thread.stop in
 test/jdk/java/net/Socket/DeadlockTest.java
Message-ID: <nOsxPSTGf8c_sze3REm3z055Y4LNMVeAvzwB9u8tc5A=.fcd444e4-bae0-411f-b897-0ea903967441@github.com>

Can I please get a review of this test-only change which removes the use of `Thread.stop()` from the test? This addresses https://bugs.openjdk.org/browse/JDK-8360981.

The use of `Thread.stop()` `test/jdk/java/net/Socket/DeadlockTest.java` isn't necessary for what this test is currently testing. The commit in this PR removes that call and instead wait for the `Thread` to complete execution, by calling `Thread.join()` without any timeouts. If a genuine deadlock does happen, then the test will time out (on the `Thread.join()` call) and the jtreg infrastructure should then help get hold of the necessary thread dumps to identify the cause of the deadlock.

The test continues to pass with this change.

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

Commit messages:
 - remove Thread.stop() from test/jdk/java/net/Socket/DeadlockTest.java test

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

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

From alanb at openjdk.org  Sat Jul 26 14:31:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 26 Jul 2025 14:31:55 GMT
Subject: RFR: 8360981: Remove use of Thread.stop in
 test/jdk/java/net/Socket/DeadlockTest.java
In-Reply-To: <nOsxPSTGf8c_sze3REm3z055Y4LNMVeAvzwB9u8tc5A=.fcd444e4-bae0-411f-b897-0ea903967441@github.com>
References: <nOsxPSTGf8c_sze3REm3z055Y4LNMVeAvzwB9u8tc5A=.fcd444e4-bae0-411f-b897-0ea903967441@github.com>
Message-ID: <W9x0VemPkowEjcMQcXKFzFs8ZUSZTL51To1xqN02peo=.44e8b241-db84-4952-be5d-5a8422010a6c@github.com>

On Sat, 26 Jul 2025 09:04:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes the use of `Thread.stop()` from the test? This addresses https://bugs.openjdk.org/browse/JDK-8360981.
> 
> The use of `Thread.stop()` `test/jdk/java/net/Socket/DeadlockTest.java` isn't necessary for what this test is currently testing. The commit in this PR removes that call and instead wait for the `Thread` to complete execution, by calling `Thread.join()` without any timeouts. If a genuine deadlock does happen, then the test will time out (on the `Thread.join()` call) and the jtreg infrastructure should then help get hold of the necessary thread dumps to identify the cause of the deadlock.
> 
> The test continues to pass with this change.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26490#pullrequestreview-3058225350

From michaelm at openjdk.org  Sat Jul 26 22:25:01 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Sat, 26 Jul 2025 22:25:01 GMT
Subject: Integrated: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX
In-Reply-To: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
References: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
Message-ID: <ho1IiJkVLCDGGNcrL9gcH8ZZMvo24leW4uUO2q7sChI=.2315d284-f2b7-44aa-ae79-5e89092205db@github.com>

On Fri, 25 Jul 2025 12:08:38 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
> An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
> because that file was renamed, and webrev doesn't show the diffs side by side.
> The effect of this change is to restore the method to pretty much what it was before, but taking account
> of the changed categorisation of exceptions.
> 
> A test is not included since this was caught by an existing regression test.
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: de59da27
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de59da27a60bd0afaf8deaf6d4a3d743a4f59db8
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8362581: Timeouts in java/nio/channels/SocketChannel/OpenLeak.java on UNIX

Reviewed-by: jpai, alanb, djelinski

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

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

From syan at openjdk.org  Sun Jul 27 01:22:07 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 27 Jul 2025 01:22:07 GMT
Subject: RFR: 8362855: Test java/net/ipv6tests/TcpTest.java should report
 SkippedException when there no ia4addr  or ia6addr
In-Reply-To: <hl_oq6R_VmIVfEx6pjTcoWYI8lcjwZNOOoNeVORhkx8=.f2ed010f-6cc1-42d6-90b0-ae8b509b81f2@github.com>
References: <L2nfMGcnwUSvQaERDSsVzhNsHah-OrgpIX907tkqCeU=.f80218f6-df3c-40c9-b1f6-7dd8d4e892c4@github.com>
 <hl_oq6R_VmIVfEx6pjTcoWYI8lcjwZNOOoNeVORhkx8=.f2ed010f-6cc1-42d6-90b0-ae8b509b81f2@github.com>
Message-ID: <yFPTqNWWsE4OZS29XfIVmP8lo8FPbUmQ3yMclKWtv_c=.ddf588b0-7218-4a53-866a-d3e0e4519d3b@github.com>

On Fri, 25 Jul 2025 07:39:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi all,
>> 
>> I think the test java/net/ipv6tests/TcpTest.java should report jtreg.SkippedException when there no IPV4 addresses or no IPV6 addresses, rather than just print a messge and then report test run passes.
>> 
>> Change has been verified locally, both enable ipv6 and disable ipv6 on linux. When enable ipv6, test run passes; when disable ipv6, test report jtreg.SkippedException as expected. Test-fix only, no risk.
>
> This looks OK to me.

@jaikiran Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26459#issuecomment-3123700220

From syan at openjdk.org  Sun Jul 27 01:22:07 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 27 Jul 2025 01:22:07 GMT
Subject: Integrated: 8362855: Test java/net/ipv6tests/TcpTest.java should
 report SkippedException when there no ia4addr  or ia6addr
In-Reply-To: <L2nfMGcnwUSvQaERDSsVzhNsHah-OrgpIX907tkqCeU=.f80218f6-df3c-40c9-b1f6-7dd8d4e892c4@github.com>
References: <L2nfMGcnwUSvQaERDSsVzhNsHah-OrgpIX907tkqCeU=.f80218f6-df3c-40c9-b1f6-7dd8d4e892c4@github.com>
Message-ID: <iS9q0y7ssOW-gM6Esr8GNMnx-3_t5jeV79nI-I3qCpc=.44941e50-24ae-4223-acbb-1cdadbf196fd@github.com>

On Thu, 24 Jul 2025 13:02:41 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> I think the test java/net/ipv6tests/TcpTest.java should report jtreg.SkippedException when there no IPV4 addresses or no IPV6 addresses, rather than just print a messge and then report test run passes.
> 
> Change has been verified locally, both enable ipv6 and disable ipv6 on linux. When enable ipv6, test run passes; when disable ipv6, test report jtreg.SkippedException as expected. Test-fix only, no risk.

This pull request has now been integrated.

Changeset: 8fcbb110
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8fcbb110e9941af5fe162c6affff36e0bf652bda
Stats:     7 lines in 1 file changed: 3 ins; 2 del; 2 mod

8362855: Test java/net/ipv6tests/TcpTest.java should report SkippedException when there no ia4addr  or ia6addr

Reviewed-by: jpai

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

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

From jpai at openjdk.org  Sun Jul 27 06:47:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 27 Jul 2025 06:47:56 GMT
Subject: RFR: 8360981: Remove use of Thread.stop in
 test/jdk/java/net/Socket/DeadlockTest.java
In-Reply-To: <nOsxPSTGf8c_sze3REm3z055Y4LNMVeAvzwB9u8tc5A=.fcd444e4-bae0-411f-b897-0ea903967441@github.com>
References: <nOsxPSTGf8c_sze3REm3z055Y4LNMVeAvzwB9u8tc5A=.fcd444e4-bae0-411f-b897-0ea903967441@github.com>
Message-ID: <SU_74YP5xWP4SngyT3GmNpoxE9bbOwVwFlgmfezpcg8=.1deb1a8c-14d8-44b3-a02f-9a32f87d66ce@github.com>

On Sat, 26 Jul 2025 09:04:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes the use of `Thread.stop()` from the test? This addresses https://bugs.openjdk.org/browse/JDK-8360981.
> 
> The use of `Thread.stop()` `test/jdk/java/net/Socket/DeadlockTest.java` isn't necessary for what this test is currently testing. The commit in this PR removes that call and instead wait for the `Thread` to complete execution, by calling `Thread.join()` without any timeouts. If a genuine deadlock does happen, then the test will time out (on the `Thread.join()` call) and the jtreg infrastructure should then help get hold of the necessary thread dumps to identify the cause of the deadlock.
> 
> The test continues to pass with this change.

Thank you Alan for the review. tier2 tests passed with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/26490#issuecomment-3124103399

From jpai at openjdk.org  Sun Jul 27 06:47:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 27 Jul 2025 06:47:56 GMT
Subject: Integrated: 8360981: Remove use of Thread.stop in
 test/jdk/java/net/Socket/DeadlockTest.java
In-Reply-To: <nOsxPSTGf8c_sze3REm3z055Y4LNMVeAvzwB9u8tc5A=.fcd444e4-bae0-411f-b897-0ea903967441@github.com>
References: <nOsxPSTGf8c_sze3REm3z055Y4LNMVeAvzwB9u8tc5A=.fcd444e4-bae0-411f-b897-0ea903967441@github.com>
Message-ID: <XZQnC353LoA_4UWkdCeA_m_ebRSvq6OY9LgU7Iv9r4c=.24da5a24-805e-42d2-a0dd-cb2a59a03174@github.com>

On Sat, 26 Jul 2025 09:04:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes the use of `Thread.stop()` from the test? This addresses https://bugs.openjdk.org/browse/JDK-8360981.
> 
> The use of `Thread.stop()` `test/jdk/java/net/Socket/DeadlockTest.java` isn't necessary for what this test is currently testing. The commit in this PR removes that call and instead wait for the `Thread` to complete execution, by calling `Thread.join()` without any timeouts. If a genuine deadlock does happen, then the test will time out (on the `Thread.join()` call) and the jtreg infrastructure should then help get hold of the necessary thread dumps to identify the cause of the deadlock.
> 
> The test continues to pass with this change.

This pull request has now been integrated.

Changeset: 3263361a
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3263361a28c7e8c02734cb94bc9576e9f3ba5b50
Stats:     22 lines in 1 file changed: 7 ins; 7 del; 8 mod

8360981: Remove use of Thread.stop in test/jdk/java/net/Socket/DeadlockTest.java

Reviewed-by: alanb

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

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

From jpai at openjdk.org  Mon Jul 28 07:02:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 07:02:00 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
Message-ID: <NQ8GkzuYvVUmP6CrBT61yjTt0B90nDKaPgX8rgG-zoE=.e56b58ef-1d46-4ba5-b413-7927bfbbf370@github.com>

On Fri, 18 Jul 2025 09:44:35 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 six additional commits since the last revision:
> 
>  - Fix typo in `Utils::getBufferWithAtMost` Javadoc
>  - Link to `BUFSIZE` in `Utils::getBuffer` Javadoc
>  - Improve wording for signaling request cancellation
>  - Remove synchronization for `FileChannelIterator`
>  - Improve exception handling and documentation for `ofFileChannel`
>  - Add `@since 26` to `ofFileChannel`

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 168:

> 166:         }
> 167: 
> 168:         private static BlockingQueue<byte[]> addRequestBodyConsumingServerHandler(

Nit - instead of the long name, it might be better to rename the method to just `addHandler(...)` and then add a one-liner comment to the method saying that the handler consumes the entire request body.

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 173:

> 171:             HttpTestHandler handler = exchange -> {
> 172:                 // `HttpTestExchange::toString` changes on failure, pin it
> 173:                 String exchangeName = exchange.toString();

Nit - the use of exchange name may not be necessary and instead we could maybe just use the request URI (`getRequestURI()`) in the log messages.

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

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

From jpai at openjdk.org  Mon Jul 28 07:11:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 07:11:01 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
Message-ID: <7weBed6pMcjo0c5EI92Vdmg7SIrWeC5-czEUwLcTzjI=.d4459bad-b956-4910-8768-4866235ccc0f@github.com>

On Fri, 18 Jul 2025 09:44:35 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 six additional commits since the last revision:
> 
>  - Fix typo in `Utils::getBufferWithAtMost` Javadoc
>  - Link to `BUFSIZE` in `Utils::getBuffer` Javadoc
>  - Improve wording for signaling request cancellation
>  - Remove synchronization for `FileChannelIterator`
>  - Improve exception handling and documentation for `ofFileChannel`
>  - Add `@since 26` to `ofFileChannel`

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 296:

> 294:             "6,2,5"     // (offset + length) > fileSize
> 295:     })
> 296:     void testIllegalOffset(

Given what this test verifies, should we name this method `testIllegalOffsetOrLen(...)`?

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 300:

> 298:             int fileChannelOffset,
> 299:             int fileChannelLength,
> 300:             @TempDir(cleanup = CleanupMode.ON_SUCCESS) Path tempDir) throws Exception {

It's not very common for us to use JUnit's `@TempDir` in our tests. I'm not completely sure where it creates those temporary directories. Instead, it might be better to use `Files.createTemporaryDirectory(Path.of("."), ...)` in these tests to allow for those temporary directories to be created under the jtreg's scratch directories.

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

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

From jpai at openjdk.org  Mon Jul 28 07:17:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 07:17:03 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
Message-ID: <7NZnAZJ-F_1T1X_WvfbT6TvXIsMwFdF8YfDxGqEyohU=.7da6125b-6ced-408f-83f7-c6cc38297ffc@github.com>

On Fri, 18 Jul 2025 09:44:35 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 six additional commits since the last revision:
> 
>  - Fix typo in `Utils::getBufferWithAtMost` Javadoc
>  - Link to `BUFSIZE` in `Utils::getBuffer` Javadoc
>  - Improve wording for signaling request cancellation
>  - Remove synchronization for `FileChannelIterator`
>  - Improve exception handling and documentation for `ofFileChannel`
>  - Add `@since 26` to `ofFileChannel`

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 309:

> 307:     @ParameterizedTest
> 308:     @MethodSource("serverRequestPairs")
> 309:     void testContentLessThanBufferSize(

Hello Volkan, on first read, it's not clear to me what this test is testing. Can a brief comment be added to this test method noting what it is testing?

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

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

From jpai at openjdk.org  Mon Jul 28 07:24:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 07:24:59 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
Message-ID: <tD3DQhrVGOHaB0rKAZzPnd4Cpwg8DtL4zu_r84V2ca0=.151540e1-5b7a-491c-a7dc-dee80ddf25bd@github.com>

On Fri, 18 Jul 2025 09:44:35 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 six additional commits since the last revision:
> 
>  - Fix typo in `Utils::getBufferWithAtMost` Javadoc
>  - Link to `BUFSIZE` in `Utils::getBuffer` Javadoc
>  - Improve wording for signaling request cancellation
>  - Remove synchronization for `FileChannelIterator`
>  - Improve exception handling and documentation for `ofFileChannel`
>  - Add `@since 26` to `ofFileChannel`

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 439:

> 437:             HttpRequest request = pair
> 438:                     .requestBuilder
> 439:                     .POST(ofFileChannel(fileChannel, fileChannelOffset, fileChannelLength))

I think it would be better to not add a static import for this method and instead use `BodyPublishers.ofFileChannel(...)` to make it easily visible what this method is (especially because this test has a similarly named `withFileChannel(...)` method).

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

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

From jpai at openjdk.org  Mon Jul 28 07:32:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 07:32:56 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
Message-ID: <UWtrN_4jV6FbwjAIryjWwxhwT3funn810jYzdipW5jk=.64990733-076a-4dc7-9c9c-c02d68051a78@github.com>

On Fri, 18 Jul 2025 09:44:35 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 six additional commits since the last revision:
> 
>  - Fix typo in `Utils::getBufferWithAtMost` Javadoc
>  - Link to `BUFSIZE` in `Utils::getBuffer` Javadoc
>  - Improve wording for signaling request cancellation
>  - Remove synchronization for `FileChannelIterator`
>  - Improve exception handling and documentation for `ofFileChannel`
>  - Add `@since 26` to `ofFileChannel`

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 198:

> 196:                             "Server[%s] failed to process the request (exchange=%s)".formatted(serverName, exception),
> 197:                             exception);
> 198:                     readRequestBodyBytes.add(new byte[0]);

Just to make the test a bit more robust and prevent the subsequent `readRequestBodyBytes.take()` from blocking forever, it might be better to either catch `Throwable` or add this `readRequestBodyBytes.add(new byte[0]);` in the `finally` block (with some condition checks).

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

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

From jpai at openjdk.org  Mon Jul 28 07:40:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 07:40:57 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
Message-ID: <SII-YJIug5CWu14KUTb03aaxcvLKCiBQkQqNXaAtMGw=.ce689cad-d0fb-4c3b-8657-ef83aea04809@github.com>

On Fri, 18 Jul 2025 09:44:35 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 six additional commits since the last revision:
> 
>  - Fix typo in `Utils::getBufferWithAtMost` Javadoc
>  - Link to `BUFSIZE` in `Utils::getBuffer` Javadoc
>  - Improve wording for signaling request cancellation
>  - Remove synchronization for `FileChannelIterator`
>  - Improve exception handling and documentation for `ofFileChannel`
>  - Add `@since 26` to `ofFileChannel`

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 513:

> 511:             LOGGER.log("Verifying the client failure");
> 512:             Exception requestFailure = assertThrows(ExecutionException.class, () -> responseFutureRef.get().get());
> 513:             assertInstanceOf(UncheckedIOException.class, requestFailure.getCause());

I think the application should be receiving a `IOException` (both for send() and sendAsync()) instead of a `UncheckedIOException`.

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

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

From jpai at openjdk.org  Mon Jul 28 07:44:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 07:44:57 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
Message-ID: <s3sQqWsLy5Mz_56WJQb3m_fZMF5jjOkUDvW89ggQPxc=.112129b5-0d77-44b2-bf88-e95b71be19e4@github.com>

On Fri, 18 Jul 2025 09:44:35 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 six additional commits since the last revision:
> 
>  - Fix typo in `Utils::getBufferWithAtMost` Javadoc
>  - Link to `BUFSIZE` in `Utils::getBuffer` Javadoc
>  - Improve wording for signaling request cancellation
>  - Remove synchronization for `FileChannelIterator`
>  - Improve exception handling and documentation for `ofFileChannel`
>  - Add `@since 26` to `ofFileChannel`

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 514:

> 512:             Exception requestFailure = assertThrows(ExecutionException.class, () -> responseFutureRef.get().get());
> 513:             assertInstanceOf(UncheckedIOException.class, requestFailure.getCause());
> 514:             assertInstanceOf(ClosedChannelException.class, requestFailure.getCause().getCause());

Nit - the `assertInstanceOf(...)` returns the instance of the exception which matches the instanceof check. So it might be easier to understand while reading this code, if we did something like:


final IOException ioe = assertInstanceOf(IOException.class, requestFailure.getCause());
assertInstanceOf(ClosedChannelException.class, ioe.getCause());

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

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

From jpai at openjdk.org  Mon Jul 28 08:13:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 08:13:55 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
Message-ID: <gfcBpHud2cqWofcDY3ply8c1dF4L4BzBVCBy36ElE8s=.db952389-1945-412a-aa91-0bfd20f46709@github.com>

On Fri, 18 Jul 2025 09:44:35 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 six additional commits since the last revision:
> 
>  - Fix typo in `Utils::getBufferWithAtMost` Javadoc
>  - Link to `BUFSIZE` in `Utils::getBuffer` Javadoc
>  - Improve wording for signaling request cancellation
>  - Remove synchronization for `FileChannelIterator`
>  - Improve exception handling and documentation for `ofFileChannel`
>  - Add `@since 26` to `ofFileChannel`

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 528:

> 526:     // On Windows, modification while reading is not possible.
> 527:     // Recall the infamous `The process cannot access the file because it is being used by another process`.
> 528:     @DisabledOnOs(OS.WINDOWS)

On Windows, is this still true if you replace the call in this test method from:


Files.write(filePath, generateFileBytes(1));

to:

fileChannel.truncate(1);

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

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

From jpai at openjdk.org  Mon Jul 28 09:04:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 09:04:01 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
Message-ID: <4CpTx4xl2DnpZWQpSyjMl7UbIglX69rZD8ojczQJP9c=.07604b4a-6fdf-46f0-a58a-1f8b6ab06bba@github.com>

On Fri, 18 Jul 2025 09:44:35 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 six additional commits since the last revision:
> 
>  - Fix typo in `Utils::getBufferWithAtMost` Javadoc
>  - Link to `BUFSIZE` in `Utils::getBuffer` Javadoc
>  - Improve wording for signaling request cancellation
>  - Remove synchronization for `FileChannelIterator`
>  - Improve exception handling and documentation for `ofFileChannel`
>  - Add `@since 26` to `ofFileChannel`

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 567:

> 565:                 String requestFailureMessage = requestFailure.getMessage();
> 566:                 assertTrue(
> 567:                         requestFailureMessage.contains("Unexpected EOF"),

Wouldn't this message be on the `ExecutionException`'s `getCause()`? instead of the `ExecutionException` itself?

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

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

From vyazici at openjdk.org  Mon Jul 28 09:53:02 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 28 Jul 2025 09:53:02 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <7weBed6pMcjo0c5EI92Vdmg7SIrWeC5-czEUwLcTzjI=.d4459bad-b956-4910-8768-4866235ccc0f@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
 <7weBed6pMcjo0c5EI92Vdmg7SIrWeC5-czEUwLcTzjI=.d4459bad-b956-4910-8768-4866235ccc0f@github.com>
Message-ID: <Hcr8kZYG-k2ikanZWPStroWzZqFOBUTjOHsiUhMJRJM=.5cb4db2f-23c1-41ba-bda0-d9870ccd1898@github.com>

On Mon, 28 Jul 2025 07:05:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I'm not completely sure where it creates those temporary directories.

JUnit `@TempDir` uses the JTreg scratch directory ? [JTreg 7.5.2](https://github.com/openjdk/jtreg/blob/master/CHANGELOG.md#752) bundles [CODETOOLS-7903953](https://bugs.openjdk.org/browse/CODETOOLS-7903953) addressing this issue. Shall I still replace these with `Files::cTD`? Or `jdk.test.lib.Utils::createTempFile`?

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

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

From jpai at openjdk.org  Mon Jul 28 10:03:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 10:03:05 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <Hcr8kZYG-k2ikanZWPStroWzZqFOBUTjOHsiUhMJRJM=.5cb4db2f-23c1-41ba-bda0-d9870ccd1898@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
 <7weBed6pMcjo0c5EI92Vdmg7SIrWeC5-czEUwLcTzjI=.d4459bad-b956-4910-8768-4866235ccc0f@github.com>
 <Hcr8kZYG-k2ikanZWPStroWzZqFOBUTjOHsiUhMJRJM=.5cb4db2f-23c1-41ba-bda0-d9870ccd1898@github.com>
Message-ID: <lHMimdpIy2I4yTHxp3HovOOWOONmyKfqcgRXd_PAa8U=.4ba0c8d6-1e5b-490a-a43b-a7a23b8fb40d@github.com>

On Mon, 28 Jul 2025 09:50:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 300:
>> 
>>> 298:             int fileChannelOffset,
>>> 299:             int fileChannelLength,
>>> 300:             @TempDir(cleanup = CleanupMode.ON_SUCCESS) Path tempDir) throws Exception {
>> 
>> It's not very common for us to use JUnit's `@TempDir` in our tests. I'm not completely sure where it creates those temporary directories. Instead, it might be better to use `Files.createTemporaryDirectory(Path.of("."), ...)` in these tests to allow for those temporary directories to be created under the jtreg's scratch directories.
>
>> I'm not completely sure where it creates those temporary directories.
> 
> JUnit `@TempDir` uses the JTreg scratch directory ? [JTreg 7.5.2](https://github.com/openjdk/jtreg/blob/master/CHANGELOG.md#752) bundles [CODETOOLS-7903953](https://bugs.openjdk.org/browse/CODETOOLS-7903953) addressing this issue. Shall I still replace these with `Files::cTD`? Or `jdk.test.lib.Utils::createTempFile`?

Can you verify how it behaves with the `-retain` option of jtreg? I think the use of `cleanup` attribute here can conflict with the `-retain` option that can be used to launch `jtreg`. If it is possible to instruct JUnit to not do any cleanup at all, then I think using `@TempDir` here is OK (since as you note, it will end up using the jtreg scratch directory). If JUnit cannot be instructed not to do any cleanup, then using `@TempDir` here would add another layer of potential issue if jtreg was launched with `-retain:all` (for example).

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

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

From abarashev at openjdk.org  Mon Jul 28 14:12:12 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 28 Jul 2025 14:12:12 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v2]
In-Reply-To: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
Message-ID: <oJ1AoP3RbB8R3dKAggoQHnfq0M-t4AYegc7VVwNRy80=.ce918b08-2592-46ea-a8df-93d7e6cebe25@github.com>

> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Address PR comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26484/files
  - new: https://git.openjdk.org/jdk/pull/26484/files/0a243a22..d5723cb8

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

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

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

From abarashev at openjdk.org  Mon Jul 28 14:18:55 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 28 Jul 2025 14:18:55 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v2]
In-Reply-To: <Udx6-zMLyoaFv5e3G2RBPiREZ5OaZRH1q-dHSyCIz5w=.dc833ed0-a793-4502-bb93-7fcdf8278bbe@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
 <Udx6-zMLyoaFv5e3G2RBPiREZ5OaZRH1q-dHSyCIz5w=.dc833ed0-a793-4502-bb93-7fcdf8278bbe@github.com>
Message-ID: <v8UlziJ_ciIwnxjn_MGilWsAD657hiHJmbZXuLl4SAw=.4889546d-1726-4a0a-8e48-b18f5717c925@github.com>

On Fri, 25 Jul 2025 20:13:00 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> The renegotiation wording should probably updated in both the SSLSocket/SSLEngine section. As was pointed out, TLSv1.3 is not a full renegotiation.
> 
> You could soften some of the wording with something like (needs wordsmithing):
> 
> ```
> The behavior of this method is protocol- and possibly implementation- dependent:  For 
> example, in TLSv1.2 and earlier could do X, and in TLSv1.3 calling this method would do
> Y.
> ```
> 
> I think the submitter was also asking for a similar layout/wording between the two, while highlighting the differences where needed. This would make the learning curve a bit smaller.
> 
> This probably will need a CSR.

Good point, I pushed an update. While both methods are similar, they are not the same due to the very nature of SSLEngine. So I made the first 2 paragraphs of the javadoc the same for both methods, the highlighting the differences follows in next paragraphs.

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

PR Comment: https://git.openjdk.org/jdk/pull/26484#issuecomment-3127444430

From mullan at openjdk.org  Tue Jul 29 14:43:03 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Jul 2025 14:43:03 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v13]
In-Reply-To: <vTn5PanuJeRPJaHjkNOEoUqwIcbRyIJ7Z2EypeOCQdg=.2b0d1321-4033-44e8-abe5-7ea79a22b51a@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <vTn5PanuJeRPJaHjkNOEoUqwIcbRyIJ7Z2EypeOCQdg=.2b0d1321-4033-44e8-abe5-7ea79a22b51a@github.com>
Message-ID: <nBSMvOBlzKn60s3_wBdc7BBzAUqp-qytw_fcn_HCI3Q=.be485c1d-7fda-4929-baf9-c1b4c187f14b@github.com>

On Wed, 23 Jul 2025 21:20:49 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
>> 
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
>> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
>> 
>> **SUNX509 KeyManager performance before the change**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> 
>> **SUNX509 KeyManager performance after the change**
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update system property name

src/java.base/share/conf/security/java.security line 29:

> 27: # an unspecified error when initializing the java.security.Security class.
> 28: # Properties in this file are typically parsed only once. If any of the
> 29: # Properties in this file are typically parsed only once. If any of the

Duplicate line added, is this an accidental change?

test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 1:

> 1: /*

Needs copyright update.

test/jdk/sun/security/ssl/X509TrustManagerImpl/PKIXExtendedTM.java line 36:

> 34:  * @run main/othervm PKIXExtendedTM 1
> 35:  * @run main/othervm PKIXExtendedTM 2
> 36:  * @run main/othervm PKIXExtendedTM 3

Why did you remove these lines/test cases?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240064384
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240068846
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240090370

From abarashev at openjdk.org  Tue Jul 29 14:50:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 14:50:00 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v13]
In-Reply-To: <nBSMvOBlzKn60s3_wBdc7BBzAUqp-qytw_fcn_HCI3Q=.be485c1d-7fda-4929-baf9-c1b4c187f14b@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <vTn5PanuJeRPJaHjkNOEoUqwIcbRyIJ7Z2EypeOCQdg=.2b0d1321-4033-44e8-abe5-7ea79a22b51a@github.com>
 <nBSMvOBlzKn60s3_wBdc7BBzAUqp-qytw_fcn_HCI3Q=.be485c1d-7fda-4929-baf9-c1b4c187f14b@github.com>
Message-ID: <3YV9bY3ogo4EjCHqsjO53Z4avgvezCvRSdBgGBUKbc0=.f771dc2d-3b15-4628-9fbc-5a275713b8a1@github.com>

On Tue, 29 Jul 2025 14:32:48 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update system property name
>
> test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 1:
> 
>> 1: /*
> 
> Needs copyright update.

The year is set to 2025 already, maybe something else needs to be changed? Please elaborate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240111694

From mullan at openjdk.org  Tue Jul 29 14:57:01 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Jul 2025 14:57:01 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v13]
In-Reply-To: <3YV9bY3ogo4EjCHqsjO53Z4avgvezCvRSdBgGBUKbc0=.f771dc2d-3b15-4628-9fbc-5a275713b8a1@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <vTn5PanuJeRPJaHjkNOEoUqwIcbRyIJ7Z2EypeOCQdg=.2b0d1321-4033-44e8-abe5-7ea79a22b51a@github.com>
 <nBSMvOBlzKn60s3_wBdc7BBzAUqp-qytw_fcn_HCI3Q=.be485c1d-7fda-4929-baf9-c1b4c187f14b@github.com>
 <3YV9bY3ogo4EjCHqsjO53Z4avgvezCvRSdBgGBUKbc0=.f771dc2d-3b15-4628-9fbc-5a275713b8a1@github.com>
Message-ID: <DLZFcL8E7oI0kiz-_66Ww--YTj13K61tnbqshh40P4w=.e11b12d2-8ce1-4f88-8839-e411aba4fe20@github.com>

On Tue, 29 Jul 2025 14:47:29 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 1:
>> 
>>> 1: /*
>> 
>> Needs copyright update.
>
> The year is set to 2025 already, maybe something else needs to be changed? Please elaborate.

Wrong file, I meant `test/jdk/sun/security/mscapi/ShortRSAKeyWithinTLS.java`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240125935

From abarashev at openjdk.org  Tue Jul 29 14:57:03 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 14:57:03 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v13]
In-Reply-To: <nBSMvOBlzKn60s3_wBdc7BBzAUqp-qytw_fcn_HCI3Q=.be485c1d-7fda-4929-baf9-c1b4c187f14b@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <vTn5PanuJeRPJaHjkNOEoUqwIcbRyIJ7Z2EypeOCQdg=.2b0d1321-4033-44e8-abe5-7ea79a22b51a@github.com>
 <nBSMvOBlzKn60s3_wBdc7BBzAUqp-qytw_fcn_HCI3Q=.be485c1d-7fda-4929-baf9-c1b4c187f14b@github.com>
Message-ID: <fYO5jC04hhTJrcfvycfoes-PAR8IyIx9guqsmt_XwMg=.4eadc9c6-333a-493c-93e8-1b001aac6794@github.com>

On Tue, 29 Jul 2025 14:40:09 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update system property name
>
> test/jdk/sun/security/ssl/X509TrustManagerImpl/PKIXExtendedTM.java line 36:
> 
>> 34:  * @run main/othervm PKIXExtendedTM 1
>> 35:  * @run main/othervm PKIXExtendedTM 2
>> 36:  * @run main/othervm PKIXExtendedTM 3
> 
> Why did you remove these lines/test cases?

Good catch, thanks! Probably removed them for testing and forgot to restore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240130988

From abarashev at openjdk.org  Tue Jul 29 15:03:01 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 15:03:01 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v13]
In-Reply-To: <nBSMvOBlzKn60s3_wBdc7BBzAUqp-qytw_fcn_HCI3Q=.be485c1d-7fda-4929-baf9-c1b4c187f14b@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <vTn5PanuJeRPJaHjkNOEoUqwIcbRyIJ7Z2EypeOCQdg=.2b0d1321-4033-44e8-abe5-7ea79a22b51a@github.com>
 <nBSMvOBlzKn60s3_wBdc7BBzAUqp-qytw_fcn_HCI3Q=.be485c1d-7fda-4929-baf9-c1b4c187f14b@github.com>
Message-ID: <--OeS9BVXbxOwVCfWNvJU3vMo3O4NvkwCrzXEc2JdQw=.f6e215b4-411e-4c61-bee1-5ca7d1a59ae8@github.com>

On Tue, 29 Jul 2025 14:31:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update system property name
>
> src/java.base/share/conf/security/java.security line 29:
> 
>> 27: # an unspecified error when initializing the java.security.Security class.
>> 28: # Properties in this file are typically parsed only once. If any of the
>> 29: # Properties in this file are typically parsed only once. If any of the
> 
> Duplicate line added, is this an accidental change?

Yes, looks like it was pasted by accident, we shouldn't make any changes to this file. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240143909

From abarashev at openjdk.org  Tue Jul 29 15:03:03 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 15:03:03 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v13]
In-Reply-To: <DLZFcL8E7oI0kiz-_66Ww--YTj13K61tnbqshh40P4w=.e11b12d2-8ce1-4f88-8839-e411aba4fe20@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <vTn5PanuJeRPJaHjkNOEoUqwIcbRyIJ7Z2EypeOCQdg=.2b0d1321-4033-44e8-abe5-7ea79a22b51a@github.com>
 <nBSMvOBlzKn60s3_wBdc7BBzAUqp-qytw_fcn_HCI3Q=.be485c1d-7fda-4929-baf9-c1b4c187f14b@github.com>
 <3YV9bY3ogo4EjCHqsjO53Z4avgvezCvRSdBgGBUKbc0=.f771dc2d-3b15-4628-9fbc-5a275713b8a1@github.com>
 <DLZFcL8E7oI0kiz-_66Ww--YTj13K61tnbqshh40P4w=.e11b12d2-8ce1-4f88-8839-e411aba4fe20@github.com>
Message-ID: <SwkJaZuysiSdfLoOFwGAwviGQGP6AksLrBrDZI75fxk=.5ef6f37d-80e3-4127-aaaa-04a550b872a6@github.com>

On Tue, 29 Jul 2025 14:52:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> The year is set to 2025 already, maybe something else needs to be changed? Please elaborate.
>
> Wrong file, I meant `test/jdk/sun/security/mscapi/ShortRSAKeyWithinTLS.java`

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240138237

From abarashev at openjdk.org  Tue Jul 29 15:11:45 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 15:11:45 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v14]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/eb972544..df1a1fac

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

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

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

From duke at openjdk.org  Tue Jul 29 17:24:34 2025
From: duke at openjdk.org (Darragh Conway)
Date: Tue, 29 Jul 2025 17:24:34 GMT
Subject: RFR: 8360408: [TEST] Use @requires tag instead of exiting based on
 "os.name" property value for sun/net/www/protocol/file/FileURLTest.java
Message-ID: <8DMh9uvckj8447yqHPMswDeg0xRxq-cnFaDW6GjjRKY=.a671b34d-b86d-4cbb-8c68-7a27eba5aed1@github.com>

Refactor remove the test logic for Windows OS and replace with jtreg check for os

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

Commit messages:
 - 8360408: [TEST] Use @requires tag instead of exiting based on "os.name" property value for sun/net/www/protocol/file/FileURLTest.java

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

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

From mullan at openjdk.org  Tue Jul 29 18:08:00 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Jul 2025 18:08:00 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v14]
In-Reply-To: <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
Message-ID: <ALtbuwkHuuYdxzcfEScHOSO8xTG3J7qhTVA97IJw0Mo=.1c7cfb9e-39da-4554-8df1-d52d9cd500fa@github.com>

On Tue, 29 Jul 2025 15:11:45 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
>> 
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
>> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
>> 
>> **SUNX509 KeyManager performance before the change**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> 
>> **SUNX509 KeyManager performance after the change**
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 74:

> 72:  * This class tests against the peer supported certificate signatures sent in
> 73:  * "signature_algorithms_cert" extension.
> 74:  */

Can you add a sentence or two about why the test should fail when the SunX509 KM is used and the certCheck property is enabled or the PKIX KM is used? I think it is because the server's cert is signed with SHA256withECDSA and the "signature_algorithms_cert" extension is set to SHA384withECDSA, so it must be signed with SHA384withECDSA, is that right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240586473

From abarashev at openjdk.org  Tue Jul 29 18:24:02 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 18:24:02 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v14]
In-Reply-To: <ALtbuwkHuuYdxzcfEScHOSO8xTG3J7qhTVA97IJw0Mo=.1c7cfb9e-39da-4554-8df1-d52d9cd500fa@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
 <ALtbuwkHuuYdxzcfEScHOSO8xTG3J7qhTVA97IJw0Mo=.1c7cfb9e-39da-4554-8df1-d52d9cd500fa@github.com>
Message-ID: <JFzxFwa0BDJ0LD7CplO0IMAAFRkFGtRnO8BrgXPegRI=.6a0dddf6-6e21-480b-8b25-965fce7f527b@github.com>

On Tue, 29 Jul 2025 18:05:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 74:
> 
>> 72:  * This class tests against the peer supported certificate signatures sent in
>> 73:  * "signature_algorithms_cert" extension.
>> 74:  */
> 
> Can you add a sentence or two about why the test should fail when the SunX509 KM is used and the certCheck property is enabled or the PKIX KM is used? I think it is because the server's cert is signed with SHA256withECDSA and the "signature_algorithms_cert" extension is set to SHA384withECDSA, so it must be signed with SHA384withECDSA, is that right?

Yes, correct: `jdk.tls.client.SignatureSchemes` and `jdk.tls.server.SignatureSchemes` system properties set signature schemes for both "signature_algorithms" and "signature_algorithms_cert" extensions. Then we fail because server's certificate is signed with `SHA256withECDSA`. I'll update the comment to highlight that detail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240621241

From abarashev at openjdk.org  Tue Jul 29 18:33:58 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 18:33:58 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v14]
In-Reply-To: <JFzxFwa0BDJ0LD7CplO0IMAAFRkFGtRnO8BrgXPegRI=.6a0dddf6-6e21-480b-8b25-965fce7f527b@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
 <ALtbuwkHuuYdxzcfEScHOSO8xTG3J7qhTVA97IJw0Mo=.1c7cfb9e-39da-4554-8df1-d52d9cd500fa@github.com>
 <JFzxFwa0BDJ0LD7CplO0IMAAFRkFGtRnO8BrgXPegRI=.6a0dddf6-6e21-480b-8b25-965fce7f527b@github.com>
Message-ID: <elIXVuwf2a0ljbpewBa_43P2faMoWOwPhi6yMhNd3eI=.fc303748-c7a6-418e-b2bd-350fbb729424@github.com>

On Tue, 29 Jul 2025 18:20:54 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 74:
>> 
>>> 72:  * This class tests against the peer supported certificate signatures sent in
>>> 73:  * "signature_algorithms_cert" extension.
>>> 74:  */
>> 
>> Can you add a sentence or two about why the test should fail when the SunX509 KM is used and the certCheck property is enabled or the PKIX KM is used? I think it is because the server's cert is signed with SHA256withECDSA and the "signature_algorithms_cert" extension is set to SHA384withECDSA, so it must be signed with SHA384withECDSA, is that right?
>
> Yes, correct: `jdk.tls.client.SignatureSchemes` and `jdk.tls.server.SignatureSchemes` system properties set signature schemes for both "signature_algorithms" and "signature_algorithms_cert" extensions. Then we fail because server's certificate is signed with `SHA256withECDSA`. I'll update the comment to highlight that detail.

BTW, by using the above system properties we also bypass this check in the process:
https://github.com/openjdk/jdk/blob/ea754316fd6d691a701dfb4bc921ea8c92dc5dd4/src/java.base/share/classes/sun/security/ssl/CertificateMessage.java#L1011

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240642639

From mdonovan at openjdk.org  Tue Jul 29 18:51:30 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 29 Jul 2025 18:51:30 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v6]
In-Reply-To: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
Message-ID: <khNW1Y-cfarzK849mQFD9dVXFBGBdPcIBeGcwDv_v-U=.eaa599e8-6cb1-4447-be30-b794ffbf9829@github.com>

> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
> 
> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)

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

 - changed keystore to PKCS12 and remove key initialization
 - added new method, setOneHourValidity(), and removed it from the static method.
 - Merge branch 'master' into certbuilder
 - fixed redundant setNotAfter() calls. One of them should have been setNotBefore
 - Merge branch 'master' into certbuilder
 - expanded wildcard imports
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - reversed order of DN strings when making certificates.
 - Merge branch 'master' into certbuilder
 - ... and 5 more: https://git.openjdk.org/jdk/compare/011de4c8...963625db

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

Changes: https://git.openjdk.org/jdk/pull/23700/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23700&range=05
  Stats: 789 lines in 3 files changed: 162 ins; 582 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/23700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23700/head:pull/23700

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

From mullan at openjdk.org  Tue Jul 29 19:06:00 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Jul 2025 19:06:00 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v14]
In-Reply-To: <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
Message-ID: <hNY32E8l-l24_x_nzWz6Wub6Jiyco1VfFbipw8Bi-2E=.1554098b-3528-4070-a3a4-01108a99ed74@github.com>

On Tue, 29 Jul 2025 15:11:45 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
>> 
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
>> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
>> 
>> **SUNX509 KeyManager performance before the change**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> 
>> **SUNX509 KeyManager performance after the change**
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 88:

> 86:         uidCounter = new AtomicLong();
> 87:         entryCacheMap = Collections.synchronizedMap
> 88:                         (new SizedMap<>());

You can remove `SizedMap` on lines 94-101. Did you see any reason why a `LinkedHashMap` was used? (I cannot, but this code has not changed in many releases, so we should be sure its ok).

test/jdk/sun/security/ssl/X509KeyManager/CertChecking.java line 110:

> 108:     private static final boolean[] NO_DG_USAGE =
> 109:             new boolean[]{false, true, true, true, true, true};
> 110:     private static final boolean[] NO_DG_NO_KE_USAGE =

Nit: how about NO_DS instead of NO_DG?

test/jdk/sun/security/ssl/X509KeyManager/CertChecking.java line 128:

> 126:         // --- Usage and expired test cases --
> 127: 
> 128:         // Both should fail with no usages at all

Clarify what you mean by "Both should fail"? This test doesn't do a TLS handshake. Maybe what you want to comment on is the order when checking is enabled (i.e. cert with bad usage is always preferred last).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240708490
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240672544
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240675270

From abarashev at openjdk.org  Tue Jul 29 19:12:59 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 19:12:59 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v14]
In-Reply-To: <hNY32E8l-l24_x_nzWz6Wub6Jiyco1VfFbipw8Bi-2E=.1554098b-3528-4070-a3a4-01108a99ed74@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
 <hNY32E8l-l24_x_nzWz6Wub6Jiyco1VfFbipw8Bi-2E=.1554098b-3528-4070-a3a4-01108a99ed74@github.com>
Message-ID: <XVXBFtL0Lk4PSxYQ-z2QKrrvsd2PUcvV1c_RxwwrU5g=.45b33d45-dc40-4436-b6e2-ff8388a5a4ff@github.com>

On Tue, 29 Jul 2025 18:45:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> test/jdk/sun/security/ssl/X509KeyManager/CertChecking.java line 110:
> 
>> 108:     private static final boolean[] NO_DG_USAGE =
>> 109:             new boolean[]{false, true, true, true, true, true};
>> 110:     private static final boolean[] NO_DG_NO_KE_USAGE =
> 
> Nit: how about NO_DS instead of NO_DG?

Good catch, I'll rename it. Not sure why I used `DG` and not `DS`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240722307

From abarashev at openjdk.org  Tue Jul 29 19:22:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 19:22:04 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v14]
In-Reply-To: <hNY32E8l-l24_x_nzWz6Wub6Jiyco1VfFbipw8Bi-2E=.1554098b-3528-4070-a3a4-01108a99ed74@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
 <hNY32E8l-l24_x_nzWz6Wub6Jiyco1VfFbipw8Bi-2E=.1554098b-3528-4070-a3a4-01108a99ed74@github.com>
Message-ID: <V4ADI2rhfypse66oGJ1Ug9q1x-6rhH1lZYM62eE_XHU=.5f828365-e6eb-41f3-9f06-b81cafb3f169@github.com>

On Tue, 29 Jul 2025 18:46:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> test/jdk/sun/security/ssl/X509KeyManager/CertChecking.java line 128:
> 
>> 126:         // --- Usage and expired test cases --
>> 127: 
>> 128:         // Both should fail with no usages at all
> 
> Clarify what you mean by "Both should fail"? This test doesn't do a TLS handshake. Maybe what you want to comment on is the order when checking is enabled (i.e. cert with bad usage is always preferred last).

Sounds good, changing it to "Both client and server should fail". `usageTestCase` method takes 2 boolean values to indicate whether to check for server and client failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240741713

From mullan at openjdk.org  Tue Jul 29 19:27:57 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Jul 2025 19:27:57 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v14]
In-Reply-To: <V4ADI2rhfypse66oGJ1Ug9q1x-6rhH1lZYM62eE_XHU=.5f828365-e6eb-41f3-9f06-b81cafb3f169@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
 <hNY32E8l-l24_x_nzWz6Wub6Jiyco1VfFbipw8Bi-2E=.1554098b-3528-4070-a3a4-01108a99ed74@github.com>
 <V4ADI2rhfypse66oGJ1Ug9q1x-6rhH1lZYM62eE_XHU=.5f828365-e6eb-41f3-9f06-b81cafb3f169@github.com>
Message-ID: <VIkMiD93om4P0-d1h-zXmvqFZbd5awpYWXcrpOTySBA=.4b474801-cb61-431f-b926-d72f96991c72@github.com>

On Tue, 29 Jul 2025 19:19:15 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/X509KeyManager/CertChecking.java line 128:
>> 
>>> 126:         // --- Usage and expired test cases --
>>> 127: 
>>> 128:         // Both should fail with no usages at all
>> 
>> Clarify what you mean by "Both should fail"? This test doesn't do a TLS handshake. Maybe what you want to comment on is the order when checking is enabled (i.e. cert with bad usage is always preferred last).
>
> Sounds good, changing it to "Both client and server should fail". `usageTestCase` method takes 2 boolean values to indicate whether to check for server and client failure.

But I am still confused by what you mean by fail? Typically that means catching an Exception and checking that it is expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240752548

From abarashev at openjdk.org  Tue Jul 29 19:34:59 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 19:34:59 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v14]
In-Reply-To: <hNY32E8l-l24_x_nzWz6Wub6Jiyco1VfFbipw8Bi-2E=.1554098b-3528-4070-a3a4-01108a99ed74@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
 <hNY32E8l-l24_x_nzWz6Wub6Jiyco1VfFbipw8Bi-2E=.1554098b-3528-4070-a3a4-01108a99ed74@github.com>
Message-ID: <qJI0hLcoIdwPdkgp29WtBt478oevFXuBm3FdhYMQ-YA=.d8c6bf12-4194-433b-bbdd-d485331a9373@github.com>

On Tue, 29 Jul 2025 19:03:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 88:
> 
>> 86:         uidCounter = new AtomicLong();
>> 87:         entryCacheMap = Collections.synchronizedMap
>> 88:                         (new SizedMap<>());
> 
> You can remove `SizedMap` on lines 94-101. Did you see any reason why a `LinkedHashMap` was used? (I cannot, but this code has not changed in many releases, so we should be sure its ok).

Looks like `LinkedHashMap` was used so we can remove the eldest entry, the `SizedMap` is limited to the size of 10. Actually, I'll restore the original assignment of `entryCacheMap` to preserve the original cache design. I should have paid more attention to this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240765575

From abarashev at openjdk.org  Tue Jul 29 19:43:59 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 19:43:59 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v14]
In-Reply-To: <VIkMiD93om4P0-d1h-zXmvqFZbd5awpYWXcrpOTySBA=.4b474801-cb61-431f-b926-d72f96991c72@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
 <hNY32E8l-l24_x_nzWz6Wub6Jiyco1VfFbipw8Bi-2E=.1554098b-3528-4070-a3a4-01108a99ed74@github.com>
 <V4ADI2rhfypse66oGJ1Ug9q1x-6rhH1lZYM62eE_XHU=.5f828365-e6eb-41f3-9f06-b81cafb3f169@github.com>
 <VIkMiD93om4P0-d1h-zXmvqFZbd5awpYWXcrpOTySBA=.4b474801-cb61-431f-b926-d72f96991c72@github.com>
Message-ID: <ZHoBs2dV8UFwruPKHqDeOMMuniY0r4x2wEo7m3rggoE=.3dd350d8-8c17-4157-b115-4aea701ae03d@github.com>

On Tue, 29 Jul 2025 19:24:53 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sounds good, changing it to "Both client and server should fail". `usageTestCase` method takes 2 boolean values to indicate whether to check for server and client failure.
>
> But I am still confused by what you mean by fail? Typically that means catching an Exception and checking that it is expected.

It means incorrect alias returned, or incorrect order of aliases. Yes, probably `fail` is a bad word choice here, I'll rephrase it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240780122

From mullan at openjdk.org  Tue Jul 29 19:53:00 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Jul 2025 19:53:00 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v14]
In-Reply-To: <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
Message-ID: <L2T2LG_8z0z1j5rnV5D3sdqhgAZPrtlE1qKQAiOaA6k=.968e9cbc-d63d-4c65-a193-9bfb538bc580@github.com>

On Tue, 29 Jul 2025 15:11:45 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
>> 
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
>> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
>> 
>> **SUNX509 KeyManager performance before the change**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> 
>> **SUNX509 KeyManager performance after the change**
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java line 58:

> 56:  * Layer that adds algorithm constraints and certificate checking to a key
> 57:  * manager.
> 58:  */

Can you add some more comments about the algorithm it uses for selecting certificates (when certChecking is enabled)? In other words, what the preference order is for selecting certs, and which certificates are not chosen due to disabled algs, or other reasons. You can probably copy some/most of this from the comments in `X509KeyManagerImpl`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240798471

From abarashev at openjdk.org  Tue Jul 29 20:38:58 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 20:38:58 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v14]
In-Reply-To: <L2T2LG_8z0z1j5rnV5D3sdqhgAZPrtlE1qKQAiOaA6k=.968e9cbc-d63d-4c65-a193-9bfb538bc580@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <e24iirywx0UVghE6HJ5ufshbh96D_m8PS2F_KLDs3Mw=.22531126-51cd-4b09-a858-52ee4188635d@github.com>
 <L2T2LG_8z0z1j5rnV5D3sdqhgAZPrtlE1qKQAiOaA6k=.968e9cbc-d63d-4c65-a193-9bfb538bc580@github.com>
Message-ID: <ER4QktLFEDVNx8LXI8Ku0PV6ZZ7oYznlGIRNmPmAOuc=.968313bc-40bb-4ea1-a18b-25f78940b17a@github.com>

On Tue, 29 Jul 2025 19:50:16 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java line 58:
> 
>> 56:  * Layer that adds algorithm constraints and certificate checking to a key
>> 57:  * manager.
>> 58:  */
> 
> Can you add some more comments about the algorithm it uses for selecting certificates (when certChecking is enabled)? In other words, what the preference order is for selecting certs, and which certificates are not chosen due to disabled algs, or other reasons. You can probably copy some/most of this from the comments in `X509KeyManagerImpl`.

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2240958831

From abarashev at openjdk.org  Tue Jul 29 21:00:44 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Jul 2025 21:00:44 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v15]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <HuXsWjY3SAI9z6YRIPJeWNJQznPcZPbkG8qgWqRHx70=.20a8dc3f-f721-4a2b-9126-d7cf4c1140ec@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Review fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/df1a1fac..c8c4008a

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

  Stats: 44 lines in 4 files changed: 22 ins; 2 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From vyazici at openjdk.org  Wed Jul 30 08:14:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 30 Jul 2025 08:14:55 GMT
Subject: RFR: 8360408: [TEST] Use @requires tag instead of exiting based on
 "os.name" property value for sun/net/www/protocol/file/FileURLTest.java
In-Reply-To: <8DMh9uvckj8447yqHPMswDeg0xRxq-cnFaDW6GjjRKY=.a671b34d-b86d-4cbb-8c68-7a27eba5aed1@github.com>
References: <8DMh9uvckj8447yqHPMswDeg0xRxq-cnFaDW6GjjRKY=.a671b34d-b86d-4cbb-8c68-7a27eba5aed1@github.com>
Message-ID: <mX2ku0qKJuLayXGtQltn6SOONdICpw-Ulnv0w4-xFBE=.48be0358-98c5-4062-b6bd-990e0c731727@github.com>

On Tue, 29 Jul 2025 17:18:12 GMT, Darragh Conway <duke at openjdk.org> wrote:

> Refactor remove the test logic for Windows OS and replace with jtreg check for os

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26537#pullrequestreview-3070360557

From vyazici at openjdk.org  Wed Jul 30 09:32:17 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 30 Jul 2025 09:32:17 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v5]
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: <RtuN1tYoGPnhKaiz_mblX3DMcHWVPTDbF-lmDpFaoXo=.c5e35618-0979-4aa1-91ef-64ffca65ff2c@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:

  Apply review feedback for `FileChannelPublisherTest`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/da698406..99503c0b

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

  Stats: 78 lines in 1 file changed: 37 ins; 20 del; 21 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  Wed Jul 30 09:36:12 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 30 Jul 2025 09:36:12 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <NQ8GkzuYvVUmP6CrBT61yjTt0B90nDKaPgX8rgG-zoE=.e56b58ef-1d46-4ba5-b413-7927bfbbf370@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
 <NQ8GkzuYvVUmP6CrBT61yjTt0B90nDKaPgX8rgG-zoE=.e56b58ef-1d46-4ba5-b413-7927bfbbf370@github.com>
Message-ID: <iivI8nKd-hVeQbv0zFmP21yvLxFCGMBxMgbtpriiqlQ=.d0b9abe7-f6d3-4412-9177-281054c61c2a@github.com>

On Mon, 28 Jul 2025 06:56:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix typo in `Utils::getBufferWithAtMost` Javadoc
>>  - Link to `BUFSIZE` in `Utils::getBuffer` Javadoc
>>  - Improve wording for signaling request cancellation
>>  - Remove synchronization for `FileChannelIterator`
>>  - Improve exception handling and documentation for `ofFileChannel`
>>  - Add `@since 26` to `ofFileChannel`
>
> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 168:
> 
>> 166:         }
>> 167: 
>> 168:         private static BlockingQueue<byte[]> addRequestBodyConsumingServerHandler(
> 
> Nit - instead of the long name, it might be better to rename the method to just `addHandler(...)` and then add a one-liner comment to the method saying that the handler consumes the entire request body.

I'm a big fan of [self-documenting code](https://en.wikipedia.org/wiki/Self-documenting_code) over comments. Unless there is a strong objection, I'd like to stick to my long method name. ?

> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 173:
> 
>> 171:             HttpTestHandler handler = exchange -> {
>> 172:                 // `HttpTestExchange::toString` changes on failure, pin it
>> 173:                 String exchangeName = exchange.toString();
> 
> Nit - the use of exchange name may not be necessary and instead we could maybe just use the request URI (`getRequestURI()`) in the log messages.

Dumping the exchange name (which includes the object identifier!) has proved in several troubleshooting occasions very helpful in this test, in particular, when request handler output can be interleaved due to either timing issues in sequential requests or concurrent requests. I settled on this version after trying out the request URI, which did not help much since it is _always_ the same.

> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 198:
> 
>> 196:                             "Server[%s] failed to process the request (exchange=%s)".formatted(serverName, exception),
>> 197:                             exception);
>> 198:                     readRequestBodyBytes.add(new byte[0]);
> 
> Just to make the test a bit more robust and prevent the subsequent `readRequestBodyBytes.take()` from blocking forever, it might be better to either catch `Throwable` or add this `readRequestBodyBytes.add(new byte[0]);` in the `finally` block (with some condition checks).

Changed to catch `Throwable` in 99503c0bac7.

> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 296:
> 
>> 294:             "6,2,5"     // (offset + length) > fileSize
>> 295:     })
>> 296:     void testIllegalOffset(
> 
> Given what this test verifies, should we name this method `testIllegalOffsetOrLen(...)`?

Changed in 99503c0bac7.

> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 309:
> 
>> 307:     @ParameterizedTest
>> 308:     @MethodSource("serverRequestPairs")
>> 309:     void testContentLessThanBufferSize(
> 
> Hello Volkan, on first read, it's not clear to me what this test is testing. Can a brief comment be added to this test method noting what it is testing?

Good call. Improved the documentation of both `testContent{Less,More}ThanBufferSize()` methods in 99503c0bac7.

> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 439:
> 
>> 437:             HttpRequest request = pair
>> 438:                     .requestBuilder
>> 439:                     .POST(ofFileChannel(fileChannel, fileChannelOffset, fileChannelLength))
> 
> I think it would be better to not add a static import for this method and instead use `BodyPublishers.ofFileChannel(...)` to make it easily visible what this method is (especially because this test has a similarly named `withFileChannel(...)` method).

Changed in 99503c0bac7.

> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 513:
> 
>> 511:             LOGGER.log("Verifying the client failure");
>> 512:             Exception requestFailure = assertThrows(ExecutionException.class, () -> responseFutureRef.get().get());
>> 513:             assertInstanceOf(UncheckedIOException.class, requestFailure.getCause());
> 
> I think the application should be receiving a `IOException` (both for send() and sendAsync()) instead of a `UncheckedIOException`.

The `IOE` thrown is wrapped by an `UncheckedIOE` in `FileChannelIterator::next`, which overrides `Iterator::next` and that does not allow a `throws` in the `next()` footprint. Would you mind elaborating on your remark, please?

> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 514:
> 
>> 512:             Exception requestFailure = assertThrows(ExecutionException.class, () -> responseFutureRef.get().get());
>> 513:             assertInstanceOf(UncheckedIOException.class, requestFailure.getCause());
>> 514:             assertInstanceOf(ClosedChannelException.class, requestFailure.getCause().getCause());
> 
> Nit - the `assertInstanceOf(...)` returns the instance of the exception which matches the instanceof check. So it might be easier to understand while reading this code, if we did something like:
> 
> 
> final IOException ioe = assertInstanceOf(IOException.class, requestFailure.getCause());
> assertInstanceOf(ClosedChannelException.class, ioe.getCause());

Changed as requested in 99503c0bac7.

> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 528:
> 
>> 526:     // On Windows, modification while reading is not possible.
>> 527:     // Recall the infamous `The process cannot access the file because it is being used by another process`.
>> 528:     @DisabledOnOs(OS.WINDOWS)
> 
> On Windows, is this still true if you replace the call in this test method from:
> 
> 
> Files.write(filePath, generateFileBytes(1));
> 
> to:
> 
> fileChannel.truncate(1);

Indeed this is not an issue anymore ? removed cited lines in 99503c0bac7.

> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 567:
> 
>> 565:                 String requestFailureMessage = requestFailure.getMessage();
>> 566:                 assertTrue(
>> 567:                         requestFailureMessage.contains("Unexpected EOF"),
> 
> Wouldn't this message be on the `ExecutionException`'s `getCause()`? instead of the `ExecutionException` itself?

In fact, the message is from the `IOE` wrapped in a `UncheckedIOE` wrapped in the `ExecutionException`. I thought it would not matter from the perspective of the test. Nevertheless, in 99503c0bac7, I've updated the code to validate this causal chain and verify the message obtained from the `IOE`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2242069117
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2242069541
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2242070753
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2242070041
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2242070310
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2242070550
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2242070964
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2242071082
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2242071466
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2242072115

From vyazici at openjdk.org  Wed Jul 30 09:36:13 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 30 Jul 2025 09:36:13 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <lHMimdpIy2I4yTHxp3HovOOWOONmyKfqcgRXd_PAa8U=.4ba0c8d6-1e5b-490a-a43b-a7a23b8fb40d@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
 <7weBed6pMcjo0c5EI92Vdmg7SIrWeC5-czEUwLcTzjI=.d4459bad-b956-4910-8768-4866235ccc0f@github.com>
 <Hcr8kZYG-k2ikanZWPStroWzZqFOBUTjOHsiUhMJRJM=.5cb4db2f-23c1-41ba-bda0-d9870ccd1898@github.com>
 <lHMimdpIy2I4yTHxp3HovOOWOONmyKfqcgRXd_PAa8U=.4ba0c8d6-1e5b-490a-a43b-a7a23b8fb40d@github.com>
Message-ID: <VkOYKu8SLHXe7mYfULFFtdo2clmklgPSx7AfLHt1F64=.8b2c81a3-19da-4601-8fda-03d1402e9977@github.com>

On Mon, 28 Jul 2025 10:00:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> I'm not completely sure where it creates those temporary directories.
>> 
>> JUnit `@TempDir` uses the JTreg scratch directory ? [JTreg 7.5.2](https://github.com/openjdk/jtreg/blob/master/CHANGELOG.md#752) bundles [CODETOOLS-7903953](https://bugs.openjdk.org/browse/CODETOOLS-7903953) addressing this issue. Shall I still replace these with `Files::cTD`? Or `jdk.test.lib.Utils::createTempFile`?
>
> Can you verify how it behaves with the `-retain` option of jtreg? I think the use of `cleanup` attribute here can conflict with the `-retain` option that can be used to launch `jtreg`. If it is possible to instruct JUnit to not do any cleanup at all, then I think using `@TempDir` here is OK (since as you note, it will end up using the jtreg scratch directory). If JUnit cannot be instructed not to do any cleanup, then using `@TempDir` here would add another layer of potential issue if jtreg was launched with `-retain:all` (for example).

Indeed JUnit's `CleanupMode.ON_SUCCESS` does not honor JTreg's `-retain` ? I will follow-up on this. That said, without a `CleanupMode`, it all works as expected ? I decided to go with that in 99503c0bac7.

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

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

From jpai at openjdk.org  Wed Jul 30 10:07:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Jul 2025 10:07:59 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <iivI8nKd-hVeQbv0zFmP21yvLxFCGMBxMgbtpriiqlQ=.d0b9abe7-f6d3-4412-9177-281054c61c2a@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
 <NQ8GkzuYvVUmP6CrBT61yjTt0B90nDKaPgX8rgG-zoE=.e56b58ef-1d46-4ba5-b413-7927bfbbf370@github.com>
 <iivI8nKd-hVeQbv0zFmP21yvLxFCGMBxMgbtpriiqlQ=.d0b9abe7-f6d3-4412-9177-281054c61c2a@github.com>
Message-ID: <eXsopp9trwJc8k2e1uNXU_fLscncMF9g1MLiL4wXNJQ=.b9111198-bbf1-41e6-900f-9852eb8178eb@github.com>

On Wed, 30 Jul 2025 09:33:29 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 513:
>> 
>>> 511:             LOGGER.log("Verifying the client failure");
>>> 512:             Exception requestFailure = assertThrows(ExecutionException.class, () -> responseFutureRef.get().get());
>>> 513:             assertInstanceOf(UncheckedIOException.class, requestFailure.getCause());
>> 
>> I think the application should be receiving a `IOException` (both for send() and sendAsync()) instead of a `UncheckedIOException`.
>
> The `IOE` thrown is wrapped by an `UncheckedIOE` in `FileChannelIterator::next`, which overrides `Iterator::next` and that does not allow a `throws` in the `next()` footprint. Would you mind elaborating on your remark, please?

Hello Volkan, the specification of `HttpClient.send(...)` (and sendAsync()) is that it throws a checked `IOException`. So any other exceptions that we throw internally (like this one) need to be converted to an `IOException` when it reaches the application code.

We have code in `HttpClientImpl.send(...)` which currently does instanceof checks against these exceptions and converts them to an `IOException`. I'm guessing your test is currently passing, which suggests to me that `sendAsync()` is propagating a `UncheckedIOException` to the application code. Would it be possible to tweak the test a bit to replace that call of `sendAsync()` with a `send()` (even if those tweaked changes cannot be pushed to this PR) and see what gets propagated? I suspect it would be `IOException`.

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

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

From jpai at openjdk.org  Wed Jul 30 10:18:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Jul 2025 10:18:57 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <iivI8nKd-hVeQbv0zFmP21yvLxFCGMBxMgbtpriiqlQ=.d0b9abe7-f6d3-4412-9177-281054c61c2a@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
 <NQ8GkzuYvVUmP6CrBT61yjTt0B90nDKaPgX8rgG-zoE=.e56b58ef-1d46-4ba5-b413-7927bfbbf370@github.com>
 <iivI8nKd-hVeQbv0zFmP21yvLxFCGMBxMgbtpriiqlQ=.d0b9abe7-f6d3-4412-9177-281054c61c2a@github.com>
Message-ID: <Ap8vRQ0baxhlm1ZKc_-VLtBaVj4L4Uxkkcu0abNkVgs=.da2730f7-4da7-4cb7-ba52-9f095a121c06@github.com>

On Wed, 30 Jul 2025 09:33:59 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 567:
>> 
>>> 565:                 String requestFailureMessage = requestFailure.getMessage();
>>> 566:                 assertTrue(
>>> 567:                         requestFailureMessage.contains("Unexpected EOF"),
>> 
>> Wouldn't this message be on the `ExecutionException`'s `getCause()`? instead of the `ExecutionException` itself?
>
> In fact, the message is from the `IOE` wrapped in a `UncheckedIOE` wrapped in the `ExecutionException`. I thought it would not matter from the perspective of the test. Nevertheless, in 99503c0bac7, I've updated the code to validate this causal chain and verify the message obtained from the `IOE`.

Thank you for this update to use the message from the underlying cause instance. This prevents the test from relying on which constructor of `ExecutionException` might have been used when throwing that exception from the `Future.get()` call.

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

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

From mullan at openjdk.org  Wed Jul 30 13:29:00 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Jul 2025 13:29:00 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v15]
In-Reply-To: <HuXsWjY3SAI9z6YRIPJeWNJQznPcZPbkG8qgWqRHx70=.20a8dc3f-f721-4a2b-9126-d7cf4c1140ec@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <HuXsWjY3SAI9z6YRIPJeWNJQznPcZPbkG8qgWqRHx70=.20a8dc3f-f721-4a2b-9126-d7cf4c1140ec@github.com>
Message-ID: <MHh4I0llc5-44CNUHozeMhH7ufEP5UYnbe66Yx7hhQc=.56069bcc-03eb-4c6f-b052-9b5e6eb311f9@github.com>

On Tue, 29 Jul 2025 21:00:44 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
>> 
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
>> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
>> 
>> **SUNX509 KeyManager performance before the change**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> 
>> **SUNX509 KeyManager performance after the change**
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fixes

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25016#pullrequestreview-3071557728

From rriggs at openjdk.org  Wed Jul 30 13:44:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Jul 2025 13:44:58 GMT
Subject: RFR: 8360408: [TEST] Use @requires tag instead of exiting based on
 "os.name" property value for sun/net/www/protocol/file/FileURLTest.java
In-Reply-To: <8DMh9uvckj8447yqHPMswDeg0xRxq-cnFaDW6GjjRKY=.a671b34d-b86d-4cbb-8c68-7a27eba5aed1@github.com>
References: <8DMh9uvckj8447yqHPMswDeg0xRxq-cnFaDW6GjjRKY=.a671b34d-b86d-4cbb-8c68-7a27eba5aed1@github.com>
Message-ID: <50PcCtDdWjkNxzDUZfFzq99uZEJN7o7d5Yo8DjlzUi4=.2b7104e5-5721-483a-9014-d89a58e613eb@github.com>

On Tue, 29 Jul 2025 17:18:12 GMT, Darragh Conway <duke at openjdk.org> wrote:

> Refactor remove the test logic for Windows OS and replace with jtreg check for os

looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26537#pullrequestreview-3071619647

From myankelevich at openjdk.org  Wed Jul 30 15:34:03 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 30 Jul 2025 15:34:03 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v5]
In-Reply-To: <RtuN1tYoGPnhKaiz_mblX3DMcHWVPTDbF-lmDpFaoXo=.c5e35618-0979-4aa1-91ef-64ffca65ff2c@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <RtuN1tYoGPnhKaiz_mblX3DMcHWVPTDbF-lmDpFaoXo=.c5e35618-0979-4aa1-91ef-64ffca65ff2c@github.com>
Message-ID: <FxxgVdmNoOgf5FqXBwE5gMd-1QZCHom2MSBx7lS5S2c=.db846d3c-08c4-4474-ad8b-e6554fd853dd@github.com>

On Wed, 30 Jul 2025 09:32:17 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:
> 
>   Apply review feedback for `FileChannelPublisherTest`

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 27:

> 25:  * @test
> 26:  * @summary Verifies `HttpRequest.BodyPublishers::ofFileChannel`
> 27:  * @library /test/lib

Nit: Could you please add a `@bug` with id here?

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

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

From vyazici at openjdk.org  Wed Jul 30 17:51:59 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 30 Jul 2025 17:51:59 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <eXsopp9trwJc8k2e1uNXU_fLscncMF9g1MLiL4wXNJQ=.b9111198-bbf1-41e6-900f-9852eb8178eb@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
 <NQ8GkzuYvVUmP6CrBT61yjTt0B90nDKaPgX8rgG-zoE=.e56b58ef-1d46-4ba5-b413-7927bfbbf370@github.com>
 <iivI8nKd-hVeQbv0zFmP21yvLxFCGMBxMgbtpriiqlQ=.d0b9abe7-f6d3-4412-9177-281054c61c2a@github.com>
 <eXsopp9trwJc8k2e1uNXU_fLscncMF9g1MLiL4wXNJQ=.b9111198-bbf1-41e6-900f-9852eb8178eb@github.com>
Message-ID: <7j14xvrLzetod3mICHEFATv0_oAB101fSyPCo8asYcc=.2775daeb-0166-4118-9cc4-b7a2345843b7@github.com>

On Wed, 30 Jul 2025 10:05:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The `IOE` thrown is wrapped by an `UncheckedIOE` in `FileChannelIterator::next`, which overrides `Iterator::next` and that does not allow a `throws` in the `next()` footprint. Would you mind elaborating on your remark, please?
>
> Hello Volkan, the specification of `HttpClient.send(...)` (and sendAsync()) is that it throws a checked `IOException`. So any other exceptions that we throw internally (like this one) need to be converted to an `IOException` when it reaches the application code.
> 
> We have code in `HttpClientImpl.send(...)` which currently does instanceof checks against these exceptions and converts them to an `IOException`. I'm guessing your test is currently passing, which suggests to me that `sendAsync()` is propagating a `UncheckedIOException` to the application code. Would it be possible to tweak the test a bit to replace that call of `sendAsync()` with a `send()` (even if those tweaked changes cannot be pushed to this PR) and see what gets propagated? I suspect it would be `IOException`.

I've confirmed that updating the test to use `send()` results in `IOE` getting received. I have not updated the PR in this direction, since it adds more boilerplate, and I read your lines as, not a change, but a research request ? let me know if you meant otherwise.

> the specification of `HttpClient.send(...)` (and `sendAsync()`) is that it throws a checked `IOException`

`HttpClient::send` has the following Javadoc:


     * @throws IOException if an I/O error occurs when sending or receiving, or
     *         the client has {@linkplain ##closing shut down}
     * @throws InterruptedException ...
     * @throws IllegalArgumentException ...


whereas `::sendAsync` Javadoc has no details regarding I/O failures. Do you think the fact that `sendAsync()` does *not* have a to-`IOException`-translation is an oversight that should be improved, or an intentional slack for the implementation?

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

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

From vyazici at openjdk.org  Wed Jul 30 17:59:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 30 Jul 2025 17:59:00 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v5]
In-Reply-To: <FxxgVdmNoOgf5FqXBwE5gMd-1QZCHom2MSBx7lS5S2c=.db846d3c-08c4-4474-ad8b-e6554fd853dd@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <RtuN1tYoGPnhKaiz_mblX3DMcHWVPTDbF-lmDpFaoXo=.c5e35618-0979-4aa1-91ef-64ffca65ff2c@github.com>
 <FxxgVdmNoOgf5FqXBwE5gMd-1QZCHom2MSBx7lS5S2c=.db846d3c-08c4-4474-ad8b-e6554fd853dd@github.com>
Message-ID: <BHqazQNl9wnSh-5p2QLrpgvujWofaGTBcQ9tRRoGP2k=.1ee71747-0fee-4c14-9875-d266c4687c53@github.com>

On Wed, 30 Jul 2025 15:30:07 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review feedback for `FileChannelPublisherTest`
>
> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 27:
> 
>> 25:  * @test
>> 26:  * @summary Verifies `HttpRequest.BodyPublishers::ofFileChannel`
>> 27:  * @library /test/lib
> 
> Nit: Could you please add a `@bug` with id here?

@myankelev, AFAIK, `@bug` is used to refer to _bugs_, not _features_. Tests in `test/jdk/java/net` adhere to this practice too. Since `FCPT` does not address a bug (at least, not yet :crossed_fingers:), I intentionally omitted the `@bug` tag.

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

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

From wetmore at openjdk.org  Thu Jul 31 00:07:54 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 31 Jul 2025 00:07:54 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v2]
In-Reply-To: <oJ1AoP3RbB8R3dKAggoQHnfq0M-t4AYegc7VVwNRy80=.ce918b08-2592-46ea-a8df-93d7e6cebe25@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
 <oJ1AoP3RbB8R3dKAggoQHnfq0M-t4AYegc7VVwNRy80=.ce918b08-2592-46ea-a8df-93d7e6cebe25@github.com>
Message-ID: <5l4q7qI1rzg6qrbCsXwqt053ItbSrTKoDGMxeCzlEaI=.fb01b538-0f90-4a69-ba60-03f9239fe932@github.com>

On Mon, 28 Jul 2025 14:12:12 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR comments

Sent a few comments/format suggestions via Slack.

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

PR Review: https://git.openjdk.org/jdk/pull/26484#pullrequestreview-3073659857

From jpai at openjdk.org  Thu Jul 31 06:32:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 31 Jul 2025 06:32:57 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <7j14xvrLzetod3mICHEFATv0_oAB101fSyPCo8asYcc=.2775daeb-0166-4118-9cc4-b7a2345843b7@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
 <NQ8GkzuYvVUmP6CrBT61yjTt0B90nDKaPgX8rgG-zoE=.e56b58ef-1d46-4ba5-b413-7927bfbbf370@github.com>
 <iivI8nKd-hVeQbv0zFmP21yvLxFCGMBxMgbtpriiqlQ=.d0b9abe7-f6d3-4412-9177-281054c61c2a@github.com>
 <eXsopp9trwJc8k2e1uNXU_fLscncMF9g1MLiL4wXNJQ=.b9111198-bbf1-41e6-900f-9852eb8178eb@github.com>
 <7j14xvrLzetod3mICHEFATv0_oAB101fSyPCo8asYcc=.2775daeb-0166-4118-9cc4-b7a2345843b7@github.com>
Message-ID: <nnyrhqHZXLgdqW13aYbz8puCM688BbdDLxZi0AwKGLQ=.8d5938ba-b88f-4b88-98af-71ae35253beb@github.com>

On Wed, 30 Jul 2025 17:49:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Hello Volkan, the specification of `HttpClient.send(...)` (and sendAsync()) is that it throws a checked `IOException`. So any other exceptions that we throw internally (like this one) need to be converted to an `IOException` when it reaches the application code.
>> 
>> We have code in `HttpClientImpl.send(...)` which currently does instanceof checks against these exceptions and converts them to an `IOException`. I'm guessing your test is currently passing, which suggests to me that `sendAsync()` is propagating a `UncheckedIOException` to the application code. Would it be possible to tweak the test a bit to replace that call of `sendAsync()` with a `send()` (even if those tweaked changes cannot be pushed to this PR) and see what gets propagated? I suspect it would be `IOException`.
>
> I've confirmed that updating the test to use `send()` results in `IOE` getting received. I have not updated the PR in this direction, since it adds more boilerplate, and I read your lines as, not a change, but a research request ? let me know if you meant otherwise.
> 
>> the specification of `HttpClient.send(...)` (and `sendAsync()`) is that it throws a checked `IOException`
> 
> `HttpClient::send` has the following Javadoc:
> 
> 
>      * @throws IOException if an I/O error occurs when sending or receiving, or
>      *         the client has {@linkplain ##closing shut down}
>      * @throws InterruptedException ...
>      * @throws IllegalArgumentException ...
> 
> 
> whereas `::sendAsync` Javadoc has no details regarding I/O failures. Do you think the fact that `sendAsync()` does *not* have a to-`IOException`-translation is an oversight that should be improved, or an intentional slack for the implementation?

Hello Volkan,

> whereas ::sendAsync Javadoc has no details regarding I/O failures.

The `sendAsync()` has the same specification about IOException as that of `send()`. It says:

* <p> The returned completable future completes exceptionally with:
* <ul>
* <li>{@link IOException} - if an I/O error occurs when sending or receiving,
*      or the client has {@linkplain ##closing shut down}.</li>
* </ul>


> Do you think the fact that sendAsync() does not have a to-IOException-translation is an oversight that should be improved, or an intentional slack for the implementation?

My expectation is that both send() and sendAsync() should propagate the same exception to the application (of course for sendAsync() it would be propagated as a cause in the `ExecutionException`). So this is a surprise to me that we aren't currently doing that. We'll need inputs from Daniel (@dfuch) and Michael (@Michael-Mc-Mahon) whether this is intentional or an oversight.

> I have not updated the PR in this direction, since it adds more boilerplate, and I read your lines as, not a change, but a research request 

Yes, that's OK. Having said that, if it's easy to add a test which uses send() and causes an IOException (due to the FileChannel being closed mid way, for example), then it would be a good thing since that will then bring in the necessary coverage for the exception propagation for that method too.

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

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

From jpai at openjdk.org  Thu Jul 31 07:05:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 31 Jul 2025 07:05:54 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <iivI8nKd-hVeQbv0zFmP21yvLxFCGMBxMgbtpriiqlQ=.d0b9abe7-f6d3-4412-9177-281054c61c2a@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
 <NQ8GkzuYvVUmP6CrBT61yjTt0B90nDKaPgX8rgG-zoE=.e56b58ef-1d46-4ba5-b413-7927bfbbf370@github.com>
 <iivI8nKd-hVeQbv0zFmP21yvLxFCGMBxMgbtpriiqlQ=.d0b9abe7-f6d3-4412-9177-281054c61c2a@github.com>
Message-ID: <DbEzEHIbTlQCrsi0B_sDR3ryo54kQxH5G1qJpfS3bXc=.2ae992dd-4b2f-4ebe-999d-91c7cfae1e31@github.com>

On Wed, 30 Jul 2025 09:32:40 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 168:
>> 
>>> 166:         }
>>> 167: 
>>> 168:         private static BlockingQueue<byte[]> addRequestBodyConsumingServerHandler(
>> 
>> Nit - instead of the long name, it might be better to rename the method to just `addHandler(...)` and then add a one-liner comment to the method saying that the handler consumes the entire request body.
>
> I'm a big fan of [self-documenting code](https://en.wikipedia.org/wiki/Self-documenting_code) over comments. Unless there is a strong objection, I'd like to stick to my long method name. ?

I don't have an objection, it's OK to continue with this method name.

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

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

From abarashev at openjdk.org  Thu Jul 31 14:00:18 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 31 Jul 2025 14:00:18 GMT
Subject: Integrated: 8359956: Support algorithm constraints and certificate
 checks in SunX509 key manager
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <yggHd5BBSeudEPGDAn0uFv228qxvQyAfYkol99IjwTQ=.7be5c9fb-e2bc-44c3-ab6f-8bf747f6ac44@github.com>

On Fri, 2 May 2025 22:48:56 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

This pull request has now been integrated.

Changeset: e544cd99
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e544cd992099ef905266610c2c1456705cdc4587
Stats:     2483 lines in 17 files changed: 1743 ins; 629 del; 111 mod

8359956: Support algorithm constraints and certificate checks in SunX509 key manager

Reviewed-by: mullan

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

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

From duke at openjdk.org  Thu Jul 31 14:16:57 2025
From: duke at openjdk.org (duke)
Date: Thu, 31 Jul 2025 14:16:57 GMT
Subject: RFR: 8360408: [TEST] Use @requires tag instead of exiting based on
 "os.name" property value for sun/net/www/protocol/file/FileURLTest.java
In-Reply-To: <8DMh9uvckj8447yqHPMswDeg0xRxq-cnFaDW6GjjRKY=.a671b34d-b86d-4cbb-8c68-7a27eba5aed1@github.com>
References: <8DMh9uvckj8447yqHPMswDeg0xRxq-cnFaDW6GjjRKY=.a671b34d-b86d-4cbb-8c68-7a27eba5aed1@github.com>
Message-ID: <vm49oS-8wadm0FvuoKCA7JOaNoNBCmgqEV_RkoIAYVY=.4a9db080-ebb9-4c9a-9910-e5545d67aa5d@github.com>

On Tue, 29 Jul 2025 17:18:12 GMT, Darragh Conway <duke at openjdk.org> wrote:

> Refactor remove the test logic for Windows OS and replace with jtreg check for os

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26537#issuecomment-3140146811

From duke at openjdk.org  Thu Jul 31 14:44:20 2025
From: duke at openjdk.org (Darragh Conway)
Date: Thu, 31 Jul 2025 14:44:20 GMT
Subject: Integrated: 8360408: [TEST] Use @requires tag instead of exiting based
 on "os.name" property value for sun/net/www/protocol/file/FileURLTest.java
In-Reply-To: <8DMh9uvckj8447yqHPMswDeg0xRxq-cnFaDW6GjjRKY=.a671b34d-b86d-4cbb-8c68-7a27eba5aed1@github.com>
References: <8DMh9uvckj8447yqHPMswDeg0xRxq-cnFaDW6GjjRKY=.a671b34d-b86d-4cbb-8c68-7a27eba5aed1@github.com>
Message-ID: <YRlQ2HCUPLDY8tho5tsxbQZZS8lGYVQAb0oDIQQqOKk=.29997918-6591-47d3-85a5-aae90365af4b@github.com>

On Tue, 29 Jul 2025 17:18:12 GMT, Darragh Conway <duke at openjdk.org> wrote:

> Refactor remove the test logic for Windows OS and replace with jtreg check for os

This pull request has now been integrated.

Changeset: d4705947
Author:    DarraghConway <darragh.conway at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4705947d89509b235cf48328014331c9c6cee80
Stats:     6 lines in 1 file changed: 1 ins; 4 del; 1 mod

8360408: [TEST] Use @requires tag instead of exiting based on "os.name" property value for sun/net/www/protocol/file/FileURLTest.java

Reviewed-by: vyazici, rriggs

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

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

From abarashev at openjdk.org  Thu Jul 31 18:53:20 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 31 Jul 2025 18:53:20 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v3]
In-Reply-To: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
Message-ID: <v08wdQTDWFv-K1M6sGzKSvXh2o_D-We5rRo_UH_UFl0=.88163a58-117f-4121-8b0f-432739578d90@github.com>

> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Address Brad's code review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26484/files
  - new: https://git.openjdk.org/jdk/pull/26484/files/d5723cb8..8cf4e12f

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

  Stats: 20 lines in 2 files changed: 4 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/26484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26484/head:pull/26484

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