From jpai at openjdk.org Fri Jul 1 03:10:42 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 1 Jul 2022 03:10:42 GMT Subject: RFR: JDK-8286610: Add additional diagnostic output to java/net/DatagramSocket/InterruptibleDatagramSocket.java [v5] In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 16:54:53 GMT, Bill Huang wrote: >> Failure was observed on java/net/DatagramSocket/InterruptibleDatagramSocket.java where data was received unexpectedly ( [JDK-8286607](https://bugs.openjdk.org/browse/JDK-8286607)). This failure could be caused by interference from other ongoing tests. The fix here is to output the unexpected received data and the sender's address for a further investigation ([JDK-8286610](https://bugs.openjdk.org/browse/JDK-8286610)). > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright header. Thank you for doing these changes, Bill. The latest state of this PR looks fine to me. Please go ahead and issue a /integrate command and one of us will then sponsor this. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/9278 From dfuchs at openjdk.org Fri Jul 1 15:59:46 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 1 Jul 2022 15:59:46 GMT Subject: RFR: 8287593: ShortResponseBody could be made more resilient to rogue connections [v2] In-Reply-To: <_kBEAdCuO1qj2WLiKdhAQbK4GUMevIrzabm2pyKkNEM=.48d1287a-19db-4b6e-b15c-3e6d64f5829f@github.com> References: <35kMOuey95Vu1_eWR2hnDLnPhE60fvYrN3dcxg9DQZo=.1b4fc8ab-a66c-4e9f-84f2-24d650d61dec@github.com> <_kBEAdCuO1qj2WLiKdhAQbK4GUMevIrzabm2pyKkNEM=.48d1287a-19db-4b6e-b15c-3e6d64f5829f@github.com> Message-ID: On Thu, 30 Jun 2022 14:26:23 GMT, Ryan Ernst wrote: >> Since ReplyingServer binds to an open port on the system where tests >> run, it is possible some other program probes that port while the test >> is running. If the probe request does not have request params, the >> request is invalid and a test assertion fails. This commit replaces that >> assertion with returning a 400 response. > > Ryan Ernst 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 two additional commits since the last revision: > > - Merge branch 'master' into httpclient_test_assert > - 8287593: ShortResponseBody could be made more resilient to rogue connections > > Since ReplyingServer binds to an open port on the system where tests > run, it is possible some other program probes that port while the test > is running. If the probe request does not have request params, the > request is invalid and a test assertion fails. This commit replaces that > assertion with returning a 400 response. test/jdk/java/net/httpclient/ShortResponseBody.java line 531: > 529: if (query == null) { > 530: out.println("Request headers: [" + headers + "]"); > 531: writeResponse(s, BAD_REQUEST_RESPONSE, BAD_REQUEST_RESPONSE.length()); I'd suggest improving the log message above to say that an unexpected request has been received, and then add a second line to say "Replying with 400 Bad Request". Otherwise this looks reasonable to me. Sending 400 is a good idea. ------------- PR: https://git.openjdk.org/jdk/pull/9329 From duke at openjdk.org Fri Jul 1 17:55:54 2022 From: duke at openjdk.org (Ryan Ernst) Date: Fri, 1 Jul 2022 17:55:54 GMT Subject: RFR: 8287593: ShortResponseBody could be made more resilient to rogue connections [v3] In-Reply-To: <35kMOuey95Vu1_eWR2hnDLnPhE60fvYrN3dcxg9DQZo=.1b4fc8ab-a66c-4e9f-84f2-24d650d61dec@github.com> References: <35kMOuey95Vu1_eWR2hnDLnPhE60fvYrN3dcxg9DQZo=.1b4fc8ab-a66c-4e9f-84f2-24d650d61dec@github.com> Message-ID: > Since ReplyingServer binds to an open port on the system where tests > run, it is possible some other program probes that port while the test > is running. If the probe request does not have request params, the > request is invalid and a test assertion fails. This commit replaces that > assertion with returning a 400 response. Ryan Ernst 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 four additional commits since the last revision: - Merge branch 'master' into httpclient_test_assert - better log message - Merge branch 'master' into httpclient_test_assert - 8287593: ShortResponseBody could be made more resilient to rogue connections Since ReplyingServer binds to an open port on the system where tests run, it is possible some other program probes that port while the test is running. If the probe request does not have request params, the request is invalid and a test assertion fails. This commit replaces that assertion with returning a 400 response. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9329/files - new: https://git.openjdk.org/jdk/pull/9329/files/46125a78..8e91bd44 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9329&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9329&range=01-02 Stats: 1157 lines in 27 files changed: 1066 ins; 18 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/9329.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9329/head:pull/9329 PR: https://git.openjdk.org/jdk/pull/9329 From duke at openjdk.org Fri Jul 1 17:55:57 2022 From: duke at openjdk.org (Ryan Ernst) Date: Fri, 1 Jul 2022 17:55:57 GMT Subject: RFR: 8287593: ShortResponseBody could be made more resilient to rogue connections [v2] In-Reply-To: References: <35kMOuey95Vu1_eWR2hnDLnPhE60fvYrN3dcxg9DQZo=.1b4fc8ab-a66c-4e9f-84f2-24d650d61dec@github.com> <_kBEAdCuO1qj2WLiKdhAQbK4GUMevIrzabm2pyKkNEM=.48d1287a-19db-4b6e-b15c-3e6d64f5829f@github.com> Message-ID: On Fri, 1 Jul 2022 15:53:57 GMT, Daniel Fuchs wrote: >> Ryan Ernst 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 two additional commits since the last revision: >> >> - Merge branch 'master' into httpclient_test_assert >> - 8287593: ShortResponseBody could be made more resilient to rogue connections >> >> Since ReplyingServer binds to an open port on the system where tests >> run, it is possible some other program probes that port while the test >> is running. If the probe request does not have request params, the >> request is invalid and a test assertion fails. This commit replaces that >> assertion with returning a 400 response. > > test/jdk/java/net/httpclient/ShortResponseBody.java line 531: > >> 529: if (query == null) { >> 530: out.println("Request headers: [" + headers + "]"); >> 531: writeResponse(s, BAD_REQUEST_RESPONSE, BAD_REQUEST_RESPONSE.length()); > > I'd suggest improving the log message above to say that an unexpected request has been received, and then add a second line to say "Replying with 400 Bad Request". > Otherwise this looks reasonable to me. Sending 400 is a good idea. I pushed [c08924b](https://github.com/openjdk/jdk/pull/9329/commits/c08924bf9e8e8153981f8d75318b510cca873452) ------------- PR: https://git.openjdk.org/jdk/pull/9329 From aturbanov at openjdk.org Sat Jul 2 15:29:33 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sat, 2 Jul 2022 15:29:33 GMT Subject: Integrated: 8289385: Cleanup redundant synchronization in Http2ClientImpl In-Reply-To: References: Message-ID: <7iX5P2Xy-Q-01eeBkwgJYh8h29Id3S9qKAqrnMcBs-Q=.9d257dd5-454e-4796-b5de-0b66e60592ca@github.com> On Tue, 28 Jun 2022 18:44:38 GMT, Andrey Turbanov wrote: > Http2ClientImpl.stopping and Http2ClientImpl.failures are always accessed under synchronized(this). > So we can remove 'volatile' modifier from 'stopping'. And remove 'synchronizedSet' wrapper from 'failures' This pull request has now been integrated. Changeset: dee5121b Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/dee5121bd4b079abb28337395be2d5dd8bbf2f11 Stats: 6 lines in 1 file changed: 3 ins; 1 del; 2 mod 8289385: Cleanup redundant synchronization in Http2ClientImpl Reviewed-by: jpai, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/9311 From duke at openjdk.org Sat Jul 2 18:43:52 2022 From: duke at openjdk.org (kristylee88) Date: Sat, 2 Jul 2022 18:43:52 GMT Subject: RFR: 8289385: Cleanup redundant synchronization in Http2ClientImpl [v2] In-Reply-To: <-0aVAMHvKi4Zy6Jn3C1ur0D8nv4gsfllOVcvdYMeY7Q=.20b5eb1c-5364-4f49-90bf-e8bfcf05eea6@github.com> References: <-0aVAMHvKi4Zy6Jn3C1ur0D8nv4gsfllOVcvdYMeY7Q=.20b5eb1c-5364-4f49-90bf-e8bfcf05eea6@github.com> Message-ID: <_wmRALtazMVHdsIXq_cVtVtv35T_H_3tLhRHpZrNNpY=.471110ce-1797-40c2-8ddf-c56281471d25@github.com> On Wed, 29 Jun 2022 20:57:14 GMT, Andrey Turbanov wrote: >> Http2ClientImpl.stopping and Http2ClientImpl.failures are always accessed under synchronized(this). >> So we can remove 'volatile' modifier from 'stopping'. And remove 'synchronizedSet' wrapper from 'failures' > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8289385: Cleanup redundant synchronization in Http2ClientImpl > add comments Marked as reviewed by kristylee88 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/9311 From duke at openjdk.org Sun Jul 3 05:23:42 2022 From: duke at openjdk.org (kristylee88) Date: Sun, 3 Jul 2022 05:23:42 GMT Subject: RFR: JDK-8286610: Add additional diagnostic output to java/net/DatagramSocket/InterruptibleDatagramSocket.java [v5] In-Reply-To: References: Message-ID: <-dBNqKfHd7IZHoxAZS7ubp5cc08fwPjfqG_mDTNikE8=.722a064d-5930-4d41-b57f-12bda3154b36@github.com> On Thu, 30 Jun 2022 16:54:53 GMT, Bill Huang wrote: >> Failure was observed on java/net/DatagramSocket/InterruptibleDatagramSocket.java where data was received unexpectedly ( [JDK-8286607](https://bugs.openjdk.org/browse/JDK-8286607)). This failure could be caused by interference from other ongoing tests. The fix here is to output the unexpected received data and the sender's address for a further investigation ([JDK-8286610](https://bugs.openjdk.org/browse/JDK-8286610)). > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright header. Marked as reviewed by kristylee88 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/9278 From duke at openjdk.org Sun Jul 3 01:26:45 2022 From: duke at openjdk.org (kristylee88) Date: Sun, 3 Jul 2022 01:26:45 GMT Subject: RFR: 8289385: Cleanup redundant synchronization in Http2ClientImpl [v2] In-Reply-To: <-0aVAMHvKi4Zy6Jn3C1ur0D8nv4gsfllOVcvdYMeY7Q=.20b5eb1c-5364-4f49-90bf-e8bfcf05eea6@github.com> References: <-0aVAMHvKi4Zy6Jn3C1ur0D8nv4gsfllOVcvdYMeY7Q=.20b5eb1c-5364-4f49-90bf-e8bfcf05eea6@github.com> Message-ID: <4Y8fPsUkLe-vCnkK02MmdwCEqWBQ62kMOBdOjcQFFGU=.dc49fe36-2097-4b17-8574-f3b7d3783bdd@github.com> On Wed, 29 Jun 2022 20:57:14 GMT, Andrey Turbanov wrote: >> Http2ClientImpl.stopping and Http2ClientImpl.failures are always accessed under synchronized(this). >> So we can remove 'volatile' modifier from 'stopping'. And remove 'synchronizedSet' wrapper from 'failures' > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8289385: Cleanup redundant synchronization in Http2ClientImpl > add comments Marked as reviewed by kristylee88 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/9311 From duke at openjdk.org Sun Jul 3 02:41:34 2022 From: duke at openjdk.org (Bill Huang) Date: Sun, 3 Jul 2022 02:41:34 GMT Subject: Integrated: JDK-8286610: Add additional diagnostic output to java/net/DatagramSocket/InterruptibleDatagramSocket.java In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 14:31:59 GMT, Bill Huang wrote: > Failure was observed on java/net/DatagramSocket/InterruptibleDatagramSocket.java where data was received unexpectedly ( [JDK-8286607](https://bugs.openjdk.org/browse/JDK-8286607)). This failure could be caused by interference from other ongoing tests. The fix here is to output the unexpected received data and the sender's address for a further investigation ([JDK-8286610](https://bugs.openjdk.org/browse/JDK-8286610)). This pull request has now been integrated. Changeset: d8444aa4 Author: Bill Huang Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/d8444aa45ef10279f5ca034bb522e92411f07255 Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod 8286610: Add additional diagnostic output to java/net/DatagramSocket/InterruptibleDatagramSocket.java Reviewed-by: msheppar, dfuchs, jpai ------------- PR: https://git.openjdk.org/jdk/pull/9278 From dfuchs at openjdk.org Mon Jul 4 08:31:51 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 4 Jul 2022 08:31:51 GMT Subject: RFR: 8287593: ShortResponseBody could be made more resilient to rogue connections [v3] In-Reply-To: References: <35kMOuey95Vu1_eWR2hnDLnPhE60fvYrN3dcxg9DQZo=.1b4fc8ab-a66c-4e9f-84f2-24d650d61dec@github.com> Message-ID: On Fri, 1 Jul 2022 17:55:54 GMT, Ryan Ernst wrote: >> Since ReplyingServer binds to an open port on the system where tests >> run, it is possible some other program probes that port while the test >> is running. If the probe request does not have request params, the >> request is invalid and a test assertion fails. This commit replaces that >> assertion with returning a 400 response. > > Ryan Ernst 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 four additional commits since the last revision: > > - Merge branch 'master' into httpclient_test_assert > - better log message > - Merge branch 'master' into httpclient_test_assert > - 8287593: ShortResponseBody could be made more resilient to rogue connections > > Since ReplyingServer binds to an open port on the system where tests > run, it is possible some other program probes that port while the test > is running. If the probe request does not have request params, the > request is invalid and a test assertion fails. This commit replaces that > assertion with returning a 400 response. Thanks for the updates! LGTM. Make sure to run tier2 before integrating. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9329 From michaelm at openjdk.org Mon Jul 4 13:12:52 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 4 Jul 2022 13:12:52 GMT Subject: RFR: 8289617: Remove test/jdk/java/net/ServerSocket/ThreadStop.java Message-ID: Hi, Could I get the following small change reviewed please? It removes a test that calls Thread.stop() which is no longer required since it was checking for a bug in the old SocketImpl that has recently been replaced by the NIO implementation. Thanks, Michael. ------------- Commit messages: - deleted redundant test Changes: https://git.openjdk.org/jdk/pull/9365/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9365&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289617 Stats: 91 lines in 1 file changed: 0 ins; 91 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9365.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9365/head:pull/9365 PR: https://git.openjdk.org/jdk/pull/9365 From alanb at openjdk.org Mon Jul 4 15:02:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Jul 2022 15:02:40 GMT Subject: RFR: 8289617: Remove test/jdk/java/net/ServerSocket/ThreadStop.java In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 13:03:46 GMT, Michael McMahon wrote: > Hi, > > Could I get the following small change reviewed please? > > It removes a test that calls Thread.stop() which is no longer required since it was checking for > a bug in the old SocketImpl that has recently been replaced by the NIO implementation. > > Thanks, > Michael. No value keeping this test. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/9365 From chegar at openjdk.org Mon Jul 4 16:00:44 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Mon, 4 Jul 2022 16:00:44 GMT Subject: RFR: 8287593: ShortResponseBody could be made more resilient to rogue connections [v3] In-Reply-To: References: <35kMOuey95Vu1_eWR2hnDLnPhE60fvYrN3dcxg9DQZo=.1b4fc8ab-a66c-4e9f-84f2-24d650d61dec@github.com> Message-ID: On Fri, 1 Jul 2022 17:55:54 GMT, Ryan Ernst wrote: >> Since ReplyingServer binds to an open port on the system where tests >> run, it is possible some other program probes that port while the test >> is running. If the probe request does not have request params, the >> request is invalid and a test assertion fails. This commit replaces that >> assertion with returning a 400 response. > > Ryan Ernst 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 four additional commits since the last revision: > > - Merge branch 'master' into httpclient_test_assert > - better log message > - Merge branch 'master' into httpclient_test_assert > - 8287593: ShortResponseBody could be made more resilient to rogue connections > > Since ReplyingServer binds to an open port on the system where tests > run, it is possible some other program probes that port while the test > is running. If the probe request does not have request params, the > request is invalid and a test assertion fails. This commit replaces that > assertion with returning a 400 response. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9329 From duke at openjdk.org Mon Jul 4 16:13:44 2022 From: duke at openjdk.org (Ryan Ernst) Date: Mon, 4 Jul 2022 16:13:44 GMT Subject: Integrated: 8287593: ShortResponseBody could be made more resilient to rogue connections In-Reply-To: <35kMOuey95Vu1_eWR2hnDLnPhE60fvYrN3dcxg9DQZo=.1b4fc8ab-a66c-4e9f-84f2-24d650d61dec@github.com> References: <35kMOuey95Vu1_eWR2hnDLnPhE60fvYrN3dcxg9DQZo=.1b4fc8ab-a66c-4e9f-84f2-24d650d61dec@github.com> Message-ID: On Wed, 29 Jun 2022 19:26:21 GMT, Ryan Ernst wrote: > Since ReplyingServer binds to an open port on the system where tests > run, it is possible some other program probes that port while the test > is running. If the probe request does not have request params, the > request is invalid and a test assertion fails. This commit replaces that > assertion with returning a 400 response. This pull request has now been integrated. Changeset: 9ccae707 Author: Ryan Ernst Committer: Chris Hegarty URL: https://git.openjdk.org/jdk/commit/9ccae7078e22c27a8f84152f005c628534c9af53 Stats: 45 lines in 1 file changed: 37 ins; 6 del; 2 mod 8287593: ShortResponseBody could be made more resilient to rogue connections Reviewed-by: chegar, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/9329 From jpai at openjdk.org Tue Jul 5 06:10:30 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 5 Jul 2022 06:10:30 GMT Subject: RFR: 8289617: Remove test/jdk/java/net/ServerSocket/ThreadStop.java In-Reply-To: References: Message-ID: <8MesviRNK-DezzK6PdPLF0PtjnYYGZps2rY51VpU8hs=.138e18cc-9ef1-4d4f-9e77-438be8bf1220@github.com> On Mon, 4 Jul 2022 13:03:46 GMT, Michael McMahon wrote: > Hi, > > Could I get the following small change reviewed please? > > It removes a test that calls Thread.stop() which is no longer required since it was checking for > a bug in the old SocketImpl that has recently been replaced by the NIO implementation. > > Thanks, > Michael. Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9365 From michaelm at openjdk.org Tue Jul 5 09:19:40 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 5 Jul 2022 09:19:40 GMT Subject: Integrated: 8289617: Remove test/jdk/java/net/ServerSocket/ThreadStop.java In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 13:03:46 GMT, Michael McMahon wrote: > Hi, > > Could I get the following small change reviewed please? > > It removes a test that calls Thread.stop() which is no longer required since it was checking for > a bug in the old SocketImpl that has recently been replaced by the NIO implementation. > > Thanks, > Michael. This pull request has now been integrated. Changeset: 77c3bbf1 Author: Michael McMahon URL: https://git.openjdk.org/jdk/commit/77c3bbf105403089fec69d51406fe3e6f562271f Stats: 91 lines in 1 file changed: 0 ins; 91 del; 0 mod 8289617: Remove test/jdk/java/net/ServerSocket/ThreadStop.java Reviewed-by: alanb, jpai ------------- PR: https://git.openjdk.org/jdk/pull/9365 From djelinski at openjdk.org Tue Jul 5 21:06:58 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 5 Jul 2022 21:06:58 GMT Subject: RFR: 8289768: Clean up unused code Message-ID: This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. ------------- Commit messages: - Remove unused variables (windows) - Remove unused variables (macos) - Remove unused variables (linux) Changes: https://git.openjdk.org/jdk/pull/9383/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289768 Stats: 69 lines in 45 files changed: 0 ins; 65 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9383.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383 PR: https://git.openjdk.org/jdk/pull/9383 From dfuchs at openjdk.org Wed Jul 6 09:39:28 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 6 Jul 2022 09:39:28 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Changes to libnet look good. Please wait until you have obtained approvals from maintainers of the other areas to integrate, ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From duke at openjdk.org Wed Jul 6 05:44:04 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Wed, 6 Jul 2022 05:44:04 GMT Subject: RFR: 8272702: Resolving URI relative path with no / may lead to incorrect toString [v3] In-Reply-To: References: Message-ID: <39SFpsJLuDcIF5LbVUdKDzuq3CBzP2NjAnd_oEX9nBM=.bb624d3d-d666-4904-bb66-59bb779f89f8@github.com> On Fri, 17 Jun 2022 09:51:48 GMT, Daniel Fuchs wrote: >> @dfuch >> Could you review this fix again, please? > > I will have a look but analyzing the proposed fix and thinking about the potential side effects will take me some time. @dfuch I merged the latest source code and modified this fix again to resolve conflicts. Please check it again. ------------- PR: https://git.openjdk.org/jdk/pull/8899 From dfuchs at openjdk.org Wed Jul 6 14:45:41 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 6 Jul 2022 14:45:41 GMT Subject: RFR: 8282395: URL.openConnection can throw IOOBE [v2] In-Reply-To: References: <0fmDCk9p_r90kbSLWTgAyHgxt4vcujOdWkSyCTstESM=.a14f3a15-3c8b-4d3b-af47-0c42e8a2b24a@github.com> Message-ID: On Mon, 27 Jun 2022 05:31:47 GMT, KIRIYAMA Takuya wrote: >> src/java.base/share/classes/java/net/URL.java line 1101: >> >>> 1099: throw new MalformedURLException(e.getMessage()); >>> 1100: } >>> 1101: return url; >> >> Please revert the changes in java.net.URL. It's not the proper place to do the conversion. If a conversion is needed, it should take place in the handler. >> One possible experiment could be to change `ParseUtil::decode` to declare `throws MalformedURLException` and see what no longer compiles. If compilation passes - then maybe that's the way to go. If it doesn't - then we could analyze what to do on a case-by-case basis. > > @dfuch > Could you tell me your opinion based on this information, please? Let me try to summarize: there are several things that we could do: 1. nothing: continue throwing IIOBE 2. throw IAE instead of IIOBE, and let IAE trickle up the calling stack to the callers code 3. throw MUE instead of IIOBE, and then update all the places where ParseUtils::decode is called to either let the MUE trickle up the stack if possible, or deal with it if not. 4. throw IAE instead of IIOBE and somewhere up the stack catch that and transform it into MUE. 4.1. do the catch & transform in URL::openConnection when calling URLStreamHandler::openConnection 4.2. do the catch & transform in every protocol handler implementation that use ParseUtils::decode Now let's see pro & cons: 1. is not ideal because it looks like a bug (and it is) 2. is expedient. There seem to be some precedent for that since ParseUtils::decode already throws IAE if it can't parse the port. However IAE is not specified to be thrown by openConnection. So maybe we should update the specification of URL::openConnection and URLStreamHandler::openConnection to allow for IAE. This is however a bit strange to use IAE because in this case the URL is indeed malformed, so MUE would be more appropriate. 3. has the advantage of being clear, and force all callers of ParseUtils to deal with the situation. However, ParseUtils seems to be widely used, so each places where it's called needs to be examined, to see what would be the appropriate solution in each case 4. The advantage here is that callers of ParseUtils don't need to be changed if IAE is already appropriate for them. But those for which MUE would be more appropriate would beneficiate from having IAE transformed in MUE, which can be achieved by 4.1 or 4.2 4.1 the issue here is that URLStreamHandler::openConnection is not specified to throw IAE, yet we catch IAE that might be thrown by custom URLStreamHandler implementation not present in the JDK, where the IAE that they throw might have nothing to do with a Malformed URL. So we risk introducing regressions for applications that provide their own custom URLStreamHandlers implementations, and that might not expect the wrapping of the IAE they throw into MUE. I believe that if we did that it would need to be specified (in URL::openConnection) and it would require a CSR. 4.2 we need to examine all protocol handler present in the JDK and do the wrapping there. URLStreamHandler::openConnection is specified to throw IOException, so throwing MUE is within the bounds. However - if we don't have ParseUtils::decode throw MUE, we're not guaranteed not to miss some places. I'd say from a consistency point of view, 3. is probably best. Then failing that, from a compatibility vs consistency point of view 4.2 might be our best shot. 2. might be envisaged, but maybe at the expense of logging a follow up issue to clean that up and later decide between 3. or 4.2. I would tend to rule out 4.1 due to the possible compatibility issue, and also because if URLStreamHandler::openConnection wanted to throw MUE it could, so there is no reason for doing 4.1. ------------- PR: https://git.openjdk.org/jdk/pull/8155 From lancea at openjdk.org Wed Jul 6 15:35:39 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 6 Jul 2022 15:35:39 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) zlib looks fine given it is openjdk and not an upstream needed change ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From djelinski at openjdk.org Wed Jul 6 05:32:29 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Jul 2022 05:32:29 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: > This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. > > The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. > > I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. Daniel Jeli?ski 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 four additional commits since the last revision: - Merge remote-tracking branch 'origin' into unused-variables - Remove unused variables (windows) - Remove unused variables (macos) - Remove unused variables (linux) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9383/files - new: https://git.openjdk.org/jdk/pull/9383/files/915680c0..b4cd5374 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=00-01 Stats: 491 lines in 22 files changed: 458 ins; 5 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/9383.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383 PR: https://git.openjdk.org/jdk/pull/9383 From smarks at openjdk.org Thu Jul 7 00:34:45 2022 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 7 Jul 2022 00:34:45 GMT Subject: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v17] In-Reply-To: References: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com> Message-ID: On Wed, 1 Jun 2022 16:45:35 GMT, liach wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> do it as naotoj said > > 'the new' fix should be applied to newHashMap etc. too. @liach > 'the new' fix should be applied to newHashMap etc. too. I've filed [JDK-8289872](https://bugs.openjdk.org/browse/JDK-8289872) for this. It's a small thing but best to fix it before we forget about it. ------------- PR: https://git.openjdk.org/jdk/pull/8302 From weijun at openjdk.org Wed Jul 6 16:44:53 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 6 Jul 2022 16:44:53 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Changes in security (`java.security.jgss`, `jdk.crypto.cryptoki`, `jdk.crypto.mscapi`) look fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From duke at openjdk.org Wed Jul 6 05:44:02 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Wed, 6 Jul 2022 05:44:02 GMT Subject: RFR: 8272702: Resolving URI relative path with no / may lead to incorrect toString [v3] In-Reply-To: References: Message-ID: > Consider an authority component without trailing "/" as a base URI. When resolving a relative path against this base URI, the resulting URI is a concatenated URI without "/". > This behaviour should be fixed, which is rationalized by rfc3986#section-5.2.3. > Could you review this fix? KIRIYAMA Takuya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - 8272702: Resolving URI relative path with no / may lead to incorrect toString - 8272702: Resolving URI relative path with no / may lead to incorrect toString - 8272702: Resolving URI relative path with no / may lead to incorrect toString ------------- Changes: https://git.openjdk.org/jdk/pull/8899/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8899&range=02 Stats: 31 lines in 2 files changed: 23 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/8899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8899/head:pull/8899 PR: https://git.openjdk.org/jdk/pull/8899 From naoto at openjdk.org Wed Jul 6 19:46:33 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 6 Jul 2022 19:46:33 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9383 From djelinski at openjdk.org Wed Jul 6 08:57:23 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Jul 2022 08:57:23 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) test failure is unrelated, caused by [JDK-8289619](https://bugs.openjdk.org/browse/JDK-8289619) ------------- PR: https://git.openjdk.org/jdk/pull/9383 From cjplummer at openjdk.org Thu Jul 7 19:16:48 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 7 Jul 2022 19:16:48 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com> On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Are you going to update copyrights? I reviewed src/jdk.hotspot.agent, src/jdk.jdi/, src/jdk.jdwp.agent, and src/jdk.management. Looks good other than copyrights and the suggestion I made for additional cleanup in symtab.c. src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 308: > 306: ELF_SHDR* shbuf = NULL; > 307: ELF_SHDR* cursct = NULL; > 308: ELF_PHDR* phbuf = NULL; phbuf is also essentially unused. The only reference is to free it if non-null, but it's always NULL, so that code can be removed too. ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From djelinski at openjdk.org Fri Jul 8 07:08:46 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 8 Jul 2022 07:08:46 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: > This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. > > The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. > > I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: - Update copyright - Remove more unused variables ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9383/files - new: https://git.openjdk.org/jdk/pull/9383/files/b4cd5374..da30ef90 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=01-02 Stats: 30 lines in 26 files changed: 0 ins; 4 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/9383.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383 PR: https://git.openjdk.org/jdk/pull/9383 From djelinski at openjdk.org Fri Jul 8 07:12:44 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 8 Jul 2022 07:12:44 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: <2_Xy-WrhqelW5xoQnKgSrnb1WSEENT6zlJ4ZRbnJDvo=.0e7b8752-9def-459a-ac6a-1172dbd3d5f7@github.com> On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Copyrights updated. ------------- PR: https://git.openjdk.org/jdk/pull/9383 From cjplummer at openjdk.org Fri Jul 8 07:20:46 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 8 Jul 2022 07:20:46 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9383 From alanb at openjdk.org Fri Jul 8 08:03:39 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Jul 2022 08:03:39 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Marked as reviewed by alanb (Reviewer). src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c line 686: > 684: LPCWSTR lpFileName = jlong_to_ptr(pathAddress); > 685: PSECURITY_DESCRIPTOR pSecurityDescriptor = jlong_to_ptr(descAddress); > 686: DWORD lengthNeeded = 0; lengthNeeded, it seems not :-) ------------- PR: https://git.openjdk.org/jdk/pull/9383 From duke at openjdk.org Fri Jul 8 13:55:47 2022 From: duke at openjdk.org (XenoAmess) Date: Fri, 8 Jul 2022 13:55:47 GMT Subject: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v17] In-Reply-To: References: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com> Message-ID: On Wed, 1 Jun 2022 16:45:35 GMT, liach wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> do it as naotoj said > > 'the new' fix should be applied to newHashMap etc. too. > @liach > > > 'the new' fix should be applied to newHashMap etc. too. > > I've filed [JDK-8289872](https://bugs.openjdk.org/browse/JDK-8289872) for this. It's a small thing but best to fix it before we forget about it. Sorry for I already forgotten it. ------------- PR: https://git.openjdk.org/jdk/pull/8302 From djelinski at openjdk.org Fri Jul 8 07:08:50 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 8 Jul 2022 07:08:50 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com> References: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com> Message-ID: <5lYmVui3caVoMyThlWMlQP1etBfuLQan6v6OUIBYh_o=.e1d33b03-8791-4462-a9e7-b13287df2aa8@github.com> On Thu, 7 Jul 2022 19:06:52 GMT, Chris Plummer wrote: >> Daniel Jeli?ski 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 four additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin' into unused-variables >> - Remove unused variables (windows) >> - Remove unused variables (macos) >> - Remove unused variables (linux) > > src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 308: > >> 306: ELF_SHDR* shbuf = NULL; >> 307: ELF_SHDR* cursct = NULL; >> 308: ELF_PHDR* phbuf = NULL; > > phbuf is also essentially unused. The only reference is to free it if non-null, but it's always NULL, so that code can be removed too. Good catch! Also removed similar code from macOS version. ------------- PR: https://git.openjdk.org/jdk/pull/9383 From michaelm at openjdk.org Mon Jul 11 07:00:45 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 11 Jul 2022 07:00:45 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables libnet changes look fine to me ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From chegar at openjdk.org Mon Jul 11 08:13:45 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Mon, 11 Jul 2022 08:13:45 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: <0LufT1j0Gvkv3sFYqCQUR7aBmIU9lHIdOWBHVJyDc-M=.ee7f2980-e54f-4507-9ce3-73378faad4b8@github.com> On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables LGTM ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From dfuchs at openjdk.org Mon Jul 11 14:45:59 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 11 Jul 2022 14:45:59 GMT Subject: RFR: 8290083: ResponseBodyBeforeError: javax.net.ssl.SSLException: Unsupported or unrecognized SSL message Message-ID: Please find enclosed a simple test fix. This test has been observed failing once with an SSLException. My suspicion is that some random process (other test or ...) has tried to connect to the test ReplyingServer and sent some plain text that failed the handshake. The fix hardens the server to close the connection and proceed to accept the next one, for a limited number of times... ------------- Commit messages: - 8290083 Changes: https://git.openjdk.org/jdk/pull/9454/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9454&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290083 Stats: 22 lines in 1 file changed: 15 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9454.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9454/head:pull/9454 PR: https://git.openjdk.org/jdk/pull/9454 From jpai at openjdk.org Tue Jul 12 07:46:43 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 12 Jul 2022 07:46:43 GMT Subject: RFR: 8290083: ResponseBodyBeforeError: javax.net.ssl.SSLException: Unsupported or unrecognized SSL message In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 14:35:55 GMT, Daniel Fuchs wrote: > Please find enclosed a simple test fix. > This test has been observed failing once with an SSLException. My suspicion is that some random process (other test or ...) has tried to connect to the test ReplyingServer and sent some plain text that failed the handshake. > > The fix hardens the server to close the connection and proceed to accept the next one, for a limited number of times... test/jdk/java/net/httpclient/ResponseBodyBeforeError.java line 349: > 347: @Override > 348: public void run() { > 349: int maxUnexpected = 2; Hello Daniel, should we have this `maxUnexpected` at all? Perhaps, we keep accepting and ignoring connections/requests that don't match our expectations? The reason I ask this is, I don't think we will know the exact number of unexpected requests/connections that this server might receive when this test is going on, so with this value of 2, I guess there still would be a chance that this test fails because of those unexpected connections? ------------- PR: https://git.openjdk.org/jdk/pull/9454 From dfuchs at openjdk.org Tue Jul 12 08:09:44 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 12 Jul 2022 08:09:44 GMT Subject: RFR: 8290083: ResponseBodyBeforeError: AssertionError or SSLException: Unsupported or unrecognized SSL message In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 07:44:39 GMT, Jaikiran Pai wrote: >> Please find enclosed a simple test fix. >> This test has been observed failing once with an SSLException. My suspicion is that some random process (other test or ...) has tried to connect to the test ReplyingServer and sent some plain text that failed the handshake. >> >> The fix hardens the server to close the connection and proceed to accept the next one, for a limited number of times... > > test/jdk/java/net/httpclient/ResponseBodyBeforeError.java line 349: > >> 347: @Override >> 348: public void run() { >> 349: int maxUnexpected = 2; > > Hello Daniel, should we have this `maxUnexpected` at all? Perhaps, we keep accepting and ignoring connections/requests that don't match our expectations? The reason I ask this is, I don't think we will know the exact number of unexpected requests/connections that this server might receive when this test is going on, so with this value of 2, I guess there still would be a chance that this test fails because of those unexpected connections? This is a good question. I believe this only happens occasionally, and if it happens more than once in the same test run then maybe it needs further diagnosis. That said - it's possible the rogue client will retry - so maybe we should increase the limit? My reasoning was that if the client side of the test was changed in the future to cause similar failures we might want the server to complain and see the full stack trace. ------------- PR: https://git.openjdk.org/jdk/pull/9454 From dfuchs at openjdk.org Tue Jul 12 08:17:35 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 12 Jul 2022 08:17:35 GMT Subject: RFR: 8290083: ResponseBodyBeforeError: AssertionError or SSLException: Unsupported or unrecognized SSL message [v2] In-Reply-To: References: Message-ID: > Please find enclosed a simple test fix. > This test has been observed failing once with an SSLException. My suspicion is that some random process (other test or ...) has tried to connect to the test ReplyingServer and sent some plain text that failed the handshake. > > The fix hardens the server to close the connection and proceed to accept the next one, for a limited number of times... Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: increase maxUnexpected limit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9454/files - new: https://git.openjdk.org/jdk/pull/9454/files/e6e667b0..3f428536 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9454&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9454&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9454.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9454/head:pull/9454 PR: https://git.openjdk.org/jdk/pull/9454 From dfuchs at openjdk.org Tue Jul 12 08:17:38 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 12 Jul 2022 08:17:38 GMT Subject: RFR: 8290083: ResponseBodyBeforeError: AssertionError or SSLException: Unsupported or unrecognized SSL message [v2] In-Reply-To: References: Message-ID: <8RUyGPyo4jDTK5TFiJGPUV9w2FIl4OJZ7NoOECADl4Y=.cabb3d8f-31d5-48ce-a279-f2931cc4b897@github.com> On Tue, 12 Jul 2022 08:07:36 GMT, Daniel Fuchs wrote: >> test/jdk/java/net/httpclient/ResponseBodyBeforeError.java line 349: >> >>> 347: @Override >>> 348: public void run() { >>> 349: int maxUnexpected = 2; >> >> Hello Daniel, should we have this `maxUnexpected` at all? Perhaps, we keep accepting and ignoring connections/requests that don't match our expectations? The reason I ask this is, I don't think we will know the exact number of unexpected requests/connections that this server might receive when this test is going on, so with this value of 2, I guess there still would be a chance that this test fails because of those unexpected connections? > > This is a good question. I believe this only happens occasionally, and if it happens more than once in the same test run then maybe it needs further diagnosis. That said - it's possible the rogue client will retry - so maybe we should increase the limit? My reasoning was that if the client side of the test was changed in the future to cause similar failures we might want the server to complain and see the full stack trace. I have increased the limit to 10 ------------- PR: https://git.openjdk.org/jdk/pull/9454 From jpai at openjdk.org Tue Jul 12 09:45:49 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 12 Jul 2022 09:45:49 GMT Subject: RFR: 8290083: ResponseBodyBeforeError: AssertionError or SSLException: Unsupported or unrecognized SSL message [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 08:17:35 GMT, Daniel Fuchs wrote: >> Please find enclosed a simple test fix. >> This test has been observed failing once with an SSLException. My suspicion is that some random process (other test or ...) has tried to connect to the test ReplyingServer and sent some plain text that failed the handshake. >> >> The fix hardens the server to close the connection and proceed to accept the next one, for a limited number of times... > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > increase maxUnexpected limit Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9454 From dfuchs at openjdk.org Tue Jul 12 10:01:59 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 12 Jul 2022 10:01:59 GMT Subject: Integrated: 8290083: ResponseBodyBeforeError: AssertionError or SSLException: Unsupported or unrecognized SSL message In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 14:35:55 GMT, Daniel Fuchs wrote: > Please find enclosed a simple test fix. > This test has been observed failing once with an SSLException. My suspicion is that some random process (other test or ...) has tried to connect to the test ReplyingServer and sent some plain text that failed the handshake. > > The fix hardens the server to close the connection and proceed to accept the next one, for a limited number of times... This pull request has now been integrated. Changeset: 3b9059a1 Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/3b9059a1471ba74af8bf6a3c0e5b2e1140eb4afd Stats: 23 lines in 1 file changed: 16 ins; 0 del; 7 mod 8290083: ResponseBodyBeforeError: AssertionError or SSLException: Unsupported or unrecognized SSL message Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/9454 From djelinski at openjdk.org Tue Jul 12 11:34:43 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Jul 2022 11:34:43 GMT Subject: Integrated: 8289768: Clean up unused code In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 20:19:10 GMT, Daniel Jeli?ski wrote: > This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. > > The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. > > I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. This pull request has now been integrated. Changeset: 04c47da1 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/04c47da118b2870d1c7525348a2ffdf9cd1cc0a4 Stats: 98 lines in 46 files changed: 0 ins; 69 del; 29 mod 8289768: Clean up unused code Reviewed-by: dfuchs, lancea, weijun, naoto, cjplummer, alanb, michaelm, chegar ------------- PR: https://git.openjdk.org/jdk/pull/9383 From duke at openjdk.org Fri Jul 15 12:10:32 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:10:32 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable Message-ID: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Simplify code with `String.join()` ------------- Commit messages: - 8290300: Fix copy-right year - 8290300: Use standard String-joining tools where applicable Changes: https://git.openjdk.org/jdk/pull/9513/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290300 Stats: 90 lines in 8 files changed: 1 ins; 68 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From jlaskey at openjdk.org Fri Jul 15 12:28:48 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 15 Jul 2022 12:28:48 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? wrote: > Simplify code with `String.join()` LGTM, however are there tests that ensure the changes are benign? ------------- PR: https://git.openjdk.org/jdk/pull/9513 From alanb at openjdk.org Fri Jul 15 12:33:48 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Jul 2022 12:33:48 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? wrote: > Simplify code with `String.join()` joptsimple is a 3rd party code so we probably don't want to change that. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 12:40:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:40:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v2] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: - 8290300: Revert jops - 8290300: Revert jops ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/f3020263..80384470 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=00-01 Stats: 73 lines in 4 files changed: 58 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 12:40:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:40:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? wrote: > Simplify code with `String.join()` Reverted jops ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 12:40:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:40:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v2] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:25:07 GMT, Jim Laskey wrote: >> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8290300: Revert jops >> - 8290300: Revert jops > > LGTM, however are there tests that ensure the changes are benign? @JimLaskey I'll double check and add tests if necessary ------------- PR: https://git.openjdk.org/jdk/pull/9513 From naoto at openjdk.org Fri Jul 15 16:31:46 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 15 Jul 2022 16:31:46 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v2] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: <4lc5aVxpfSL9ukqHt2IDLR_LQDkQx-3htusBXQDsx1I=.9c453024-986b-4828-9775-f5a1561d0097@github.com> On Fri, 15 Jul 2022 12:40:50 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: > > - 8290300: Revert jops > - 8290300: Revert jops Changes to `Locale` look good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/9513 From dholmes at openjdk.org Sun Jul 17 23:03:37 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 17 Jul 2022 23:03:37 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC Message-ID: Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: The Java manpage was missing updates from: - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. The Java manpage has slight formatting differences from: - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) The keytool manpage was missing updates from: - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA The jar manpage was missing updates from: - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) The jarsigner manpage was missing updates from: - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA The javadoc manpage was missing updates from: - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option The jmod manpage was missing updates from: - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) The jpackage manpage was missing updates from: - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code The jshell manpage was missing updates from: - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. ------------- Commit messages: - 8278274: Update nroff pages in JDK 19 before RC Changes: https://git.openjdk.org/jdk19/pull/145/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=145&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8278274 Stats: 515 lines in 28 files changed: 431 ins; 16 del; 68 mod Patch: https://git.openjdk.org/jdk19/pull/145.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/145/head:pull/145 PR: https://git.openjdk.org/jdk19/pull/145 From duke at openjdk.org Mon Jul 18 11:17:37 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 11:17:37 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v3] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: <6NKq2IAULEe2WYW2aIEOvu9-8_p4aKtrW1ZFRJo16mc=.17712761-2483-49b4-acf4-2faa394a1a99@github.com> > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290300: Remove unused piece of code in formatList() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/80384470..4f2bbfd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 11:17:37 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 11:17:37 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v3] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:25:07 GMT, Jim Laskey wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290300: Remove unused piece of code in formatList() > > LGTM, however are there tests that ensure the changes are benign? @JimLaskey changes in `WindowsPath` are covered by `PathOps`, apart from this there are 10 tests calling this method. With `ProcessBuilder` and `Locale` it looks like the code I've changed is never executed at all for `ProcessStartEvent.isEnabled()` always return false. For `Locale` all the call sites of `formatList()` never pass null, so the code in `if` block is never executed. I think we can delete this unused parts of the code in `Locale`, but I'm not sure about `ProcessBuilder`. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 11:31:59 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 11:31:59 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v4] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290300: Remove unused import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/4f2bbfd3..5b18c39c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From jjg at openjdk.org Mon Jul 18 15:24:06 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 18 Jul 2022 15:24:06 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: Message-ID: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes wrote: > Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. > > All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: > > The Java manpage was missing updates from: > - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. > > The Java manpage has slight formatting differences from: > - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux > - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS > > The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) > > > The keytool manpage was missing updates from: > - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA > > The jar manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jarsigner manpage was missing updates from: > - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA > > The javadoc manpage was missing updates from: > - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option > > The jmod manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jpackage manpage was missing updates from: > - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature > - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 > - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code > > The jshell manpage was missing updates from: > - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. src/java.base/share/man/keytool.1 line 456: > 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the > 455: keystore. > 456: This option is used to sign the certificate with the signer?s private Not a problem with this PR as such, but we still have a `?` character in the output. ------------- PR: https://git.openjdk.org/jdk19/pull/145 From jjg at openjdk.org Mon Jul 18 15:30:09 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 18 Jul 2022 15:30:09 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: Message-ID: On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes wrote: > Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. > > All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: > > The Java manpage was missing updates from: > - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. > > The Java manpage has slight formatting differences from: > - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux > - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS > > The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) > > > The keytool manpage was missing updates from: > - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA > > The jar manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jarsigner manpage was missing updates from: > - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA > > The javadoc manpage was missing updates from: > - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option > > The jmod manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jpackage manpage was missing updates from: > - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature > - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 > - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code > > The jshell manpage was missing updates from: > - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. The version changes in each file look good (`19-ea` to `19`). The changes for javadoc look good. I looked over the other changes for other files, and while they look good, I cannot speak for their technical accuracy. That being said, this is an automated process deriving info from upstream, so is likely OK. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.org/jdk19/pull/145 From naoto at openjdk.org Mon Jul 18 16:49:45 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 18 Jul 2022 16:49:45 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v4] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Mon, 18 Jul 2022 11:08:24 GMT, ?????? ??????? wrote: > For `Locale` all the call sites of `formatList()` never pass null, so the code in `if` block is never executed. I think we can delete this unused parts of the code in `Locale`, Are you sure about this? `pattern` is derived from `LocaleResources.getLocaleName()` which could return `null`. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 18:40:51 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 18:40:51 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v5] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290300: Revert erroneous changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/5b18c39c..af555897 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=03-04 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 18:40:51 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 18:40:51 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v4] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Mon, 18 Jul 2022 11:31:59 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290300: Remove unused import Right, my bad. I've confused arguments. The changes reverted. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From naoto at openjdk.org Mon Jul 18 18:56:50 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 18 Jul 2022 18:56:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v5] In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> Message-ID: <9nxXC6TKJOwD19iPW3lSojz6aWMT91DCTH3rrqx4C-8=.d43bb635-f3b1-4ebf-8baa-7b85078b7694@github.com> On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290300: Revert erroneous changes Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9513 From rriggs at openjdk.org Mon Jul 18 19:10:11 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 18 Jul 2022 19:10:11 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v5] In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> Message-ID: <4MM9EyQBrfbebIry8tPi_LRPHaRGPbmVYp7xwf0hewQ=.6ae982ac-d33f-49f0-927c-f574c148ec35@github.com> On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290300: Revert erroneous changes Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9513 From dholmes at openjdk.org Mon Jul 18 23:32:04 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Jul 2022 23:32:04 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 15:26:23 GMT, Jonathan Gibbons wrote: >> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. >> >> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: >> >> The Java manpage was missing updates from: >> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. >> >> The Java manpage has slight formatting differences from: >> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux >> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS >> >> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) >> >> >> The keytool manpage was missing updates from: >> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. >> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA >> >> The jar manpage was missing updates from: >> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) >> >> The jarsigner manpage was missing updates from: >> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. >> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA >> >> The javadoc manpage was missing updates from: >> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option >> >> The jmod manpage was missing updates from: >> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) >> >> The jpackage manpage was missing updates from: >> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature >> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 >> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code >> >> The jshell manpage was missing updates from: >> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. > > The version changes in each file look good (`19-ea` to `19`). > The changes for javadoc look good. > > I looked over the other changes for other files, and while they look good, I cannot speak for their technical accuracy. That being said, this is an automated process deriving info from upstream, so is likely OK. Thanks for the review @jonathan-gibbons ! I'll wait a day in case there are any further comments. > src/java.base/share/man/keytool.1 line 456: > >> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the >> 455: keystore. >> 456: This option is used to sign the certificate with the signer?s private > > Not a problem with this PR as such, but we still have a `?` character in the output. Yeah I spotted that too, but it would need to be fixed in source and nroff. Must be some kind of "smart quote" from an editor. Do you think this needs to be fixed or just handle it in mainline? ------------- PR: https://git.openjdk.org/jdk19/pull/145 From duke at openjdk.org Tue Jul 19 06:40:48 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Tue, 19 Jul 2022 06:40:48 GMT Subject: RFR: 8282395: URL.openConnection can throw IOOBE [v2] In-Reply-To: References: <0fmDCk9p_r90kbSLWTgAyHgxt4vcujOdWkSyCTstESM=.a14f3a15-3c8b-4d3b-af47-0c42e8a2b24a@github.com> Message-ID: <2Y7_2I2uEj1rIP7bC3S53CCqR7lPLTOFK3AAE5CIwLw=.a6b064d9-65a6-470f-b9e3-a5a1956c92cf@github.com> On Wed, 6 Jul 2022 14:39:37 GMT, Daniel Fuchs wrote: >> @dfuch >> Could you tell me your opinion based on this information, please? > > Let me try to summarize: there are several things that we could do: > > 1. nothing: continue throwing IIOBE > 2. throw IAE instead of IIOBE, and let IAE trickle up the calling stack to the callers code > 3. throw MUE instead of IIOBE, and then update all the places where ParseUtils::decode is called to either let the MUE trickle up the stack if possible, or deal with it if not. > 4. throw IAE instead of IIOBE and somewhere up the stack catch that and transform it into MUE. > 4.1. do the catch & transform in URL::openConnection when calling URLStreamHandler::openConnection > 4.2. do the catch & transform in every protocol handler implementation that use ParseUtils::decode > > Now let's see pro & cons: > 1. is not ideal because it looks like a bug (and it is) > 2. is expedient. There seems to be some precedent for that since ParseUtils::decode already throws IAE if it can't parse the port. However IAE is not specified to be thrown by openConnection. So maybe we should update the specification of URL::openConnection and URLStreamHandler::openConnection to allow for IAE. This is however a bit strange to use IAE because in this case the URL is indeed malformed, so MUE would be more appropriate. > 3. has the advantage of being clear, and to force all callers of ParseUtils to deal with the situation. However, ParseUtils seems to be widely used, so each places where it's called needs to be examined, to see what would be the more appropriate solution in each case > 4. The advantage here is that callers of ParseUtils don't need to be changed if IAE is already appropriate for them. But those for which MUE would be more appropriate would benefit from having IAE transformed in MUE, which can be achieved by 4.1 or 4.2 > 4.1 the issue here is that URLStreamHandler::openConnection is not specified to throw IAE, yet we catch IAE that might be thrown by custom URLStreamHandler implementations not present in the JDK, where the IAE that they throw might have nothing to do with a Malformed URL. So we risk introducing regressions for applications that provide their own custom URLStreamHandlers implementations, and that might not expect the wrapping of the IAE they throw into MUE. I believe that if we did that it would need to be specified (in URL::openConnection) and it would require a CSR. > 4.2 we need to examine all protocol handler implementations present in the JDK and do the wrapping there. URLStreamHandler::openConnection is specified to throw IOException, so throwing MUE is within the bounds. However - if we don't have ParseUtils::decode throw MUE, we're not guaranteed not to miss some places. > > I'd say from a consistency point of view, 3. is probably best. Then failing that, from a compatibility vs consistency point of view 4.2 might be our best shot. 2. might be envisaged, but maybe at the expense of logging a follow up issue to clean that up and later decide between 3. or 4.2. > I would tend to rule out 4.1 due to the possible compatibility issue, and also because if URLStreamHandler::openConnection wanted to throw MUE it could, so there is no reason for doing 4.1. Thank you for your valuable comments. I think 3 is a good idea. I will try fix, but it takes some time to see the impact on many other methods. ------------- PR: https://git.openjdk.org/jdk/pull/8155 From dholmes at openjdk.org Wed Jul 20 04:44:05 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Jul 2022 04:44:05 GMT Subject: [jdk19] Integrated: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: Message-ID: On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes wrote: > Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. > > All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: > > The Java manpage was missing updates from: > - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. > > The Java manpage has slight formatting differences from: > - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux > - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS > > The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) > > > The keytool manpage was missing updates from: > - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA > > The jar manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jarsigner manpage was missing updates from: > - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA > > The javadoc manpage was missing updates from: > - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option > > The jmod manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jpackage manpage was missing updates from: > - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature > - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 > - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code > > The jshell manpage was missing updates from: > - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. This pull request has now been integrated. Changeset: 618f3a82 Author: David Holmes URL: https://git.openjdk.org/jdk19/commit/618f3a82a4d45cdb66b86259ae60dd1c322b987b Stats: 515 lines in 28 files changed: 431 ins; 16 del; 68 mod 8278274: Update nroff pages in JDK 19 before RC Reviewed-by: jjg ------------- PR: https://git.openjdk.org/jdk19/pull/145 From dholmes at openjdk.org Wed Jul 20 05:37:13 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Jul 2022 05:37:13 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 23:27:58 GMT, David Holmes wrote: >> src/java.base/share/man/keytool.1 line 456: >> >>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the >>> 455: keystore. >>> 456: This option is used to sign the certificate with the signer?s private >> >> Not a problem with this PR as such, but we still have a `?` character in the output. > > Yeah I spotted that too, but it would need to be fixed in source and nroff. Must be some kind of "smart quote" from an editor. Do you think this needs to be fixed or just handle it in mainline? Filed [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626). It can easily be fixed before RDP2. ------------- PR: https://git.openjdk.org/jdk19/pull/145 From djelinski at openjdk.org Wed Jul 20 19:49:27 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 20 Jul 2022 19:49:27 GMT Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header Message-ID: This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X. All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*. On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options. As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test. Testing performed (with IP_DONTFRAGMENT flag): Windows 10: With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag. Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable. For other systems I could not capture packets, so I can only report the observed behavior of sending packets. Windows 2012 and 2016 (IP_MTU_DISCOVER not supported): With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds. If a packet is sent to a non-routable address, send succeeds, no error is reported. Linux: With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds. Mac OS X 12: Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior. ------------- Commit messages: - Revert test - Fix retrieval of dontfragment flag - Improve dontfragment handling on dual stack sockets Changes: https://git.openjdk.org/jdk/pull/9575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9575&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290349 Stats: 136 lines in 9 files changed: 2 ins; 66 del; 68 mod Patch: https://git.openjdk.org/jdk/pull/9575.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9575/head:pull/9575 PR: https://git.openjdk.org/jdk/pull/9575 From dcubed at openjdk.org Wed Jul 20 22:44:07 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 20 Jul 2022 22:44:07 GMT Subject: RFR: Merge jdk19 Message-ID: Merge jdk19 -> jdk20. ------------- Commit messages: - Merge - 8290625: Test jdk/javadoc/tool/CheckManPageOptions.java after manpage update - 8278274: Update nroff pages in JDK 19 before RC - 8287916: Address the inconsistency between the constant array and pool size - 8285407: Improve Xalan supports - 8282676: Improve subject handling - 8284370: Improve zlib usage - 8283190: Improve MIDI processing - 8281866: Enhance MethodHandle invocations - 8281859: Improve class compilation - ... and 3 more: https://git.openjdk.org/jdk/compare/b1817a30...aaca8b9d The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/9578/files Stats: 504 lines in 28 files changed: 428 ins; 16 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/9578.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9578/head:pull/9578 PR: https://git.openjdk.org/jdk/pull/9578 From dcubed at openjdk.org Wed Jul 20 22:59:25 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 20 Jul 2022 22:59:25 GMT Subject: RFR: Merge jdk19 In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 22:20:31 GMT, Daniel D. Daugherty wrote: > Merge jdk19 -> jdk20. Mach5 Tier1 passed. ------------- PR: https://git.openjdk.org/jdk/pull/9578 From dcubed at openjdk.org Wed Jul 20 22:59:26 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 20 Jul 2022 22:59:26 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 22:20:31 GMT, Daniel D. Daugherty wrote: > Merge jdk19 -> jdk20. This pull request has now been integrated. Changeset: 9c19d89c Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/9c19d89c9c564e436732c5f7851f4960fb5d783c Stats: 504 lines in 28 files changed: 428 ins; 16 del; 60 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9578 From dholmes at openjdk.org Thu Jul 21 00:43:38 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Jul 2022 00:43:38 GMT Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20 Message-ID: The version will be 20-ea and the copyright year 2023 (for March 2023 release date). Thanks. ------------- Commit messages: - 8290489: Initial nroff manpage generation for JDK 20 Changes: https://git.openjdk.org/jdk/pull/9581/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9581&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290489 Stats: 28 lines in 28 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/9581.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9581/head:pull/9581 PR: https://git.openjdk.org/jdk/pull/9581 From dcubed at openjdk.org Thu Jul 21 01:07:02 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 21 Jul 2022 01:07:02 GMT Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20 In-Reply-To: References: Message-ID: <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com> On Thu, 21 Jul 2022 00:34:53 GMT, David Holmes wrote: > The version will be 20-ea and the copyright year 2023 (for March 2023 release date). > > Thanks. Thumbs up. This is a trivial change. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/9581 From duke at openjdk.org Thu Jul 21 04:47:05 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Thu, 21 Jul 2022 04:47:05 GMT Subject: RFR: 8272702: Resolving URI relative path with no / may lead to incorrect toString [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 09:51:48 GMT, Daniel Fuchs wrote: >> @dfuch >> Could you review this fix again, please? > > I will have a look but analyzing the proposed fix and thinking about the potential side effects will take me some time. @dfuch I'm sorry to bother you, is there anything wtong in this fix? ------------- PR: https://git.openjdk.org/jdk/pull/8899 From dholmes at openjdk.org Thu Jul 21 05:49:57 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Jul 2022 05:49:57 GMT Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20 In-Reply-To: <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com> References: <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com> Message-ID: On Thu, 21 Jul 2022 01:03:46 GMT, Daniel D. Daugherty wrote: >> The version will be 20-ea and the copyright year 2023 (for March 2023 release date). >> >> Thanks. > > Thumbs up. This is a trivial change. Thanks @dcubed-ojdk ! ------------- PR: https://git.openjdk.org/jdk/pull/9581 From michaelm at openjdk.org Thu Jul 21 09:55:40 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 21 Jul 2022 09:55:40 GMT Subject: RFR: 8276561: URL$DefaultFactory::PREFIX should be static final Message-ID: <_5dJ8Y74YfF7h9Lw6IHKOMOIne9RZ0giqGz8MEY6uZM=.e4de5a02-49f3-4fee-8b1d-042fcb144a43@github.com> Hi, Could I get the following trivial code change reviewed please? Static analysis shows one static field declaration in java.net.URL that should be final. Thanks, Michael. ------------- Commit messages: - add final keyword Changes: https://git.openjdk.org/jdk/pull/9586/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9586&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8276561 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9586.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9586/head:pull/9586 PR: https://git.openjdk.org/jdk/pull/9586 From djelinski at openjdk.org Thu Jul 21 10:01:57 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 21 Jul 2022 10:01:57 GMT Subject: RFR: 8276561: URL$DefaultFactory::PREFIX should be static final In-Reply-To: <_5dJ8Y74YfF7h9Lw6IHKOMOIne9RZ0giqGz8MEY6uZM=.e4de5a02-49f3-4fee-8b1d-042fcb144a43@github.com> References: <_5dJ8Y74YfF7h9Lw6IHKOMOIne9RZ0giqGz8MEY6uZM=.e4de5a02-49f3-4fee-8b1d-042fcb144a43@github.com> Message-ID: On Thu, 21 Jul 2022 09:46:27 GMT, Michael McMahon wrote: > Hi, > > Could I get the following trivial code change reviewed please? Static analysis shows one > static field declaration in java.net.URL that should be final. > > Thanks, > Michael. Marked as reviewed by djelinski (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/9586 From jpai at openjdk.org Thu Jul 21 10:01:58 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 21 Jul 2022 10:01:58 GMT Subject: RFR: 8276561: URL$DefaultFactory::PREFIX should be static final In-Reply-To: <_5dJ8Y74YfF7h9Lw6IHKOMOIne9RZ0giqGz8MEY6uZM=.e4de5a02-49f3-4fee-8b1d-042fcb144a43@github.com> References: <_5dJ8Y74YfF7h9Lw6IHKOMOIne9RZ0giqGz8MEY6uZM=.e4de5a02-49f3-4fee-8b1d-042fcb144a43@github.com> Message-ID: On Thu, 21 Jul 2022 09:46:27 GMT, Michael McMahon wrote: > Hi, > > Could I get the following trivial code change reviewed please? Static analysis shows one > static field declaration in java.net.URL that should be final. > > Thanks, > Michael. Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9586 From michaelm at openjdk.org Thu Jul 21 11:07:14 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 21 Jul 2022 11:07:14 GMT Subject: Integrated: 8276561: URL$DefaultFactory::PREFIX should be static final In-Reply-To: <_5dJ8Y74YfF7h9Lw6IHKOMOIne9RZ0giqGz8MEY6uZM=.e4de5a02-49f3-4fee-8b1d-042fcb144a43@github.com> References: <_5dJ8Y74YfF7h9Lw6IHKOMOIne9RZ0giqGz8MEY6uZM=.e4de5a02-49f3-4fee-8b1d-042fcb144a43@github.com> Message-ID: On Thu, 21 Jul 2022 09:46:27 GMT, Michael McMahon wrote: > Hi, > > Could I get the following trivial code change reviewed please? Static analysis shows one > static field declaration in java.net.URL that should be final. > > Thanks, > Michael. This pull request has now been integrated. Changeset: 799a2c84 Author: Michael McMahon URL: https://git.openjdk.org/jdk/commit/799a2c844d904b675abd324ab09cbda7faf70b0f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8276561: URL$DefaultFactory::PREFIX should be static final Reviewed-by: djelinski, jpai ------------- PR: https://git.openjdk.org/jdk/pull/9586 From duke at openjdk.org Thu Jul 21 13:26:20 2022 From: duke at openjdk.org (Jason Laber) Date: Thu, 21 Jul 2022 13:26:20 GMT Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header [v8] In-Reply-To: References: Message-ID: <5I5ef9XXzzrSL0FgsYL0DYkItQr8jNSOq9N__SGfCW0=.1d0ec7df-eb90-407f-abee-a6f82db13571@github.com> On Mon, 16 May 2022 08:59:43 GMT, Conor Cleary wrote: >> **Issue** >> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. >> >> **Solution** >> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added. > > Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: > > 8283544: Added in missing case It's tough to tell what versions this fix will get into. Will this go into a Java 11 patch? ------------- PR: https://git.openjdk.org/jdk/pull/8017 From jpai at openjdk.org Thu Jul 21 13:47:07 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 21 Jul 2022 13:47:07 GMT Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header [v8] In-Reply-To: <5I5ef9XXzzrSL0FgsYL0DYkItQr8jNSOq9N__SGfCW0=.1d0ec7df-eb90-407f-abee-a6f82db13571@github.com> References: <5I5ef9XXzzrSL0FgsYL0DYkItQr8jNSOq9N__SGfCW0=.1d0ec7df-eb90-407f-abee-a6f82db13571@github.com> Message-ID: On Thu, 21 Jul 2022 13:24:01 GMT, Jason Laber wrote: >> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: >> >> 8283544: Added in missing case > > It's tough to tell what versions this fix will get into. Will this go into a Java 11 patch? Hello @jlaber, the linked issue will have the fix version corresponding to this integrated fix. In this case it is https://bugs.openjdk.org/browse/JDK-8283544 which is marked as fixed in 19, so this will be available in the JDK 19 release. If a particular issue gets backported then that issue will have corresponding links to the backports. Right now there are no backports for this issue. ------------- PR: https://git.openjdk.org/jdk/pull/8017 From jpai at openjdk.org Thu Jul 21 14:49:04 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 21 Jul 2022 14:49:04 GMT Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header In-Reply-To: References: Message-ID: <3no302rlOTE2mXILPU297bKZCbSgwgDK5I5mGDp9Cis=.b7c9e3ca-5971-4e54-8526-01fe2ca7a5f8@github.com> On Wed, 20 Jul 2022 17:19:50 GMT, Daniel Jeli?ski wrote: > This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X. > > All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*. > > On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options. > > As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test. > > Testing performed (with IP_DONTFRAGMENT flag): > Windows 10: > With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag. > Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable. > > For other systems I could not capture packets, so I can only report the observed behavior of sending packets. > Windows 2012 and 2016 (IP_MTU_DISCOVER not supported): > With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds. > If a packet is sent to a non-routable address, send succeeds, no error is reported. > > Linux: > With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds. > > Mac OS X 12: > Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior. src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c line 207: > 205: } > 206: } > 207: return JNI_TRUE; Hello Daniel, if I'm reading this diff correctly, then we have inverted the check on `fd`. So I suspect this final `return` now needs to be changed to `return JNI_FALSE` to account for `fd` being `-1`? ------------- PR: https://git.openjdk.org/jdk/pull/9575 From djelinski at openjdk.org Thu Jul 21 17:45:06 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 21 Jul 2022 17:45:06 GMT Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header In-Reply-To: <3no302rlOTE2mXILPU297bKZCbSgwgDK5I5mGDp9Cis=.b7c9e3ca-5971-4e54-8526-01fe2ca7a5f8@github.com> References: <3no302rlOTE2mXILPU297bKZCbSgwgDK5I5mGDp9Cis=.b7c9e3ca-5971-4e54-8526-01fe2ca7a5f8@github.com> Message-ID: On Thu, 21 Jul 2022 14:46:58 GMT, Jaikiran Pai wrote: >> This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X. >> >> All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*. >> >> On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options. >> >> As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test. >> >> Testing performed (with IP_DONTFRAGMENT flag): >> Windows 10: >> With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag. >> Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable. >> >> For other systems I could not capture packets, so I can only report the observed behavior of sending packets. >> Windows 2012 and 2016 (IP_MTU_DISCOVER not supported): >> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds. >> If a packet is sent to a non-routable address, send succeeds, no error is reported. >> >> Linux: >> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds. >> >> Mac OS X 12: >> Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior. > > src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c line 207: > >> 205: } >> 206: } >> 207: return JNI_TRUE; > > Hello Daniel, if I'm reading this diff correctly, then we have inverted the check on `fd`. So I suspect this final `return` now needs to be changed to `return JNI_FALSE` to account for `fd` being `-1`? Hi Jaikiran, the point of this change was to better support systems where either IPv4 or IPv6 was disabled. I'm not sure if that can even happen on Mac. The change here is that if we can't create one socket, we don't immediately return false, but instead return the result for the other socket. For example, if creating IPv4 socket fails, we only check if DF is supported on IPv6 socket, and return that as a result. If both `socket` calls fail, we don't know if the DF flag is supported, and return true (before the patch we would return false in that case). I can modify the patch to return false in that case, or roll back this change entirely if you think it makes no sense. ------------- PR: https://git.openjdk.org/jdk/pull/9575 From dholmes at openjdk.org Fri Jul 22 04:45:03 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 22 Jul 2022 04:45:03 GMT Subject: Integrated: 8290489: Initial nroff manpage generation for JDK 20 In-Reply-To: References: Message-ID: <2vnXOAQlpH9CGjFVkGkL4pWyCPxneNmWrxV8V6j5b_w=.c951b25d-e0cd-4902-ad79-200ca4238f91@github.com> On Thu, 21 Jul 2022 00:34:53 GMT, David Holmes wrote: > The version will be 20-ea and the copyright year 2023 (for March 2023 release date). > > Thanks. This pull request has now been integrated. Changeset: e9f97b2e Author: David Holmes URL: https://git.openjdk.org/jdk/commit/e9f97b2e8cf301ba6b69101e5efc5c71d26bc87b Stats: 28 lines in 28 files changed: 0 ins; 0 del; 28 mod 8290489: Initial nroff manpage generation for JDK 20 Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/9581 From aturbanov at openjdk.org Fri Jul 22 07:08:15 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 22 Jul 2022 07:08:15 GMT Subject: RFR: 8290861: Remove unused field URLJarFile.BUF_SIZE Message-ID: Static field 'BUF_SIZE' in the class sun.net.[www.protocol.jar.URLJarFile](http://www.protocol.jar.urljarfile/) is unused and can be removed. ------------- Commit messages: - [PATCH] Remove unused field URLJarFile.BUF_SIZE Changes: https://git.openjdk.org/jdk/pull/9602/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9602&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290861 Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9602.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9602/head:pull/9602 PR: https://git.openjdk.org/jdk/pull/9602 From jpai at openjdk.org Fri Jul 22 07:22:06 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 22 Jul 2022 07:22:06 GMT Subject: RFR: 8290861: Remove unused field URLJarFile.BUF_SIZE In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 20:00:37 GMT, Andrey Turbanov wrote: > Static field 'BUF_SIZE' in the class sun.net.[www.protocol.jar.URLJarFile](http://www.protocol.jar.urljarfile/) is unused and can be removed. The change looks fine to me. The `BUF_SIZE` appears to be a left over from the change done in https://github.com/openjdk/jdk/commit/313991183b716ea420c2a2155ada03191faca6b7 for https://bugs.openjdk.org/browse/JDK-7018392 ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/9602 From djelinski at openjdk.org Fri Jul 22 07:48:08 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 22 Jul 2022 07:48:08 GMT Subject: RFR: 8290861: Remove unused field URLJarFile.BUF_SIZE In-Reply-To: References: Message-ID: <9yXawsyZJHOuSbos2puJn2h0KyY4B0be6kN7PRrRSX0=.408e26fe-a3f9-4b04-9411-cea824e863f8@github.com> On Thu, 21 Jul 2022 20:00:37 GMT, Andrey Turbanov wrote: > Static field 'BUF_SIZE' in the class sun.net.[www.protocol.jar.URLJarFile](http://www.protocol.jar.urljarfile/) is unused and can be removed. Marked as reviewed by djelinski (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/9602 From aefimov at openjdk.org Fri Jul 22 11:45:24 2022 From: aefimov at openjdk.org (Aleksei Efimov) Date: Fri, 22 Jul 2022 11:45:24 GMT Subject: RFR: 8290861: Remove unused field URLJarFile.BUF_SIZE In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 20:00:37 GMT, Andrey Turbanov wrote: > Static field 'BUF_SIZE' in the class sun.net.[www.protocol.jar.URLJarFile](http://www.protocol.jar.urljarfile/) is unused and can be removed. Marked as reviewed by aefimov (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/9602 From aturbanov at openjdk.org Fri Jul 22 15:59:58 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 22 Jul 2022 15:59:58 GMT Subject: Integrated: 8290861: Remove unused field URLJarFile.BUF_SIZE In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 20:00:37 GMT, Andrey Turbanov wrote: > Static field 'BUF_SIZE' in the class sun.net.[www.protocol.jar.URLJarFile](http://www.protocol.jar.urljarfile/) is unused and can be removed. This pull request has now been integrated. Changeset: 62f22633 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/62f22633d1025809f88b41ae3a6891f23215be09 Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod 8290861: Remove unused field URLJarFile.BUF_SIZE Reviewed-by: jpai, djelinski, aefimov ------------- PR: https://git.openjdk.org/jdk/pull/9602 From michaelm at openjdk.org Mon Jul 25 10:55:04 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 25 Jul 2022 10:55:04 GMT Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header In-Reply-To: References: Message-ID: <1Flj2PO4zcxQgpmfZ3aw29S4PV5Wb1AyGs835PUezy8=.ba1e88f3-15c2-4e61-808b-d301ab372ec8@github.com> On Wed, 20 Jul 2022 17:19:50 GMT, Daniel Jeli?ski wrote: > This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X. > > All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*. > > On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options. > > As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test. > > Testing performed (with IP_DONTFRAGMENT flag): > Windows 10: > With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag. > Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable. > > For other systems I could not capture packets, so I can only report the observed behavior of sending packets. > Windows 2012 and 2016 (IP_MTU_DISCOVER not supported): > With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds. > If a packet is sent to a non-routable address, send succeeds, no error is reported. > > Linux: > With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds. > > Mac OS X 12: > Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior. Thanks for taking care of this. One small comment. I think we should edit the comments (such as in src/java.base/unix/native/libnio/ch/Net.c, also the windows version) that say the dual set option call is only for multicast options to also include this option. ------------- PR: https://git.openjdk.org/jdk/pull/9575 From michaelm at openjdk.org Mon Jul 25 10:55:06 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 25 Jul 2022 10:55:06 GMT Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header In-Reply-To: References: <3no302rlOTE2mXILPU297bKZCbSgwgDK5I5mGDp9Cis=.b7c9e3ca-5971-4e54-8526-01fe2ca7a5f8@github.com> Message-ID: On Thu, 21 Jul 2022 17:41:22 GMT, Daniel Jeli?ski wrote: >> src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c line 207: >> >>> 205: } >>> 206: } >>> 207: return JNI_TRUE; >> >> Hello Daniel, if I'm reading this diff correctly, then we have inverted the check on `fd`. So I suspect this final `return` now needs to be changed to `return JNI_FALSE` to account for `fd` being `-1`? > > Hi Jaikiran, the point of this change was to better support systems where either IPv4 or IPv6 was disabled. I'm not sure if that can even happen on Mac. > The change here is that if we can't create one socket, we don't immediately return false, but instead return the result for the other socket. For example, if creating IPv4 socket fails, we only check if DF is supported on IPv6 socket, and return that as a result. If both `socket` calls fail, we don't know if the DF flag is supported, and return true (before the patch we would return false in that case). I can modify the patch to return false in that case, or roll back this change entirely if you think it makes no sense. I think this change makes sense so long as we are sure that if IPv4 or IPv6 is disabled then the right call happens for the other option. ------------- PR: https://git.openjdk.org/jdk/pull/9575 From duke at openjdk.org Fri Jul 29 06:49:22 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Fri, 29 Jul 2022 06:49:22 GMT Subject: RFR: 8051627: Invariants about java.net.URI resolve and relativize are wrong Message-ID: The current documentation of URI class describes relationship between resolve and relativize methods as follows. For any two normalized URIs u and v, u.relativize(u.resolve(v)).equals(v) and u.resolve(u.relativize(v)).equals(v) . However, there are some cases where this relationship is not true. For example, when u and v are "http://a/b" and "c/d", respectively, both u.relativize(u.resolve(v)) and u.resolve(u.relativize(v)) equal to "http://a/c/d" not "c/d". The documentation should be updated to avoid confusion by describing the relationship between resolve nd relativize methods under certain conditions of the URI. Note that these conditions are sufficient but not necessary for the statement. ------------- Commit messages: - 8051627: Invariants about java.net.URI resolve and relativize are wrong - 8051627: Invariants about java.net.URI resolve and relativize are wrong Changes: https://git.openjdk.org/jdk/pull/9671/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9671&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8051627 Stats: 12 lines in 1 file changed: 8 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9671.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9671/head:pull/9671 PR: https://git.openjdk.org/jdk/pull/9671