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 > ? > ?