From lkorinth at openjdk.org Mon Sep 1 08:07:48 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 08:07:48 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v8] In-Reply-To: References: Message-ID: <1SVkL88-a7Es6cosezvIjvZ63F4nv-2Kut2oKG27Eo8=.f2e2a083-b51d-4df9-ab6e-ec324467ebb9@github.com> > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth 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 10 additional commits since the last revision: - new timeouts - Merge branch '_master_jdk' into _8260555 - update copyright - revert added timeout, it is not needed - feedback from Mark Sheppard - update testing.md, remove makefile link, fix bad text - after suggestion from Daniel - added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD - After suggestions from Erik and Andrey - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/4b33904a..7ca719c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=06-07 Stats: 37788 lines in 1054 files changed: 23834 ins; 9562 del; 4392 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From vyazici at openjdk.org Mon Sep 1 08:52:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 1 Sep 2025 08:52:53 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: dacd9af9 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/dacd9af9a02464d2d6144e29d851216641e836c9 Stats: 851 lines in 4 files changed: 846 ins; 2 del; 3 mod 8329829: HttpClient: Add a BodyPublishers.ofFileChannel method Reviewed-by: dfuchs, jpai, michaelm ------------- PR: https://git.openjdk.org/jdk/pull/26155 From lkorinth at openjdk.org Mon Sep 1 13:21:49 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 13:21:49 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/7ca719c8..5c0bcd19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From alanb at openjdk.org Mon Sep 1 13:55:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Sep 2025 13:55:46 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:21:49 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3173774701 From lkorinth at openjdk.org Mon Sep 1 16:00:47 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:00:47 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: <9X-5PBm7G1Y8vJ8bw02E501aWdgleLyUWMk3nhSrF08=.bb490a54-e687-49cc-9ecc-df7c051eef18@github.com> On Fri, 22 Aug 2025 15:46:18 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31: > >> 29: * @compile SuspendResume2.java >> 30: * @run driver jdk.test.lib.FileInstaller . . >> 31: * @run main/othervm/native/timeout=700 > > Why `700` instead of `480` in this file? I think this is one of the earlier tests that failed with a timeout factor of `0.7` on 480. Later on I doubled it, but here I was a bit more conservative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314279387 From lkorinth at openjdk.org Mon Sep 1 16:09:44 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:09:44 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:48:10 GMT, Albert Mingkun Yang wrote: >> It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4). > >> while not multiplying a 10x factor with four resulting in a 40x factor. > > Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000) * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO. Because 40x is a very large timeout factor. I think I might misunderstand you in some way. My change is conservative, and will give a timeout that is not smaller than before (but can be larger if an explicit (non-default) timeout factor less than 4 was used before). Does that make sense, or do I answer something different from what you are asking? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314295263 From jpai at openjdk.org Tue Sep 2 05:56:42 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 05:56:42 GMT Subject: RFR: 8366031: Mark com/sun/nio/sctp/SctpChannel/CloseDescriptors.java as intermittent In-Reply-To: References: Message-ID: On Sat, 23 Aug 2025 02:46:06 GMT, SendaoYan wrote: > The test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java observed intermittent fails. Before the root cause of failure has been fixed, should we mark this test `@key intermittent`, to make some setups skip this test or re-run this test when it's fails. > > After the failure root cause has been fixed, we should remove the `@key intermittent` in test definition. Looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26910#pullrequestreview-3174961187 From jpai at openjdk.org Tue Sep 2 06:06:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 06:06:43 GMT Subject: RFR: 8365983: Tests should throw SkippedException when SCTP not supported [v2] In-Reply-To: References: Message-ID: <12_5743yT9i10BZfiusBcUN_5Ra2r5-z5cuzQ3lWtZs=.add75a85-1612-4bf4-90e4-12e0f2bec44e@github.com> On Sat, 23 Aug 2025 02:17:18 GMT, SendaoYan wrote: >> Currently, take test/jdk/com/sun/nio/sctp/SctpMultiChannel/Branch.java as example. When Util.isSCTPSupported() return false, then test print a warning and the exit. >> >> I think it's better to throw jtreg.SkippedException rather than only print a warning and then report test passed. >> >> Change has been verified locally, test-fix only, almost no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Replace "throw new jtreg.SkippedException" ad "throw new SkippedException" test/jdk/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java line 42: > 40: import com.sun.nio.sctp.AbstractNotificationHandler; > 41: import com.sun.nio.sctp.Association; > 42: import com.sun.nio.sctp.SctpStandardSocketOptions.InitMaxStreams; Was this intentional? Few lines below, there's already a static wildcard import for this: import static com.sun.nio.sctp.SctpStandardSocketOptions.*; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26903#discussion_r2314996165 From jpai at openjdk.org Tue Sep 2 06:10:47 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 06:10:47 GMT Subject: RFR: 8365983: Tests should throw SkippedException when SCTP not supported [v2] In-Reply-To: References: Message-ID: On Sat, 23 Aug 2025 02:17:18 GMT, SendaoYan wrote: >> Currently, take test/jdk/com/sun/nio/sctp/SctpMultiChannel/Branch.java as example. When Util.isSCTPSupported() return false, then test print a warning and the exit. >> >> I think it's better to throw jtreg.SkippedException rather than only print a warning and then report test passed. >> >> Change has been verified locally, test-fix only, almost no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Replace "throw new jtreg.SkippedException" ad "throw new SkippedException" Overall this looks OK to me. I wonder if we could instead have a `@requires` implemented in the JDK repo for the presence of SCTP support. That way all these repeated checks (backed by opening and closing a socket) wouldn't be necessary in the test code. But it's OK in this proposed form for now. I've a trivial review comment which I've added inline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26903#issuecomment-3243905559 From syan at openjdk.org Tue Sep 2 06:53:48 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 06:53:48 GMT Subject: RFR: 8366031: Mark com/sun/nio/sctp/SctpChannel/CloseDescriptors.java as intermittent In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 05:54:18 GMT, Jaikiran Pai wrote: >> The test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java observed intermittent fails. Before the root cause of failure has been fixed, should we mark this test `@key intermittent`, to make some setups skip this test or re-run this test when it's fails. >> >> After the failure root cause has been fixed, we should remove the `@key intermittent` in test definition. > > Looks OK to me. @jaikiran Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26910#issuecomment-3244011749 From syan at openjdk.org Tue Sep 2 06:53:49 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 06:53:49 GMT Subject: Integrated: 8366031: Mark com/sun/nio/sctp/SctpChannel/CloseDescriptors.java as intermittent In-Reply-To: References: Message-ID: On Sat, 23 Aug 2025 02:46:06 GMT, SendaoYan wrote: > The test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java observed intermittent fails. Before the root cause of failure has been fixed, should we mark this test `@key intermittent`, to make some setups skip this test or re-run this test when it's fails. > > After the failure root cause has been fixed, we should remove the `@key intermittent` in test definition. This pull request has now been integrated. Changeset: efb81daf Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/efb81dafaf6da334674e52dbb509208d7d872440 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8366031: Mark com/sun/nio/sctp/SctpChannel/CloseDescriptors.java as intermittent Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/26910 From syan at openjdk.org Tue Sep 2 07:01:56 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 07:01:56 GMT Subject: RFR: 8365983: Tests should throw SkippedException when SCTP not supported [v3] In-Reply-To: References: Message-ID: > Currently, take test/jdk/com/sun/nio/sctp/SctpMultiChannel/Branch.java as example. When Util.isSCTPSupported() return false, then test print a warning and the exit. > > I think it's better to throw jtreg.SkippedException rather than only print a warning and then report test passed. > > Change has been verified locally, test-fix only, almost no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary "import com.sun.nio.sctp.SctpStandardSocketOptions.InitMaxStreams;" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26903/files - new: https://git.openjdk.org/jdk/pull/26903/files/eb1b137f..11122b91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26903&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26903&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26903.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26903/head:pull/26903 PR: https://git.openjdk.org/jdk/pull/26903 From syan at openjdk.org Tue Sep 2 07:01:56 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 07:01:56 GMT Subject: RFR: 8365983: Tests should throw SkippedException when SCTP not supported [v2] In-Reply-To: <12_5743yT9i10BZfiusBcUN_5Ra2r5-z5cuzQ3lWtZs=.add75a85-1612-4bf4-90e4-12e0f2bec44e@github.com> References: <12_5743yT9i10BZfiusBcUN_5Ra2r5-z5cuzQ3lWtZs=.add75a85-1612-4bf4-90e4-12e0f2bec44e@github.com> Message-ID: On Tue, 2 Sep 2025 06:03:34 GMT, Jaikiran Pai wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace "throw new jtreg.SkippedException" ad "throw new SkippedException" > > test/jdk/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java line 42: > >> 40: import com.sun.nio.sctp.AbstractNotificationHandler; >> 41: import com.sun.nio.sctp.Association; >> 42: import com.sun.nio.sctp.SctpStandardSocketOptions.InitMaxStreams; > > Was this intentional? Few lines below, there's already a static wildcard import for this: > > > import static com.sun.nio.sctp.SctpStandardSocketOptions.*; Maybe the redundant import added by IDE automatically. I have deleted the unnecessary import and verified it locally. Thanks your reviews. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26903#discussion_r2315107144 From syan at openjdk.org Tue Sep 2 07:04:03 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 07:04:03 GMT Subject: RFR: 8365983: Tests should throw SkippedException when SCTP not supported [v4] In-Reply-To: References: Message-ID: > Currently, take test/jdk/com/sun/nio/sctp/SctpMultiChannel/Branch.java as example. When Util.isSCTPSupported() return false, then test print a warning and the exit. > > I think it's better to throw jtreg.SkippedException rather than only print a warning and then report test passed. > > Change has been verified locally, test-fix only, almost no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Remove extra blank line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26903/files - new: https://git.openjdk.org/jdk/pull/26903/files/11122b91..6f3cec99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26903&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26903&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26903.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26903/head:pull/26903 PR: https://git.openjdk.org/jdk/pull/26903 From jpai at openjdk.org Tue Sep 2 07:08:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 07:08:46 GMT Subject: RFR: 8365983: Tests should throw SkippedException when SCTP not supported [v4] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 07:04:03 GMT, SendaoYan wrote: >> Currently, take test/jdk/com/sun/nio/sctp/SctpMultiChannel/Branch.java as example. When Util.isSCTPSupported() return false, then test print a warning and the exit. >> >> I think it's better to throw jtreg.SkippedException rather than only print a warning and then report test passed. >> >> Change has been verified locally, test-fix only, almost no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra blank line These test-only changes look OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26903#pullrequestreview-3175155396 From lkorinth at openjdk.org Tue Sep 2 07:29:57 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 2 Sep 2025 07:29:57 GMT Subject: Integrated: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... This pull request has now been integrated. Changeset: 55e7af05 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/55e7af0560335ef69af072cee60956cf8e6d00a1 Stats: 901 lines in 342 files changed: 51 ins; 91 del; 759 mod 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 Reviewed-by: alanb, sspitsyn, lmesnik, ihse ------------- PR: https://git.openjdk.org/jdk/pull/26749 From mdonovan at openjdk.org Tue Sep 2 11:20:53 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 2 Sep 2025 11:20:53 GMT Subject: Integrated: 8325766: Extend CertificateBuilder to create trust and end entity certificates programmatically In-Reply-To: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> Message-ID: On Wed, 19 Feb 2025 15:48:10 GMT, Matthew Donovan wrote: > This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates. > > ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1) > ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa) > ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0) This pull request has now been integrated. Changeset: 31847149 Author: Matthew Donovan URL: https://git.openjdk.org/jdk/commit/31847149c1956b23c19a99309982660b4bbdd2d6 Stats: 771 lines in 3 files changed: 163 ins; 565 del; 43 mod 8325766: Extend CertificateBuilder to create trust and end entity certificates programmatically Reviewed-by: mullan, abarashev ------------- PR: https://git.openjdk.org/jdk/pull/23700 From syan at openjdk.org Tue Sep 2 13:28:51 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 13:28:51 GMT Subject: RFR: 8365983: Tests should throw SkippedException when SCTP not supported [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 06:08:12 GMT, Jaikiran Pai wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace "throw new jtreg.SkippedException" ad "throw new SkippedException" > > Overall this looks OK to me. I wonder if we could instead have a `@requires` implemented in the JDK repo for the presence of SCTP support. That way all these repeated checks (backed by opening and closing a socket) wouldn't be necessary in the test code. But it's OK in this proposed form for now. I've a trivial review comment which I've added inline. @jaikiran Thanks for the reviews and suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26903#issuecomment-3245340810 From syan at openjdk.org Tue Sep 2 13:28:52 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 13:28:52 GMT Subject: Integrated: 8365983: Tests should throw SkippedException when SCTP not supported In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 13:30:19 GMT, SendaoYan wrote: > Currently, take test/jdk/com/sun/nio/sctp/SctpMultiChannel/Branch.java as example. When Util.isSCTPSupported() return false, then test print a warning and the exit. > > I think it's better to throw jtreg.SkippedException rather than only print a warning and then report test passed. > > Change has been verified locally, test-fix only, almost no risk. This pull request has now been integrated. Changeset: a029245a Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/a029245a4e1f04052fa0f0a5af16ae0e770bd822 Stats: 209 lines in 16 files changed: 103 ins; 89 del; 17 mod 8365983: Tests should throw SkippedException when SCTP not supported Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/26903 From josiahnoel at gmail.com Wed Sep 3 03:54:01 2025 From: josiahnoel at gmail.com (Josiah Noel) Date: Tue, 2 Sep 2025 23:54:01 -0400 Subject: jdk.httpserver 101 status code closing connection Message-ID: Hey team, I was trying to manually implement a WebSocket using the jdk.httpserver module, but it seems that when I use sendHeaders to send a 101 status code, the request is terminated and the streams are closed, preventing me from reading/sending websocket frames. Is it right to say that we shouldn't close the exchange in this situation? Just to clarify, this is *not* a request for adding an implementation of the websocket protocol to the module. The fix would would be: - Check request connection header to see if it is an upgrade request - If so, set getRequestBody/getResponseBody to return the raw streams - flush (but don't close) the outputstream when sending a 101 status code I am willing to contribute this myself. (Indeed I already have the changes on my local) -- Cheers, Josiah. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed Sep 3 10:24:29 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 3 Sep 2025 11:24:29 +0100 Subject: jdk.httpserver 101 status code closing connection In-Reply-To: References: Message-ID: <1f989c04-9aae-40ac-92cc-80d0b8395253@oracle.com> Hi Josiah, This is a feature that is currently not supported by the jdk.httpserver. Part of a larger problem that support for sending interim responses (1xx) is currently missing. The current code has some provision for some one hundred codes but sendResponseHeaders appears not to have been designed to send interim responses. This is something we are aware of - but haven't decided how best to tackle it. A new method to send interim response codes might be better than trying to shoehorn sending one hundreds with the current API, but we haven't investigated that yet. We have an issue opened that touches on that (https://bugs.openjdk.org/browse/JDK-8349670) Making it possible to handle protocols like WebSocket from within a Handler/Filter would bring that to the next level though, and I suspect more surgery would be needed. I am not sure it is something we would be looking forward to support this in the long run. best regards, -- daniel On 03/09/2025 04:54, Josiah Noel wrote: > Hey team, > > I was trying to manually implement a WebSocket using the jdk.httpserver > module, but it seems that when I use sendHeaders to send a 101 status > code, the request is terminated and the streams are > closed,?preventing?me from reading/sending websocket frames. > > Is it right to say that we shouldn't close the exchange in this > situation? Just to clarify, this is *not*?a request for adding an > implementation of the websocket protocol to the module. > > The fix would would be: > > * Check request connection header to see if it is an upgrade request > * If so, set getRequestBody/getResponseBody to return the raw streams > * flush (but don't close) the outputstream when sending a 101 status code > > I am willing to contribute this myself. (Indeed I already have the > changes on my local) > > -- > Cheers, Josiah. From josiahnoel at gmail.com Wed Sep 3 12:31:24 2025 From: josiahnoel at gmail.com (Josiah Noel) Date: Wed, 3 Sep 2025 08:31:24 -0400 Subject: jdk.httpserver 101 status code closing connection In-Reply-To: <1f989c04-9aae-40ac-92cc-80d0b8395253@oracle.com> References: <1f989c04-9aae-40ac-92cc-80d0b8395253@oracle.com> Message-ID: > The current code has some provision for some one hundred > codes but sendResponseHeaders appears not to have been > designed to send interim responses A new method to send interim response codes might be better than trying to shoehorn sending one hundreds with the current API, but we haven't investigated that yet. As the JIRA issue notes, there is nothing in the javadocs that suggests that sending informational codes with the current API closes the streams. Merely teaching the exchange that 101 status codes should not enforce content-length -1 is enough. > Making it possible to handle protocols like WebSocket from > within a Handler/Filter would bring that to the next level > though, and I suspect more surgery would be needed. > I am not sure it is something we would be looking forward > to support this in the long run. Indeed, if you were to add code to process WebSocket frames, that would be yet another thing to maintain long-term, which is why I'm not suggesting it. Not closing access to the streams is good enough to allow the consumer to implement WebSockets. While I do also have code to process the frames, that is out of scope for the issue at hand. I've raised a one-file PR illustrating the changes I'm talking about . If you could spare time to briefly skim it over to get a better sense of what I'm talking about, I would be most grateful. Thanks for your time, -- Josiah -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed Sep 3 13:24:24 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 3 Sep 2025 14:24:24 +0100 Subject: jdk.httpserver 101 status code closing connection In-Reply-To: References: <1f989c04-9aae-40ac-92cc-80d0b8395253@oracle.com> Message-ID: Hi Josia, Unfortunately I can't look at that PR until the OCA has been signed and processed. That said I'd be worried about several potential issues: - will the server keep a reference to the connection/socket so that it can be closed if HttpServer::close is called? - how will the server know that the stream/connection has been closed so that the above reference can be removed, and stop can return early - would there be a need to adjust any of the various timers that the server maintains? - if HttpServer::stop is called before the connection is closed, what happens? - will/should the Handler implementation return after acquiring the streams? Or after having closed them? etc... There may be a lot of corner cases in there that will need to be tested, and maintained, and supported. best regards, -- daniel On 03/09/2025 13:31, Josiah Noel wrote: > > The current code has some provision for some one hundred > codes but sendResponseHeaders appears not to have been > designed to send interim responses > > > A new method to send interim response codes might be better > > than trying to shoehorn sending one hundreds with the > > current API, but we haven't investigated that yet. > > > As the JIRA issue notes, there is nothing in the javadocs that suggests > that sending informational codes with the current API closes the > streams. Merely teaching the exchange that 101 status codes should not > enforce content-length?-1 is enough. > > Making it possible to handle protocols like WebSocket from > within a Handler/Filter would bring that to the next level > though, and I suspect more surgery would be needed. > I am not sure it is something we would be looking forward > to support this in the long run. > > > Indeed, if you were to add code to process WebSocket frames, that would > be yet another thing to maintain long-term, which is why I'm not > suggesting it. Not closing access to the streams is good enough to allow > the?consumer to implement WebSockets. While I do also have code to > process the frames, that is out of scope for the issue at hand. > > I've raised a one-file PR illustrating the changes I'm talking about > . If you could spare time to briefly?skim it over to?get?a better?sense of what I'm talking about, I would be most grateful. > > Thanks for your time, > > -- Josiah From josiahnoel at gmail.com Wed Sep 3 14:47:03 2025 From: josiahnoel at gmail.com (Josiah Noel) Date: Wed, 3 Sep 2025 10:47:03 -0400 Subject: jdk.httpserver 101 status code closing connection In-Reply-To: References: <1f989c04-9aae-40ac-92cc-80d0b8395253@oracle.com> Message-ID: > > Unfortunately I can't look at that PR until the OCA > has been signed and processed. Yeah, I put it in draft for now until that goes through. I had signed for helidon and not OpenJDK I guess - if HttpServer::stop is called before the connection is > closed, what happens? Testing locally, when stop is called after sending the 101, the connection is closed, and an AsynchronousCloseException is thrown if you try to continue reading the body input stream. The executor will also cancel the request as usual If stop is called after sending the 101 and the body is never read, the request is canceled as usual. It doesn't appear to hang or anything. - will/should the Handler implementation return after acquiring > the streams? Or after having closed them? Returning would end the request like it does today. - will the server keep a reference to the connection/socket > so that it can be closed if HttpServer::close is called? > - how will the server know that the stream/connection > has been closed so that the above reference can be > removed, and stop can return early I don't understand why we need to keep a reference if we expect the handler to manage the stream. On Wed, Sep 3, 2025 at 9:24?AM Daniel Fuchs wrote: > Hi Josia, > > Unfortunately I can't look at that PR until the OCA > has been signed and processed. > > That said I'd be worried about several potential issues: > > - will the server keep a reference to the connection/socket > so that it can be closed if HttpServer::close is called? > - how will the server know that the stream/connection > has been closed so that the above reference can be > removed, and stop can return early > - would there be a need to adjust any of the various timers that > the server maintains? > - if HttpServer::stop is called before the connection is > closed, what happens? > - will/should the Handler implementation return after acquiring > the streams? Or after having closed them? > > etc... > > There may be a lot of corner cases in there that will need to > be tested, and maintained, and supported. > > best regards, > > -- daniel > > On 03/09/2025 13:31, Josiah Noel wrote: > > > > The current code has some provision for some one hundred > > codes but sendResponseHeaders appears not to have been > > designed to send interim responses > > > > > > A new method to send interim response codes might be better > > > > than trying to shoehorn sending one hundreds with the > > > > current API, but we haven't investigated that yet. > > > > > > As the JIRA issue notes, there is nothing in the javadocs that suggests > > that sending informational codes with the current API closes the > > streams. Merely teaching the exchange that 101 status codes should not > > enforce content-length -1 is enough. > > > > Making it possible to handle protocols like WebSocket from > > within a Handler/Filter would bring that to the next level > > though, and I suspect more surgery would be needed. > > I am not sure it is something we would be looking forward > > to support this in the long run. > > > > > > Indeed, if you were to add code to process WebSocket frames, that would > > be yet another thing to maintain long-term, which is why I'm not > > suggesting it. Not closing access to the streams is good enough to allow > > the consumer to implement WebSockets. While I do also have code to > > process the frames, that is out of scope for the issue at hand. > > > > I've raised a one-file PR illustrating the changes I'm talking about > > < > https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27069__;!!ACWV5N9M2RV99hQ!JOxb2ls3Lkvn31MUo0cJkXKCVB9LU1okVBNXGBsZMDk9TfdS5ZcnZoBTyNe8epT9YnnfCEbpmuQkINHFTYT_hQ$>. > If you could spare time to briefly skim it over to get a better sense of > what I'm talking about, I would be most grateful. > > > > Thanks for your time, > > > > -- Josiah > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Sep 3 21:06:00 2025 From: duke at openjdk.org (duke) Date: Wed, 3 Sep 2025 21:06:00 GMT Subject: Withdrawn: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: On Mon, 5 May 2025 13:41:22 GMT, Per Minborg wrote: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25040 From josiahnoel at gmail.com Thu Sep 4 04:05:07 2025 From: josiahnoel at gmail.com (Josiah Noel) Date: Thu, 4 Sep 2025 00:05:07 -0400 Subject: jdk.httpserver 101 status code closing connection In-Reply-To: References: <1f989c04-9aae-40ac-92cc-80d0b8395253@oracle.com> Message-ID: I've been playing around with it, and it looks like the interim problem of 1xx requests can be resolved if sendResponseHeaders is modified so that the sentHeaders is not set to true for 1xx status codes. The fix would be: - Check for 1xx status code - If so, do not close the streams - flush (but don't close) the raw outputstream - set sentHeaders to false With this, I was able to call sendResponseHeaders again with the full response code and have it work. Thoughts? - will the server keep a reference to the connection/socket > Digging deeper into the code, the server already keeps a reference of every active connection, which is why the stop methods worked as normal. The Dispatcher thread also handles terminating the connection when the stream is closed manually. Can you think of any other potential issues/scenarios with keeping the streams available for 1xx codes? Thanks for your time, -- Josiah -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfuchs at openjdk.org Thu Sep 4 14:06:52 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 4 Sep 2025 14:06:52 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v16] 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 653 commits: - merge latest changes from master branch - http3: fix at since - merge latest http3 changes - Remove unused variables - Simplify control flow - Remove unnecessary instanceof checks - Use IntFunction for header generator - merge latest changes from master branch - http3: minor cleanup - http3: cleanup - QuicConnectionImpl::maxInitialTimer should be volatile - ... and 643 more: https://git.openjdk.org/jdk/compare/a40afdd0...3925afda ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=15 Stats: 105850 lines in 474 files changed: 103019 ins; 1333 del; 1498 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 djelinski at openjdk.org Thu Sep 4 14:16:03 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 4 Sep 2025 14:16:03 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v16] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:06:52 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 653 commits: > > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - Simplify control flow > - Remove unnecessary instanceof checks > - Use IntFunction for header generator > - merge latest changes from master branch > - http3: minor cleanup > - http3: cleanup - QuicConnectionImpl::maxInitialTimer should be volatile > - ... and 643 more: https://git.openjdk.org/jdk/compare/a40afdd0...3925afda Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3185555986 From geliang at kernel.org Fri Sep 5 08:43:16 2025 From: geliang at kernel.org (Geliang Tang) Date: Fri, 05 Sep 2025 16:43:16 +0800 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API Message-ID: Hi OpenJDK maintainers, I hope this message finds you well. The purpose of this letter is to propose the integration of Multipath TCP (MPTCP) support into OpenJDK. We have developed a set of patches to enable this functionality and are eager to submit it for upstream inclusion. We would greatly appreciate your feedback and opinions on this contribution. 1. Introduction Multipath TCP (MPTCP), as standardized in RFC 8684, is a major evolution of the TCP protocol. It enables a transport connection to use multiple network paths simultaneously for redundancy, resilience, and bandwidth aggregation. Since its introduction in Linux kernel v5.6, it has become a key technology for modern networking, particularly on mobile devices with multiple interfaces (e.g., Wi-Fi and cellular). Key benefits include: Bandwidth Aggregation: Combine the bandwidth of multiple network links. Seamless Handover: Maintain connections when switching networks without dropping the session. Improved Resilience: Traffic is automatically rerouted if one path fails. For more details, see the project website: https://mptcp.dev. 2. Technical Background On a supporting system like Linux, an MPTCP socket is created by specifying the IPPROTO_MPTCP protocol in the socket() system call instead of IPPROTO_TCP (or 0): int fd = socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP); This creates a socket that looks like a standard TCP socket to the application but uses the MPTCP protocol stack underneath. With the Java API, it is possible to create "stream" sockets, but it is not possible to change the last argument, which blocks apps to ask to use MPTCP. 3. Proposed Java API Changes The goal is to allow Java applications to opt-in to using MPTCP when creating sockets, without breaking existing code. The proposed changes are additive and backward-compatible. The core idea is to add a boolean mptcp parameter through the API layers, from the public Socket class down to the native system call. 4. Implementation Plan The implementation involves changes across four layers of the JDK: JNI Layer (sun.nio.ch.Net): Modify Java_sun_nio_ch_Net_socket0 to accept a new jboolean mptcp parameter. The native implementation will be updated to use this parameter: int protocol = mptcp == JNI_TRUE ? IPPROTO_MPTCP : 0; fd = socket(domain, type, protocol); NIO Layer (sun.nio.ch): Add the mptcp parameter to the Net.socket() and Net.serverSocket() methods. Propagate the parameter down to the JNI call. Socket Implementation Layer (java.net): Add the mptcp parameter to the constructor of NioSocketImpl. Within NioSocketImpl, pass the parameter to the Net.socket() or Net.serverSocket() calls. Public API Layer (java.net.Socket & java.net.ServerSocket): Add new constructors that accept the mptcp parameter. Example: // Proposed new constructor public Socket(String host, int port, boolean stream, boolean mptcp) throws IOException { // ... implementation that passes 'mptcp' to NioSocketImpl } 5. Full Implementation The complete working implementation for this proposal is available for review: https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master We look forward to your valuable feedback and suggestions on this proposal. We can create a new issue for this feature, and submit a proper pull request after if that's OK for you. We didn't do that yet because we noticed that it is recommended to send more explanations to this list first. Best regards, MPTCP Upstream Developers From alan.bateman at oracle.com Fri Sep 5 09:28:59 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Fri, 5 Sep 2025 10:28:59 +0100 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: References: Message-ID: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> On 05/09/2025 09:43, Geliang Tang wrote: > : > > 3. Proposed Java API Changes > > The goal is to allow Java applications to opt-in to using MPTCP when > creating sockets, without breaking existing code. The proposed changes > are additive and backward-compatible. > > The core idea is to add a boolean mptcp parameter through the API > layers, from the public Socket class down to the native system call. (moving the discussion to nio-dev and net-dev). Adding new constructors to legacy Socket/ServerSocket may work for your initial prototype but would be problematic to propose as it would bake non-standard features into the standard API. Also many high performance servers use SocketChannel rather than Socket. One suggestion for a next prototype is to model the enablement of MultiPath TCP as as a JDK-specific socket option (see jdk.net.ExtendingSocketOptions). All of the standard APIs for networking sockets define a setOption method for setting socket options. If modeled as a socket option then enabling can create a new AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into place so that the original AF_INET6/SOCK_STREAM/0 socket is closed. Enabling can be made to fail if the socket is already bound. It could copy over existing socket options if needed. Look at the built-in (and no longer used) SDP support for an example that does similar with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a socket option defined in jdk.net.ExtendingSocketOptions. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From geliang at kernel.org Fri Sep 5 10:05:15 2025 From: geliang at kernel.org (Geliang Tang) Date: Fri, 05 Sep 2025 18:05:15 +0800 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> Message-ID: <7de753a3852e66e42e3087e14e94de9a95b3ed59.camel@kernel.org> Hi Alan, Thanks for your reply. On Fri, 2025-09-05 at 10:28 +0100, Alan Bateman wrote: > ? > On 05/09/2025 09:43, Geliang Tang wrote: > ? > ? > > ? > > : > > > > 3. Proposed Java API Changes > > > > The goal is to allow Java applications to opt-in to using MPTCP > > when > > creating sockets, without breaking existing code. The proposed > > changes > > are additive and backward-compatible. > > > > The core idea is to add a boolean mptcp parameter through the API > > layers, from the public Socket class down to the native system > > call. > > ? > ? > ?(moving the discussion to nio-dev and net-dev). > ? > ?Adding new constructors to legacy Socket/ServerSocket may work for > your initial prototype but would be problematic to propose as it > would bake non-standard features into the standard API. Also many > high performance servers use SocketChannel rather than Socket. > ? > ?One suggestion for a next prototype is to model the enablement of > MultiPath TCP as as a JDK-specific socket option (see > jdk.net.ExtendingSocketOptions). All of the standard APIs for > networking sockets define a setOption method for setting socket I was initially concerned that calling setOption() after Socket() creation to convert TCP to MPTCP was too late. Creating an MPTCP socket must be done during the socket() system call. > options. If modeled as a socket option then enabling can create a new > AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into place Until I saw here, it should be feasible if the socket can be created again and dup when calling setOption(). I will try to reimplement MPTCP support using jdk.net.ExtendingSocketOptions soon and give you feedback. Thanks, -Geliang > so that the original AF_INET6/SOCK_STREAM/0 socket is closed. > Enabling can be made to fail if the socket is already bound. It could > copy over existing socket options if needed. Look at the built-in > (and no longer used) SDP support for an example that does similar > with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a > socket option defined in jdk.net.ExtendingSocketOptions. > ? > ?-Alan > ? > ? From geliang at kernel.org Fri Sep 5 10:11:22 2025 From: geliang at kernel.org (Geliang Tang) Date: Fri, 05 Sep 2025 18:11:22 +0800 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> Message-ID: Hi Alan, Thanks for your reply. On Fri, 2025-09-05 at 10:28 +0100, Alan Bateman wrote: > ? > On 05/09/2025 09:43, Geliang Tang wrote: > ? > ? > > ? > > : > > > > 3. Proposed Java API Changes > > > > The goal is to allow Java applications to opt-in to using MPTCP > > when > > creating sockets, without breaking existing code. The proposed > > changes > > are additive and backward-compatible. > > > > The core idea is to add a boolean mptcp parameter through the API > > layers, from the public Socket class down to the native system > > call. > > ? > ? > ?(moving the discussion to nio-dev and net-dev). > ? > ?Adding new constructors to legacy Socket/ServerSocket may work for > your initial prototype but would be problematic to propose as it > would bake non-standard features into the standard API. Also many > high performance servers use SocketChannel rather than Socket. > ? > ?One suggestion for a next prototype is to model the enablement of > MultiPath TCP as as a JDK-specific socket option (see > jdk.net.ExtendingSocketOptions). All of the standard APIs for > networking sockets define a setOption method for setting socket I was initially concerned that calling setOption() after Socket() creation to convert TCP to MPTCP was too late. Creating an MPTCP socket must be done during the socket() system call. > options. If modeled as a socket option then enabling can create a new > AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into place Until I saw here, it should be feasible if the socket can be created again and dup when calling setOption(). I will try to reimplement MPTCP support using jdk.net.ExtendingSocketOptions soon and give you feedback. Thanks, -Geliang > so that the original AF_INET6/SOCK_STREAM/0 socket is closed. > Enabling can be made to fail if the socket is already bound. It could > copy over existing socket options if needed. Look at the built-in > (and no longer used) SDP support for an example that does similar > with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a > socket option defined in jdk.net.ExtendingSocketOptions. > ? > ?-Alan > ? > ? From vyazici at openjdk.org Mon Sep 8 09:19:32 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 8 Sep 2025 09:19:32 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers Message-ID: Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into sendAsyncEx - Revert clean-up of redundant tests to keep PR focused - Minor improvements - Improve `FromPublisherTest` - Fix compilation errors - Merge branch 'sendAsyncEx2' into sendAsyncEx - More tests and improvements - Harden exception handling in request publishers - Revert redundant changes - Improve wording on nullability - ... and 6 more: https://git.openjdk.org/jdk/compare/bea2b029...2d0cc8d8 Changes: https://git.openjdk.org/jdk/pull/26876/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26876&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367067 Stats: 1710 lines in 15 files changed: 1611 ins; 57 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/26876.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26876/head:pull/26876 PR: https://git.openjdk.org/jdk/pull/26876 From liach at openjdk.org Mon Sep 8 09:19:32 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Sep 2025 09:19:32 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers In-Reply-To: References: Message-ID: <7MX5WVLOMcZ2ZtTfa6Ps8eVkr1P1hGZRF_bXTomiQp8=.c8519060-a609-4063-9a9b-ccf27cbfae55@github.com> On Thu, 21 Aug 2025 09:43:47 GMT, Volkan Yazici wrote: > Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. I don't think we need to add new `throws Exception` declarations if the existing code does not need it. src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 47: > 45: > 46: PullPublisher(CheckedIterable iterable, Throwable throwable) { > 47: if ((iterable == null && throwable == null) || (iterable != null && throwable != null)) { You can express this as `((iterable == null) == (throwable == null))` for simplicity. src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 49: > 47: if ((iterable == null && throwable == null) || (iterable != null && throwable != null)) { > 48: String message = String.format( > 49: "only one of `iterable` or `throwable` can be null, but %s are", "only one of xxx can be null" sounds like you allow both to be non-null, but that is not the case. Maybe use other wording like "one argument should be null and the other should be non-null, but both are null/non-null"? ------------- PR Review: https://git.openjdk.org/jdk/pull/26876#pullrequestreview-3141492419 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2291597776 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2291628366 From vyazici at openjdk.org Mon Sep 8 09:19:33 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 8 Sep 2025 09:19:33 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 09:43:47 GMT, Volkan Yazici wrote: > Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. > I don't think we need to add new `throws Exception` declarations if the existing code does not need it. @liach, I've did some cleaning in 89dba9a14cd. Let me know if you were concerned about more places. @jaikiran, created the [JDK-8367067] sub-task to dedicate this PR to the hardening of exception handling in built-in body publishers ? recall that the parent issue, [JDK-8364733], of exceptions leaking for `sendAsync` still needs to be addressed. I had already removed the duplication in tests, though @dfuch suggested to do the clean-up in a follow-up ticket. Hence, 1. Removed clean-up related changes in fa1a7368fee to keep the PR focused 2. Created the [JDK-8367068] subtask for the clean-up [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 [JDK-8367068]: https://bugs.openjdk.org/browse/JDK-8367068 src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 77: > 75: > 76: private ByteArrayPublisher(byte[] content, int offset, int length, int bufSize) { > 77: Objects.checkFromIndexSize(offset, length, content.length); // Implicit null check on `content` This check already exists in the `HttpRequest.BodyPublishers#ofByteArray(byte[],int,int)` public API ? though duplicating it here since this is the canonical constructor. src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 78: > 76: private ByteArrayPublisher(byte[] content, int offset, int length, int bufSize) { > 77: Objects.checkFromIndexSize(offset, length, content.length); // Implicit null check on `content` > 78: if (bufSize <= 0) { New validation to checking on `bufSize`. src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 342: > 340: is.close(); > 341: } catch (IOException e) { > 342: throw new UncheckedIOException(e); We don't convert `IOE`s to `UncheckedIOE`s anymore. This effectively makes the `HttpClientImpl::send` exception translation logic branching on `if (throwable instanceof IOException)` to kick in. src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 357: > 355: haveNext = false; > 356: need2Read = false; > 357: throw new IOException(e); We don't convert `IOE`s to `UncheckedIOE`s anymore. This effectively makes the `HttpClientImpl::send` exception translation logic branching on `if (throwable instanceof IOException)` to kick in. src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 395: > 393: Exception exception = null; > 394: try { > 395: is = streamSupplier.get(); Fixes leaked `streamSupplier.get()` failures src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 486: > 484: } catch (IOException ioe) { > 485: terminated = true; > 486: throw new IOException(ioe); We don't convert `IOE`s to `UncheckedIOE`s anymore. This effectively makes the `HttpClientImpl::send` exception translation logic branching on `if (throwable instanceof IOException)` to kick in. ------------- PR Review: https://git.openjdk.org/jdk/pull/26876#pullrequestreview-3143702796 PR Comment: https://git.openjdk.org/jdk/pull/26876#issuecomment-3265349702 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2329446658 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2329449047 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2329474662 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2329474192 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2329441592 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2329475172 From vyazici at openjdk.org Mon Sep 8 09:19:33 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 8 Sep 2025 09:19:33 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers In-Reply-To: <7MX5WVLOMcZ2ZtTfa6Ps8eVkr1P1hGZRF_bXTomiQp8=.c8519060-a609-4063-9a9b-ccf27cbfae55@github.com> References: <7MX5WVLOMcZ2ZtTfa6Ps8eVkr1P1hGZRF_bXTomiQp8=.c8519060-a609-4063-9a9b-ccf27cbfae55@github.com> Message-ID: On Thu, 21 Aug 2025 16:40:15 GMT, Chen Liang wrote: >> Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. > > src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 47: > >> 45: >> 46: PullPublisher(CheckedIterable iterable, Throwable throwable) { >> 47: if ((iterable == null && throwable == null) || (iterable != null && throwable != null)) { > > You can express this as `((iterable == null) == (throwable == null))` for simplicity. Changed as suggested in 53f483bb. > src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 49: > >> 47: if ((iterable == null && throwable == null) || (iterable != null && throwable != null)) { >> 48: String message = String.format( >> 49: "only one of `iterable` or `throwable` can be null, but %s are", > > "only one of xxx can be null" sounds like you allow both to be non-null, but that is not the case. Maybe use other wording like "one argument should be null and the other should be non-null, but both are null/non-null"? I had copy-pasted that phrase from line 39. I've updated both as suggested in a68707c6. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2293142237 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2293142343 From vyazici at openjdk.org Mon Sep 8 10:11:12 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 8 Sep 2025 10:11:12 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 09:43:47 GMT, Volkan Yazici wrote: > Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 39: > 37: class PullPublisher implements Flow.Publisher { > 38: > 39: // Only one of `iterable` or `throwable` should be null, and the other non-null. throwable is `PullPublisher` logic is branching on the `throwable == null` condition on several places ? this increases code size and complexity. Plus, all `PullPublisher::new` call sites know at compile time whether `throwable` is null or not. I think `PullPublisher` should only accept a `CheckedIterable`, and we should create a new, say, `ImmediatelyFailingPublisher` to cover the cases where a `Throwable` needs to be passed to subscribers verbatim. I did not carry out this improvement in this PR to avoid scope creep, but I'm inclined to create a ticket for it. WDYT? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2329782120 From liach at openjdk.org Mon Sep 8 13:22:18 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Sep 2025 13:22:18 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 08:10:06 GMT, Volkan Yazici wrote: >> Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. > > src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 357: > >> 355: haveNext = false; >> 356: need2Read = false; >> 357: throw new IOException(e); > > We don't convert `IOE`s to `UncheckedIOE`s anymore. This effectively makes the `HttpClientImpl::send` exception translation logic branching on `if (throwable instanceof IOException)` to kick in. Then why can't we simply `throw e` instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2330226401 From dfuchs at openjdk.org Mon Sep 8 13:56:16 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 8 Sep 2025 13:56:16 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 10:08:05 GMT, Volkan Yazici wrote: >> Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. > > src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 39: > >> 37: class PullPublisher implements Flow.Publisher { >> 38: >> 39: // Only one of `iterable` or `throwable` should be null, and the other non-null. throwable is > > `PullPublisher` logic is branching on the `throwable == null` condition on several places ? this increases code size and complexity. Plus, all `PullPublisher::new` call sites know at compile time whether `throwable` is null or not. I think `PullPublisher` should only accept a `CheckedIterable`, and we should create a new, say, `ImmediatelyFailingPublisher` to cover the cases where a `Throwable` needs to be passed to subscribers verbatim. I did not carry out this improvement in this PR to avoid scope creep, but I'm inclined to create a ticket for it. WDYT? You might discover that it's not as simple, as the case where the throwable is known in advance folds within the case where getting the interator throws... You'd still need to be able to create a failed subscription at line 73 below. I am not opposed to exploring that route though - and see if it really simplifies the code. > src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 78: > >> 76: private ByteArrayPublisher(byte[] content, int offset, int length, int bufSize) { >> 77: Objects.checkFromIndexSize(offset, length, content.length); // Implicit null check on `content` >> 78: if (bufSize <= 0) { > > New validation to checking on `bufSize`. Can bufSize be <= 0 in our implementation? Where does bufSize comes from? If it can't be <= 0 in our implemlementation then an `assert` would be more appropriate. > src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 357: > >> 355: haveNext = false; >> 356: need2Read = false; >> 357: throw new IOException(e); > > We don't convert `IOE`s to `UncheckedIOE`s anymore. This effectively makes the `HttpClientImpl::send` exception translation logic branching on `if (throwable instanceof IOException)` to kick in. That's a good point. The question is whether the call to read() that throws will be in the exception stack trace or not. We're in an asynchronous system so it might not. @vy were you able to trick the code into generating an IOException here - and did you observe that the additional stack trace information added by the wrapping in UncheckedIOException was useful? Because if it's not, we can simply rethrow e as @liach suggests. > src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 486: > >> 484: } catch (IOException ioe) { >> 485: terminated = true; >> 486: throw new IOException(ioe); > > We don't convert `IOE`s to `UncheckedIOE`s anymore. This effectively makes the `HttpClientImpl::send` exception translation logic branching on `if (throwable instanceof IOException)` to kick in. (same question that @liach asked before) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2330265962 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2330275013 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2330291788 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2330313850 From dfuchs at openjdk.org Mon Sep 8 13:56:18 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 8 Sep 2025 13:56:18 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 09:43:47 GMT, Volkan Yazici wrote: > Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 68: > 66: try { > 67: iterator = iterable.iterator(); > 68: } catch (Exception exception) { Either CheckedIterable::iterator() should be declared to throw Exception, or we should catch `RuntimeException` here - or even maybe `RuntimeException | Error` ? src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 395: > 393: exception = new IOException("Stream supplier returned null"); > 394: } > 395: } catch (Exception cause) { Can we get anything but RuntimeException here? test/jdk/java/net/httpclient/FilePublisherTest.java line 178: > 176: } > 177: } > 178: Maybe we could revert the changes to this file and do that in a followup test/jdk/java/net/httpclient/FlowAdapterPublisherTest.java line 122: > 120: > 121: // Flow.Publisher > 122: Maybe we could revert changes to this file and do that in a followup ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2330256448 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2330297271 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2330319905 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2330321263 From vyazici at openjdk.org Mon Sep 8 18:33:07 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 8 Sep 2025 18:33:07 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 13:32:26 GMT, Daniel Fuchs wrote: >> src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 39: >> >>> 37: class PullPublisher implements Flow.Publisher { >>> 38: >>> 39: // Only one of `iterable` or `throwable` should be null, and the other non-null. throwable is >> >> `PullPublisher` logic is branching on the `throwable == null` condition on several places ? this increases code size and complexity. Plus, all `PullPublisher::new` call sites know at compile time whether `throwable` is null or not. I think `PullPublisher` should only accept a `CheckedIterable`, and we should create a new, say, `ImmediatelyFailingPublisher` to cover the cases where a `Throwable` needs to be passed to subscribers verbatim. I did not carry out this improvement in this PR to avoid scope creep, but I'm inclined to create a ticket for it. WDYT? > > You might discover that it's not as simple, as the case where the throwable is known in advance folds within the case where getting the interator throws... > You'd still need to be able to create a failed subscription at line 73 below. > > I am not opposed to exploring that route though - and see if it really simplifies the code. Thanks for the feedback. I?ll set this exploration aside until after the PR. If I get convincing results, I?ll knock on your door again. >> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 78: >> >>> 76: private ByteArrayPublisher(byte[] content, int offset, int length, int bufSize) { >>> 77: Objects.checkFromIndexSize(offset, length, content.length); // Implicit null check on `content` >>> 78: if (bufSize <= 0) { >> >> New validation to checking on `bufSize`. > > Can bufSize be <= 0 in our implementation? Where does bufSize comes from? If it can't be <= 0 in our implemlementation then an `assert` would be more appropriate. It is provided in the ctor above using `Utils.BUFSIZE`, which reads the `jdk.httpclient.bufsize` system property, and that can be negative. >> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 357: >> >>> 355: haveNext = false; >>> 356: need2Read = false; >>> 357: throw new IOException(e); >> >> We don't convert `IOE`s to `UncheckedIOE`s anymore. This effectively makes the `HttpClientImpl::send` exception translation logic branching on `if (throwable instanceof IOException)` to kick in. > > That's a good point. The question is whether the call to read() that throws will be in the exception stack trace or not. We're in an asynchronous system so it might not. @vy were you able to trick the code into generating an IOException here - and did you observe that the additional stack trace information added by the wrapping in UncheckedIOException was useful? Because if it's not, we can simply rethrow e as @liach suggests. > Then why can't we simply `throw e` instead? Rethrows generally start hurting while debugging, hence I favor an accurate stack trace instead ? granted no performance implications. > did you observe that the additional stack trace information added by the wrapping in UncheckedIOException was useful Not really. Switched to rethrows in e9bc9e769c3. >> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 486: >> >>> 484: } catch (IOException ioe) { >>> 485: terminated = true; >>> 486: throw new IOException(ioe); >> >> We don't convert `IOE`s to `UncheckedIOE`s anymore. This effectively makes the `HttpClientImpl::send` exception translation logic branching on `if (throwable instanceof IOException)` to kick in. > > (same question that @liach asked before) Switched to rethrows in e9bc9e769c3. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2330943110 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2330967491 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2331034601 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2331035119 From vyazici at openjdk.org Mon Sep 8 18:33:10 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 8 Sep 2025 18:33:10 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 13:29:07 GMT, Daniel Fuchs wrote: >> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision: >> >> - Remove IOE rethrows >> - Revert `FilePublisherTest` and `FlowAdapterPublisherTest` changes >> - Make `CheckedIterable` throw exceptions > > src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 68: > >> 66: try { >> 67: iterator = iterable.iterator(); >> 68: } catch (Exception exception) { > > Either CheckedIterable::iterator() should be declared to throw Exception, or we should catch `RuntimeException` here - or even maybe `RuntimeException | Error` ? Changed `CheckedIterable::iterator` to throw `Exception` in 75e98c4bc45. > src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 395: > >> 393: exception = new IOException("Stream supplier returned null"); >> 394: } >> 395: } catch (Exception cause) { > > Can we get anything but RuntimeException here? AFAICT, no ? I thought being cautious as catching `Exception` would be a good practice here. > test/jdk/java/net/httpclient/FilePublisherTest.java line 178: > >> 176: var resp = client.send(req, HttpResponse.BodyHandlers.ofString()); >> 177: out.println("Got response: " + resp); >> 178: out.println("Got body: " + resp.body()); > > Maybe we could revert the changes to this file and do that in a followup Reverted these in 9fd8958932b ? I will remove duplicates in [JDK-8367068]. [JDK-8367068]: https://bugs.openjdk.org/browse/JDK-8367068 > test/jdk/java/net/httpclient/FlowAdapterPublisherTest.java line 122: > >> 120: } >> 121: } >> 122: > > Maybe we could revert changes to this file and do that in a followup Reverted these in 9fd8958932b ? I will remove duplicates in [JDK-8367068]. [JDK-8367068]: https://bugs.openjdk.org/browse/JDK-8367068 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2330963062 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2331003299 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2331019821 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2331020844 From vyazici at openjdk.org Mon Sep 8 18:33:04 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 8 Sep 2025 18:33:04 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v2] In-Reply-To: References: Message-ID: <8a3sJUo9afYRfzjlAOMGrcX9VTnGLlXOgZmZ4vggRPo=.6a5b97da-1221-4b7d-87e8-d918b7df6a83@github.com> > Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision: - Remove IOE rethrows - Revert `FilePublisherTest` and `FlowAdapterPublisherTest` changes - Make `CheckedIterable` throw exceptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26876/files - new: https://git.openjdk.org/jdk/pull/26876/files/2d0cc8d8..e9bc9e76 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26876&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26876&range=00-01 Stats: 43 lines in 4 files changed: 39 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26876.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26876/head:pull/26876 PR: https://git.openjdk.org/jdk/pull/26876 From dfuchs at openjdk.org Tue Sep 9 13:30:56 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 9 Sep 2025 13:30:56 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 18:06:23 GMT, Volkan Yazici wrote: >> Can bufSize be <= 0 in our implementation? Where does bufSize comes from? If it can't be <= 0 in our implemlementation then an `assert` would be more appropriate. > > It is provided in the ctor above using `Utils.BUFSIZE`, which reads the `jdk.httpclient.bufsize` system property, and that can be negative. I think it would make more sense to make sure that Utils.BUFSIZE is initialized to a strictly positive value and only assert here. It could be useful to see if we have any test that set BUFSIZE to a small value - but if we don't maybe we could go and clamp it to e.g. `2^10 <= BUFSIZE < 2^24` or `2^10 <= BUFSIZE <= 2^23` if we want to keep powers of two. (2^24 - 1 is the maximum allowed value for [SETTINGS_MAX_FRAME_SIZE](https://www.rfc-editor.org/rfc/rfc9113.html#SETTINGS_MAX_FRAME_SIZE) ) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2333555522 From dfuchs at openjdk.org Tue Sep 9 15:14:56 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 9 Sep 2025 15:14:56 GMT Subject: RFR: 8365239: Spec Clarification - InterfaceAddress:getBroadcast() returning null for loop back address Message-ID: <1JHm4W0EacrwU_Dx4yNvFBFjIpk2qzJYmdINGSlKzVE=.ff7809d0-c26f-4699-ac69-8747d04ddbe5@github.com> Hi, This is a documentation change only. The specification of `InterfaceAddress:getBroadcast()` should not say anything specific about the loopback interface as it appears that on some systems a broadcast address can be configured on the loopback. The API documentation of `InterfaceAddress:getBroadcast()` is updated to simply say that: * Some network interfaces do not support broadcasting and may * also return {@code null}. ------------- Commit messages: - 8365239: Spec Clarification- InterfaceAddress:getBroadcast() returning null for loop back address Changes: https://git.openjdk.org/jdk/pull/27174/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27174&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365239 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27174.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27174/head:pull/27174 PR: https://git.openjdk.org/jdk/pull/27174 From msheppar at openjdk.org Tue Sep 9 15:33:08 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Tue, 9 Sep 2025 15:33:08 GMT Subject: RFR: 8365239: Spec Clarification - InterfaceAddress:getBroadcast() returning null for loop back address In-Reply-To: <1JHm4W0EacrwU_Dx4yNvFBFjIpk2qzJYmdINGSlKzVE=.ff7809d0-c26f-4699-ac69-8747d04ddbe5@github.com> References: <1JHm4W0EacrwU_Dx4yNvFBFjIpk2qzJYmdINGSlKzVE=.ff7809d0-c26f-4699-ac69-8747d04ddbe5@github.com> Message-ID: On Tue, 9 Sep 2025 15:03:15 GMT, Daniel Fuchs wrote: > Hi, > > This is a documentation change only. The specification of `InterfaceAddress:getBroadcast()` should not say anything specific about the loopback interface as it appears that on some systems a broadcast address can be configured on the loopback. The API documentation of `InterfaceAddress:getBroadcast()` is updated to simply say that: > > * Some network interfaces do not support broadcasting and may > * also return {@code null}. looks like a reasonable change to accommodate the variability caused by Windows ------------- Marked as reviewed by msheppar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27174#pullrequestreview-3202176849 From djelinski at openjdk.org Tue Sep 9 16:04:30 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 9 Sep 2025 16:04:30 GMT Subject: RFR: 8365239: Spec Clarification - InterfaceAddress:getBroadcast() returning null for loop back address In-Reply-To: <1JHm4W0EacrwU_Dx4yNvFBFjIpk2qzJYmdINGSlKzVE=.ff7809d0-c26f-4699-ac69-8747d04ddbe5@github.com> References: <1JHm4W0EacrwU_Dx4yNvFBFjIpk2qzJYmdINGSlKzVE=.ff7809d0-c26f-4699-ac69-8747d04ddbe5@github.com> Message-ID: On Tue, 9 Sep 2025 15:03:15 GMT, Daniel Fuchs wrote: > Hi, > > This is a documentation change only. The specification of `InterfaceAddress:getBroadcast()` should not say anything specific about the loopback interface as it appears that on some systems a broadcast address can be configured on the loopback. The API documentation of `InterfaceAddress:getBroadcast()` is updated to simply say that: > > * Some network interfaces do not support broadcasting and may > * also return {@code null}. Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27174#pullrequestreview-3202303373 From jpai at openjdk.org Tue Sep 9 16:09:45 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 9 Sep 2025 16:09:45 GMT Subject: RFR: 8365239: Spec Clarification - InterfaceAddress:getBroadcast() returning null for loop back address In-Reply-To: <1JHm4W0EacrwU_Dx4yNvFBFjIpk2qzJYmdINGSlKzVE=.ff7809d0-c26f-4699-ac69-8747d04ddbe5@github.com> References: <1JHm4W0EacrwU_Dx4yNvFBFjIpk2qzJYmdINGSlKzVE=.ff7809d0-c26f-4699-ac69-8747d04ddbe5@github.com> Message-ID: On Tue, 9 Sep 2025 15:03:15 GMT, Daniel Fuchs wrote: > Hi, > > This is a documentation change only. The specification of `InterfaceAddress:getBroadcast()` should not say anything specific about the loopback interface as it appears that on some systems a broadcast address can be configured on the loopback. The API documentation of `InterfaceAddress:getBroadcast()` is updated to simply say that: > > * Some network interfaces do not support broadcasting and may > * also return {@code null}. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27174#pullrequestreview-3202322604 From asmehra at openjdk.org Tue Sep 9 16:49:12 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 9 Sep 2025 16:49:12 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 21:17:42 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @DanHeidinga comments -- added comments and asserts about the handling of enums > - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase > - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run > - @DanHeidinga comments > - tightened SystemDictionary::preload_class() > - Fixed bugs found in JCK > - added entry in ProblemList-AotJdk.txt due to 8323727 > - more clean up > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - ... and 10 more: https://git.openjdk.org/jdk/compare/075ddef8...1a8ea501 src/hotspot/share/cds/aotOopChecker.cpp line 53: > 51: // the production run. > 52: void AOTOopChecker::check(oop obj) { > 53: precond(vmClasses::URL_klass()->is_final()); `AOTOopChecker::check` is a generic method, so this precond should ideally be inside the next block that explicitly handles URL class objects. src/hotspot/share/cds/aotOopChecker.cpp line 55: > 53: precond(vmClasses::URL_klass()->is_final()); > 54: > 55: if (obj->klass()->is_subclass_of(vmClasses::URL_klass())) { URL is a final class, so shouldn't `obj->klass() == vmClasses::URL_klass()` be sufficient? src/hotspot/share/classfile/javaClasses.cpp line 1063: > 1061: > 1062: // Statically allocate fixup lists because they always get created. > 1063: void java_lang_Class::allocate_fixup_lists() { Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true? src/hotspot/share/memory/iterator.inline.hpp line 58: > 56: ClaimMetadataVisitingOopIterateClosure::do_cld(cld); > 57: } else { > 58: assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); Why is the null check and assert not valid anymore? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2331108015 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334124611 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334124798 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334211674 From vyazici at openjdk.org Tue Sep 9 18:27:27 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 9 Sep 2025 18:27:27 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v2] In-Reply-To: References: Message-ID: <3Oq-RRTjykFuFr0EnCQ870ccq1HIzCOT_2w6SZKjJgk=.987862ee-9303-4cc4-879c-ef53c1fb9d76@github.com> On Tue, 9 Sep 2025 13:15:27 GMT, Daniel Fuchs wrote: >> It is provided in the ctor above using `Utils.BUFSIZE`, which reads the `jdk.httpclient.bufsize` system property, and that can be negative. > > I think it would make more sense to make sure that Utils.BUFSIZE is initialized to a strictly positive value and only assert here. It could be useful to see if we have any test that set BUFSIZE to a small value - but if we don't maybe we could go and clamp it to e.g. `2^10 <= BUFSIZE < 2^24` or `2^10 <= BUFSIZE <= 2^23` if we want to keep powers of two. > (2^24 - 1 is the maximum allowed value for [SETTINGS_MAX_FRAME_SIZE](https://www.rfc-editor.org/rfc/rfc9113.html#SETTINGS_MAX_FRAME_SIZE) ) @dfuch, where shall I carry out that change? 1. In this PR? 2. In a follow-up a PR? 3. In a parallel PR to be merged before this one? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2334423774 From iklam at openjdk.org Wed Sep 10 04:16:03 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 04:16:03 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: Message-ID: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - @ashu-mehra review comments - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @DanHeidinga comments -- added comments and asserts about the handling of enums - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run - @DanHeidinga comments - tightened SystemDictionary::preload_class() - Fixed bugs found in JCK - added entry in ProblemList-AotJdk.txt due to 8323727 - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 ------------- Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=06 Stats: 716 lines in 44 files changed: 602 ins; 13 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Wed Sep 10 04:16:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 04:16:07 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 18:57:16 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: >> >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run >> - @DanHeidinga comments >> - tightened SystemDictionary::preload_class() >> - Fixed bugs found in JCK >> - added entry in ProblemList-AotJdk.txt due to 8323727 >> - more clean up >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - ... and 10 more: https://git.openjdk.org/jdk/compare/075ddef8...1a8ea501 > > src/hotspot/share/cds/aotOopChecker.cpp line 53: > >> 51: // the production run. >> 52: void AOTOopChecker::check(oop obj) { >> 53: precond(vmClasses::URL_klass()->is_final()); > > `AOTOopChecker::check` is a generic method, so this precond should ideally be inside the next block that explicitly handles URL class objects. I moved this line inside the next block. I also added comments that in the future we may check more types of objects. > src/hotspot/share/cds/aotOopChecker.cpp line 55: > >> 53: precond(vmClasses::URL_klass()->is_final()); >> 54: >> 55: if (obj->klass()->is_subclass_of(vmClasses::URL_klass())) { > > URL is a final class, so shouldn't `obj->klass() == vmClasses::URL_klass()` be sufficient? Since the `precond` is now inside this block, I can't use `==` anymore. Othewise if we had an instance of a subclass of URL then we will never get into the `if` block. > src/hotspot/share/classfile/javaClasses.cpp line 1063: > >> 1061: >> 1062: // Statically allocate fixup lists because they always get created. >> 1063: void java_lang_Class::allocate_fixup_lists() { > > Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true? I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499266 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499303 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499362 From iklam at openjdk.org Wed Sep 10 04:16:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 04:16:10 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 16:46:13 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: >> >> - @ashu-mehra review comments >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run >> - @DanHeidinga comments >> - tightened SystemDictionary::preload_class() >> - Fixed bugs found in JCK >> - added entry in ProblemList-AotJdk.txt due to 8323727 >> - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 > > src/hotspot/share/memory/iterator.inline.hpp line 58: > >> 56: ClaimMetadataVisitingOopIterateClosure::do_cld(cld); >> 57: } else { >> 58: assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); > > Why is the null check and assert not valid anymore? The AOT cache can have heap objects whose class are loaded by the platform/app loaders. These objects usually come from aot-linked Lambda expressions. Before this PR, the platform/app classes are loaded after executing quite a bit of Java code (i.e.,module graph initialization). It's possible for a GC to happen and discover those heap objects, whose classes are not yet loaded (i.e., having a null `cld`). After this PR, all boot/platform/app classes are loaded before GC can happen, so we will never run into such null `cld` anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499472 From dfuchs at openjdk.org Wed Sep 10 09:48:27 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 10 Sep 2025 09:48:27 GMT Subject: Integrated: 8365239: Spec Clarification - InterfaceAddress:getBroadcast() returning null for loop back address In-Reply-To: <1JHm4W0EacrwU_Dx4yNvFBFjIpk2qzJYmdINGSlKzVE=.ff7809d0-c26f-4699-ac69-8747d04ddbe5@github.com> References: <1JHm4W0EacrwU_Dx4yNvFBFjIpk2qzJYmdINGSlKzVE=.ff7809d0-c26f-4699-ac69-8747d04ddbe5@github.com> Message-ID: <3uUqkl8rJlXWNBHEj-hbuGIPCxLlbNfQjP9eAf1YEdI=.1a7726cb-5ffd-4e3f-9634-cf45f4980b23@github.com> On Tue, 9 Sep 2025 15:03:15 GMT, Daniel Fuchs wrote: > Hi, > > This is a documentation change only. The specification of `InterfaceAddress:getBroadcast()` should not say anything specific about the loopback interface as it appears that on some systems a broadcast address can be configured on the loopback. The API documentation of `InterfaceAddress:getBroadcast()` is updated to simply say that: > > * Some network interfaces do not support broadcasting and may > * also return {@code null}. This pull request has now been integrated. Changeset: 1d3364b0 Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/1d3364b00725f9d2afa8274e2244357a109be545 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8365239: Spec Clarification - InterfaceAddress:getBroadcast() returning null for loop back address Reviewed-by: msheppar, djelinski, jpai ------------- PR: https://git.openjdk.org/jdk/pull/27174 From dfuchs at openjdk.org Wed Sep 10 09:51:16 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 10 Sep 2025 09:51:16 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v2] In-Reply-To: <3Oq-RRTjykFuFr0EnCQ870ccq1HIzCOT_2w6SZKjJgk=.987862ee-9303-4cc4-879c-ef53c1fb9d76@github.com> References: <3Oq-RRTjykFuFr0EnCQ870ccq1HIzCOT_2w6SZKjJgk=.987862ee-9303-4cc4-879c-ef53c1fb9d76@github.com> Message-ID: On Tue, 9 Sep 2025 18:24:33 GMT, Volkan Yazici wrote: >> I think it would make more sense to make sure that Utils.BUFSIZE is initialized to a strictly positive value and only assert here. It could be useful to see if we have any test that set BUFSIZE to a small value - but if we don't maybe we could go and clamp it to e.g. `2^10 <= BUFSIZE < 2^24` or `2^10 <= BUFSIZE <= 2^23` if we want to keep powers of two. >> (2^24 - 1 is the maximum allowed value for [SETTINGS_MAX_FRAME_SIZE](https://www.rfc-editor.org/rfc/rfc9113.html#SETTINGS_MAX_FRAME_SIZE) ) > > @dfuch, where shall I carry out that change? > > 1. In this PR? > 2. In a follow-up a PR? > 3. In a parallel PR to be merged before this one? hmm... I see the `jdk.httpclient.bufsize` property is documented in module-info.java. So let's keep the code as you have it now (with the IAE) and do the clamping in a folowup. That will allow us to improve the documentation for that property. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2336206586 From asmehra at openjdk.org Wed Sep 10 14:22:44 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 10 Sep 2025 14:22:44 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 04:12:04 GMT, Ioi Lam wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 1063: >> >>> 1061: >>> 1062: // Statically allocate fixup lists because they always get created. >>> 1063: void java_lang_Class::allocate_fixup_lists() { >> >> Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true? > > I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true? I was referring to `fixup_module_field_list`, but the comments are for `fixup_mirror_list`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2336936776 From asmehra at openjdk.org Wed Sep 10 14:52:31 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 10 Sep 2025 14:52:31 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> References: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> Message-ID: On Wed, 10 Sep 2025 04:16:03 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - @ashu-mehra review comments > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @DanHeidinga comments -- added comments and asserts about the handling of enums > - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase > - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run > - @DanHeidinga comments > - tightened SystemDictionary::preload_class() > - Fixed bugs found in JCK > - added entry in ProblemList-AotJdk.txt due to 8323727 > - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 src/hotspot/share/cds/filemap.cpp line 1861: > 1859: const char* archive_type = CDSConfig::type_of_archive_being_loaded(); > 1860: CDSConfig::set_has_aot_linked_classes(true); > 1861: if (is_static()) { `CDSConfig` is a global configuration, not specific to static or dynamic archive, and IIUC it is not possible to just load a dynamic archive, without loading a static archive. So it seems `is_static()` check is redundant here. Continuing with this line of thought, it seems if `has_aot_linked_classes` is true then `is_using_preloaded_classes` will also be true. Then why do we even need this additional flag to indicate preloading of classes? This is going to be the default behavior when `has_aot_linked_classes` is true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337020552 From asmehra at openjdk.org Wed Sep 10 14:52:33 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 10 Sep 2025 14:52:33 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 04:12:08 GMT, Ioi Lam wrote: >> src/hotspot/share/memory/iterator.inline.hpp line 58: >> >>> 56: ClaimMetadataVisitingOopIterateClosure::do_cld(cld); >>> 57: } else { >>> 58: assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); >> >> Why is the null check and assert not valid anymore? > > The AOT cache can have heap objects whose class are loaded by the platform/app loaders. These objects usually come from aot-linked Lambda expressions. > > Before this PR, the platform/app classes are loaded after executing quite a bit of Java code (i.e.,module graph initialization). It's possible for a GC to happen and discover those heap objects, whose classes are not yet loaded (i.e., having a null `cld`). > > After this PR, all boot/platform/app classes are loaded before GC can happen, so we will never run into such null `cld` anymore. That makes `is_pending_aot_linked_class` dead code. Can it be removed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337025501 From dfuchs at openjdk.org Wed Sep 10 18:08:20 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 10 Sep 2025 18:08:20 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v17] 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 656 commits: - merge latest changes from master branch - modify http3 test timeouts - qpack - take knownReceivedCount into account during DT entries eviction - merge latest changes from master branch - http3: fix at since - merge latest http3 changes - Remove unused variables - Simplify control flow - Remove unnecessary instanceof checks - Use IntFunction for header generator - ... and 646 more: https://git.openjdk.org/jdk/compare/5cd7721a...9acc3590 ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=16 Stats: 105844 lines in 474 files changed: 103013 ins; 1333 del; 1498 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 iklam at openjdk.org Wed Sep 10 18:30:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 18:30:57 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> Message-ID: On Wed, 10 Sep 2025 14:47:19 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: >> >> - @ashu-mehra review comments >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run >> - @DanHeidinga comments >> - tightened SystemDictionary::preload_class() >> - Fixed bugs found in JCK >> - added entry in ProblemList-AotJdk.txt due to 8323727 >> - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 > > src/hotspot/share/cds/filemap.cpp line 1861: > >> 1859: const char* archive_type = CDSConfig::type_of_archive_being_loaded(); >> 1860: CDSConfig::set_has_aot_linked_classes(true); >> 1861: if (is_static()) { > > `CDSConfig` is a global configuration, not specific to static or dynamic archive, and IIUC it is not possible to just load a dynamic archive, without loading a static archive. So it seems `is_static()` check is redundant here. > Continuing with this line of thought, it seems if `has_aot_linked_classes` is true then `is_using_preloaded_classes` will also be true. Then why do we even need this additional flag to indicate preloading of classes? This is going to be the default behavior when `has_aot_linked_classes` is true. There is actually a tricky situation -- static archive doesn't have `-XX:+AOTClassLinking` but the dynamic archive was created with `-XX:+AOTClassLinking`. I have created [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366) to remove support for `-XX:+AOTClassLinking` for the dynamic archive. If that gets reviewed and integrated, then I will update this PR to remove `is_using_preloaded_classes()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337574998 From iklam at openjdk.org Wed Sep 10 18:30:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 18:30:58 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:19:33 GMT, Ashutosh Mehra wrote: >> I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true? > > I was referring to `fixup_module_field_list`, but the comments are for `fixup_mirror_list`. It's needed because of `-XX:+AOTClassLinking` in the dynamic archive. I will update this after removing `-XX:+AOTClassLinking` support for the dynamic archive in [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337579397 From jpai at openjdk.org Thu Sep 11 06:17:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Sep 2025 06:17:52 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v17] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:08:20 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 656 commits: > > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - Simplify control flow > - Remove unnecessary instanceof checks > - Use IntFunction for header generator > - ... and 646 more: https://git.openjdk.org/jdk/compare/5cd7721a...9acc3590 Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3209058486 From djelinski at openjdk.org Thu Sep 11 06:30:50 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 11 Sep 2025 06:30:50 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v17] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:08:20 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 656 commits: > > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - Simplify control flow > - Remove unnecessary instanceof checks > - Use IntFunction for header generator > - ... and 646 more: https://git.openjdk.org/jdk/compare/5cd7721a...9acc3590 Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3209123887 From aefimov at openjdk.org Fri Sep 12 13:33:19 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Fri, 12 Sep 2025 13:33:19 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v17] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:08:20 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 656 commits: > > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - Simplify control flow > - Remove unnecessary instanceof checks > - Use IntFunction for header generator > - ... and 646 more: https://git.openjdk.org/jdk/compare/5cd7721a...9acc3590 Marked as reviewed by aefimov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3216731618 From swen at openjdk.org Sun Sep 14 09:40:32 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 14 Sep 2025 09:40:32 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v2] In-Reply-To: <8a3sJUo9afYRfzjlAOMGrcX9VTnGLlXOgZmZ4vggRPo=.6a5b97da-1221-4b7d-87e8-d918b7df6a83@github.com> References: <8a3sJUo9afYRfzjlAOMGrcX9VTnGLlXOgZmZ4vggRPo=.6a5b97da-1221-4b7d-87e8-d918b7df6a83@github.com> Message-ID: On Mon, 8 Sep 2025 18:33:04 GMT, Volkan Yazici wrote: >> Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. > > Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision: > > - Remove IOE rethrows > - Revert `FilePublisherTest` and `FlowAdapterPublisherTest` changes > - Make `CheckedIterable` throw exceptions src/java.net.http/share/classes/jdk/internal/net/http/CheckedIterable.java line 47: > 45: Iterator iterator = iterable.iterator(); > 46: return CheckedIterator.fromIterator(iterator); > 47: }; Suggestion: return () -> CheckedIterator.fromIterator(iterable.iterator()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2347220518 From swen at openjdk.org Sun Sep 14 09:58:23 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 14 Sep 2025 09:58:23 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v2] In-Reply-To: <8a3sJUo9afYRfzjlAOMGrcX9VTnGLlXOgZmZ4vggRPo=.6a5b97da-1221-4b7d-87e8-d918b7df6a83@github.com> References: <8a3sJUo9afYRfzjlAOMGrcX9VTnGLlXOgZmZ4vggRPo=.6a5b97da-1221-4b7d-87e8-d918b7df6a83@github.com> Message-ID: On Mon, 8 Sep 2025 18:33:04 GMT, Volkan Yazici wrote: >> Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. > > Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision: > > - Remove IOE rethrows > - Revert `FilePublisherTest` and `FlowAdapterPublisherTest` changes > - Make `CheckedIterable` throw exceptions RequestPublishers$FilePublisher and RequestPublishers$InputStreamPublisher should be final src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 37: > 35: * Each new subscription gets a new {@link CheckedIterator}. > 36: */ > 37: class PullPublisher implements Flow.Publisher { Suggestion: final class PullPublisher implements Flow.Publisher { add final src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 202: > 200: } > 201: > 202: public static class StringPublisher extends ByteArrayPublisher { Suggestion: public static final class StringPublisher extends ByteArrayPublisher { src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 208: > 206: } > 207: > 208: public static class EmptyPublisher implements BodyPublisher { Suggestion: public static final class EmptyPublisher implements BodyPublisher { ------------- PR Comment: https://git.openjdk.org/jdk/pull/26876#issuecomment-3289406471 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2347225544 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2347227054 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2347227613 From djelinski at openjdk.org Mon Sep 15 12:12:08 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 15 Sep 2025 12:12:08 GMT Subject: RFR: 8367112: HttpClient does not support Named Groups set on SSLParameters Message-ID: HttpClient currently ignores the named groups and signature schemes configured on the SSLParameters. Given that it processes the configured protocols and cipher suites, I think it should process named groups and signature schemes as well. Tier1-3 tests continue to pass. ------------- Commit messages: - Use configured named groups and signature schemes Changes: https://git.openjdk.org/jdk/pull/27292/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27292&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367112 Stats: 18 lines in 2 files changed: 16 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27292.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27292/head:pull/27292 PR: https://git.openjdk.org/jdk/pull/27292 From jpai at openjdk.org Tue Sep 16 13:19:00 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 16 Sep 2025 13:19:00 GMT Subject: RFR: 8367112: HttpClient does not support Named Groups set on SSLParameters In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 11:29:24 GMT, Daniel Jeli?ski wrote: > HttpClient currently ignores the named groups and signature schemes configured on the SSLParameters. Given that it processes the configured protocols and cipher suites, I think it should process named groups and signature schemes as well. > > Tier1-3 tests continue to pass. This looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27292#pullrequestreview-3229956631 From dfuchs at openjdk.org Tue Sep 16 13:22:47 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 16 Sep 2025 13:22:47 GMT Subject: RFR: 8367112: HttpClient does not support Named Groups set on SSLParameters In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 11:29:24 GMT, Daniel Jeli?ski wrote: > HttpClient currently ignores the named groups and signature schemes configured on the SSLParameters. Given that it processes the configured protocols and cipher suites, I think it should process named groups and signature schemes as well. > > Tier1-3 tests continue to pass. This looks reasonable. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27292#pullrequestreview-3229967435 From mdonovan at openjdk.org Wed Sep 17 11:58:25 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 17 Sep 2025 11:58:25 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures Message-ID: This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. ------------- Commit messages: - 8353738: Update TLS unit tests to not use certificates with MD5 signatures Changes: https://git.openjdk.org/jdk/pull/27342/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353738 Stats: 2551 lines in 10 files changed: 400 ins; 2046 del; 105 mod Patch: https://git.openjdk.org/jdk/pull/27342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342 PR: https://git.openjdk.org/jdk/pull/27342 From djelinski at openjdk.org Wed Sep 17 14:01:56 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 17 Sep 2025 14:01:56 GMT Subject: RFR: 8367112: HttpClient does not support Named Groups set on SSLParameters In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 11:29:24 GMT, Daniel Jeli?ski wrote: > HttpClient currently ignores the named groups and signature schemes configured on the SSLParameters. Given that it processes the configured protocols and cipher suites, I think it should process named groups and signature schemes as well. > > Tier1-3 tests continue to pass. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27292#issuecomment-3303140085 From djelinski at openjdk.org Wed Sep 17 14:04:42 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 17 Sep 2025 14:04:42 GMT Subject: Integrated: 8367112: HttpClient does not support Named Groups set on SSLParameters In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 11:29:24 GMT, Daniel Jeli?ski wrote: > HttpClient currently ignores the named groups and signature schemes configured on the SSLParameters. Given that it processes the configured protocols and cipher suites, I think it should process named groups and signature schemes as well. > > Tier1-3 tests continue to pass. This pull request has now been integrated. Changeset: d7eeacf2 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/d7eeacf2a0c24946de56471a99e744f21642d784 Stats: 18 lines in 2 files changed: 16 ins; 0 del; 2 mod 8367112: HttpClient does not support Named Groups set on SSLParameters Reviewed-by: jpai, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/27292 From syan at openjdk.org Wed Sep 17 14:30:02 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 17 Sep 2025 14:30:02 GMT Subject: RFR: 8367904: Test java/net/InetAddress/ptr/Lookup.java should throw SkippedException Message-ID: Hi all, Currently test java/net/InetAddress/ptr/Lookup.java print message and return when test can not run normally. I think it's better to throw jtreg.SkippedException rather report test passed when test can not execute normally. ------------- Commit messages: - 8367904: Test java/net/InetAddress/ptr/Lookup.java should throw SkippedException Changes: https://git.openjdk.org/jdk/pull/27347/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27347&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367904 Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27347.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27347/head:pull/27347 PR: https://git.openjdk.org/jdk/pull/27347 From fandreuzzi at openjdk.org Wed Sep 17 14:53:04 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 17 Sep 2025 14:53:04 GMT Subject: RFR: 8367904: Test java/net/InetAddress/ptr/Lookup.java should throw SkippedException In-Reply-To: References: Message-ID: <6L66G7ss0eYLW7vTm5dVK4Xo_wpsxpvLJWJWR77CaRE=.e2339958-f1e2-4ce6-ba02-3eab5976f8ae@github.com> On Wed, 17 Sep 2025 14:22:39 GMT, SendaoYan wrote: > Hi all, > > Currently test java/net/InetAddress/ptr/Lookup.java print message and return when test can not run normally. I think it's better to throw jtreg.SkippedException rather report test passed when test can not execute normally. Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27347#pullrequestreview-3234884690 From dfuchs at openjdk.org Wed Sep 17 14:59:55 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 17 Sep 2025 14:59:55 GMT Subject: RFR: 8367904: Test java/net/InetAddress/ptr/Lookup.java should throw SkippedException In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 14:22:39 GMT, SendaoYan wrote: > Hi all, > > Currently test java/net/InetAddress/ptr/Lookup.java print message and return when test can not run normally. I think it's better to throw jtreg.SkippedException rather report test passed when test can not execute normally. Good finding. Looks reasonable to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27347#pullrequestreview-3234916555 From mullan at openjdk.org Wed Sep 17 16:49:46 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 17 Sep 2025 16:49:46 GMT Subject: RFR: 8367112: HttpClient does not support Named Groups set on SSLParameters In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 11:29:24 GMT, Daniel Jeli?ski wrote: > HttpClient currently ignores the named groups and signature schemes configured on the SSLParameters. Given that it processes the configured protocols and cipher suites, I think it should process named groups and signature schemes as well. > > Tier1-3 tests continue to pass. This seems like a change that would be useful to document in a release note. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27292#issuecomment-3303813652 From dfuchs at openjdk.org Wed Sep 17 16:58:04 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 17 Sep 2025 16:58:04 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] 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 659 commits: - merge latest changes from master branch - merge latest changes from master branch - http3: CSR review feedback - merge latest changes from master branch - modify http3 test timeouts - qpack - take knownReceivedCount into account during DT entries eviction - merge latest changes from master branch - http3: fix at since - merge latest http3 changes - Remove unused variables - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=17 Stats: 105854 lines in 474 files changed: 103017 ins; 1337 del; 1500 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 dfuchs at openjdk.org Wed Sep 17 17:38:54 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 17 Sep 2025 17:38:54 GMT Subject: RFR: 8367112: HttpClient does not support Named Groups set on SSLParameters In-Reply-To: References: Message-ID: <-FFTgCqmNjJwJeEgXHNlax5me07WED1c1XQ7K-_TM0s=.6a5058c4-c43c-49b5-8049-274bc34abba6@github.com> On Wed, 17 Sep 2025 16:47:12 GMT, Sean Mullan wrote: >> HttpClient currently ignores the named groups and signature schemes configured on the SSLParameters. Given that it processes the configured protocols and cipher suites, I think it should process named groups and signature schemes as well. >> >> Tier1-3 tests continue to pass. > > This seems like a change that would be useful to document in a release note. Ah! Good point. Thanks for chiming in @seanjmullan ... I have added the release-note=yes label to the JBS issue so that we don't forget. @djelinski could you work on the release note while your memory of the issue is fresh? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27292#issuecomment-3303962210 From syan at openjdk.org Thu Sep 18 02:48:42 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Sep 2025 02:48:42 GMT Subject: RFR: 8367904: Test java/net/InetAddress/ptr/Lookup.java should throw SkippedException In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 14:22:39 GMT, SendaoYan wrote: > Hi all, > > Currently test java/net/InetAddress/ptr/Lookup.java print message and return when test can not run normally. I think it's better to throw jtreg.SkippedException rather report test passed when test can not execute normally. Change has been verified localy: TEST RESULT: Passed. Skipped: jtreg.SkippedException: icann.org can't be resolved - test skipped. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27347#issuecomment-3305212963 From geliang at kernel.org Thu Sep 18 07:36:58 2025 From: geliang at kernel.org (Geliang Tang) Date: Thu, 18 Sep 2025 15:36:58 +0800 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> Message-ID: <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> Hi Alan, On Fri, 2025-09-05 at 18:11 +0800, Geliang Tang wrote: > Hi Alan, > > Thanks for your reply. > > On Fri, 2025-09-05 at 10:28 +0100, Alan Bateman wrote: > > ? > > On 05/09/2025 09:43, Geliang Tang wrote: > > ? > > ? > > > ? > > > : > > > > > > 3. Proposed Java API Changes > > > > > > The goal is to allow Java applications to opt-in to using MPTCP > > > when > > > creating sockets, without breaking existing code. The proposed > > > changes > > > are additive and backward-compatible. > > > > > > The core idea is to add a boolean mptcp parameter through the API > > > layers, from the public Socket class down to the native system > > > call. > > > ? > > ? > > ?(moving the discussion to nio-dev and net-dev). > > ? > > ?Adding new constructors to legacy Socket/ServerSocket may work for > > your initial prototype but would be problematic to propose as it > > would bake non-standard features into the standard API. Also many > > high performance servers use SocketChannel rather than Socket. > > ? > > ?One suggestion for a next prototype is to model the enablement of > > MultiPath TCP as as a JDK-specific socket option (see > > jdk.net.ExtendingSocketOptions). All of the standard APIs for > > networking sockets define a setOption method for setting socket > > I was initially concerned that calling setOption() after Socket() > creation to convert TCP to MPTCP was too late. Creating an MPTCP > socket > must be done during the socket() system call. > > > options. If modeled as a socket option then enabling can create a > > new > > AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into > > place > > Until I saw here, it should be feasible if the socket can be created > again and dup when calling setOption(). > > I will try to reimplement MPTCP support using > jdk.net.ExtendingSocketOptions soon and give you feedback. I have completed the implementation. Thanks to Xiang Gao and Gang Yan for their help. I added a new option named TCP_MPTCPIFY in jdk.net.ExtendedSocketOptions (the name was chosen to align with 'mptcpize' tool in mptcpd and 'mptcpify' in BCC). When this option is set, it calls the JNI function mptcpify0. Following your suggestion, mptcpify0 is implemented by referencing Java_sun_net_sdp_SdpSupport_convert0. It creates a new MPTCP socket, uses dup2 to duplicate it, and then closes the redundant socket. I have added your tag in the patch: Suggested-by: Alan Bateman I also included a test example for this option. All modifications can be found here: https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master Please provide any feedback or suggestions. As for the next steps, should I create a new issue for this feature and submit a proper pull request? Thanks, -Geliang > > Thanks, > -Geliang > > > so that the original AF_INET6/SOCK_STREAM/0 socket is closed. > > Enabling can be made to fail if the socket is already bound. It > > could > > copy over existing socket options if needed. Look at the built-in > > (and no longer used) SDP support for an example that does similar > > with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a > > socket option defined in jdk.net.ExtendingSocketOptions. > > ? > > ?-Alan > > ? > > ? From vyazici at openjdk.org Thu Sep 18 09:28:20 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 18 Sep 2025 09:28:20 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v2] In-Reply-To: References: <3Oq-RRTjykFuFr0EnCQ870ccq1HIzCOT_2w6SZKjJgk=.987862ee-9303-4cc4-879c-ef53c1fb9d76@github.com> Message-ID: On Wed, 10 Sep 2025 09:48:36 GMT, Daniel Fuchs wrote: >> @dfuch, where shall I carry out that change? >> >> 1. In this PR? >> 2. In a follow-up a PR? >> 3. In a parallel PR to be merged before this one? > > hmm... I see the `jdk.httpclient.bufsize` property is documented in module-info.java. So let's keep the code as you have it now (with the IAE) and do the clamping in a folowup. That will allow us to improve the documentation for that property. Created [JDK-8367976] to address this. [JDK-8367976]: https://bugs.openjdk.org/browse/JDK-8367976 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2358207559 From vyazici at openjdk.org Thu Sep 18 09:44:09 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 18 Sep 2025 09:44:09 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v2] In-Reply-To: References: <8a3sJUo9afYRfzjlAOMGrcX9VTnGLlXOgZmZ4vggRPo=.6a5b97da-1221-4b7d-87e8-d918b7df6a83@github.com> Message-ID: On Sun, 14 Sep 2025 09:37:26 GMT, Shaojin Wen wrote: >> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision: >> >> - Remove IOE rethrows >> - Revert `FilePublisherTest` and `FlowAdapterPublisherTest` changes >> - Make `CheckedIterable` throw exceptions > > src/java.net.http/share/classes/jdk/internal/net/http/CheckedIterable.java line 47: > >> 45: Iterator iterator = iterable.iterator(); >> 46: return CheckedIterator.fromIterator(iterator); >> 47: }; > > Suggestion: > > return () -> CheckedIterator.fromIterator(iterable.iterator()); I will keep the current style which enables stepping convenience in the debugger. > src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 37: > >> 35: * Each new subscription gets a new {@link CheckedIterator}. >> 36: */ >> 37: class PullPublisher implements Flow.Publisher { > > Suggestion: > > final class PullPublisher implements Flow.Publisher { > > add final No unrelated improvements ? see [my earlier comment]. [my earlier comment]: https://github.com/openjdk/jdk/pull/26876/files#r2358241186 > src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 202: > >> 200: } >> 201: >> 202: public static class StringPublisher extends ByteArrayPublisher { > > Suggestion: > > public static final class StringPublisher extends ByteArrayPublisher { No unrelated improvements ? see [my earlier comment]. [my earlier comment]: https://github.com/openjdk/jdk/pull/26876/files#r2358241186 > src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 208: > >> 206: } >> 207: >> 208: public static class EmptyPublisher implements BodyPublisher { > > Suggestion: > > public static final class EmptyPublisher implements BodyPublisher { I kept unrelated improvements limited to the lines already touched, to avoid cluttering the diff and the VCS history. While I fully agree with your proposal, I'd prefer to address it some other time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2358248786 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2358250645 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2358244313 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2358241186 From alan.bateman at oracle.com Thu Sep 18 11:30:16 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Thu, 18 Sep 2025 12:30:16 +0100 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> Message-ID: <2b699d6c-d05b-4445-9448-99348eebdf4a@oracle.com> On 18/09/2025 08:36, Geliang Tang wrote: > I have completed the implementation. Thanks to Xiang Gao and Gang Yan > for their help. I added a new option named TCP_MPTCPIFY in > jdk.net.ExtendedSocketOptions (the name was chosen to align with > 'mptcpize' tool in mptcpd and 'mptcpify' in BCC). When this option is > set, it calls the JNI function mptcpify0. > > Following your suggestion, mptcpify0 is implemented by referencing > Java_sun_net_sdp_SdpSupport_convert0. It creates a new MPTCP socket, > uses dup2 to duplicate it, and then closes the redundant socket. > > I have added your tag in the patch: > > Suggested-by: Alan Bateman > > I also included a test example for this option. All modifications can > be found here: > > https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master > > Please provide any feedback or suggestions. As for the next steps, > should I create a new issue for this feature and submit a proper pull > request? Thanks for confirming that the direction suggested works. This at least demonstrates a feasible direction that does not impact the standard API. As regards next steps then I think start a thread on net-dev to try to get input. I think it would be useful to show potential scenarios where it would be useful and what performance benefits might come from it. I think also useful to talk about whether this is something that an application has to opt into, maybe there are other configuration approaches that would not require application changes? I think it would be useful to discuss testing. If this feature were integrated into the JDK then how would it be tested? Who would test and maintain it? There is a JDK release every 6 months, is someone going test it with each release? If it goes ahead then there the name of the extended socket option and its API docs will need discussion. Details around state will need to be specified, would it be supported to set TCP_MPTCP when bound or connected, does it make sense to ever attempt to set it to false after setting it to true (these are just examples of the details that will need to be specified, they are not important right now). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyazici at openjdk.org Thu Sep 18 12:46:43 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 18 Sep 2025 12:46:43 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v3] In-Reply-To: References: Message-ID: > Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Fix `FileChannelPublisherTest` failures ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26876/files - new: https://git.openjdk.org/jdk/pull/26876/files/e9bc9e76..983c1e7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26876&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26876&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26876.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26876/head:pull/26876 PR: https://git.openjdk.org/jdk/pull/26876 From jpai at openjdk.org Thu Sep 18 16:33:58 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Sep 2025 16:33:58 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v3] In-Reply-To: References: Message-ID: <54H7JFeCRznBSh2S0YBaVdfxbMlH-A1ATAxLCdk0v_0=.bc253f1a-4c84-4aec-bfe0-4047dd3c8cc9@github.com> On Thu, 18 Sep 2025 12:46:43 GMT, Volkan Yazici wrote: >> Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix `FileChannelPublisherTest` failures src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 47: > 45: > 46: PullPublisher(CheckedIterable iterable, Throwable throwable) { > 47: if ((iterable == null) == (throwable == null)) { Hello Volkan, I realize this style of condition check was done based on a review suggestion, so I don't expect you to undo it. Personally, I find this check hard to grasp and takes me a few rounds to understand what it is doing. But it's OK to leave it in this form. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2360192499 From jpai at openjdk.org Thu Sep 18 16:33:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Sep 2025 16:33:59 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v3] In-Reply-To: <54H7JFeCRznBSh2S0YBaVdfxbMlH-A1ATAxLCdk0v_0=.bc253f1a-4c84-4aec-bfe0-4047dd3c8cc9@github.com> References: <54H7JFeCRznBSh2S0YBaVdfxbMlH-A1ATAxLCdk0v_0=.bc253f1a-4c84-4aec-bfe0-4047dd3c8cc9@github.com> Message-ID: <3Dl5cNEdmlbmhI1iVvnaW4rVEYI7pQf81vbKBdZ5A7g=.b3545111-a53a-499b-be50-d8571fdcc682@github.com> On Thu, 18 Sep 2025 16:31:07 GMT, Jaikiran Pai wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix `FileChannelPublisherTest` failures > > src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 47: > >> 45: >> 46: PullPublisher(CheckedIterable iterable, Throwable throwable) { >> 47: if ((iterable == null) == (throwable == null)) { > > Hello Volkan, I realize this style of condition check was done based on a review suggestion, so I don't expect you to undo it. Personally, I find this check hard to grasp and takes me a few rounds to understand what it is doing. But it's OK to leave it in this form. This file will need a copyright year update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2360193515 From jpai at openjdk.org Thu Sep 18 16:42:33 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Sep 2025 16:42:33 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v3] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 12:46:43 GMT, Volkan Yazici wrote: >> Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix `FileChannelPublisherTest` failures src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 46: > 44: private final Throwable throwable; > 45: > 46: PullPublisher(CheckedIterable iterable, Throwable throwable) { Looking at the usages of this constructor, would it be better if we got rid of this 2-arg constructor and introduced a new PullPublisher(Throwable throwable) { } That way all we have to do is verify that the incoming argument is non-null, both in this constructor and the other existing `PullPublisher(CheckedIterable iterable)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2360235119 From djelinski at openjdk.org Thu Sep 18 17:45:17 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 18 Sep 2025 17:45:17 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: <_7u8--cDXCFXH9dBDOIxXrK977Hco0wt1tujbg8diJY=.eac75161-a9a0-4e2c-84e3-aef2489e01c4@github.com> On Wed, 17 Sep 2025 16:58:04 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 659 commits: > > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3241201475 From jpai at openjdk.org Thu Sep 18 17:45:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Sep 2025 17:45:18 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:58:04 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 659 commits: > > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3241211547 From aefimov at openjdk.org Thu Sep 18 21:56:20 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Thu, 18 Sep 2025 21:56:20 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:58:04 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 659 commits: > > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb Marked as reviewed by aefimov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3242208335 From iklam at openjdk.org Fri Sep 19 01:38:25 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 01:38:25 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v8] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class - @ashu-mehra review comments - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @DanHeidinga comments -- added comments and asserts about the handling of enums - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase - ... and 17 more: https://git.openjdk.org/jdk/compare/91a97943...04cb7a64 ------------- Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=07 Stats: 903 lines in 43 files changed: 498 ins; 212 del; 193 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Fri Sep 19 01:44:26 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 01:44:26 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v8] In-Reply-To: References: Message-ID: <5_ai8lG-Zs7B3xi8XQ0dnrr2TDmywRALaeN0uyqyUQ8=.18e3bfa2-9512-4173-8fc3-a83d827e7353@github.com> On Fri, 19 Sep 2025 01:38:25 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes > - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class > - @ashu-mehra review comments > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @DanHeidinga comments -- added comments and asserts about the handling of enums > - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase > - ... and 17 more: https://git.openjdk.org/jdk/compare/91a97943...04cb7a64 @ashu-mehra , I've remove all the code that was needed to handle aot-linked classes from the dynamic archive but is no longer needed since [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366). I am able to remove about 200 lines of code. I also renamed a few functions in `AOTLinkedClassBulkLoader` to reflect the up-to-date meaning. `CDSConfig::is_using_preloaded_classes()` has been removed and replaced with `CDSConfig::is_using_aot_linked_classes()` The handling of `fixup_mirror_list()` and `fixup_module_field_list()` in javaClasses.cpp have been made uniform. Please see https://github.com/openjdk/jdk/pull/26375/commits/896ce8b9636a5534f1db487afbe27e875022fbfa ------------- PR Comment: https://git.openjdk.org/jdk/pull/26375#issuecomment-3310193834 From syan at openjdk.org Fri Sep 19 01:53:20 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Sep 2025 01:53:20 GMT Subject: RFR: 8367904: Test java/net/InetAddress/ptr/Lookup.java should throw SkippedException In-Reply-To: <6L66G7ss0eYLW7vTm5dVK4Xo_wpsxpvLJWJWR77CaRE=.e2339958-f1e2-4ce6-ba02-3eab5976f8ae@github.com> References: <6L66G7ss0eYLW7vTm5dVK4Xo_wpsxpvLJWJWR77CaRE=.e2339958-f1e2-4ce6-ba02-3eab5976f8ae@github.com> Message-ID: On Wed, 17 Sep 2025 14:50:29 GMT, Francesco Andreuzzi wrote: >> Hi all, >> >> Currently test java/net/InetAddress/ptr/Lookup.java print message and return when test can not run normally. I think it's better to throw jtreg.SkippedException rather report test passed when test can not execute normally. > > Marked as reviewed by fandreuzzi (Author). @fandreuz @dfuch Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27347#issuecomment-3310208976 From syan at openjdk.org Fri Sep 19 01:53:21 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Sep 2025 01:53:21 GMT Subject: Integrated: 8367904: Test java/net/InetAddress/ptr/Lookup.java should throw SkippedException In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 14:22:39 GMT, SendaoYan wrote: > Hi all, > > Currently test java/net/InetAddress/ptr/Lookup.java print message and return when test can not run normally. I think it's better to throw jtreg.SkippedException rather report test passed when test can not execute normally. This pull request has now been integrated. Changeset: c0815e40 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/c0815e40b6f5feeb4bfa791ccd91d662c205068d Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod 8367904: Test java/net/InetAddress/ptr/Lookup.java should throw SkippedException Reviewed-by: fandreuzzi, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/27347 From iklam at openjdk.org Fri Sep 19 04:46:13 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 04:46:13 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v9] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed 32-bit builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26375/files - new: https://git.openjdk.org/jdk/pull/26375/files/04cb7a64..9ec10f5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=07-08 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From jpai at openjdk.org Fri Sep 19 06:38:35 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Sep 2025 06:38:35 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v3] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 12:46:43 GMT, Volkan Yazici wrote: >> Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix `FileChannelPublisherTest` failures test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfByteArraysTest.java line 263: > 261: * Initiates tests that depend on a custom-configured JVM. > 262: */ > 263: public static void main(String[] args) throws Exception { Hello Volkan, I am not completely certain whether having a test class which has both a `@run main` and a `@run junit` is guaranteed to always work. What I mean is, I don't know if jtreg will setup the (runtime) classpath to always include junit libraries which will be required by this class (since it references those junit classes) when running the `@run main` action. It might be better to separate out the junit testing and the main() testing into 2 separate test classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2361934948 From jpai at openjdk.org Fri Sep 19 06:42:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Sep 2025 06:42:41 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v3] In-Reply-To: References: Message-ID: <3PAkugP-1ML_ypkqJgWuTDredizINYa4TzpxB89u4kk=.6c4f18b2-6b93-43cb-88ba-050e12d87854@github.com> On Thu, 18 Sep 2025 12:46:43 GMT, Volkan Yazici wrote: >> Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix `FileChannelPublisherTest` failures test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfFileTest.java line 63: > 61: public class OfFileTest { > 62: > 63: private static final Path DEFAULT_FS_DIR = Path.of(System.getProperty("java.io.tmpdir")); Is it intentional to use `java.io.tmpdir` as the Path instead of the test's scratch dir - `Path.of(".")`? test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfFileTest.java line 72: > 70: try { > 71: Path zipFile = DEFAULT_FS_DIR.resolve("file.zip"); > 72: FileSystem zipFS = FileSystems.newFileSystem(zipFile, Map.of("create", "true")); This can lead to the `FileSystem` not being closed even after the test completes. I think we should move out the `FileSystem` instance out of this method into a class level field which can then be closed when the test is done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2361940787 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2361943150 From vyazici at openjdk.org Fri Sep 19 10:07:16 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 19 Sep 2025 10:07:16 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v4] In-Reply-To: References: Message-ID: > Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge remote-tracking branch 'upstream/master' into sendAsyncEx - Close ZIP file system at exit - Use scratch directory for `OfFileTest::DEFAULT_FS_DIR` - Update copyright year of `PullPublisher` - Fix `FileChannelPublisherTest` failures - Remove IOE rethrows - Revert `FilePublisherTest` and `FlowAdapterPublisherTest` changes - Make `CheckedIterable` throw exceptions - Merge remote-tracking branch 'upstream/master' into sendAsyncEx - Revert clean-up of redundant tests to keep PR focused - ... and 14 more: https://git.openjdk.org/jdk/compare/94a301a7...74dddad1 ------------- Changes: https://git.openjdk.org/jdk/pull/26876/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26876&range=03 Stats: 1685 lines in 14 files changed: 1618 ins; 20 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/26876.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26876/head:pull/26876 PR: https://git.openjdk.org/jdk/pull/26876 From vyazici at openjdk.org Fri Sep 19 10:07:17 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 19 Sep 2025 10:07:17 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v4] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 17:55:56 GMT, Volkan Yazici wrote: >> You might discover that it's not as simple, as the case where the throwable is known in advance folds within the case where getting the interator throws... >> You'd still need to be able to create a failed subscription at line 73 below. >> >> I am not opposed to exploring that route though - and see if it really simplifies the code. > > Thanks for the feedback. I?ll set this exploration aside until after the PR. If I get convincing results, I?ll knock on your door again. Created [JDK-8368077] to address this. [JDK-8368077]: https://bugs.openjdk.org/browse/JDK-8368077 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2362172647 From vyazici at openjdk.org Fri Sep 19 10:07:23 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 19 Sep 2025 10:07:23 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v3] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 16:40:02 GMT, Jaikiran Pai wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix `FileChannelPublisherTest` failures > > src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 46: > >> 44: private final Throwable throwable; >> 45: >> 46: PullPublisher(CheckedIterable iterable, Throwable throwable) { > > Looking at the usages of this constructor, would it be better if we got rid of this 2-arg constructor and introduced a new > > PullPublisher(Throwable throwable) { > } > > > That way all we have to do is verify that the incoming argument is non-null, both in this constructor and the other existing `PullPublisher(CheckedIterable iterable)` I agree with your sentiment, which is something I raised [earlier]. I intend to carry out this improvement in a follow-up ticket to avoid bloating this PR ? created [JDK-8368077]. [earlier]: https://github.com/openjdk/jdk/pull/26876/files#r2329782120 [JDK-8368077]: https://bugs.openjdk.org/browse/JDK-8368077 > test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfByteArraysTest.java line 263: > >> 261: * Initiates tests that depend on a custom-configured JVM. >> 262: */ >> 263: public static void main(String[] args) throws Exception { > > Hello Volkan, I am not completely certain whether having a test class which has both a `@run main` and a `@run junit` is guaranteed to always work. What I mean is, I don't know if jtreg will setup the (runtime) classpath to always include junit libraries which will be required by this class (since it references those junit classes) when running the `@run main` action. It might be better to separate out the junit testing and the main() testing into 2 separate test classes. You have a very valid point. `@run main` executions should indeed fail due to missing JUnit classes ? yet it works, which is, IMHO, unexpected. Agreeing with your sentiment, and putting aside the fact that _"it works"_, I've tried to refactor these `@run main` tests out to separate classes, but I ended up duplicating quite some code. Later on I've checked this issue with @sormuras and we've found that, except `@run java`, all `@run` executions in the same `@test` block get JUnit/TestNG added to their classpath in the presence of a `@run junit`/`@run testng`. Since this is an established JTreg ~bug~ feature, and helps with DRY, I will keep the code as is for the time being. > test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfFileTest.java line 63: > >> 61: public class OfFileTest { >> 62: >> 63: private static final Path DEFAULT_FS_DIR = Path.of(System.getProperty("java.io.tmpdir")); > > Is it intentional to use `java.io.tmpdir` as the Path instead of the test's scratch dir - `Path.of(".")`? Fixed in 6e46e61eb9. Adopted the code in `jdk.test.lib.Utils::createTempFile`. > test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfFileTest.java line 72: > >> 70: try { >> 71: Path zipFile = DEFAULT_FS_DIR.resolve("file.zip"); >> 72: FileSystem zipFS = FileSystems.newFileSystem(zipFile, Map.of("create", "true")); > > This can lead to the `FileSystem` not being closed even after the test completes. I think we should move out the `FileSystem` instance out of this method into a class level field which can then be closed when the test is done. Fixed in 11a74dde85. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2362172857 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2362381864 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2362233541 PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2362290580 From vyazici at openjdk.org Fri Sep 19 10:07:24 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 19 Sep 2025 10:07:24 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v3] In-Reply-To: <3Dl5cNEdmlbmhI1iVvnaW4rVEYI7pQf81vbKBdZ5A7g=.b3545111-a53a-499b-be50-d8571fdcc682@github.com> References: <54H7JFeCRznBSh2S0YBaVdfxbMlH-A1ATAxLCdk0v_0=.bc253f1a-4c84-4aec-bfe0-4047dd3c8cc9@github.com> <3Dl5cNEdmlbmhI1iVvnaW4rVEYI7pQf81vbKBdZ5A7g=.b3545111-a53a-499b-be50-d8571fdcc682@github.com> Message-ID: <4rnU0N5kxr7-IvCmPC6CoNrZsLT7dcgTzMowcTIqEPQ=.4b183d90-7432-41eb-bcc0-2511b08f3fe2@github.com> On Thu, 18 Sep 2025 16:31:24 GMT, Jaikiran Pai wrote: >> src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 47: >> >>> 45: >>> 46: PullPublisher(CheckedIterable iterable, Throwable throwable) { >>> 47: if ((iterable == null) == (throwable == null)) { >> >> Hello Volkan, I realize this style of condition check was done based on a review suggestion, so I don't expect you to undo it. Personally, I find this check hard to grasp and takes me a few rounds to understand what it is doing. But it's OK to leave it in this form. > > This file will need a copyright year update. Updated the year in 88ea9d4640. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26876#discussion_r2362173005 From fandreuzzi at openjdk.org Fri Sep 19 10:16:26 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 19 Sep 2025 10:16:26 GMT Subject: RFR: 8368029: Several tests in httpserver/simpleserver should throw SkipException Message-ID: I propose a change to have these tests listed appropriately as "skipped" rather than "passing" on Windows. I'm also taking the opportunity to save an indentation level since we can throw a `SkipException` early in all the related methods. ------------- Commit messages: - skip Changes: https://git.openjdk.org/jdk/pull/27387/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27387&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368029 Stats: 120 lines in 2 files changed: 12 ins; 4 del; 104 mod Patch: https://git.openjdk.org/jdk/pull/27387.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27387/head:pull/27387 PR: https://git.openjdk.org/jdk/pull/27387 From jpai at openjdk.org Fri Sep 19 10:19:34 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Sep 2025 10:19:34 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v4] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 10:07:16 GMT, Volkan Yazici wrote: >> Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Merge remote-tracking branch 'upstream/master' into sendAsyncEx > - Close ZIP file system at exit > - Use scratch directory for `OfFileTest::DEFAULT_FS_DIR` > - Update copyright year of `PullPublisher` > - Fix `FileChannelPublisherTest` failures > - Remove IOE rethrows > - Revert `FilePublisherTest` and `FlowAdapterPublisherTest` changes > - Make `CheckedIterable` throw exceptions > - Merge remote-tracking branch 'upstream/master' into sendAsyncEx > - Revert clean-up of redundant tests to keep PR focused > - ... and 14 more: https://git.openjdk.org/jdk/compare/94a301a7...74dddad1 Thank you Volkan for the updates, this looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26876#pullrequestreview-3244203057 From djelinski at openjdk.org Fri Sep 19 10:36:04 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 19 Sep 2025 10:36:04 GMT Subject: RFR: 8368029: Several tests in httpserver/simpleserver should throw SkipException In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 10:07:01 GMT, Francesco Andreuzzi wrote: > I propose a change to have these tests listed appropriately as "skipped" rather than "passing" on Windows. I'm also taking the opportunity to save an indentation level since we can throw a `SkipException` early in all the related methods. Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27387#pullrequestreview-3244280611 From mchhipa at openjdk.org Fri Sep 19 10:51:49 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Fri, 19 Sep 2025 10:51:49 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit Message-ID: Refactoring following httpclient/http2 testng test to JUnit : test/jdk/java/net/httpclient/http2/BadHeadersTest.java test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java test/jdk/java/net/httpclient/http2/BasicTest.java test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java ------------- Commit messages: - JDK-8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit Changes: https://git.openjdk.org/jdk/pull/27388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27388&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318662 Stats: 167 lines in 5 files changed: 13 ins; 30 del; 124 mod Patch: https://git.openjdk.org/jdk/pull/27388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27388/head:pull/27388 PR: https://git.openjdk.org/jdk/pull/27388 From michaelm at openjdk.org Fri Sep 19 11:19:39 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 19 Sep 2025 11:19:39 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:58:04 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 659 commits: > > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb I have reviewed the version independent changes only. They look fine to me. ------------- Marked as reviewed by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3244405763 From dfuchs at openjdk.org Fri Sep 19 12:04:00 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 19 Sep 2025 12:04:00 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v4] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 10:07:16 GMT, Volkan Yazici wrote: >> Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Merge remote-tracking branch 'upstream/master' into sendAsyncEx > - Close ZIP file system at exit > - Use scratch directory for `OfFileTest::DEFAULT_FS_DIR` > - Update copyright year of `PullPublisher` > - Fix `FileChannelPublisherTest` failures > - Remove IOE rethrows > - Revert `FilePublisherTest` and `FlowAdapterPublisherTest` changes > - Make `CheckedIterable` throw exceptions > - Merge remote-tracking branch 'upstream/master' into sendAsyncEx > - Revert clean-up of redundant tests to keep PR focused > - ... and 14 more: https://git.openjdk.org/jdk/compare/94a301a7...74dddad1 Latest changes LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26876#pullrequestreview-3244552122 From vyazici at openjdk.org Fri Sep 19 12:10:21 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 19 Sep 2025 12:10:21 GMT Subject: RFR: 8367067: Improve exception handling in HttpRequest.BodyPublishers [v4] In-Reply-To: References: Message-ID: <7VydQJ8WY88SejsQvmAdisfAEei8wO6FUVLvuzBtJws=.72b1753b-e859-4c7a-92db-9c7ece2226c3@github.com> On Fri, 19 Sep 2025 12:01:18 GMT, Daniel Fuchs wrote: >> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: >> >> - Merge remote-tracking branch 'upstream/master' into sendAsyncEx >> - Close ZIP file system at exit >> - Use scratch directory for `OfFileTest::DEFAULT_FS_DIR` >> - Update copyright year of `PullPublisher` >> - Fix `FileChannelPublisherTest` failures >> - Remove IOE rethrows >> - Revert `FilePublisherTest` and `FlowAdapterPublisherTest` changes >> - Make `CheckedIterable` throw exceptions >> - Merge remote-tracking branch 'upstream/master' into sendAsyncEx >> - Revert clean-up of redundant tests to keep PR focused >> - ... and 14 more: https://git.openjdk.org/jdk/compare/94a301a7...74dddad1 > > Latest changes LGTM @dfuch, @jaikiran, @liach, @wenshao, thanks so much for your patience and insightful reviews. `tier1,2` passes on several platforms using 74dddad1089. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26876#issuecomment-3311940500 From vyazici at openjdk.org Fri Sep 19 12:10:25 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 19 Sep 2025 12:10:25 GMT Subject: Integrated: 8367067: Improve exception handling in HttpRequest.BodyPublishers In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 09:43:47 GMT, Volkan Yazici wrote: > Improves exception handling of built-in `HttpClient.BodyPublisher`s to ensure exceptions get propagated in a way compliant with the reactive specification. This pull request has now been integrated. Changeset: 87d50425 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/87d50425fce3b76ecc03f087dbb81b86edeed1cd Stats: 1685 lines in 14 files changed: 1618 ins; 20 del; 47 mod 8367067: Improve exception handling in HttpRequest.BodyPublishers Reviewed-by: jpai, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/26876 From dfuchs at openjdk.org Fri Sep 19 12:12:01 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 19 Sep 2025 12:12:01 GMT Subject: RFR: 8368029: Several tests in httpserver/simpleserver should throw SkipException In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 10:07:01 GMT, Francesco Andreuzzi wrote: > I propose a change to have these tests listed appropriately as "skipped" rather than "passing" on Windows. I'm also taking the opportunity to save an indentation level since we can throw a `SkipException` early in all the related methods. LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27387#pullrequestreview-3244581500 From asmehra at openjdk.org Fri Sep 19 18:41:00 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 18:41:00 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v8] In-Reply-To: <5_ai8lG-Zs7B3xi8XQ0dnrr2TDmywRALaeN0uyqyUQ8=.18e3bfa2-9512-4173-8fc3-a83d827e7353@github.com> References: <5_ai8lG-Zs7B3xi8XQ0dnrr2TDmywRALaeN0uyqyUQ8=.18e3bfa2-9512-4173-8fc3-a83d827e7353@github.com> Message-ID: On Fri, 19 Sep 2025 01:41:34 GMT, Ioi Lam wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: >> >> - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes >> - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class >> - @ashu-mehra review comments >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - ... and 17 more: https://git.openjdk.org/jdk/compare/91a97943...04cb7a64 > > @ashu-mehra , I've remove all the code that was needed to handle aot-linked classes from the dynamic archive but is no longer needed since [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366). I am able to remove about 200 lines of code. > > I also renamed a few functions in `AOTLinkedClassBulkLoader` to reflect the up-to-date meaning. > > `CDSConfig::is_using_preloaded_classes()` has been removed and replaced with `CDSConfig::is_using_aot_linked_classes()` > > The handling of `fixup_mirror_list()` and `fixup_module_field_list()` in javaClasses.cpp have been made uniform. > > Please see https://github.com/openjdk/jdk/pull/26375/commits/896ce8b9636a5534f1db487afbe27e875022fbfa @iklam thank you for updating the changes. It is much easier to follow the code now. I have just one additional comment, otherwise looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26375#issuecomment-3313363526 From asmehra at openjdk.org Fri Sep 19 18:41:03 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 18:41:03 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v9] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 04:46:13 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed 32-bit builds src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 184: > 182: > 183: void AOTLinkedClassBulkLoader::link_or_init_javabase_classes(TRAPS) { > 184: link_or_init_classes_for_loader(Handle(), AOTLinkedClassTable::get()->boot1(), CHECK); Is exception check not needed here, like it is done in `link_or_init_non_javabase_classes()`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2364073186 From iklam at openjdk.org Sat Sep 20 00:57:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 20 Sep 2025 00:57:12 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v9] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 18:35:36 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed 32-bit builds > > src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 184: > >> 182: >> 183: void AOTLinkedClassBulkLoader::link_or_init_javabase_classes(TRAPS) { >> 184: link_or_init_classes_for_loader(Handle(), AOTLinkedClassTable::get()->boot1(), CHECK); > > Is exception check not needed here, like it is done in `link_or_init_non_javabase_classes()`? I changed this function to do the same check as in `link_or_init_non_javabase_classes()`. I also updated the comments to explain why this is necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2364925599 From iklam at openjdk.org Sat Sep 20 00:57:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 20 Sep 2025 00:57:09 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26375/files - new: https://git.openjdk.org/jdk/pull/26375/files/9ec10f5f..9072a1df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=08-09 Stats: 20 lines in 3 files changed: 14 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From duke at openjdk.org Sat Sep 20 06:25:15 2025 From: duke at openjdk.org (duke) Date: Sat, 20 Sep 2025 06:25:15 GMT Subject: RFR: 8368029: Several tests in httpserver/simpleserver should throw SkipException In-Reply-To: References: Message-ID: <-jl7lYJl2mZ2pbtxln5oOY76tog9bvIeFx5jUuRDxxk=.203467ef-2f37-497c-84e1-9eb925de66c9@github.com> On Fri, 19 Sep 2025 10:07:01 GMT, Francesco Andreuzzi wrote: > I propose a change to have these tests listed appropriately as "skipped" rather than "passing" on Windows. I'm also taking the opportunity to save an indentation level since we can throw a `SkipException` early in all the related methods. @fandreuz Your change (at version 842fdf8402c94760ca74550bcc520c1a4564e170) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27387#issuecomment-3314628206 From fandreuzzi at openjdk.org Sat Sep 20 06:51:24 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Sat, 20 Sep 2025 06:51:24 GMT Subject: Integrated: 8368029: Several tests in httpserver/simpleserver should throw SkipException In-Reply-To: References: Message-ID: <_1IG2Ei35ONm7PalsgeDSCfbnHdAtVTEiNTwGWAybVs=.9a85fdf4-e251-47db-b6d7-15b6d926af9d@github.com> On Fri, 19 Sep 2025 10:07:01 GMT, Francesco Andreuzzi wrote: > I propose a change to have these tests listed appropriately as "skipped" rather than "passing" on Windows. I'm also taking the opportunity to save an indentation level since we can throw a `SkipException` early in all the related methods. This pull request has now been integrated. Changeset: 5a684e31 Author: Francesco Andreuzzi Committer: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/5a684e3196593c4d44ee35f7624246fc461b4af6 Stats: 120 lines in 2 files changed: 12 ins; 4 del; 104 mod 8368029: Several tests in httpserver/simpleserver should throw SkipException Reviewed-by: djelinski, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/27387 From alan.bateman at oracle.com Sun Sep 21 07:20:30 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Sun, 21 Sep 2025 08:20:30 +0100 Subject: InetAddress.isReachable fix ETA In-Reply-To: References: Message-ID: <4013655b-21df-4dbc-8b6a-f929005b6ccc@oracle.com> On 20/09/2025 15:24, Yuval Lombard wrote: > Hello team, > > Is there an estimated time/jdk release for fixing the InetAddress > isReachable issue? > net-dev would be a better replace to discuss this.? As I mentioned in JDK-8357160 [1], I think it would be useful to know if it common for deployments to have CAP_NET_RAW/equivalent or whether the TCP implementation is more commonly used. If the TCP implementation were to re-written in Java (not hard) then it would be "virtual thread friendly" in the sense that waiting for SYN-ACK would release the carrier to do other work. -Alan [1] https://bugs.openjdk.org/browse/JDK-8357160 From dfuchs at openjdk.org Sun Sep 21 09:10:54 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Sun, 21 Sep 2025 09:10:54 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v19] 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 661 commits: - http3: add null check in SSLAlgorithmConstraints::forQUIC - merge latest changes from master branch - merge latest changes from master branch - merge latest changes from master branch - http3: CSR review feedback - merge latest changes from master branch - modify http3 test timeouts - qpack - take knownReceivedCount into account during DT entries eviction - merge latest changes from master branch - http3: fix at since - ... and 651 more: https://git.openjdk.org/jdk/compare/54206943...797d797c ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=18 Stats: 105840 lines in 474 files changed: 103005 ins; 1337 del; 1498 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 jpai at openjdk.org Sun Sep 21 09:43:39 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 21 Sep 2025 09:43:39 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v19] In-Reply-To: References: Message-ID: On Sun, 21 Sep 2025 09:10:54 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 661 commits: > > - http3: add null check in SSLAlgorithmConstraints::forQUIC > - merge latest changes from master branch > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - ... and 651 more: https://git.openjdk.org/jdk/compare/54206943...797d797c The updates look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3249956734 From aefimov at openjdk.org Sun Sep 21 09:57:38 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Sun, 21 Sep 2025 09:57:38 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v19] In-Reply-To: References: Message-ID: On Sun, 21 Sep 2025 09:10:54 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 661 commits: > > - http3: add null check in SSLAlgorithmConstraints::forQUIC > - merge latest changes from master branch > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - ... and 651 more: https://git.openjdk.org/jdk/compare/54206943...797d797c Marked as reviewed by aefimov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3249960698 From djelinski at openjdk.org Mon Sep 22 07:24:06 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 22 Sep 2025 07:24:06 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v19] In-Reply-To: References: Message-ID: On Sun, 21 Sep 2025 09:10:54 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 661 commits: > > - http3: add null check in SSLAlgorithmConstraints::forQUIC > - merge latest changes from master branch > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - ... and 651 more: https://git.openjdk.org/jdk/compare/54206943...797d797c Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3250922345 From vyazici at openjdk.org Mon Sep 22 08:12:22 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 22 Sep 2025 08:12:22 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 10:44:36 GMT, Mahendra Chhipa wrote: > Refactoring following httpclient/http2 testng test to JUnit : > test/jdk/java/net/httpclient/http2/BadHeadersTest.java > test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java > test/jdk/java/net/httpclient/http2/BasicTest.java > test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java > test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java @mahendrachhipa, would you mind confirming that `tier1,2` pass, please? test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 88: > 86: ); > 87: > 88: SSLContext sslContext; These can be `private` for better encapsulation. test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 145: > 143: Arguments.of(http2URI, true, byteAtATime), > 144: Arguments.of(https2URI, true, byteAtATime) > 145: ); AFAICT, you don't need to return a `Stream`, the old `Object[][]` should suffice. Maybe that is better to revert this to old style to keep the diff minimal ? granted `Object[][]` indeed works with JUnit. test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 247: > 245: > 246: @BeforeAll > 247: public static void setup() throws Exception { `setup()` and `teardown()` can be package-private. Note that this comment applies to all `@AfterAll`- and `@BeforeAll`-annotated methods also present in other touched files. test/jdk/java/net/httpclient/http2/BasicTest.java line 129: > 127: > 128: @Test > 129: public void test() throws Exception { `@[Parameterized]Test`-annotated methods can be package-private. test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java line 83: > 81: static HttpTestServer https2TestServer; // HTTP/2 ( h2 ) > 82: static String http2URI; > 83: static String https2URI; These can be `private`. test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java line 90: > 88: Arguments.of(http2URI), > 89: Arguments.of(https2URI) > 90: ); You can use `Object[][]`. test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java line 82: > 80: static String noBodyhttp2URI; > 81: static String noBodyhttps2URI; > 82: final static ReferenceTracker TRACKER = ReferenceTracker.INSTANCE; These can be `private`. test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java line 137: > 135: }; > 136: > 137: static Stream variants() { This can be `Object[][]`. ------------- Changes requested by vyazici (Committer). PR Review: https://git.openjdk.org/jdk/pull/27388#pullrequestreview-3251038574 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2367030229 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2367041647 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2367032448 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2367043354 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2367045449 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2367045017 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2367060462 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2367061035 From dfuchs at openjdk.org Mon Sep 22 10:16:00 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 22 Sep 2025 10:16:00 GMT Subject: Integrated: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 13:05:24 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. This pull request has now been integrated. Changeset: e8db14f5 Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/e8db14f584fa92db170e056bc68074ccabae82c9 Stats: 105840 lines in 474 files changed: 103005 ins; 1337 del; 1498 mod 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API Co-authored-by: Aleksei Efimov Co-authored-by: Bradford Wetmore Co-authored-by: Daniel Jeli?ski Co-authored-by: Darragh Clarke Co-authored-by: Jaikiran Pai Co-authored-by: Michael McMahon Co-authored-by: Volkan Yazici Co-authored-by: Conor Cleary Co-authored-by: Patrick Concannon Co-authored-by: Rahul Yadav Co-authored-by: Daniel Fuchs Reviewed-by: djelinski, jpai, aefimov, abarashev, michaelm ------------- PR: https://git.openjdk.org/jdk/pull/24751 From vyazici at openjdk.org Mon Sep 22 11:15:37 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 22 Sep 2025 11:15:37 GMT Subject: RFR: 8367068: Remove redundant HttpRequest.BodyPublisher tests Message-ID: Remove `HttpRequest.BodyPublisher` tests rendered redundant by [JDK-8367067] (#26876). [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 ------------- Commit messages: - Remove redundant tests Changes: https://git.openjdk.org/jdk/pull/27421/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27421&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367068 Stats: 461 lines in 7 files changed: 134 ins; 325 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27421.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27421/head:pull/27421 PR: https://git.openjdk.org/jdk/pull/27421 From vyazici at openjdk.org Mon Sep 22 11:15:42 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 22 Sep 2025 11:15:42 GMT Subject: RFR: 8367068: Remove redundant HttpRequest.BodyPublisher tests In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 10:12:28 GMT, Volkan Yazici wrote: > Remove `HttpRequest.BodyPublisher` tests rendered redundant by [JDK-8367067] (#26876). > > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 test/jdk/java/net/httpclient/FilePublisherTest.java line 160: > 158: > 159: @Test > 160: public void testFileNotFound() throws Exception { Duplicates [OfFileTest::testNonExistentPath]. [OfFileTest::testNonExistentPath]: https://github.com/openjdk/jdk/blob/e8db14f584fa92db170e056bc68074ccabae82c9/test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfFileTest.java#L97 test/jdk/java/net/httpclient/FlowAdapterPublisherTest.java line 110: > 108: private HttpClient newHttpClient(String uri) { > 109: var version = Optional.ofNullable(version(uri)); > 110: var builder = version.isEmpty() || version.get() != Version.HTTP_3 Duplicates [FromPublisherTest]. [FromPublisherTest]: https://github.com/openjdk/jdk/blob/e8db14f584fa92db170e056bc68074ccabae82c9/test/jdk/java/net/httpclient/HttpRequestBodyPublishers/FromPublisherTest.java test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfByteArraysTest.java line 47: > 45: /* > 46: * @test > 47: * @bug 8226303 8364733 Copied 8226303 from `RelayingPublishers` to preserve the association. test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfFileTest.java line 52: > 50: /* > 51: * @test > 52: * @bug 8226303 8235459 8358688 8364733 Copied 8226303 and 8358688 from `RelayingPublishers`, and 8235459 from `FilePublisherTest` to preserve the association. test/jdk/java/net/httpclient/RelayingPublishers.java line 52: > 50: > 51: @Test > 52: public void ofFile0() throws IOException { Duplicates [OfFileTest::testIrregularFile]. [OfFileTest::testIrregularFile]: https://github.com/openjdk/jdk/blob/e8db14f584fa92db170e056bc68074ccabae82c9/test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfFileTest.java#L131C10-L131C27 test/jdk/java/net/httpclient/RelayingPublishers.java line 66: > 64: > 65: @Test > 66: public void ofFile1() throws IOException { Duplicates [OfFileTest::testNonExistentPath]. [OfFileTest::testNonExistentPath]: https://github.com/openjdk/jdk/blob/e8db14f584fa92db170e056bc68074ccabae82c9/test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfFileTest.java#L97C10-L97C29 test/jdk/java/net/httpclient/RelayingPublishers.java line 76: > 74: > 75: @Test > 76: public void ofByteArrays() { Duplicates [OfByteArraysTest::testNullArray]. [OfByteArraysTest::testNullArray]: https://github.com/openjdk/jdk/blob/e8db14f584fa92db170e056bc68074ccabae82c9/test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfByteArraysTest.java#L136C10-L136C23 test/jdk/java/net/httpclient/SubscriberAPIExceptions.java line 1: > 1: /* Duplicates [HttpRequestBodyPublishers/*Test]. [HttpRequestBodyPublishers/*Test]: https://github.com/openjdk/jdk/tree/e8db14f584fa92db170e056bc68074ccabae82c9/test/jdk/java/net/httpclient/HttpRequestBodyPublishers ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27421#discussion_r2367460633 PR Review Comment: https://git.openjdk.org/jdk/pull/27421#discussion_r2367577590 PR Review Comment: https://git.openjdk.org/jdk/pull/27421#discussion_r2367678247 PR Review Comment: https://git.openjdk.org/jdk/pull/27421#discussion_r2367690928 PR Review Comment: https://git.openjdk.org/jdk/pull/27421#discussion_r2367606889 PR Review Comment: https://git.openjdk.org/jdk/pull/27421#discussion_r2367609281 PR Review Comment: https://git.openjdk.org/jdk/pull/27421#discussion_r2367627229 PR Review Comment: https://git.openjdk.org/jdk/pull/27421#discussion_r2367616967 From mbaesken at openjdk.org Mon Sep 22 12:45:40 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 22 Sep 2025 12:45:40 GMT Subject: RFR: 8368273: LIBPTHREAD dependency is not needed for some jdk libs Message-ID: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com> A couple of JDK native libs link to $(LIBPTHREAD) but the dependency is not needed. libsctp has no `pthread*` calls so most likely we can omit $(LIBPTHREAD). libawt_xawt only uses `pthread_self()` ; so on Linux it links without adding $(LIBPTHREAD) because it then uses `pthread_self() `from glibc; however it might still be better to link $(LIBPTHREAD) in this special case. ------------- Commit messages: - JDK-8368273 Changes: https://git.openjdk.org/jdk/pull/27426/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27426&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368273 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27426.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27426/head:pull/27426 PR: https://git.openjdk.org/jdk/pull/27426 From dfuchs at openjdk.org Mon Sep 22 13:30:32 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 22 Sep 2025 13:30:32 GMT Subject: RFR: 8367068: Remove redundant HttpRequest.BodyPublisher tests In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 10:18:30 GMT, Volkan Yazici wrote: >> Remove `HttpRequest.BodyPublisher` tests rendered redundant by [JDK-8367067] (#26876). >> >> [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 > > test/jdk/java/net/httpclient/FilePublisherTest.java line 160: > >> 158: >> 159: @Test >> 160: public void testFileNotFound() throws Exception { > > Duplicates [OfFileTest::testNonExistentPath]. > > [OfFileTest::testNonExistentPath]: https://github.com/openjdk/jdk/blob/e8db14f584fa92db170e056bc68074ccabae82c9/test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfFileTest.java#L97 The original test was also testing with a Path coming from a non-default filesystem (ZipFs) - does the new test still have that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27421#discussion_r2368372643 From dfuchs at openjdk.org Mon Sep 22 14:52:40 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 22 Sep 2025 14:52:40 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 07:55:22 GMT, Volkan Yazici wrote: >> Refactoring following httpclient/http2 testng test to JUnit : >> test/jdk/java/net/httpclient/http2/BadHeadersTest.java >> test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java >> test/jdk/java/net/httpclient/http2/BasicTest.java >> test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java >> test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java > > test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 88: > >> 86: ); >> 87: >> 88: SSLContext sslContext; > > These can be `private` for better encapsulation. Agreed - though that doesn't really matter here. We're changing those line anayway to make the fields static - so yes - we can make them private. > test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 145: > >> 143: Arguments.of(http2URI, true, byteAtATime), >> 144: Arguments.of(https2URI, true, byteAtATime) >> 145: ); > > AFAICT, you don't need to return a `Stream`, the old `Object[][]` should suffice. Maybe that is better to revert this to old style to keep the diff minimal ? granted `Object[][]` indeed works with JUnit. If this was a new tests then IMO using `Arguments.of(...)` would be preferable. Since this is an old test then arguably keeping the old Object[][] could make backports easier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2368693907 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2368703123 From dfuchs at openjdk.org Mon Sep 22 14:52:43 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 22 Sep 2025 14:52:43 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 10:44:36 GMT, Mahendra Chhipa wrote: > Refactoring following httpclient/http2 testng test to JUnit : > test/jdk/java/net/httpclient/http2/BadHeadersTest.java > test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java > test/jdk/java/net/httpclient/http2/BasicTest.java > test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java > test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java line 75: > 73: import org.junit.jupiter.params.provider.MethodSource; > 74: > 75: import static org.junit.jupiter.api.Assertions.*; This test uses `assertEquals` and `assertNotEquals`. Unless I'm mistaken, the parameters order are reversed in JUnit compared to TestNG. That is, one has (expected, actual), the other has (actual, expected). Unless there was already a mistake in the original code, you should also reverse the parameters order at the call sites of `assertEquals`/`assertNotEquals`. Otherwise, the text message of any `AssertionError` thrown by these will be confusing. test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java line 265: > 263: > 264: http2TestServerLocal.start(); > 265: https2TestServerLocal.start(); I believe you should revert these changes or make sure they result in exactly the same calls. For instance - `http2TestServerLocal.start();` is not exactly the same as `this.http2TestServer.start();` - the original code was calling start() on the wrapper, and IMO it's better to continue doing that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2368766736 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2368799614 From duke at openjdk.org Mon Sep 22 18:24:05 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 22 Sep 2025 18:24:05 GMT Subject: RFR: 8347167: Implementation in com.sun.net.httpserver.Headers.normalize() can be improved Message-ID: Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized. ------------- Commit messages: - formatting - Optimize header normalization Changes: https://git.openjdk.org/jdk/pull/27276/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27276&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347167 Stats: 30 lines in 2 files changed: 22 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27276.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27276/head:pull/27276 PR: https://git.openjdk.org/jdk/pull/27276 From aturbanov at openjdk.org Mon Sep 22 18:24:08 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 22 Sep 2025 18:24:08 GMT Subject: RFR: 8347167: Implementation in com.sun.net.httpserver.Headers.normalize() can be improved In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 02:50:27 GMT, Josiah Noel wrote: > Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized. src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 126: > 124: if (c == '\r' || c == '\n') > 125: throw new IllegalArgumentException("illegal character in key"); > 126: if(c >= 'a' && c <= 'z') { Suggestion: if (c >= 'a' && c <= 'z') { src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 130: > 128: } else { > 129: i++; > 130: for(; i < len; i++) { Suggestion: for (; i < len; i++) { src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 139: > 137: } > 138: } > 139: if(i == len) return key; Suggestion: if (i == len) return key; src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 142: > 140: > 141: char[] b = key.toCharArray(); > 142: if(i == 0) { Suggestion: if (i == 0) { src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 148: > 146: for (; i < len; i++) { > 147: c = b[i]; > 148: if(c >= 'A' && c <= 'Z') { Suggestion: if (c >= 'A' && c <= 'Z') { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2355652408 PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2355653084 PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2355653399 PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2355653593 PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2355653920 From duke at openjdk.org Mon Sep 22 18:24:16 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 22 Sep 2025 18:24:16 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 Message-ID: Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. - Adds a new flag checking if the incoming request is an upgrade request. - When receiving an upgrade request, directly return the input/output stream - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. - sentHeaders will not be set to true when sending 1xx status codes ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8349670 - Update InputRead1xxTest.java - Update InputRead1xxTest.java - support all 1xx - Create InputRead101Test.java - Send interim responses for 101 upgrade requests Changes: https://git.openjdk.org/jdk/pull/27069/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349670 Stats: 317 lines in 2 files changed: 293 ins; 0 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From duke at openjdk.org Mon Sep 22 18:24:16 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 22 Sep 2025 18:24:16 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 12:06:45 GMT, Josiah Noel wrote: > Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. > > - Adds a new flag checking if the incoming request is an upgrade request. > - When receiving an upgrade request, directly return the input/output stream > - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. > - sentHeaders will not be set to true when sending 1xx status codes It turns out I had previously signed the OCA but forgot to put my GH username on it. Edit: no wait my OCA does have my GH username on it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3255936539 From vyazici at openjdk.org Mon Sep 22 19:11:47 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 22 Sep 2025 19:11:47 GMT Subject: RFR: 8367068: Remove redundant HttpRequest.BodyPublisher tests In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 13:21:26 GMT, Daniel Fuchs wrote: >> test/jdk/java/net/httpclient/FilePublisherTest.java line 160: >> >>> 158: >>> 159: @Test >>> 160: public void testFileNotFound() throws Exception { >> >> Duplicates [OfFileTest::testNonExistentPath]. >> >> [OfFileTest::testNonExistentPath]: https://github.com/openjdk/jdk/blob/e8db14f584fa92db170e056bc68074ccabae82c9/test/jdk/java/net/httpclient/HttpRequestBodyPublishers/OfFileTest.java#L97 > > The original test was also testing with a Path coming from a non-default filesystem (ZipFs) - does the new test still have that? Very sharp of you @dfuch! Yes, it does. See the `@MethodSource("parentDirs")` annotation above the test method, where `parentDirs` is a list composed of 1. a default file system directory, and 2. a ZIP file system directory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27421#discussion_r2369936453 From vyazici at openjdk.org Mon Sep 22 19:16:59 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 22 Sep 2025 19:16:59 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 14:46:25 GMT, Daniel Fuchs wrote: > I believe you should revert these changes @dfuch, IMHO, the changes are (partially) necessary since the associated _instance_ variables are switched to _class_ variables, and `this.`-prefixing and variable shadowing do not work anymore. That said, I agree with your suggestion that changes should be minimal and functionally equivalent to the old ones. > the original code was calling start() on the wrapper, and IMO it's better to continue doing that. Agreed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2369962913 From asmehra at openjdk.org Mon Sep 22 19:30:40 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 22 Sep 2025 19:30:40 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 00:57:09 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/26375#pullrequestreview-3254807664 From kvn at openjdk.org Tue Sep 23 02:05:15 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Sep 2025 02:05:15 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 00:57:09 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() Few comments. src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 60: > 58: // Preloading requires that the Java heap objects of java.lang.Class, java.lang.Package and > 59: // java.security.ProtectionDomain already exist for the preloaded classes. Therefore, we support preloading > 60: // only for the classes in the static CDS archive. Classes in the dynamic archive are not supported because "for the classes in the static CDS archive"? Do you mean "AOT cache"? Or this feature also works for old static CDS archive? src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 97: > 95: } > 96: > 97: ClassLoaderData* loader_data = ClassLoaderData::class_loader_data(loader()); `loader_data` is not used in this method. src/hotspot/share/cds/aotLinkedClassBulkLoader.hpp line 52: > 50: // > 51: // [2] load_javabase_classes() and load_non_javabase_classes(): > 52: // This happens after some Java code is executed, to load aot-linked classes in the dynamic archive. Previous comment say that dynamic archive is not supported. src/hotspot/share/cds/aotLinkedClassTable.hpp line 45: > 43: > 44: Array* _boot1; // boot classes in java.base module > 45: Array* _boot2; // boot classes in all other (named and unnamed) modules Do you mean JDK's modules or user's modules too? ------------- PR Review: https://git.openjdk.org/jdk/pull/26375#pullrequestreview-3255743679 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370759818 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370778138 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370797359 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370798743 From kvn at openjdk.org Tue Sep 23 02:05:16 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Sep 2025 02:05:16 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: <5Tw9z22Y6nsL7pGxDqShTXtMBnaaoWUAG1AjXOhUL2s=.104e2915-21b3-4474-8a12-2b4f435d268b@github.com> On Tue, 23 Sep 2025 01:18:29 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() > > src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 60: > >> 58: // Preloading requires that the Java heap objects of java.lang.Class, java.lang.Package and >> 59: // java.security.ProtectionDomain already exist for the preloaded classes. Therefore, we support preloading >> 60: // only for the classes in the static CDS archive. Classes in the dynamic archive are not supported because > > "for the classes in the static CDS archive"? Do you mean "AOT cache"? Or this feature also works for old static CDS archive? I see `precond(CDSConfig::is_using_aot_linked_classes())` on following cod. Which means it only works for AOT cache. Please update comment to avoid confusion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370761057 From iklam at openjdk.org Tue Sep 23 03:24:28 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 03:24:28 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v11] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - @vnkozlov review comments - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() - Fixed 32-bit builds - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class - @ashu-mehra review comments - ... and 21 more: https://git.openjdk.org/jdk/compare/61c5245b...bd08a0b5 ------------- Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=10 Stats: 941 lines in 43 files changed: 534 ins; 236 del; 171 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Tue Sep 23 03:24:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 03:24:30 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: <5Tw9z22Y6nsL7pGxDqShTXtMBnaaoWUAG1AjXOhUL2s=.104e2915-21b3-4474-8a12-2b4f435d268b@github.com> References: <5Tw9z22Y6nsL7pGxDqShTXtMBnaaoWUAG1AjXOhUL2s=.104e2915-21b3-4474-8a12-2b4f435d268b@github.com> Message-ID: On Tue, 23 Sep 2025 01:19:59 GMT, Vladimir Kozlov wrote: >> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 60: >> >>> 58: // Preloading requires that the Java heap objects of java.lang.Class, java.lang.Package and >>> 59: // java.security.ProtectionDomain already exist for the preloaded classes. Therefore, we support preloading >>> 60: // only for the classes in the static CDS archive. Classes in the dynamic archive are not supported because >> >> "for the classes in the static CDS archive"? Do you mean "AOT cache"? Or this feature also works for old static CDS archive? > > I see `precond(CDSConfig::is_using_aot_linked_classes())` on following cod. Which means it only works for AOT cache. Please update comment to avoid confusion. AOTClassLinking for the dynamic archive has been removed in [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366). Currently, AOT-linked classes are supported for both the static archive and AOT cache. I've updated the comments to reflect that. We probably should remove AOTClassLinking from static CDS archive as well. I've created [JDK-8368350](https://bugs.openjdk.org/browse/JDK-8368350) for that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370946875 From iklam at openjdk.org Tue Sep 23 03:24:34 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 03:24:34 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 01:29:00 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() > > src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 97: > >> 95: } >> 96: >> 97: ClassLoaderData* loader_data = ClassLoaderData::class_loader_data(loader()); > > `loader_data` is not used in this method. Removed. > src/hotspot/share/cds/aotLinkedClassBulkLoader.hpp line 52: > >> 50: // >> 51: // [2] load_javabase_classes() and load_non_javabase_classes(): >> 52: // This happens after some Java code is executed, to load aot-linked classes in the dynamic archive. > > Previous comment say that dynamic archive is not supported. That comment was written before AOTClassLinking was removed from dynamic archive. I have removed it. I also added a comment about the new `link_or_init_xxx()` functions added in this PR. > src/hotspot/share/cds/aotLinkedClassTable.hpp line 45: > >> 43: >> 44: Array* _boot1; // boot classes in java.base module >> 45: Array* _boot2; // boot classes in all other (named and unnamed) modules > > Do you mean JDK's modules or user's modules too? Currently it's not possible to use `--module-path` to add user modules to the boot loader, so the only kind of user classes that can be loaded in `boot2` are the ones from `-Xbootclasspath/a`, which are loaded from the unnamed module. I updated the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370946983 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370947364 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370948225 From syan at openjdk.org Tue Sep 23 08:13:10 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 23 Sep 2025 08:13:10 GMT Subject: RFR: 8368373: Test H3MalformedResponseTest.testMalformedResponse intermittent timed out Message-ID: Hi all, The sub-test H3MalformedResponseTest.testMalformedResponse in test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java intermittent report java.util.concurrent.TimeoutException, espicial when this test run with other jtreg tests simultancely. This PR change the timeout vaule from 10 to 30 to make test run passed steady. ------------- Commit messages: - 8368373: Test java/net/httpclient/http3/H3MalformedResponseTest.java intermittent fails Changes: https://git.openjdk.org/jdk/pull/27447/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27447&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368373 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27447.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27447/head:pull/27447 PR: https://git.openjdk.org/jdk/pull/27447 From vyazici at openjdk.org Tue Sep 23 08:31:12 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 23 Sep 2025 08:31:12 GMT Subject: RFR: 8368373: Test H3MalformedResponseTest.testMalformedResponse intermittent timed out In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 08:05:42 GMT, SendaoYan wrote: > Hi all, > > The sub-test H3MalformedResponseTest.testMalformedResponse in test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java intermittent report java.util.concurrent.TimeoutException, espicial when this test run with other jtreg tests simultancely. This PR change the timeout vaule from 10 to 30 to make test run passed steady. test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java line 371: > 369: request, > 370: BodyHandlers.discarding()) > 371: .get(30, TimeUnit.SECONDS); @dfuch, @jaikiran, can we replace this with a simple `get()` and rely on JTreg's default timeout settings? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27447#discussion_r2371562116 From djelinski at openjdk.org Tue Sep 23 09:26:47 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 23 Sep 2025 09:26:47 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 22:05:33 GMT, Josiah Noel wrote: >> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. >> >> - Adds a new flag checking if the incoming request is an upgrade request. >> - When receiving an upgrade request, directly return the input/output stream >> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. >> - sentHeaders will not be set to true when sending 1xx status codes > > It turns out I had previously signed the OCA but forgot to put my GH username on it. > > Edit: no wait my OCA does have my GH username on it? Hi @SentryMan, thanks for contributing! The informational response handling looks good, but the upgrades need to be handled differently. If we start treating every request with an `Upgrade` header as an upgrade, we will invalidate pretty much every existing application that uses the httpserver. We need a check that the application understands the semantics of the `Upgrade` header before we proceed with the upgrade. Both uses of the `Upgrade` header (WebSockets and HTTP/2 upgrade) provide means for the server to accept or reject the upgrade. In both cases the server is required to send a `101 Switching protocols` response, any other response means that the server decided to keep using HTTP 1.1. The second issue is resource handling. The server keeps a list of all active connections and exchanges. The existing OutputStream classes like `UndefLengthOutputStream` notify the server when the exchange finishes, permitting it to close the exchange and remove the connection from the active connection list as needed. Here you give the raw input/output streams to the user; the raw streams do not notify the server, so the server's bookkeeping will be incorrect. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3323119186 From geliang at kernel.org Tue Sep 23 09:34:52 2025 From: geliang at kernel.org (Geliang Tang) Date: Tue, 23 Sep 2025 17:34:52 +0800 Subject: Add Extended MPTCP (Multipath TCP) Socket Option Support to OpenJDK Message-ID: <69f2513f5d13b65aeb3fd23c9fcc6dc410968466.camel@kernel.org> Dear OpenJDK Maintainers, We are writing to propose the integration of Multipath TCP (MPTCP) support into OpenJDK. In response to Alan's feedback in earlier discussions [1], we have developed a Java-based implementation that utilizes the setOption method to enable MPTCP before binding or connecting a socket, as illustrated below: Socket c = new Socket(); c.setOption(ExtendedSocketOptions.TCP_MPTCPIFY, true); c.connect(new InetSocketAddress(loop.getHostAddress(), port)); The name 'TCP_MPTCPIFY' was chosen to align with 'mptcpize' tool in mptcpd and 'mptcpify' in BCC. The complete implementation can be found in [2]. This email outlines the technical background and aims to facilitate further discussion on the proposed approach. 1. Use Cases and Performance Benefits MPTCP extends standard TCP (as defined in RFC 8684) by allowing the use of multiple paths simultaneously, offering significant advantages: Seamless handover: Maintain active connections during network transitions (e.g., as implemented in Apple smartphones since 2013). Optimized path selection: Dynamically route traffic based on latency, cost, bandwidth, and other metrics. Bandwidth aggregation: Combine links (e.g., Wi-Fi and cellular) to increase total throughput. Our immediate motivation for introducing MPTCP support in Java is to enable MPTCP capabilities in valkey-java [3]. Valkey - a Redis- compatible key-value database - officially incorporated MPTCP support in its 9.0.0-rc1 release, which reduced latency by approximately 25% under 1% packet loss conditions (see PR [4]). While the Valkey server (written in C) uses MPTCP natively via the socket() API, most Java clients (including valkey-java) currently lack built-in MPTCP support. As multi-NIC systems become increasingly common, providing Java applications with native MPTCP support is essential for enhancing network performance and reliability. 2. Application Compatibility A number of applications already support MPTCP natively, as documented on?https://www.mptcp.dev/apps.html, including Apache, FreeNginx, and QEmu. In response to Alan's earlier question regarding enabling MPTCP without modifying applications: the MPTCP community does provide tools such as mptcpize and BCC (mptcpify) to enable MPTCP at the socket level system- wide - for example: $ mptcpize run java app.jar However, this method lacks fine-grained control, which becomes problematic when a Java application must use MPTCP and TCP simultaneously - such as one that connects to both Valkey and MySQL. Given this limitation, enabling MPTCP explicitly within the application code remains the most practical and controlled approach, consistent with early MPTCP adoption strategies. 3. Testing We would also like to initiate a discussion on testing strategies and API documentation for this feature. In [2], we have included a basic MPTCP test. Should this MPTCP implementation be accepted into OpenJDK, we are prepared to develop and maintain corresponding jtreg test cases within the OpenJDK test framework to ensure interface stability. If needed, we - the MPTCP upstream developers - commit to validating this feature in each future OpenJDK release. We welcome alternative ideas or suggestions on this topic and are open to further discussion. Your feedback on this proposal is highly appreciated. Best regards, MPTCP Upstream Developers References [1] https://mail.openjdk.org/pipermail/net-dev/2025-September/027969.html [2] https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master [3] https://github.com/valkey-io/valkey-java [4] https://github.com/valkey-io/valkey/pull/1811 From geliang at kernel.org Tue Sep 23 09:55:15 2025 From: geliang at kernel.org (Geliang Tang) Date: Tue, 23 Sep 2025 17:55:15 +0800 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: <2b699d6c-d05b-4445-9448-99348eebdf4a@oracle.com> References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> <2b699d6c-d05b-4445-9448-99348eebdf4a@oracle.com> Message-ID: <2baf027907da32f096cb522691e5d92c454000e4.camel@kernel.org> Hi Alan, Thanks for your reply. On Thu, 2025-09-18 at 12:30 +0100, Alan Bateman wrote: > ? > On 18/09/2025 08:36, Geliang Tang wrote: > ? > > ? > > I have completed the implementation. Thanks to Xiang Gao and Gang > > Yan > > for their help. I added a new option named TCP_MPTCPIFY in > > jdk.net.ExtendedSocketOptions (the name was chosen to align with > > 'mptcpize' tool in mptcpd and 'mptcpify' in BCC). When this option > > is > > set, it calls the JNI function mptcpify0. > > > > Following your suggestion, mptcpify0 is implemented by referencing > > Java_sun_net_sdp_SdpSupport_convert0. It creates a new MPTCP > > socket, > > uses dup2 to duplicate it, and then closes the redundant socket. > > > > I have added your tag in the patch: > > > > Suggested-by: Alan Bateman > > > > I also included a test example for this option. All modifications > > can > > be found here: > > > > https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master > > > > Please provide any feedback or suggestions. As for the next steps, > > should I create a new issue for this feature and submit a proper > > pull > > request? > > ? > ? > ?Thanks for confirming that the direction suggested works. This at > least demonstrates a feasible direction that does not impact the > standard API. > ? > ?As regards next steps then I think start a thread on net-dev to try > to get input. I think it would be useful to show potential scenarios > where it would be useful and what performance benefits might come > from it. I think also useful to talk about whether this is something > that an application has to opt into, maybe there are other > configuration approaches that would not require application changes? > ? > ?I think it would be useful to discuss testing. If this feature were > integrated into the JDK then how would it be tested? Who would test > and maintain it? There is a JDK release every 6 months, is someone > going test it with each release? > ? > ?If it goes ahead then there the name of the extended socket option > and its API docs will need discussion. Details around state will need > to be specified, would it be supported to set TCP_MPTCP when bound or > connected, does it make sense to ever attempt to set it to false > after setting it to true (these are just examples of the details that > will need to be specified, they are not important right now). Following your suggestion, I have started a new thread on net-dev: Add Extended MPTCP (Multipath TCP) Socket Option Support to OpenJDK https://mail.openjdk.org/pipermail/net-dev/2025-September/028085.html Thanks, -Geliang > ? > ?-Alan. > ? > ? From alan.bateman at oracle.com Tue Sep 23 11:09:58 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Tue, 23 Sep 2025 12:09:58 +0100 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: <2baf027907da32f096cb522691e5d92c454000e4.camel@kernel.org> References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> <2b699d6c-d05b-4445-9448-99348eebdf4a@oracle.com> <2baf027907da32f096cb522691e5d92c454000e4.camel@kernel.org> Message-ID: <452654a0-d835-4934-9fd2-8218f63bb5e1@oracle.com> On 23/09/2025 10:55, Geliang Tang wrote: > Following your suggestion, I have started a new thread on net-dev: > > Add Extended MPTCP (Multipath TCP) Socket Option Support to OpenJDK > https://mail.openjdk.org/pipermail/net-dev/2025-September/028085.html > Thanks, let's continue the discussion there. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski at openjdk.org Tue Sep 23 12:16:40 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 23 Sep 2025 12:16:40 GMT Subject: RFR: 8368373: Test H3MalformedResponseTest.testMalformedResponse intermittent timed out In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 08:05:42 GMT, SendaoYan wrote: > Hi all, > > The sub-test H3MalformedResponseTest.testMalformedResponse in test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java intermittent report java.util.concurrent.TimeoutException, espicial when this test run with other jtreg tests simultancely. This PR change the timeout vaule from 10 to 30 to make test run passed steady. Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27447#pullrequestreview-3257693952 From djelinski at openjdk.org Tue Sep 23 12:16:42 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 23 Sep 2025 12:16:42 GMT Subject: RFR: 8368373: Test H3MalformedResponseTest.testMalformedResponse intermittent timed out In-Reply-To: References: Message-ID: <31hNf5hPnSYu2Jm1tKCQa_Lm1ymCSARvIzorOymxW70=.08aa6e47-0a2f-4f17-b530-07184ea0db6e@github.com> On Tue, 23 Sep 2025 08:27:39 GMT, Volkan Yazici wrote: >> Hi all, >> >> The sub-test H3MalformedResponseTest.testMalformedResponse in test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java intermittent report java.util.concurrent.TimeoutException, espicial when this test run with other jtreg tests simultancely. This PR change the timeout vaule from 10 to 30 to make test run passed steady. > > test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java line 371: > >> 369: request, >> 370: BodyHandlers.discarding()) >> 371: .get(30, TimeUnit.SECONDS); > > @dfuch, @jaikiran, can we replace this with a simple `get()` and rely on JTreg's default timeout settings? we probably could. This test should work equally well with a `send` instead of `sendAsync` too. But the proposed change is good enough for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27447#discussion_r2372114756 From dfuchs at openjdk.org Tue Sep 23 13:37:27 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 23 Sep 2025 13:37:27 GMT Subject: RFR: 8368373: Test H3MalformedResponseTest.testMalformedResponse intermittent timed out In-Reply-To: <31hNf5hPnSYu2Jm1tKCQa_Lm1ymCSARvIzorOymxW70=.08aa6e47-0a2f-4f17-b530-07184ea0db6e@github.com> References: <31hNf5hPnSYu2Jm1tKCQa_Lm1ymCSARvIzorOymxW70=.08aa6e47-0a2f-4f17-b530-07184ea0db6e@github.com> Message-ID: On Tue, 23 Sep 2025 12:13:37 GMT, Daniel Jeli?ski wrote: >> test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java line 371: >> >>> 369: request, >>> 370: BodyHandlers.discarding()) >>> 371: .get(30, TimeUnit.SECONDS); >> >> @dfuch, @jaikiran, can we replace this with a simple `get()` and rely on JTreg's default timeout settings? > > we probably could. This test should work equally well with a `send` instead of `sendAsync` too. But the proposed change is good enough for now. @sendaoYan is this test run with a timeout factor > 1 in the configuration where it fails? If so a possibility could also be to use `Utils.adjustTimeout` to adjust the timeout with the timeout factor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27447#discussion_r2372360504 From dfuchs at openjdk.org Tue Sep 23 13:41:29 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 23 Sep 2025 13:41:29 GMT Subject: RFR: 8368373: Test H3MalformedResponseTest.testMalformedResponse intermittent timed out In-Reply-To: References: <31hNf5hPnSYu2Jm1tKCQa_Lm1ymCSARvIzorOymxW70=.08aa6e47-0a2f-4f17-b530-07184ea0db6e@github.com> Message-ID: On Tue, 23 Sep 2025 13:34:02 GMT, Daniel Fuchs wrote: >> we probably could. This test should work equally well with a `send` instead of `sendAsync` too. But the proposed change is good enough for now. > > @sendaoYan is this test run with a timeout factor > 1 in the configuration where it fails? > If so a possibility could also be to use `Utils.adjustTimeout` to adjust the timeout with the timeout factor. I see from the log that timeoutFactor is 2.0 - so if the test passes with a timeout of 20 instead of 10, using `Utils.adjustTimeout` might be preferable as it will extend the timeout on those configurations where timeoutFactor is even greater. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27447#discussion_r2372378492 From kvn at openjdk.org Tue Sep 23 13:47:26 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Sep 2025 13:47:26 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v11] In-Reply-To: References: Message-ID: <0IoLphlvsBS-Kr7-NbUG0pNMjTe3B8kJ7VsDypm9xHw=.2105c0b4-60c5-4eaa-98a2-bedbbbaae995@github.com> On Tue, 23 Sep 2025 03:24:28 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: > > - @vnkozlov review comments > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() > - Fixed 32-bit builds > - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes > - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class > - @ashu-mehra review comments > - ... and 21 more: https://git.openjdk.org/jdk/compare/61c5245b...bd08a0b5 Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26375#pullrequestreview-3258111898 From duke at openjdk.org Tue Sep 23 13:59:38 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 23 Sep 2025 13:59:38 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v2] In-Reply-To: References: Message-ID: > Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. > > - Adds a new flag checking if the incoming request is an upgrade request. > - When receiving an upgrade request, directly return the input/output stream > - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. > - sentHeaders will not be set to true when sending 1xx status codes Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: address pr comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/bbc2a975..d76ff991 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=00-01 Stats: 12 lines in 2 files changed: 5 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From ihse at openjdk.org Tue Sep 23 14:04:17 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 23 Sep 2025 14:04:17 GMT Subject: RFR: 8368273: LIBPTHREAD dependency is not needed for some jdk libs In-Reply-To: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com> References: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com> Message-ID: On Mon, 22 Sep 2025 12:38:45 GMT, Matthias Baesken wrote: > A couple of JDK native libs link to $(LIBPTHREAD) but the dependency is not needed. > > libsctp has no `pthread*` calls so most likely we can omit $(LIBPTHREAD). > libawt_xawt only uses `pthread_self()` ; so on Linux it links without adding $(LIBPTHREAD) because it then uses `pthread_self() `from glibc; however it might still be better to link $(LIBPTHREAD) in this special case. Looks good! I agree that it is better to keep libpthread for libawt_xawt. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27426#pullrequestreview-3258186230 From duke at openjdk.org Tue Sep 23 14:12:20 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 23 Sep 2025 14:12:20 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v2] In-Reply-To: References: Message-ID: <0pyxdsr7fTBvXA7n957j-9tXNrivEfEim3d0REZidX4=.9544d8b3-d948-408c-a635-ca14cdc7c179@github.com> On Tue, 23 Sep 2025 13:59:38 GMT, Josiah Noel wrote: >> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. >> >> - Adds a new flag checking if the incoming request is an upgrade request. >> - When receiving an upgrade request, directly return the input/output stream >> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. >> - sentHeaders will not be set to true when sending 1xx status codes > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > address pr comments Thank you for taking the time to review. > In both cases the server _is required_ to send a 101 Switching protocols response, any other response means that the server decided to keep using HTTP 1.1. It does not appear that this is the case. Looking at [rfc9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-upgrade), a server can send other status codes to reject the connection, such as 426 or ignore the header altogether and not upgrade as you say. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3324187810 From dfuchs at openjdk.org Tue Sep 23 14:34:37 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 23 Sep 2025 14:34:37 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 13:59:38 GMT, Josiah Noel wrote: >> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. >> >> - Adds a new flag checking if the incoming request is an upgrade request. >> - When receiving an upgrade request, directly return the input/output stream >> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. >> - sentHeaders will not be set to true when sending 1xx status codes > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > address pr comments Hi Josiah! Glad to see that the OCA verification finally went through! It seems to me that this PR addresses two different problems: 1. attempting to fix sendResponseHeaders to support sending informational responses (1xx status - a bug fix) 2. attempting to add support for switching protocols to the HttpServer (a new functionality) I believe it would be best to separate these two issues into two different PRs to avoid mixing them up. I would suggest only addressing 1. in this PR and log an enhancement for 2. With regard to supporting some way to support upgrading protocols in the HTTP server I believe more discussion will be needed. best regards, -- daniel ------------- PR Review: https://git.openjdk.org/jdk/pull/27069#pullrequestreview-3258310895 From syan at openjdk.org Tue Sep 23 14:36:14 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 23 Sep 2025 14:36:14 GMT Subject: RFR: 8368373: Test H3MalformedResponseTest.testMalformedResponse intermittent timed out [v2] In-Reply-To: References: Message-ID: > Hi all, > > The sub-test H3MalformedResponseTest.testMalformedResponse in test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java intermittent report java.util.concurrent.TimeoutException, espicial when this test run with other jtreg tests simultancely. This PR change the timeout vaule from 10 to 30 to make test run passed steady. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Utils.adjustTimeout(10) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27447/files - new: https://git.openjdk.org/jdk/pull/27447/files/16d6b3e2..0b218056 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27447&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27447&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27447.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27447/head:pull/27447 PR: https://git.openjdk.org/jdk/pull/27447 From syan at openjdk.org Tue Sep 23 14:36:15 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 23 Sep 2025 14:36:15 GMT Subject: RFR: 8368373: Test H3MalformedResponseTest.testMalformedResponse intermittent timed out [v2] In-Reply-To: References: <31hNf5hPnSYu2Jm1tKCQa_Lm1ymCSARvIzorOymxW70=.08aa6e47-0a2f-4f17-b530-07184ea0db6e@github.com> Message-ID: On Tue, 23 Sep 2025 13:38:42 GMT, Daniel Fuchs wrote: >> @sendaoYan is this test run with a timeout factor > 1 in the configuration where it fails? >> If so a possibility could also be to use `Utils.adjustTimeout` to adjust the timeout with the timeout factor. > > I see from the log that timeoutFactor is 2.0 - so if the test passes with a timeout of 20 instead of 10, using `Utils.adjustTimeout` might be preferable as it will extend the timeout on those configurations where timeoutFactor is even greater. Thanks the advice. Timeout 20 make test run passed steady. PR has been updated, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27447#discussion_r2372534386 From iklam at openjdk.org Tue Sep 23 14:43:45 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 14:43:45 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 19:18:41 GMT, Dan Heidinga wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @DanHeidinga comments -- added comments and asserts about the handling of enums > > My concerns have been addressed. Thanks Ioi Thanks @DanHeidinga @ashu-mehra @vnkozlov for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/26375#issuecomment-3324325748 From iklam at openjdk.org Tue Sep 23 14:46:17 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 14:46:17 GMT Subject: Integrated: 8350550: Preload classes from AOT cache during VM bootstrap In-Reply-To: References: Message-ID: <0g4ainvBjH046UiFMkElHNhUgLhBTEhVih6KTHLTgmA=.37cb0c1d-8239-4b7c-a150-6bdb272df63c@github.com> On Thu, 17 Jul 2025 22:38:48 GMT, Ioi Lam wrote: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. This pull request has now been integrated. Changeset: fd30ae98 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/fd30ae988bc512b5d2a5a3fd1bc1ed351af974c7 Stats: 941 lines in 43 files changed: 534 ins; 236 del; 171 mod 8350550: Preload classes from AOT cache during VM bootstrap Reviewed-by: kvn, heidinga, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/26375 From dfuchs at openjdk.org Tue Sep 23 14:48:23 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 23 Sep 2025 14:48:23 GMT Subject: RFR: 8368373: Test H3MalformedResponseTest.testMalformedResponse intermittent timed out [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 14:36:14 GMT, SendaoYan wrote: >> Hi all, >> >> The sub-test H3MalformedResponseTest.testMalformedResponse in test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java intermittent report java.util.concurrent.TimeoutException, espicial when this test run with other jtreg tests simultancely. This PR change the timeout vaule from 10 to 30 to make test run passed steady. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Utils.adjustTimeout(10) Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27447#pullrequestreview-3258374063 From duke at openjdk.org Tue Sep 23 14:50:23 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 23 Sep 2025 14:50:23 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v3] In-Reply-To: References: Message-ID: > Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. > > - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. > - sentHeaders will not be set to true when sending 1xx status codes Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: remove upgrade ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/d76ff991..fa42e77c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=01-02 Stats: 462 lines in 3 files changed: 181 ins; 279 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From duke at openjdk.org Tue Sep 23 14:50:26 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 23 Sep 2025 14:50:26 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v2] In-Reply-To: References: Message-ID: <1EzGhq-mlpJNHn4nvu0Wik5Iq8cklns3J-eti5YJaoM=.dc03067d-3a90-438e-99ae-b3d4a508889a@github.com> On Tue, 23 Sep 2025 13:59:38 GMT, Josiah Noel wrote: >> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. >> >> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. >> - sentHeaders will not be set to true when sending 1xx status codes > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > address pr comments ok will move the upgrade stuff to a different pr ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3324350274 From dfuchs at openjdk.org Tue Sep 23 15:04:36 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 23 Sep 2025 15:04:36 GMT Subject: RFR: 8367068: Remove redundant HttpRequest.BodyPublisher tests In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 10:12:28 GMT, Volkan Yazici wrote: > Remove `HttpRequest.BodyPublisher` tests rendered redundant by [JDK-8367067] (#26876). > > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27421#pullrequestreview-3258445760 From jaikiran.pai at oracle.com Tue Sep 23 16:03:50 2025 From: jaikiran.pai at oracle.com (Jaikiran Pai) Date: Tue, 23 Sep 2025 21:33:50 +0530 Subject: Add Extended MPTCP (Multipath TCP) Socket Option Support to OpenJDK In-Reply-To: <69f2513f5d13b65aeb3fd23c9fcc6dc410968466.camel@kernel.org> References: <69f2513f5d13b65aeb3fd23c9fcc6dc410968466.camel@kernel.org> Message-ID: <290d13ad-a624-44ad-8390-a73a3c3b96ec@oracle.com> Hello Geliang, Just a few initial observations: On 23/09/25 3:04 pm, Geliang Tang wrote: > Dear OpenJDK Maintainers, > > We are writing to propose the integration of Multipath TCP (MPTCP) > support into OpenJDK. In response to Alan's feedback in earlier > discussions [1], we have developed a Java-based implementation that > utilizes the setOption method to enable MPTCP before binding or > connecting a socket, as illustrated below: > > Socket c = new Socket(); > c.setOption(ExtendedSocketOptions.TCP_MPTCPIFY, true); > c.connect(new InetSocketAddress(loop.getHostAddress(), port)); > > The name 'TCP_MPTCPIFY' was chosen to align with 'mptcpize' tool in > mptcpd and 'mptcpify' in BCC. The complete implementation can be found > in [2]. I realize it's still a bit early to discuss naming of this option, but if we do go ahead with this approach of introducing an ExtendedSocketOption, then maybe calling it TCP_MULTIPATH might be more suitable. > This email outlines the technical background and aims to facilitate > further discussion on the proposed approach. Looking at the linked github diff in your mail, the biggest difference between existing (Extended)SocketOptions and this new proposed one is that, as far as I can tell, this new one isn't a socket option and instead is a protocol value that is used when constructing the socket(): > fdm = socket(domain, type, IPPROTO_MPTCP); I don't yet know if fitting this into the existing ExtendedSocketOptions may end up being tricky for long term maintenance of this (internal) API. The other question this raises is, are applications allowed to call Socket.getOption(...) for this option and then expect it to return true/false depending on whether multicast TCP was set for that socket? I briefly glanced at the proposed diff and I couldn't spot any changes in the ExtendedSocketOptions.getOption(...) code to deal with this option. But that too I think is a trivial thing for later. The bigger question, I think, is whether constructing a "socket()" with a specific "protocol" value in this manner by trying to adjust the implementation in the code which deals with socket options is the right thing to do. I realize that this proposal of prototyping it as a socket option was suggested in response to your first email, so I am not saying this direction should be abandoned, I just haven't fully grasped if this can cause us problems with this approach. I have several other questions, both implementation details as well as the basics of multipath TCP, but I haven't yet read up on all the material that's been linked in your email. So I'll catch up on that first. -Jaikiran From michaelm at openjdk.org Tue Sep 23 16:11:42 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 23 Sep 2025 16:11:42 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v3] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 14:50:23 GMT, Josiah Noel wrote: >> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. >> >> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. >> - sentHeaders will not be set to true when sending 1xx status codes > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > remove upgrade I agree that switching protocols should not be part of the PR. We discussed this before, but I think we _should_ include as part of this fix, some symbolic constants to represent the special (and counter-intuitive) length values of 0 and -1 for sendResponseHeaders. I started a patch for this and can provide what I had. The idea is to define two constants in HttpExchange /** * No response body is being sent with this response */ public static final long RSPBODY_EMPTY = -1l; /** * The response body is unspecified and will be chunk encoded */ public static final long RSPBODY_CHUNKED = 0; and then link to these constants (instead of stating 0, or -1 literally) in the apidoc for sendResponseHeaders. The following could be a starting point for this: /** - * Starts sending the response back to the client using the current set of - * response headers and the numeric response code as specified in this + * Starts sending the final response back to the client using the current set of + * response headers obtained from {@link #getResponseHeaders()} and the numeric + * response code as specified in this * method. The response body length is also specified as follows. If the * response length parameter is greater than {@code zero}, this specifies an * exact number of bytes to send and the application must send that exact - * amount of data. If the response length parameter is {@code zero}, then - * chunked transfer encoding is used and an arbitrary amount of data may be + * amount of data. If the response length parameter has the value + * {@link #RSPBODY_CHUNKED} then the response body uses + * chunked transfer encoding and an arbitrary amount of data may be * sent. The application terminates the response body by closing the * {@link OutputStream}. - * If response length has the value {@code -1} then no response body is - * being sent. + * If response length has the value {@link #RSPBODY_EMPTY} then no + * response body is being sent. * *

If the content-length response header has not already been set then * this is set to the appropriate value depending on the response length * parameter. * *

This method must be called prior to calling {@link #getResponseBody()}. * + *

The request body must be consumed before calling this method. + * * @implNote This implementation allows the caller to instruct the * server to force a connection close after the exchange terminates, by * supplying a {@code Connection: close} header to the {@linkplain * #getResponseHeaders() response headers} before {@code sendResponseHeaders} * is called. * * @param rCode the response code to send * @param responseLength if {@literal > 0}, specifies a fixed response body * length and that exact number of bytes must be written * to the stream acquired from {@link #getResponseCode()} - * If {@literal == 0}, then chunked encoding is used, + * If equal to {@link #RSPBODY_CHUNKED}, then chunked encoding is used, * and an arbitrary number of bytes may be written. - * If {@literal <= -1}, then no response body length is + * If equal to {@link #RSPBODY_EMPTY}, then no response body length is * specified and no response body may be written. * @throws IOException if the response headers have already been sent or an I/O error occurs * @see HttpExchange#getResponseBody() */ public abstract void sendResponseHeaders(int rCode, long responseLength) throws IOException; It's only a doc change obviously. So, existing (correct) code can continue to use numeric values, but hopefully new code can be less error-prone if the constant names are used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3324672414 From duke at openjdk.org Tue Sep 23 16:18:47 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 23 Sep 2025 16:18:47 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v3] In-Reply-To: References: Message-ID: <3vYgfgCEGC8HPdzSuR6OomJ0NWLVReu2SmLKBmAA7-Y=.af7745df-ec4e-421f-bf55-f2532a91a2ca@github.com> On Tue, 23 Sep 2025 14:50:23 GMT, Josiah Noel wrote: >> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. >> >> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. >> - sentHeaders will not be set to true when sending 1xx status codes > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > remove upgrade > we should include as part of this fix, some symbolic constants to represent the special (and counter-intuitive) length values of 0 and -1 for sendResponseHeaders I mean I like this too and would appreciate that as well, but it seems a bit unrelated to the current change. > This method must be called prior to calling {@link #getResponseBody()}. Hm? I do this all the time though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3324700536 From dfuchs at openjdk.org Tue Sep 23 16:27:44 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 23 Sep 2025 16:27:44 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v3] In-Reply-To: <3vYgfgCEGC8HPdzSuR6OomJ0NWLVReu2SmLKBmAA7-Y=.af7745df-ec4e-421f-bf55-f2532a91a2ca@github.com> References: <3vYgfgCEGC8HPdzSuR6OomJ0NWLVReu2SmLKBmAA7-Y=.af7745df-ec4e-421f-bf55-f2532a91a2ca@github.com> Message-ID: <0usn2CSwCOqexn0Cae-A8gdJW36vRsNy6t1cYhOAPZI=.d6d97b39-1778-483d-9498-468bfafb2b79@github.com> On Tue, 23 Sep 2025 16:15:41 GMT, Josiah Noel wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> remove upgrade > >> we should include as part of this fix, some symbolic constants to represent the special (and counter-intuitive) length values of 0 and -1 for sendResponseHeaders > > I mean I like this too and would appreciate that as well, but it seems a bit unrelated to the current change. > >> This method must be called prior to calling {@link #getResponseBody()}. > > Hm? I do this all the time though. @SentryMan Thanks for your patience! I will have a deeper look at your proposed changes and see how it behave in our CI. I suspect we might want to add some `@apiNote` to highlight how to send interim responses, and possibly clarify what the `length` parameter means in this case. Not sure if we should accept (and ignore) any value that is passed - or request that a specific value is passed (like 0 or -1) - something to be discussed. Let me review the code - then we can figure out what kind of note/statement we want to add to the API documentation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3324740260 From mchhipa at openjdk.org Tue Sep 23 16:33:49 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Tue, 23 Sep 2025 16:33:49 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v2] In-Reply-To: References: Message-ID: > Refactoring following httpclient/http2 testng test to JUnit : > test/jdk/java/net/httpclient/http2/BadHeadersTest.java > test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java > test/jdk/java/net/httpclient/http2/BasicTest.java > test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java > test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Implemented the review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27388/files - new: https://git.openjdk.org/jdk/pull/27388/files/055a1cfe..ea197296 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27388&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27388&range=00-01 Stats: 74 lines in 5 files changed: 0 ins; 7 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/27388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27388/head:pull/27388 PR: https://git.openjdk.org/jdk/pull/27388 From mchhipa at openjdk.org Tue Sep 23 16:48:15 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Tue, 23 Sep 2025 16:48:15 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 14:25:54 GMT, Daniel Fuchs wrote: >> test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 88: >> >>> 86: ); >>> 87: >>> 88: SSLContext sslContext; >> >> These can be `private` for better encapsulation. > > Agreed - though that doesn't really matter here. We're changing those line anayway to make the fields static - so yes - we can make them private. Thanks. Now these are private. >> test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 145: >> >>> 143: Arguments.of(http2URI, true, byteAtATime), >>> 144: Arguments.of(https2URI, true, byteAtATime) >>> 145: ); >> >> AFAICT, you don't need to return a `Stream`, the old `Object[][]` should suffice. Maybe that is better to revert this to old style to keep the diff minimal ? granted `Object[][]` indeed works with JUnit. > > If this was a new tests then IMO using `Arguments.of(...)` would be preferable. Since this is an old test then arguably keeping the old Object[][] could make backports easier. Thanks. reverted to Object[][]. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2372905788 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2372906936 From mchhipa at openjdk.org Tue Sep 23 16:48:22 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Tue, 23 Sep 2025 16:48:22 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 07:56:18 GMT, Volkan Yazici wrote: >> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented the review comments. > > test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 247: > >> 245: >> 246: @BeforeAll >> 247: public static void setup() throws Exception { > > `setup()` and `teardown()` can be package-private. > > Note that this comment applies to all `@AfterAll`- and `@BeforeAll`-annotated methods also present in other touched files. Now all AfterAll and BeforeAll methods are package private. > test/jdk/java/net/httpclient/http2/BasicTest.java line 129: > >> 127: >> 128: @Test >> 129: public void test() throws Exception { > > `@[Parameterized]Test`-annotated methods can be package-private. Now all all test methods are package private. > test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java line 83: > >> 81: static HttpTestServer https2TestServer; // HTTP/2 ( h2 ) >> 82: static String http2URI; >> 83: static String https2URI; > > These can be `private`. Now these variables are private. > test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java line 90: > >> 88: Arguments.of(http2URI), >> 89: Arguments.of(https2URI) >> 90: ); > > You can use `Object[][]`. reverted to Object[][] > test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java line 137: > >> 135: }; >> 136: >> 137: static Stream variants() { > > This can be `Object[][]`. reverted to Object[][]. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2372904500 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2372909168 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2372911379 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2372910141 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2372912184 From mchhipa at openjdk.org Tue Sep 23 16:48:24 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Tue, 23 Sep 2025 16:48:24 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 14:40:19 GMT, Daniel Fuchs wrote: >> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented the review comments. > > test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java line 75: > >> 73: import org.junit.jupiter.params.provider.MethodSource; >> 74: >> 75: import static org.junit.jupiter.api.Assertions.*; > > This test uses `assertEquals` and `assertNotEquals`. Unless I'm mistaken, the parameters order are reversed in JUnit compared to TestNG. That is, one has (expected, actual), the other has (actual, expected). Unless there was already a mistake in the original code, you should also reverse the parameters order at the call sites of `assertEquals`/`assertNotEquals`. Otherwise, the text message of any `AssertionError` thrown by these will be confusing. Thanks. Now corrected with expected and actul values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2372914172 From duke at openjdk.org Tue Sep 23 16:49:31 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 23 Sep 2025 16:49:31 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v4] In-Reply-To: References: Message-ID: > Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. > > - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. > - sentHeaders will not be set to true when sending 1xx status codes Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update ExchangeImpl.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/fa42e77c..f6a5a224 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From alan.bateman at oracle.com Tue Sep 23 16:53:14 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Tue, 23 Sep 2025 17:53:14 +0100 Subject: Add Extended MPTCP (Multipath TCP) Socket Option Support to OpenJDK In-Reply-To: <290d13ad-a624-44ad-8390-a73a3c3b96ec@oracle.com> References: <69f2513f5d13b65aeb3fd23c9fcc6dc410968466.camel@kernel.org> <290d13ad-a624-44ad-8390-a73a3c3b96ec@oracle.com> Message-ID: On 23/09/2025 17:03, Jaikiran Pai wrote: > : > > The bigger question, I think, is whether constructing a "socket()" > with a specific "protocol" value in this manner by trying to adjust > the implementation in the code which deals with socket options is the > right thing to do. I realize that this proposal of prototyping it as a > socket option was suggested in response to your first email, so I am > not saying this direction should be abandoned, I just haven't fully > grasped if this can cause us problems with this approach. Just to point that using dup2 to "convert" the socket to IPPROTO_MPTCP is the same trick that the JDK did for SDP. I think the main question is whether it is compelling enough for the JDK to include, and if so, how would it be tested and maintained. I'm not too concerned about the API docs right now. As with all "socket options", there are many details, esp. around state, that would need to be specified. The JDK has several examples of options that don't support both "set" and "get". Another direction that would allow the existing APIs to be used if to expose a restricted method to get at the raw file descriptor, something we've toyed with several times. That approach would allow MPTCP to be implemented as its own library, wouldn't need anything in the JDK, but would require users to run with a CLI option to enable native access (the current way to allow restricted methods). -Alan. From mchhipa at openjdk.org Tue Sep 23 16:54:37 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Tue, 23 Sep 2025 16:54:37 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 19:14:39 GMT, Volkan Yazici wrote: >> test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java line 265: >> >>> 263: >>> 264: http2TestServerLocal.start(); >>> 265: https2TestServerLocal.start(); >> >> I believe you should revert these changes or make sure they result in exactly the same calls. For instance - `http2TestServerLocal.start();` is not exactly the same as `this.http2TestServer.start();` - the original code was calling start() on the wrapper, and IMO it's better to continue doing that. > >> I believe you should revert these changes > > @dfuch, IMHO, the changes are (partially) necessary since the associated _instance_ variables are switched to _class_ variables, and `this.`-prefixing and variable shadowing do not work anymore. That said, I agree with your suggestion that changes should be minimal and functionally equivalent to the old ones. > >> the original code was calling start() on the wrapper, and IMO it's better to continue doing that. > > Agreed. Thanks. now corrected with start() call on wrapper. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2372927498 From duke at openjdk.org Tue Sep 23 17:05:23 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 23 Sep 2025 17:05:23 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v5] In-Reply-To: References: Message-ID: > Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. > > - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. > - sentHeaders will not be set to true when sending 1xx status codes Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update InputRead100Test.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/f6a5a224..b41f1dc1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From dfuchs at openjdk.org Tue Sep 23 17:05:24 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 23 Sep 2025 17:05:24 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v4] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 16:49:31 GMT, Josiah Noel wrote: >> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. >> >> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. >> - sentHeaders will not be set to true when sending 1xx status codes > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update ExchangeImpl.java test/jdk/com/sun/net/httpserver/InputRead100Test.java line 28: > 26: * @bug 8349670 > 27: * @summary Test 1xx response handling > 28: * @run testng/othervm InputRead1xxTest Did you forget to rename the test class and test file? The class is still called InputRead100Test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2372941800 From duke at openjdk.org Tue Sep 23 17:05:25 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 23 Sep 2025 17:05:25 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v4] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 16:57:57 GMT, Daniel Fuchs wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> Update ExchangeImpl.java > > test/jdk/com/sun/net/httpserver/InputRead100Test.java line 28: > >> 26: * @bug 8349670 >> 27: * @summary Test 1xx response handling >> 28: * @run testng/othervm InputRead1xxTest > > Did you forget to rename the test class and test file? The class is still called InputRead100Test. looks so ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2372942958 From dfuchs at openjdk.org Tue Sep 23 17:08:01 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 23 Sep 2025 17:08:01 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v4] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 16:58:23 GMT, Josiah Noel wrote: >> test/jdk/com/sun/net/httpserver/InputRead100Test.java line 28: >> >>> 26: * @bug 8349670 >>> 27: * @summary Test 1xx response handling >>> 28: * @run testng/othervm InputRead1xxTest >> >> Did you forget to rename the test class and test file? The class is still called InputRead100Test. > > looks so Rather than having two `@run` lines I'd suggest to split this into two full blown jtreg comments - using e.g. @test id=default for the first, and @test id=preferIPv6 for the second. That makes it easier to track down which configuration is causing problems when the test fails. Also we tend to use Junit 5 (jupiter) in new tests in preference to TestNG when possible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2372957273 From duke at openjdk.org Tue Sep 23 17:17:22 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 23 Sep 2025 17:17:22 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v6] In-Reply-To: References: Message-ID: > Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. > > - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. > - sentHeaders will not be set to true when sending 1xx status codes Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: junit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/b41f1dc1..2f969128 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=04-05 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From duke at openjdk.org Tue Sep 23 17:21:57 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 23 Sep 2025 17:21:57 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v7] In-Reply-To: References: Message-ID: <8sCGsTViRbv_FnNgG3nSGdp4dxkjb2idhl3jwr-OnbA=.2bb4885e-5641-482b-9e43-419641862bcc@github.com> > Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. > > - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. > - sentHeaders will not be set to true when sending 1xx status codes Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update InputRead100Test.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/2f969128..07282362 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From duke at openjdk.org Tue Sep 23 17:43:42 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 23 Sep 2025 17:43:42 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: > Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. > > - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. > - sentHeaders will not be set to true when sending 1xx status codes Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update InputRead100Test.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/07282362..144110bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From dfuchs at openjdk.org Tue Sep 23 17:43:43 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 23 Sep 2025 17:43:43 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v7] In-Reply-To: <8sCGsTViRbv_FnNgG3nSGdp4dxkjb2idhl3jwr-OnbA=.2bb4885e-5641-482b-9e43-419641862bcc@github.com> References: <8sCGsTViRbv_FnNgG3nSGdp4dxkjb2idhl3jwr-OnbA=.2bb4885e-5641-482b-9e43-419641862bcc@github.com> Message-ID: On Tue, 23 Sep 2025 17:21:57 GMT, Josiah Noel wrote: >> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. >> >> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. >> - sentHeaders will not be set to true when sending 1xx status codes > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update InputRead100Test.java test/jdk/com/sun/net/httpserver/InputRead100Test.java line 28: > 26: * @bug 8349670 > 27: * @summary Test 100 continue response handling > 28: * @run testng/othervm InputRead100Test Should be `@run junit/othervm` here and below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2373032963 From vyazici at openjdk.org Tue Sep 23 18:25:45 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 23 Sep 2025 18:25:45 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 16:33:49 GMT, Mahendra Chhipa wrote: >> Refactoring following httpclient/http2 testng test to JUnit : >> test/jdk/java/net/httpclient/http2/BadHeadersTest.java >> test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java >> test/jdk/java/net/httpclient/http2/BasicTest.java >> test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java >> test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Implemented the review comments. Changes requested by vyazici (Committer). test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 142: > 140: {https2URI, false, byteAtATime }, > 141: {http2URI, true, byteAtATime }, > 142: {https2URI, true, byteAtATime }, @mahendrachhipa, I'd advise avoiding styling changes, unless it is really necessary. test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java line 150: > 148: {https2URI, false, byteAtATime}, > 149: {http2URI, true, byteAtATime}, > 150: {https2URI, true, byteAtATime}, Again, I'd suggest reverting these. ------------- PR Review: https://git.openjdk.org/jdk/pull/27388#pullrequestreview-3259142225 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2373119960 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2373124975 From duke at openjdk.org Tue Sep 23 19:22:47 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 23 Sep 2025 19:22:47 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 14:31:41 GMT, Daniel Fuchs wrote: > I would suggest only addressing 1. in this PR and log an enhancement for 2. Alright, so how do I log an enhancement? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3325252769 From syan at openjdk.org Wed Sep 24 06:07:28 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Sep 2025 06:07:28 GMT Subject: RFR: 8368373: Test H3MalformedResponseTest.testMalformedResponse intermittent timed out [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 14:36:14 GMT, SendaoYan wrote: >> Hi all, >> >> The sub-test H3MalformedResponseTest.testMalformedResponse in test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java intermittent report java.util.concurrent.TimeoutException, espicial when this test run with other jtreg tests simultancely. This PR change the timeout vaule from 10 to 30 to make test run passed steady. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Utils.adjustTimeout(10) Thanks for the advices and reviews @vy @djelinski @dfuch ------------- PR Comment: https://git.openjdk.org/jdk/pull/27447#issuecomment-3326665231 From syan at openjdk.org Wed Sep 24 06:07:29 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Sep 2025 06:07:29 GMT Subject: Integrated: 8368373: Test H3MalformedResponseTest.testMalformedResponse intermittent timed out In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 08:05:42 GMT, SendaoYan wrote: > Hi all, > > The sub-test H3MalformedResponseTest.testMalformedResponse in test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java intermittent report java.util.concurrent.TimeoutException, espicial when this test run with other jtreg tests simultancely. This PR change the timeout vaule from 10 to 30 to make test run passed steady. This pull request has now been integrated. Changeset: 5350ce10 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/5350ce105973945e899b82a4c066d6ec5439102d Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8368373: Test H3MalformedResponseTest.testMalformedResponse intermittent timed out Reviewed-by: dfuchs, djelinski ------------- PR: https://git.openjdk.org/jdk/pull/27447 From michaelm at openjdk.org Wed Sep 24 06:14:17 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 24 Sep 2025 06:14:17 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v3] In-Reply-To: <3vYgfgCEGC8HPdzSuR6OomJ0NWLVReu2SmLKBmAA7-Y=.af7745df-ec4e-421f-bf55-f2532a91a2ca@github.com> References: <3vYgfgCEGC8HPdzSuR6OomJ0NWLVReu2SmLKBmAA7-Y=.af7745df-ec4e-421f-bf55-f2532a91a2ca@github.com> Message-ID: On Tue, 23 Sep 2025 16:15:41 GMT, Josiah Noel wrote: > > we should include as part of this fix, some symbolic constants to represent the special (and counter-intuitive) length values of 0 and -1 for sendResponseHeaders > > I mean I like this too and would appreciate that as well, but it seems a bit unrelated to the current change. > > > This method must be called prior to calling {@link #getResponseBody()}. > > Hm? I do this all the time though. (call `getResponseBody` that is) I just suggested it because I was planning to include it with the fix. But, I'm happy to file a separate issue for it, and fix it myself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3326688077 From vyazici at openjdk.org Wed Sep 24 08:11:12 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 24 Sep 2025 08:11:12 GMT Subject: RFR: 8367068: Remove redundant HttpRequest.BodyPublisher tests In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 10:12:28 GMT, Volkan Yazici wrote: > Remove `HttpRequest.BodyPublisher` tests rendered redundant by [JDK-8367067] (#26876). > > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 Merged changes from 47efe3c794c (of `master`) into e1dbf78dd9c (of PR) and verified that `test/jdk/java/net/httpclient/` tests pass on several platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27421#issuecomment-3327117432 From vyazici at openjdk.org Wed Sep 24 08:11:13 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 24 Sep 2025 08:11:13 GMT Subject: Integrated: 8367068: Remove redundant HttpRequest.BodyPublisher tests In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 10:12:28 GMT, Volkan Yazici wrote: > Remove `HttpRequest.BodyPublisher` tests rendered redundant by [JDK-8367067] (#26876). > > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 This pull request has now been integrated. Changeset: 288822a5 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/288822a5c2bbaba7b6b897faab1a9cc076c906cc Stats: 461 lines in 7 files changed: 134 ins; 325 del; 2 mod 8367068: Remove redundant HttpRequest.BodyPublisher tests Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/27421 From daniel.fuchs at oracle.com Wed Sep 24 10:02:21 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 24 Sep 2025 11:02:21 +0100 Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v2] In-Reply-To: References: Message-ID: <45ddd353-6ba0-49df-ad28-8239c6ff21e5@oracle.com> Hi Josiah, > Alright, so how do I log an enhancement? Do you have a JBS access? If so that would be at https://bugs.openjdk.org/ choose component core-libs subcomponent java.net Otherwise you could do it at: https://bugreport.java.com/bugreport/ You will find a link to there at the bottom of every Java API doc page: e.g.: https://docs.oracle.com/en/java/javase/25/docs/api/search.html?q=HttpServer best regards, -- daniel On 23/09/2025 20:22, Josiah Noel wrote: > On Tue, 23 Sep 2025 14:31:41 GMT, Daniel Fuchs wrote: > >> I would suggest only addressing 1. in this PR and log an enhancement for 2. > > Alright, so how do I log an enhancement? > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3325252769 From mchhipa at openjdk.org Wed Sep 24 11:34:22 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Wed, 24 Sep 2025 11:34:22 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v3] In-Reply-To: References: Message-ID: <02H3cMAC_sdc0u5QESw7jJ_Xz5AqBtTmgk0ag-dfmDo=.76dbe12d-875a-4296-b7e5-e9724c1d7e47@github.com> > Refactoring following httpclient/http2 testng test to JUnit : > test/jdk/java/net/httpclient/http2/BadHeadersTest.java > test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java > test/jdk/java/net/httpclient/http2/BasicTest.java > test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java > test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java Mahendra Chhipa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Updated test data indentation. - Merge branch 'master' into JDK-8318662 - Implemented the review comments. - JDK-8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit ------------- Changes: https://git.openjdk.org/jdk/pull/27388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27388&range=02 Stats: 150 lines in 5 files changed: 5 ins; 30 del; 115 mod Patch: https://git.openjdk.org/jdk/pull/27388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27388/head:pull/27388 PR: https://git.openjdk.org/jdk/pull/27388 From vyazici at openjdk.org Wed Sep 24 11:47:52 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 24 Sep 2025 11:47:52 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v3] In-Reply-To: <02H3cMAC_sdc0u5QESw7jJ_Xz5AqBtTmgk0ag-dfmDo=.76dbe12d-875a-4296-b7e5-e9724c1d7e47@github.com> References: <02H3cMAC_sdc0u5QESw7jJ_Xz5AqBtTmgk0ag-dfmDo=.76dbe12d-875a-4296-b7e5-e9724c1d7e47@github.com> Message-ID: On Wed, 24 Sep 2025 11:34:22 GMT, Mahendra Chhipa wrote: >> Refactoring following httpclient/http2 testng test to JUnit : >> test/jdk/java/net/httpclient/http2/BadHeadersTest.java >> test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java >> test/jdk/java/net/httpclient/http2/BasicTest.java >> test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java >> test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java > > Mahendra Chhipa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Updated test data indentation. > - Merge branch 'master' into JDK-8318662 > - Implemented the review comments. > - JDK-8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit Changes requested by vyazici (Committer). test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java line 33: > 31: * -Djdk.httpclient.connectionWindowSize=65535 > 32: * -Djdk.httpclient.windowsize=16384 > 33: * ConnectionFlowControlTest Could you also revert these, please? test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java line 150: > 148: { https2URI, false, byteAtATime}, > 149: { http2URI, true, byteAtATime}, > 150: { https2URI, true, byteAtATime}, Could you also revert these, please? ------------- PR Review: https://git.openjdk.org/jdk/pull/27388#pullrequestreview-3262500457 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2375512679 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2375512047 From mchhipa at openjdk.org Wed Sep 24 12:36:56 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Wed, 24 Sep 2025 12:36:56 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v3] In-Reply-To: References: <02H3cMAC_sdc0u5QESw7jJ_Xz5AqBtTmgk0ag-dfmDo=.76dbe12d-875a-4296-b7e5-e9724c1d7e47@github.com> Message-ID: On Wed, 24 Sep 2025 11:44:52 GMT, Volkan Yazici wrote: >> Mahendra Chhipa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Updated test data indentation. >> - Merge branch 'master' into JDK-8318662 >> - Implemented the review comments. >> - JDK-8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit > > test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java line 33: > >> 31: * -Djdk.httpclient.connectionWindowSize=65535 >> 32: * -Djdk.httpclient.windowsize=16384 >> 33: * ConnectionFlowControlTest > > Could you also revert these, please? Thanks, reverted now. > test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java line 150: > >> 148: { https2URI, false, byteAtATime}, >> 149: { http2URI, true, byteAtATime}, >> 150: { https2URI, true, byteAtATime}, > > Could you also revert these, please? REverted now. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2375633895 PR Review Comment: https://git.openjdk.org/jdk/pull/27388#discussion_r2375635842 From mchhipa at openjdk.org Wed Sep 24 12:36:52 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Wed, 24 Sep 2025 12:36:52 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v4] In-Reply-To: References: Message-ID: > Refactoring following httpclient/http2 testng test to JUnit : > test/jdk/java/net/httpclient/http2/BadHeadersTest.java > test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java > test/jdk/java/net/httpclient/http2/BasicTest.java > test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java > test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Reverted few formattings. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27388/files - new: https://git.openjdk.org/jdk/pull/27388/files/f4add754..bd122881 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27388&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27388&range=02-03 Stats: 18 lines in 2 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/27388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27388/head:pull/27388 PR: https://git.openjdk.org/jdk/pull/27388 From mbaesken at openjdk.org Wed Sep 24 13:10:37 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 24 Sep 2025 13:10:37 GMT Subject: RFR: 8368273: LIBPTHREAD dependency is not needed for some jdk libs In-Reply-To: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com> References: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com> Message-ID: On Mon, 22 Sep 2025 12:38:45 GMT, Matthias Baesken wrote: > A couple of JDK native libs link to $(LIBPTHREAD) but the dependency is not needed. > > libsctp has no `pthread*` calls so most likely we can omit $(LIBPTHREAD). > libawt_xawt only uses `pthread_self()` ; so on Linux it links without adding $(LIBPTHREAD) because it then uses `pthread_self() `from glibc; however it might still be better to link $(LIBPTHREAD) in this special case. Hi Magnus, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27426#issuecomment-3328331208 From mbaesken at openjdk.org Wed Sep 24 13:10:39 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 24 Sep 2025 13:10:39 GMT Subject: Integrated: 8368273: LIBPTHREAD dependency is not needed for some jdk libs In-Reply-To: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com> References: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com> Message-ID: On Mon, 22 Sep 2025 12:38:45 GMT, Matthias Baesken wrote: > A couple of JDK native libs link to $(LIBPTHREAD) but the dependency is not needed. > > libsctp has no `pthread*` calls so most likely we can omit $(LIBPTHREAD). > libawt_xawt only uses `pthread_self()` ; so on Linux it links without adding $(LIBPTHREAD) because it then uses `pthread_self() `from glibc; however it might still be better to link $(LIBPTHREAD) in this special case. This pull request has now been integrated. Changeset: 0a64358a Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/0a64358aa82930e2bd323fcec2c1cb269ee200e0 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8368273: LIBPTHREAD dependency is not needed for some jdk libs Reviewed-by: ihse ------------- PR: https://git.openjdk.org/jdk/pull/27426 From vyazici at openjdk.org Wed Sep 24 13:31:45 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 24 Sep 2025 13:31:45 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v4] In-Reply-To: References: Message-ID: <1cLFZE_uNC1NssFSP1mxFC72Fqht1gW8zKvuiIR0QFc=.698dcd3f-f778-4d83-b50e-62a911f776c2@github.com> On Wed, 24 Sep 2025 12:36:52 GMT, Mahendra Chhipa wrote: >> Refactoring following httpclient/http2 testng test to JUnit : >> test/jdk/java/net/httpclient/http2/BadHeadersTest.java >> test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java >> test/jdk/java/net/httpclient/http2/BasicTest.java >> test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java >> test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Reverted few formattings. @mahendrachhipa, would you mind confirming that all `test/jdk/java/net/httpclient/http2/` tests still pass on all supported platforms, please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27388#issuecomment-3328455797 From dfuchs at openjdk.org Wed Sep 24 13:34:58 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 24 Sep 2025 13:34:58 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 17:43:42 GMT, Josiah Noel wrote: >> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. >> >> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. >> - sentHeaders will not be set to true when sending 1xx status codes > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update InputRead100Test.java Hi Josiah, I'm seeing `com/sun/net/httpserver/ServerStopTerminationTest.java` failing intermittently in the CI with your changes. I am not fully confident it's attributable to your changes, but it does seem suspicious and would need to be investigated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3328472508 From dfuchs at openjdk.org Wed Sep 24 14:04:31 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 24 Sep 2025 14:04:31 GMT Subject: RFR: 8368546: java/net/httpclient/RedirectTimeoutTest.java fails intermittently for HTTP/3 in tier7 Message-ID: <_oWb6uqUdup6KnPdMaN1KmWxFAYlkn8eyEGwJcbSbcM=.8c81a67f-99f3-4051-856c-2ffe121c662a@github.com> The java/net/httpclient/RedirectTimeoutTest.java has been observed failing (once) for HTTP/3 on Windows in tier 7 (debug builds) The log reveals that it's the HEAD request used for warmup that is failing in timeout. This was surprising as this HEAD request was not supposed to be configured with a timeout, and a reading of the test code revealed that a non-obvious call to HttpRequest.Builder::copy was missing in the test. I added that call, which should fix the issue. ------------- Commit messages: - 8368546: java/net/httpclient/RedirectTimeoutTest.java fails intermittently for HTTP/3 in tier7 Changes: https://git.openjdk.org/jdk/pull/27471/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27471&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368546 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27471/head:pull/27471 PR: https://git.openjdk.org/jdk/pull/27471 From duke at openjdk.org Wed Sep 24 14:06:54 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 24 Sep 2025 14:06:54 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 17:43:42 GMT, Josiah Noel wrote: >> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. >> >> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely. >> - sentHeaders will not be set to true when sending 1xx status codes > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update InputRead100Test.java That is pretty sus, because this PR should only change behavior for 1xx codes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3328674743 From jpai at openjdk.org Wed Sep 24 14:12:40 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 24 Sep 2025 14:12:40 GMT Subject: RFR: 8368546: java/net/httpclient/RedirectTimeoutTest.java fails intermittently for HTTP/3 in tier7 In-Reply-To: <_oWb6uqUdup6KnPdMaN1KmWxFAYlkn8eyEGwJcbSbcM=.8c81a67f-99f3-4051-856c-2ffe121c662a@github.com> References: <_oWb6uqUdup6KnPdMaN1KmWxFAYlkn8eyEGwJcbSbcM=.8c81a67f-99f3-4051-856c-2ffe121c662a@github.com> Message-ID: On Wed, 24 Sep 2025 13:57:04 GMT, Daniel Fuchs wrote: > The java/net/httpclient/RedirectTimeoutTest.java has been observed failing (once) for HTTP/3 on Windows in tier 7 (debug builds) > > The log reveals that it's the HEAD request used for warmup that is failing in timeout. This was surprising as this HEAD request was not supposed to be configured with a timeout, and a reading of the test code revealed that a non-obvious call to HttpRequest.Builder::copy was missing in the test. I added that call, which should fix the issue. This looks good to me. When reading code, reuse of builders always requires going back each line and seeing what its state is. So like you note, this is easy to overlook. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27471#pullrequestreview-3263124091 From syan at openjdk.org Wed Sep 24 14:16:57 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Sep 2025 14:16:57 GMT Subject: RFR: 8368552: H3ErrorHandlingTest.testCloseControlStream intermittent timed out Message-ID: Hi all, H3ErrorHandlingTest.testCloseControlStream(java/net/httpclient/http3/H3ErrorHandlingTest.java) intermittent timed out with fastdebug build on linux-x64. This PR use Utils.adjustTimeout to receive the timeout factor from jtreg, and change the default timeout in 'triggerError' function value from 10 to 20 to make test run passed steady with fastdebug build. I run this test 120 times simultancely all passed after this PR with fastbug build. ------------- Commit messages: - 8368552: H3ErrorHandlingTest.testCloseControlStream intermittent timed out Changes: https://git.openjdk.org/jdk/pull/27472/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27472&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368552 Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27472.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27472/head:pull/27472 PR: https://git.openjdk.org/jdk/pull/27472 From syan at openjdk.org Wed Sep 24 14:23:19 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Sep 2025 14:23:19 GMT Subject: RFR: 8368546: java/net/httpclient/RedirectTimeoutTest.java fails intermittently for HTTP/3 in tier7 In-Reply-To: <_oWb6uqUdup6KnPdMaN1KmWxFAYlkn8eyEGwJcbSbcM=.8c81a67f-99f3-4051-856c-2ffe121c662a@github.com> References: <_oWb6uqUdup6KnPdMaN1KmWxFAYlkn8eyEGwJcbSbcM=.8c81a67f-99f3-4051-856c-2ffe121c662a@github.com> Message-ID: On Wed, 24 Sep 2025 13:57:04 GMT, Daniel Fuchs wrote: > The java/net/httpclient/RedirectTimeoutTest.java has been observed failing (once) for HTTP/3 on Windows in tier 7 (debug builds) > > The log reveals that it's the HEAD request used for warmup that is failing in timeout. This was surprising as this HEAD request was not supposed to be configured with a timeout, and a reading of the test code revealed that a non-obvious call to HttpRequest.Builder::copy was missing in the test. I added that call, which should fix the issue. I run this test with this fix 120 times simultancely, and all the test passed. ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/27471#pullrequestreview-3263178931 From dfuchs at openjdk.org Wed Sep 24 14:27:52 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 24 Sep 2025 14:27:52 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 14:04:26 GMT, Josiah Noel wrote: > That is pretty sus, because this PR should only change behavior for 1xx codes. Right. Emphasis on the 'should' :-) I haven't actually reviewed the proposed changes, just gave them a cursory look. This was just a guinea pig test run experiment to see if any tests would fail consistently and try to catch early mistakes. I intend to do a more thorough review in the coming days. The state management in the HttpServer is far from obvious - and stop() relies on the state to be accurate. stop() happens asynchronously, which adds opportunity for more races. That failing test is kind of timeout dependent - so it is possible that it will fail on overloaded machines. That said - I didn't see evidence in the log that the test was executing slower that usual, and I haven't seen that test failing before in the CI. I will need to investigate more (which will take time). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3328813080 From dfuchs at openjdk.org Wed Sep 24 14:29:56 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 24 Sep 2025 14:29:56 GMT Subject: RFR: 8368546: java/net/httpclient/RedirectTimeoutTest.java fails intermittently for HTTP/3 in tier7 In-Reply-To: References: <_oWb6uqUdup6KnPdMaN1KmWxFAYlkn8eyEGwJcbSbcM=.8c81a67f-99f3-4051-856c-2ffe121c662a@github.com> Message-ID: On Wed, 24 Sep 2025 14:20:47 GMT, SendaoYan wrote: >> The java/net/httpclient/RedirectTimeoutTest.java has been observed failing (once) for HTTP/3 on Windows in tier 7 (debug builds) >> >> The log reveals that it's the HEAD request used for warmup that is failing in timeout. This was surprising as this HEAD request was not supposed to be configured with a timeout, and a reading of the test code revealed that a non-obvious call to HttpRequest.Builder::copy was missing in the test. I added that call, which should fix the issue. > > I run this test with this fix 120 times simultancely, and all the test passed. Before apply this fix the failure rate is 100/120 for the same test. Thanks a lot @sendaoYan ! This is really helpful! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27471#issuecomment-3328820711 From dfuchs at openjdk.org Wed Sep 24 14:50:05 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 24 Sep 2025 14:50:05 GMT Subject: RFR: 8368552: H3ErrorHandlingTest.testCloseControlStream intermittent timed out In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 14:09:09 GMT, SendaoYan wrote: > Hi all, > > H3ErrorHandlingTest.testCloseControlStream(java/net/httpclient/http3/H3ErrorHandlingTest.java) intermittent timed out with fastdebug build on linux-x64. > This PR use Utils.adjustTimeout to receive the timeout factor from jtreg, and change the default timeout in 'triggerError' function value from 10 to 20 to make test run passed steady with fastdebug build. > > I run this test 120 times simultancely all passed after this PR with fastbug build. Thanks! The proposed changes look reasonable to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27472#pullrequestreview-3263300036 From djelinski at openjdk.org Wed Sep 24 15:18:24 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 24 Sep 2025 15:18:24 GMT Subject: RFR: 8368546: java/net/httpclient/RedirectTimeoutTest.java fails intermittently for HTTP/3 in tier7 In-Reply-To: <_oWb6uqUdup6KnPdMaN1KmWxFAYlkn8eyEGwJcbSbcM=.8c81a67f-99f3-4051-856c-2ffe121c662a@github.com> References: <_oWb6uqUdup6KnPdMaN1KmWxFAYlkn8eyEGwJcbSbcM=.8c81a67f-99f3-4051-856c-2ffe121c662a@github.com> Message-ID: On Wed, 24 Sep 2025 13:57:04 GMT, Daniel Fuchs wrote: > The java/net/httpclient/RedirectTimeoutTest.java has been observed failing (once) for HTTP/3 on Windows in tier 7 (debug builds) > > The log reveals that it's the HEAD request used for warmup that is failing in timeout. This was surprising as this HEAD request was not supposed to be configured with a timeout, and a reading of the test code revealed that a non-obvious call to HttpRequest.Builder::copy was missing in the test. I added that call, which should fix the issue. Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27471#pullrequestreview-3263423144 From mchhipa at openjdk.org Wed Sep 24 16:43:37 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Wed, 24 Sep 2025 16:43:37 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v4] In-Reply-To: <1cLFZE_uNC1NssFSP1mxFC72Fqht1gW8zKvuiIR0QFc=.698dcd3f-f778-4d83-b50e-62a911f776c2@github.com> References: <1cLFZE_uNC1NssFSP1mxFC72Fqht1gW8zKvuiIR0QFc=.698dcd3f-f778-4d83-b50e-62a911f776c2@github.com> Message-ID: <8mKqSPfEOpQy8k0B-lg1nv-Qp84sbv2MMNIIy9s7-z4=.4c41b332-458e-4f94-9ceb-72dd7097f8d1@github.com> On Wed, 24 Sep 2025 13:29:21 GMT, Volkan Yazici wrote: > @mahendrachhipa, would you mind confirming that all `test/jdk/java/net/httpclient/http2/` tests still pass on all supported platforms, please? Yes, Mach5 Job link is added in https://bugs.openjdk.org/browse/JDK-8318662 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27388#issuecomment-3329815129 From dfuchs at openjdk.org Wed Sep 24 16:59:21 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 24 Sep 2025 16:59:21 GMT Subject: RFR: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit [v4] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 12:36:52 GMT, Mahendra Chhipa wrote: >> Refactoring following httpclient/http2 testng test to JUnit : >> test/jdk/java/net/httpclient/http2/BadHeadersTest.java >> test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java >> test/jdk/java/net/httpclient/http2/BasicTest.java >> test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java >> test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Reverted few formattings. Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27388#pullrequestreview-3263814515 From mchhipa at openjdk.org Wed Sep 24 17:51:24 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Wed, 24 Sep 2025 17:51:24 GMT Subject: Integrated: 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 10:44:36 GMT, Mahendra Chhipa wrote: > Refactoring following httpclient/http2 testng test to JUnit : > test/jdk/java/net/httpclient/http2/BadHeadersTest.java > test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java > test/jdk/java/net/httpclient/http2/BasicTest.java > test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java > test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java This pull request has now been integrated. Changeset: 7fe71a78 Author: Mahendra Chhipa URL: https://git.openjdk.org/jdk/commit/7fe71a78137991d26553b6d5e0d4d74900f01ba3 Stats: 133 lines in 5 files changed: 5 ins; 30 del; 98 mod 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/27388 From vyazici at openjdk.org Thu Sep 25 07:17:40 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 25 Sep 2025 07:17:40 GMT Subject: RFR: 8368546: java/net/httpclient/RedirectTimeoutTest.java fails intermittently for HTTP/3 in tier7 In-Reply-To: <_oWb6uqUdup6KnPdMaN1KmWxFAYlkn8eyEGwJcbSbcM=.8c81a67f-99f3-4051-856c-2ffe121c662a@github.com> References: <_oWb6uqUdup6KnPdMaN1KmWxFAYlkn8eyEGwJcbSbcM=.8c81a67f-99f3-4051-856c-2ffe121c662a@github.com> Message-ID: On Wed, 24 Sep 2025 13:57:04 GMT, Daniel Fuchs wrote: > The java/net/httpclient/RedirectTimeoutTest.java has been observed failing (once) for HTTP/3 on Windows in tier 7 (debug builds) > > The log reveals that it's the HEAD request used for warmup that is failing in timeout. This was surprising as this HEAD request was not supposed to be configured with a timeout, and a reading of the test code revealed that a non-obvious call to HttpRequest.Builder::copy was missing in the test. I added that call, which should fix the issue. Marked as reviewed by vyazici (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27471#pullrequestreview-3266123092 From yuval.l at securithings.com Thu Sep 25 06:09:02 2025 From: yuval.l at securithings.com (Yuval Lombard) Date: Thu, 25 Sep 2025 09:09:02 +0300 Subject: InetAddress.isReachable fix ETA In-Reply-To: <1c6fce1b-9a18-4a29-b913-3ea763b63fcf@oracle.com> References: <303E017C-91AD-43CE-911D-2D83D8BB91A7@me.com> <1c6fce1b-9a18-4a29-b913-3ea763b63fcf@oracle.com> Message-ID: Hey Team Is there an ETA for addressing the mentioned issue? https://bugs.openjdk.org/browse/JDK-8357160 > > On 20/09/2025 15:24, Yuval Lombard wrote: > > Hello team, > > > > Is there an estimated time/jdk release for fixing the InetAddress > > isReachable issue? > > > net-dev would be a better replace to discuss this. As I mentioned in > JDK-8357160 [1], I think it would be useful to know if it common for > deployments to have CAP_NET_RAW/equivalent or whether the TCP > implementation is more commonly used. If the TCP implementation were to > re-written in Java (not hard) then it would be "virtual thread friendly" > in the sense that waiting for SYN-ACK would release the carrier to do > other work. > > -Alan > > [1] https://bugs.openjdk.org/browse/JDK-8357160 -- Kind regards, *Yuval Lombard* *Staff Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From dfuchs at openjdk.org Thu Sep 25 09:46:21 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 25 Sep 2025 09:46:21 GMT Subject: Integrated: 8368546: java/net/httpclient/RedirectTimeoutTest.java fails intermittently for HTTP/3 in tier7 In-Reply-To: <_oWb6uqUdup6KnPdMaN1KmWxFAYlkn8eyEGwJcbSbcM=.8c81a67f-99f3-4051-856c-2ffe121c662a@github.com> References: <_oWb6uqUdup6KnPdMaN1KmWxFAYlkn8eyEGwJcbSbcM=.8c81a67f-99f3-4051-856c-2ffe121c662a@github.com> Message-ID: On Wed, 24 Sep 2025 13:57:04 GMT, Daniel Fuchs wrote: > The java/net/httpclient/RedirectTimeoutTest.java has been observed failing (once) for HTTP/3 on Windows in tier 7 (debug builds) > > The log reveals that it's the HEAD request used for warmup that is failing in timeout. This was surprising as this HEAD request was not supposed to be configured with a timeout, and a reading of the test code revealed that a non-obvious call to HttpRequest.Builder::copy was missing in the test. I added that call, which should fix the issue. This pull request has now been integrated. Changeset: d85e410c Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/d85e410c191bdcc8c20498f1c3c4516193bc79dd Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8368546: java/net/httpclient/RedirectTimeoutTest.java fails intermittently for HTTP/3 in tier7 Reviewed-by: jpai, syan, djelinski, vyazici ------------- PR: https://git.openjdk.org/jdk/pull/27471 From jaikiran.pai at oracle.com Thu Sep 25 12:18:43 2025 From: jaikiran.pai at oracle.com (Jaikiran Pai) Date: Thu, 25 Sep 2025 17:48:43 +0530 Subject: InetAddress.isReachable fix ETA In-Reply-To: References: <303E017C-91AD-43CE-911D-2D83D8BB91A7@me.com> <1c6fce1b-9a18-4a29-b913-3ea763b63fcf@oracle.com> Message-ID: Hello Yuval, Can you provide some details (including any relevant application code snippet) on what issue you are running into? The linked JBS issue is an enhancement raised in context of a specific virtual thread usage that was discussed in the mailing lists (the links to those are available in the JBS issue's comment). Are you using virtual threads in your application? How/where does InetAddress.isReachable() get used in your application? Is the issue you are running into applicable even for platform threads? Which version of Java is your application using? -Jaikiran On 25/09/25 11:39 am, Yuval Lombard wrote: > Hey Team > > Is there an ETA for addressing the mentioned issue? > > https://bugs.openjdk.org/browse/JDK-8357160 > > > On 20/09/2025 15:24, Yuval Lombard wrote: > > Hello team, > > > > Is there an estimated time/jdk release for fixing the InetAddress > > isReachable issue? > > > net-dev would be a better replace to discuss this. As I mentioned in > JDK-8357160 [1], I think it would be useful to know if it common for > deployments to have CAP_NET_RAW/equivalent or whether the TCP > implementation is more commonly used. If the TCP implementation > were to > re-written in Java (not hard) then it would be "virtual thread > friendly" > in the sense that waiting for SYN-ACK would release the carrier to do > other work. > > -Alan > > [1] https://bugs.openjdk.org/browse/JDK-8357160 > > > > -- > > Kind regards,* > > Yuval Lombard* > > *Staff Software Engineer* > > +972.50.548.0111 > > yuval.l at securithings.com > > logo_black.png > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From duke at openjdk.org Thu Sep 25 12:44:33 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 12:44:33 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v15] In-Reply-To: References: Message-ID: > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: - Merge branch 'openjdk:master' into jdk-8360498 - Removes not needed changes - Revert "Removes not needed changes" This reverts commit e76780d50cc390e35443dccb193cfbc9a1cec1cb. - Removes not needed changes - Removes extra white lines - Merge branch 'pr/25971' into jdk-8360498 - Merge branch 'openjdk:master' into jdk-8158801 - Merge branch 'pr/25971' into jdk-8360498 - Merge branch 'openjdk:master' into jdk-8158801 - Centers missed frames in the middle of screen - ... and 64 more: https://git.openjdk.org/jdk/compare/26b5708c...e5753d14 ------------- Changes: https://git.openjdk.org/jdk/pull/26625/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14 Stats: 185 lines in 14 files changed: 96 ins; 44 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From duke at openjdk.org Thu Sep 25 13:03:51 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 13:03:51 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16] In-Reply-To: References: Message-ID: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: Resolves confict for when there is a merge with jdk-8158801 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26625/files - new: https://git.openjdk.org/jdk/pull/26625/files/e5753d14..8794db9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14-15 Stats: 55 lines in 1 file changed: 36 ins; 3 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From alanb at openjdk.org Thu Sep 25 13:30:34 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Sep 2025 13:30:34 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16] In-Reply-To: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> References: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> Message-ID: On Thu, 25 Sep 2025 13:03:51 GMT, Khalid Boulanouare wrote: >> This PR will consolidate fixes of the following bugs: >> >> https://bugs.openjdk.org/browse/JDK-8361188 >> https://bugs.openjdk.org/browse/JDK-8361189 >> https://bugs.openjdk.org/browse/JDK-8361190 >> https://bugs.openjdk.org/browse/JDK-8361191 >> https://bugs.openjdk.org/browse/JDK-8361192 >> https://bugs.openjdk.org/browse/JDK-8361193 >> https://bugs.openjdk.org/browse/JDK-8361195 >> >> This PR depends on https://github.com/openjdk/jdk/pull/25971 >> >> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) >> >> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 >> >> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 >> >> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 >> >> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 > > Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: > > Resolves confict for when there is a merge with jdk-8158801 What is this about? The PR suggests 500+ commits and 300+ files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334044893 From duke at openjdk.org Thu Sep 25 14:00:08 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 14:00:08 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v17] In-Reply-To: References: Message-ID: > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'openjdk:master' into jdk-8360498 - 8359378: aarch64: crash when using -XX:+UseFPUForSpilling Reviewed-by: aph, rcastanedalo - 8367103: RISC-V: store cpu features in a bitmap Reviewed-by: fyang, luhenry ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26625/files - new: https://git.openjdk.org/jdk/pull/26625/files/8794db9a..69c087a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15-16 Stats: 214 lines in 3 files changed: 142 ins; 4 del; 68 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From duke at openjdk.org Thu Sep 25 14:00:10 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 14:00:10 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16] In-Reply-To: References: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> Message-ID: On Thu, 25 Sep 2025 13:26:46 GMT, Alan Bateman wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Resolves confict for when there is a merge with jdk-8158801 > > What is this about? The PR suggests 500+ commits and 300+ files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists. @AlanBateman This PR is created based on PR https://github.com/openjdk/jdk/tree/pr/25971. My branch https://github.com/kboulanou/jdk/tree/jdk-8360498 is only 2 commits behind master. I am waiting for approval for PR https://github.com/openjdk/jdk/tree/pr/25971 for this PR to follow. Please let me know if there is anything I need to do. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334251324 From syan at openjdk.org Thu Sep 25 14:34:00 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 25 Sep 2025 14:34:00 GMT Subject: RFR: 8368552: H3ErrorHandlingTest.testCloseControlStream intermittent timed out In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 14:47:31 GMT, Daniel Fuchs wrote: >> Hi all, >> >> H3ErrorHandlingTest.testCloseControlStream(java/net/httpclient/http3/H3ErrorHandlingTest.java) intermittent timed out with fastdebug build on linux-x64. >> This PR use Utils.adjustTimeout to receive the timeout factor from jtreg, and change the default timeout value in 'triggerError' function from 10 to 20 to make test run passed steady with fastdebug build. >> >> I run this test 120 times simultancely all passed after this PR with fastdebug build. > > Thanks! The proposed changes look reasonable to me. Thanks for the reviews @dfuch ------------- PR Comment: https://git.openjdk.org/jdk/pull/27472#issuecomment-3334453133 From syan at openjdk.org Thu Sep 25 14:34:01 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 25 Sep 2025 14:34:01 GMT Subject: Integrated: 8368552: H3ErrorHandlingTest.testCloseControlStream intermittent timed out In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 14:09:09 GMT, SendaoYan wrote: > Hi all, > > H3ErrorHandlingTest.testCloseControlStream(java/net/httpclient/http3/H3ErrorHandlingTest.java) intermittent timed out with fastdebug build on linux-x64. > This PR use Utils.adjustTimeout to receive the timeout factor from jtreg, and change the default timeout value in 'triggerError' function from 10 to 20 to make test run passed steady with fastdebug build. > > I run this test 120 times simultancely all passed after this PR with fastdebug build. This pull request has now been integrated. Changeset: 043aeaf0 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/043aeaf02a50a7413e1956a99341d04ea3f9ac92 Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod 8368552: H3ErrorHandlingTest.testCloseControlStream intermittent timed out Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/27472 From dfuchs at openjdk.org Thu Sep 25 16:01:15 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 25 Sep 2025 16:01:15 GMT Subject: RFR: 8368630: java/net/httpclient/http3/H3ServerPushTest.java succeeds but fails in jtreg timeout Message-ID: Hi, The H3ServerPushTest.java has been observed failing once in the CI on a personal job. Analysis reveals that the test actually passed, but the timeout handler killed the test. SUCCESSFUL H3ServerPushTest::testExcessivePushResponsesWithDistinctIdsInOneResponse 'testExcessivePushResponsesWithDistinctIdsInOneResponse(TestInfo)' [2840ms] [ JUnit Containers: found 4, started 4, succeeded 4, failed 0, aborted 0, skipped 0] [ JUnit Tests: found 17, started 17, succeeded 17, failed 0, aborted 0, skipped 0] JavaTest Message: Test complete. ... result: Error. "junit" action timed out with a timeout of 120 seconds on agent 23 test result: Error. "junit" action timed out with a timeout of 120 seconds on agent 23 This is probably attributable to the change of timeoutFactor to timeoutFactor=1, this change proposes to use othervm double the default timeout for that test to `/othervm/timeout=120` . ------------- Commit messages: - 8368630: java/net/httpclient/http3/H3ServerPushTest.java succeeds but fails in jtreg timeout Changes: https://git.openjdk.org/jdk/pull/27492/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27492&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368630 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27492.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27492/head:pull/27492 PR: https://git.openjdk.org/jdk/pull/27492 From dfuchs at openjdk.org Thu Sep 25 16:31:31 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 25 Sep 2025 16:31:31 GMT Subject: RFR: 8368630: java/net/httpclient/http3/H3ServerPushTest.java succeeds but fails in jtreg timeout [v2] In-Reply-To: References: Message-ID: > Hi, > > The H3ServerPushTest.java has been observed failing once in the CI on a personal job. > Analysis reveals that the test actually passed, but the timeout handler killed the test. > > > SUCCESSFUL H3ServerPushTest::testExcessivePushResponsesWithDistinctIdsInOneResponse 'testExcessivePushResponsesWithDistinctIdsInOneResponse(TestInfo)' [2840ms] > > [ JUnit Containers: found 4, started 4, succeeded 4, failed 0, aborted 0, skipped 0] > [ JUnit Tests: found 17, started 17, succeeded 17, failed 0, aborted 0, skipped 0] > > JavaTest Message: Test complete. > ... > result: Error. "junit" action timed out with a timeout of 120 seconds on agent 23 > > test result: Error. "junit" action timed out with a timeout of 120 seconds on agent 23 > > > This is probably attributable to the change of timeoutFactor to timeoutFactor=1, this change proposes to use othervm double the default timeout for that test to `/othervm/timeout=240` . Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: Really change timeout ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27492/files - new: https://git.openjdk.org/jdk/pull/27492/files/388db3dc..93df2f6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27492&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27492&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27492.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27492/head:pull/27492 PR: https://git.openjdk.org/jdk/pull/27492 From srayan.jana at outlook.com Fri Sep 26 06:00:48 2025 From: srayan.jana at outlook.com (Srayan Jana) Date: Fri, 26 Sep 2025 06:00:48 +0000 Subject: Exposing QUIC API in Java Message-ID: Hello! (Alan Bateman told me to post here instead) I recently heard that Java is getting HTTP/3 support in Java 26 through JEP 517. That's really cool! However, I saw in the non goals that this won't include the QUIC API itself. Is that going to be in a follow up JEP? I'm interested in QUIC for multimedia and gaming related applications. See: https://moq.dev/ https://developer.mozilla.org/en-US/docs/Web/API/WebTransport https://github.com/MOZGIII/xwt https://daposto.medium.com/quic-for-gamenetworking-46cf23936228 Will QUIC/Webtransport be added to Java as well? It would be nice to be able to have a quinn (https://github.com/quinn-rs/quinn) style API in Java with unreliable datagrams and other additional features that QUIC enables. You could even do an Iroh (https://github.com/n0-computer/iroh) implementation in Java! How would this work? Would QUIC be added as the "third" network transport layer besides TCP and UDP? Or would it require its own separate API in order to use it? I really think it's a good idea for future improvements to be added to QUIC support in Java, since I think it will allow unlocking a lot of interesting use cases -------------- next part -------------- An HTML attachment was scrubbed... URL: From myankelevich at openjdk.org Mon Sep 29 10:28:19 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 29 Sep 2025 10:28:19 GMT Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v3] In-Reply-To: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> Message-ID: > Tests changed in this PR: > 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java > 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java > 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java > 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java > 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java > 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java > 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java > 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java > 12. test/jdk/sun/security/rsa/InvalidBitString.java > 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java > 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java > 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java > > PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326) Mikhail Yankelevich has updated the pull request incrementally with 364 additional commits since the last revision: - removed pemrecord usage - 8365190: Remove LockingMode related code from share Reviewed-by: aboldtch, dholmes, ayang, coleenp, lmesnik, rcastanedalo - 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp Reviewed-by: aboldtch, tschatzl, jwaters - 8360219: [AIX] assert(locals_base >= l2) failed: bad placement Reviewed-by: dlong, mdoerr - 8366864: Sort os/linux includes Reviewed-by: ayang, dholmes - 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages Reviewed-by: ayang, shade, stefank, tschatzl - 8351260: java.lang.AssertionError: Unexpected type tree: (ERROR) = (ERROR) Reviewed-by: vromero - 8365776: Convert JShell tests to use JUnit instead of TestNG Reviewed-by: vromero - 8354871: Replace stack map frame type magics with constants Reviewed-by: liach - 8361533: Apply java.io.Serial annotations in java.logging Reviewed-by: rriggs - ... and 354 more: https://git.openjdk.org/jdk/compare/d44cb277...e0be5eaa ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27194/files - new: https://git.openjdk.org/jdk/pull/27194/files/d44cb277..e0be5eaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=01-02 Stats: 53711 lines in 1891 files changed: 31453 ins; 14034 del; 8224 mod Patch: https://git.openjdk.org/jdk/pull/27194.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27194/head:pull/27194 PR: https://git.openjdk.org/jdk/pull/27194 From syan at openjdk.org Mon Sep 29 13:34:45 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 29 Sep 2025 13:34:45 GMT Subject: RFR: 8368630: java/net/httpclient/http3/H3ServerPushTest.java succeeds but fails in jtreg timeout [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 16:31:31 GMT, Daniel Fuchs wrote: >> Hi, >> >> The H3ServerPushTest.java has been observed failing once in the CI on a personal job. >> Analysis reveals that the test actually passed, but the timeout handler killed the test. >> >> >> SUCCESSFUL H3ServerPushTest::testExcessivePushResponsesWithDistinctIdsInOneResponse 'testExcessivePushResponsesWithDistinctIdsInOneResponse(TestInfo)' [2840ms] >> >> [ JUnit Containers: found 4, started 4, succeeded 4, failed 0, aborted 0, skipped 0] >> [ JUnit Tests: found 17, started 17, succeeded 17, failed 0, aborted 0, skipped 0] >> >> JavaTest Message: Test complete. >> ... >> result: Error. "junit" action timed out with a timeout of 120 seconds on agent 23 >> >> test result: Error. "junit" action timed out with a timeout of 120 seconds on agent 23 >> >> >> This is probably attributable to the change of timeoutFactor to timeoutFactor=1, this change proposes to use othervm double the default timeout for that test to `/othervm/timeout=240` . > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Really change timeout LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/27492#pullrequestreview-3279840546 From jpai at openjdk.org Tue Sep 30 06:44:48 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 30 Sep 2025 06:44:48 GMT Subject: RFR: 8368630: java/net/httpclient/http3/H3ServerPushTest.java succeeds but fails in jtreg timeout [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 16:31:31 GMT, Daniel Fuchs wrote: >> Hi, >> >> The H3ServerPushTest.java has been observed failing once in the CI on a personal job. >> Analysis reveals that the test actually passed, but the timeout handler killed the test. >> >> >> SUCCESSFUL H3ServerPushTest::testExcessivePushResponsesWithDistinctIdsInOneResponse 'testExcessivePushResponsesWithDistinctIdsInOneResponse(TestInfo)' [2840ms] >> >> [ JUnit Containers: found 4, started 4, succeeded 4, failed 0, aborted 0, skipped 0] >> [ JUnit Tests: found 17, started 17, succeeded 17, failed 0, aborted 0, skipped 0] >> >> JavaTest Message: Test complete. >> ... >> result: Error. "junit" action timed out with a timeout of 120 seconds on agent 23 >> >> test result: Error. "junit" action timed out with a timeout of 120 seconds on agent 23 >> >> >> This is probably attributable to the change of timeoutFactor to timeoutFactor=1, this change proposes to use othervm double the default timeout for that test to `/othervm/timeout=240` . > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Really change timeout Hello Daniel, this looks OK to me, but is the addition of `othervm` intentional? The PR description seems to suggest it is, but I couldn't see why that would be needed. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27492#pullrequestreview-3282829642