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: References: Message-ID: <9emDG6j2YwGq9q_uNha4OikutXt4gQ9CB8gw4_LllVQ=.296775c8-b81a-447b-bd0b-cbff2adbaef7@github.com> On Mon, 16 Jun 2025 08:04:19 GMT, Jaikiran Pai 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: References: Message-ID: On Thu, 26 Jun 2025 17:34:45 GMT, Daniel Fuchs 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: <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 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: References: Message-ID: > 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: References: Message-ID: <4QVjomzAiiiLlRQy3rP_wsRw9f7wMpLCoJFgFf9wv8c=.49dc881f-9733-4482-af42-f07097de1592@github.com> On Tue, 1 Jul 2025 09:31:15 GMT, Jaikiran Pai 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: References: Message-ID: On Tue, 1 Jul 2025 09:31:15 GMT, Jaikiran Pai 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: References: Message-ID: <2uIlI67ZuXY_FGElLjUN1wcwoPSdVrQACgyVF7AEbfk=.624e0472-4a35-4c9a-aec8-cc02e28d5632@github.com> On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs 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: References: Message-ID: > 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: References: Message-ID: On Tue, 1 Jul 2025 09:54:07 GMT, Daniel Fuchs 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: References: Message-ID: > 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: References: Message-ID: On Tue, 1 Jul 2025 11:25:32 GMT, Jaikiran Pai 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: References: Message-ID: On Tue, 1 Jul 2025 11:25:32 GMT, Jaikiran Pai 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: References: Message-ID: On Tue, 1 Jul 2025 12:43:58 GMT, Jaikiran Pai 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: References: Message-ID: On Tue, 1 Jul 2025 11:21:53 GMT, Jaikiran Pai 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: References: Message-ID: On Tue, 1 Jul 2025 12:43:58 GMT, Jaikiran Pai 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: References: Message-ID: On Mon, 16 Jun 2025 07:22:25 GMT, Jaikiran Pai 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 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: References: Message-ID: <3UR7O_cfQFPcsz5GseXURHT9KVC6pUFSxa_KsNLtYNY=.d579b776-0eee-467b-b993-c1341b2dcb19@github.com> On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs 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 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: References: Message-ID: <3lbVW_vZLe7AqGQprT2k4Xa0gOwgsxzBfGmlwcPHtsQ=.abb14e6f-d7ef-4f36-a420-219dde365b52@github.com> On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs 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 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 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: References: Message-ID: > 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: References: Message-ID: > 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: References: Message-ID: On Wed, 2 Jul 2025 06:19:58 GMT, Jaikiran Pai 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: References: <5A_SpOuvlXtTWrMOvuCA48FSlJ0j8mwUZFtF4CYogaQ=.1152a6c6-3a7f-47aa-b09c-c33a0c8dc53b@github.com> Message-ID: On Mon, 30 Jun 2025 15:41:24 GMT, Daniel Fuchs 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: References: Message-ID: On Fri, 27 Jun 2025 13:21:12 GMT, Daniel Fuchs 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: 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: References: Message-ID: > 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: References: Message-ID: <-kAOLGhaGTLlDuS49RU63bG-1eRjtiBD9DUFBhvKOgY=.1e5b22a1-d67e-489b-98d7-083eca0ba521@github.com> On Wed, 2 Jul 2025 06:19:58 GMT, Jaikiran Pai 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: References: Message-ID: On Wed, 2 Jul 2025 12:45:59 GMT, Jaikiran Pai 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: References: Message-ID: On Wed, 2 Jul 2025 12:45:59 GMT, Jaikiran Pai 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: References: Message-ID: On Mon, 30 Jun 2025 11:07:55 GMT, Jaikiran Pai 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 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: References: Message-ID: On Wed, 2 Jul 2025 08:37:34 GMT, Daniel Fuchs 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: References: Message-ID: On Thu, 3 Jul 2025 10:49:21 GMT, Volkan Yazici 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: References: Message-ID: On Wed, 5 Feb 2025 17:39:42 GMT, Mikhail Yankelevich 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: On Thu, 3 Jul 2025 20:25:13 GMT, Volkan Yazici 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 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: References: 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: References: Message-ID: > 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: References: Message-ID: <30ssA_NIcu71eM9Y-3101xNAETCGjqX5g_qml9q80SE=.02e2b0c0-8260-4e03-8518-0fb6e7ab08c3@github.com> On Thu, 3 Jul 2025 12:56:00 GMT, Daniel Fuchs 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: References: Message-ID: On Fri, 4 Jul 2025 08:34:52 GMT, Daniel Fuchs 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: References: Message-ID: On Wed, 2 Jul 2025 07:47:31 GMT, Daniel Jeli?ski 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: References: Message-ID: On Fri, 4 Jul 2025 08:34:52 GMT, Daniel Fuchs 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: On Thu, 3 Jul 2025 20:25:13 GMT, Volkan Yazici 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: References: Message-ID: On Fri, 4 Jul 2025 08:34:52 GMT, Daniel Fuchs 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: References: Message-ID: On Fri, 4 Jul 2025 13:08:28 GMT, Michael McMahon 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: References: Message-ID: On Fri, 4 Jul 2025 08:34:52 GMT, Daniel Fuchs 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: References: Message-ID: On Fri, 4 Jul 2025 08:34:52 GMT, Daniel Fuchs 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: 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: References: Message-ID: On Fri, 4 Jul 2025 09:04:52 GMT, Daniel Jeli?ski 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: References: Message-ID: On Wed, 2 Jul 2025 08:37:34 GMT, Daniel Fuchs 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 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: References: Message-ID: On Mon, 7 Jul 2025 07:33:58 GMT, Volkan Yazici 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: References: Message-ID: On Mon, 7 Jul 2025 08:29:40 GMT, Daniel Fuchs 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: References: 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: References: Message-ID: On Mon, 7 Jul 2025 08:31:10 GMT, Daniel Fuchs 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: References: Message-ID: On Mon, 7 Jul 2025 08:36:51 GMT, Daniel Fuchs 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: <6WB4eKx3ZvooH-P60TuaJp8q3f3X2AcdZsXf6EtYfgs=.0f137df4-f3cc-463a-92e1-17d19fa26259@github.com> Message-ID: On Mon, 7 Jul 2025 09:32:33 GMT, Volkan Yazici 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: References: Message-ID: > 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: References: Message-ID: > 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: 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: References: Message-ID: On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters 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: References: Message-ID: On Wed, 23 Oct 2024 04:40:50 GMT, Julian Waters 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 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: References: Message-ID: On Tue, 8 Jul 2025 01:28:04 GMT, Julian Waters 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: References: Message-ID: On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters 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: References: Message-ID: On Tue, 8 Jul 2025 04:20:32 GMT, Jaikiran Pai 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: References: Message-ID: On Tue, 8 Jul 2025 01:49:14 GMT, David Holmes 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: References: 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: References: Message-ID: > 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: References: Message-ID: On Tue, 8 Jul 2025 14:33:04 GMT, Darragh Clarke 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: References: Message-ID: On Tue, 8 Jul 2025 14:33:04 GMT, Darragh Clarke 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: References: Message-ID: > 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: References: Message-ID: On Tue, 8 Jul 2025 14:33:04 GMT, Darragh Clarke 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: 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: References: Message-ID: On Wed, 9 Jul 2025 05:49:30 GMT, Erik Gahlin 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: References: Message-ID: <_pYZlNrH5axGeFZQrBzLb69rU55YsqlrMW5abLBJ-zU=.2e64c02e-eeab-4cd2-8caf-9d32b55ada89@github.com> On Wed, 9 Jul 2025 17:59:44 GMT, Alan Bateman 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