From redestad at openjdk.java.net Mon Aug 2 11:40:36 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 11:40:36 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList [v5] In-Reply-To: References: Message-ID: <_IT0JRHdfpmkeZIKV0F3138xY_AJgeRi8_-iRh0ZgkQ=.2b1bfed1-0473-4f45-be5a-8da3a3b14406@github.com> On Mon, 26 Jul 2021 08:27:20 GMT, ?????? ??????? wrote: >> After I've renamed remove branch GitHub for some reason has closed original https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it. > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'master' into 8263561 > - Merge branch 'master' into 8263561 > - Merge branch 'master' into 8263561 > - Merge branch 'master' into 8263561 > - Merge branch 'master' into 8263561 > > # Conflicts: > # src/java.base/unix/classes/sun/net/dns/ResolverConfigurationImpl.java > - Merge branch 'master' into purge-linked-list > - 8263561: Use sized constructor where reasonable > - 8263561: Use interface List instead of particular type where possible > - 8263561: Rename requestList -> requests > - 8263561: Re-examine uses of LinkedList I always approve of removing LinkedLists and Vectors. Using ArrayDeque in AbstractPoller seems like the right choice. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4304 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:39:47 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 12:39:47 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList [v6] In-Reply-To: References: Message-ID: > After I've renamed remove branch GitHub for some reason has closed original https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it. ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'master' into 8263561 # Conflicts: # src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java - Merge branch 'master' into 8263561 - Merge branch 'master' into 8263561 - Merge branch 'master' into 8263561 - Merge branch 'master' into 8263561 - Merge branch 'master' into 8263561 # Conflicts: # src/java.base/unix/classes/sun/net/dns/ResolverConfigurationImpl.java - Merge branch 'master' into purge-linked-list - 8263561: Use sized constructor where reasonable - 8263561: Use interface List instead of particular type where possible - 8263561: Rename requestList -> requests - ... and 1 more: https://git.openjdk.java.net/jdk/compare/7cc1eb3e...dea42cac ------------- Changes: https://git.openjdk.java.net/jdk/pull/4304/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4304&range=05 Stats: 47 lines in 9 files changed: 0 ins; 2 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/4304.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4304/head:pull/4304 PR: https://git.openjdk.java.net/jdk/pull/4304 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:53:37 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 12:53:37 GMT Subject: Integrated: 8263561: Re-examine uses of LinkedList In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 12:10:46 GMT, ?????? ??????? wrote: > After I've renamed remove branch GitHub for some reason has closed original https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it. This pull request has now been integrated. Changeset: 249d6418 Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/249d641889c6f9aed6957502d5fca9c74c9baceb Stats: 47 lines in 9 files changed: 0 ins; 2 del; 45 mod 8263561: Re-examine uses of LinkedList Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/4304 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 15:55:34 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 15:55:34 GMT Subject: RFR: 8267840: Improve URLStreamHandler.parseURL() In-Reply-To: References: <-R7H3cRkX5gZ6CVkIgSKlHjFjch26YNdrf7KeUcDKjw=.2f407d7e-810f-48ae-bb9b-4b9fec96e5ce@github.com> Message-ID: On Wed, 23 Jun 2021 10:03:48 GMT, ?????? ??????? wrote: >> Hi Sergey, >> >> That exception means you're using an obsolete version of jtreg: you need jtreg-6+1 now. >> >> best regards, >> -- daniel > > @dfuch I've fixed the issue and retested the changes, tier1 is ok, in tier2 some IPv6 tests on my machine are failing, but they fail both on `master` and `8267840` branches, so seem to be unrelated to the change. > @stsypanov This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! Let's wait ------------- PR: https://git.openjdk.java.net/jdk/pull/4526 From dfuchs at openjdk.java.net Wed Aug 4 10:57:29 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 4 Aug 2021 10:57:29 GMT Subject: RFR: 8270903: sun.net.httpserver.HttpConnection: Improve toString In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 10:22:51 GMT, Julia Boes wrote: > This is a minor change that updates `sun.net.httpserver.HttpConnection::toString` to never return null. > > Testing: tier 1-3 all clear src/jdk.httpserver/share/classes/sun/net/httpserver/HttpConnection.java line 69: > 67: > 68: public String toString() { > 69: final var sb = new StringBuilder(HttpConnection.class.getSimpleName()); Why not simplify into `new StringBuilder(getClass().getSimpleName());` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4928 From chegar at openjdk.java.net Wed Aug 4 12:48:27 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 4 Aug 2021 12:48:27 GMT Subject: RFR: 8270903: sun.net.httpserver.HttpConnection: Improve toString In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 10:22:51 GMT, Julia Boes wrote: > This is a minor change that updates `sun.net.httpserver.HttpConnection::toString` to never return null. > > Testing: tier 1-3 all clear Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4928 From chegar at openjdk.java.net Wed Aug 4 12:48:28 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 4 Aug 2021 12:48:28 GMT Subject: RFR: 8270903: sun.net.httpserver.HttpConnection: Improve toString In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 10:54:10 GMT, Daniel Fuchs wrote: >> This is a minor change that updates `sun.net.httpserver.HttpConnection::toString` to never return null. >> >> Testing: tier 1-3 all clear > > src/jdk.httpserver/share/classes/sun/net/httpserver/HttpConnection.java line 69: > >> 67: >> 68: public String toString() { >> 69: final var sb = new StringBuilder(HttpConnection.class.getSimpleName()); > > Why not simplify into `new StringBuilder(getClass().getSimpleName());` ? Have a marginal preference for HttpConnection.class.getSimpleName(), since it is a constant, but don't object to getClass(). ------------- PR: https://git.openjdk.java.net/jdk/pull/4928 From dfuchs at openjdk.java.net Wed Aug 4 15:11:30 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 4 Aug 2021 15:11:30 GMT Subject: RFR: 8267840: Improve URLStreamHandler.parseURL() [v3] In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 13:42:15 GMT, ?????? ??????? wrote: >> There is an optimization opportunity for the widespread use-case when a resource is read from classpath using `getClass().getClassLoader().getResource()` or `getClass().getClassLoader().getResourceAsStream()`. >> >> Pay attention to lines starting from 261. In case I run something like >> >> var props = getClass().getClassLoader().getResource("/application.properties"); >> >> I get into the if-else block starting from 251 and here 'separator' variable is an empty String. In this case we can skip 'separator' from concatenation chain and use `String.concat()` as there are only two items concatenated. >> >> In the opposite case `separator` variable is `"/"` and at the same time `ind` variable is `-1`. This means that expression `path.substring(0, ind + 1)` always returns an empty String and again can be excluded from concatenation chain allowing usage of `String.concat()` which allows to dodge utilization of `StringBuilder` (here `StringConcatFactory` is not available, see https://github.com/openjdk/jdk/pull/3627) >> >> In the next else-block, starting from 274, again, `String.concat()` is applicable. >> >> In another if-else block, starting from 277, when id is 0 again path.substring(0, ind) returns empty String making concatenation pointless and avoidable. >> >> There are also some other minor clean-ups possible regarding constant conditions (lines 252 and 161). >> >> The change allows to reduce significantly resource look-up costs for a very wide-spread case: >> >> @State(Scope.Benchmark) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class ClassGetResourceBenchmark { >> private final Class clazz = getClass(); >> >> @Benchmark >> public URL getResource() { >> return clazz.getResource("/application.properties"); >> } >> } >> >> The change allows to reduce memory consumption significantly: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> ClassGetResourceBenchmark.getResource avgt 100 1649,367 ? 5,904 ns/op >> ClassGetResourceBenchmark.getResource:?gc.alloc.rate avgt 100 619,204 ? 2,413 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.alloc.rate.norm avgt 100 1339,232 ? 4,909 B/op >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 627,192 ? 74,972 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 1356,681 ? 162,354 B/op >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,119 ? 0,100 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,257 ? 0,217 B/op >> ClassGetResourceBenchmark.getResource:?gc.count avgt 100 128,000 counts >> ClassGetResourceBenchmark.getResource:?gc.time avgt 100 227,000 ms >> >> after >> >> Benchmark Mode Cnt Score Error Units >> ClassGetResourceBenchmark.getResource avgt 100 1599,948 ? 4,115 ns/op >> ClassGetResourceBenchmark.getResource:?gc.alloc.rate avgt 100 358,434 ? 0,922 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.alloc.rate.norm avgt 100 752,016 ? 0,004 B/op >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 342,778 ? 76,490 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 719,264 ? 160,513 B/op >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,008 ? 0,005 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,017 ? 0,010 B/op >> ClassGetResourceBenchmark.getResource:?gc.count avgt 100 70,000 counts >> ClassGetResourceBenchmark.getResource:?gc.time avgt 100 151,000 ms > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8267840: Improve URLStreamHandler.parseURL() - remove unnecessary String.concat() call Thanks for waiting - and sorry for the delay. I want to send this PR through our test system before approving, but things LGTM so far. ------------- PR: https://git.openjdk.java.net/jdk/pull/4526 From dfuchs at openjdk.java.net Wed Aug 4 15:14:29 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 4 Aug 2021 15:14:29 GMT Subject: RFR: 8270903: sun.net.httpserver.HttpConnection: Improve toString In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 12:43:43 GMT, Chris Hegarty wrote: >> src/jdk.httpserver/share/classes/sun/net/httpserver/HttpConnection.java line 69: >> >>> 67: >>> 68: public String toString() { >>> 69: final var sb = new StringBuilder(HttpConnection.class.getSimpleName()); >> >> Why not simplify into `new StringBuilder(getClass().getSimpleName());` ? > > Have a marginal preference for HttpConnection.class.getSimpleName(), since it is a constant, but don't object to getClass(). Right - but then why not use a string literal? If you're going to call a method to get the class name then I assume you want to get the actual concrete class name... I don't have much objection either way - especially since I suspect there are no subclasses anyway... ------------- PR: https://git.openjdk.java.net/jdk/pull/4928 From dfuchs at openjdk.java.net Wed Aug 4 18:21:32 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 4 Aug 2021 18:21:32 GMT Subject: RFR: 8267840: Improve URLStreamHandler.parseURL() [v3] In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 13:42:15 GMT, ?????? ??????? wrote: >> There is an optimization opportunity for the widespread use-case when a resource is read from classpath using `getClass().getClassLoader().getResource()` or `getClass().getClassLoader().getResourceAsStream()`. >> >> Pay attention to lines starting from 261. In case I run something like >> >> var props = getClass().getClassLoader().getResource("/application.properties"); >> >> I get into the if-else block starting from 251 and here 'separator' variable is an empty String. In this case we can skip 'separator' from concatenation chain and use `String.concat()` as there are only two items concatenated. >> >> In the opposite case `separator` variable is `"/"` and at the same time `ind` variable is `-1`. This means that expression `path.substring(0, ind + 1)` always returns an empty String and again can be excluded from concatenation chain allowing usage of `String.concat()` which allows to dodge utilization of `StringBuilder` (here `StringConcatFactory` is not available, see https://github.com/openjdk/jdk/pull/3627) >> >> In the next else-block, starting from 274, again, `String.concat()` is applicable. >> >> In another if-else block, starting from 277, when id is 0 again path.substring(0, ind) returns empty String making concatenation pointless and avoidable. >> >> There are also some other minor clean-ups possible regarding constant conditions (lines 252 and 161). >> >> The change allows to reduce significantly resource look-up costs for a very wide-spread case: >> >> @State(Scope.Benchmark) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class ClassGetResourceBenchmark { >> private final Class clazz = getClass(); >> >> @Benchmark >> public URL getResource() { >> return clazz.getResource("/application.properties"); >> } >> } >> >> The change allows to reduce memory consumption significantly: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> ClassGetResourceBenchmark.getResource avgt 100 1649,367 ? 5,904 ns/op >> ClassGetResourceBenchmark.getResource:?gc.alloc.rate avgt 100 619,204 ? 2,413 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.alloc.rate.norm avgt 100 1339,232 ? 4,909 B/op >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 627,192 ? 74,972 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 1356,681 ? 162,354 B/op >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,119 ? 0,100 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,257 ? 0,217 B/op >> ClassGetResourceBenchmark.getResource:?gc.count avgt 100 128,000 counts >> ClassGetResourceBenchmark.getResource:?gc.time avgt 100 227,000 ms >> >> after >> >> Benchmark Mode Cnt Score Error Units >> ClassGetResourceBenchmark.getResource avgt 100 1599,948 ? 4,115 ns/op >> ClassGetResourceBenchmark.getResource:?gc.alloc.rate avgt 100 358,434 ? 0,922 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.alloc.rate.norm avgt 100 752,016 ? 0,004 B/op >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 342,778 ? 76,490 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 719,264 ? 160,513 B/op >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,008 ? 0,005 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,017 ? 0,010 B/op >> ClassGetResourceBenchmark.getResource:?gc.count avgt 100 70,000 counts >> ClassGetResourceBenchmark.getResource:?gc.time avgt 100 151,000 ms > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8267840: Improve URLStreamHandler.parseURL() - remove unnecessary String.concat() call Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4526 From vtewari at openjdk.java.net Thu Aug 5 06:49:29 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Thu, 5 Aug 2021 06:49:29 GMT Subject: RFR: 8270903: sun.net.httpserver.HttpConnection: Improve toString In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 10:22:51 GMT, Julia Boes wrote: > This is a minor change that updates `sun.net.httpserver.HttpConnection::toString` to never return null. > > Testing: tier 1-3 all clear Looks good. ------------- Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.java.net/jdk/pull/4928 From jboes at openjdk.java.net Thu Aug 5 09:25:30 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 5 Aug 2021 09:25:30 GMT Subject: RFR: 8270903: sun.net.httpserver.HttpConnection: Improve toString In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 15:11:59 GMT, Daniel Fuchs wrote: >> Have a marginal preference for HttpConnection.class.getSimpleName(), since it is a constant, but don't object to getClass(). > > Right - but then why not use a string literal? If you're going to call a method to get the class name then I assume you want to get the actual concrete class name... I don't have much objection either way - especially since I suspect there are no subclasses anyway... Given that there are no subclasses and it's not a public class, I'll stick to the original version. ------------- PR: https://git.openjdk.java.net/jdk/pull/4928 From jboes at openjdk.java.net Thu Aug 5 09:45:32 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 5 Aug 2021 09:45:32 GMT Subject: Integrated: 8270903: sun.net.httpserver.HttpConnection: Improve toString In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 10:22:51 GMT, Julia Boes wrote: > This is a minor change that updates `sun.net.httpserver.HttpConnection::toString` to never return null. > > Testing: tier 1-3 all clear This pull request has now been integrated. Changeset: 685fc3c6 Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/685fc3c677cd0e71ef4443214ae14c7eed355140 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod 8270903: sun.net.httpserver.HttpConnection: Improve toString Reviewed-by: chegar, vtewari ------------- PR: https://git.openjdk.java.net/jdk/pull/4928 From dfuchs at openjdk.java.net Thu Aug 5 10:34:31 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 5 Aug 2021 10:34:31 GMT Subject: RFR: 8270553: Tests should not use (real, in-use, routable) 1.1.1.1 as dummy IP value In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 09:16:23 GMT, Jonathan Dowland wrote: > The tests `test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java` uses the IP address "1.1.1.1" as a value. I think at the time the address was picked, the assumption was the address was not valid / not routable. Since April 2018 the address is part of CloudFlare's "Free" DNS product: . (this test was originally written in 2016, before the service was launched) > > I've verified using local packet captures that running the test does result in IP traffic being sent to 1.1.1.1. (Several other tests in JDK use 1.1.1.1 as a placeholder IP. I've checked them all and none of the others connect out to the IP like this one) > > This PR substitutes that IP address value (and two others) for ones from a reserved IP range (240.0.0.0/4 according to RFC 6761) which will not result in runners of the test suit inadvertently sending IP packets to the CloudFlare service. > > This could be invalidated again if that address range is allocated at some point in the future. A more future-proof fix would be to bind to random ports on localhost for each dummy proxy (as done for the target HTTP server in the test already). I can do that if preferred. > > Thanks for suggesting a replacement for the 1.1.1.1 address Jonathan! I have run your patch through our test system and not observed any errors caused by this patch - so from my perspective you're good to go. Could you please add a comment before the line where the `240.*` addresses are used that explains that these addresses are reserved (Class E network) and are not supposed to point to any existing endpoint? ------------- PR: https://git.openjdk.java.net/jdk/pull/4806 From redestad at openjdk.java.net Thu Aug 5 14:50:31 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 5 Aug 2021 14:50:31 GMT Subject: RFR: 8267840: Improve URLStreamHandler.parseURL() [v3] In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 13:42:15 GMT, ?????? ??????? wrote: >> There is an optimization opportunity for the widespread use-case when a resource is read from classpath using `getClass().getClassLoader().getResource()` or `getClass().getClassLoader().getResourceAsStream()`. >> >> Pay attention to lines starting from 261. In case I run something like >> >> var props = getClass().getClassLoader().getResource("/application.properties"); >> >> I get into the if-else block starting from 251 and here 'separator' variable is an empty String. In this case we can skip 'separator' from concatenation chain and use `String.concat()` as there are only two items concatenated. >> >> In the opposite case `separator` variable is `"/"` and at the same time `ind` variable is `-1`. This means that expression `path.substring(0, ind + 1)` always returns an empty String and again can be excluded from concatenation chain allowing usage of `String.concat()` which allows to dodge utilization of `StringBuilder` (here `StringConcatFactory` is not available, see https://github.com/openjdk/jdk/pull/3627) >> >> In the next else-block, starting from 274, again, `String.concat()` is applicable. >> >> In another if-else block, starting from 277, when id is 0 again path.substring(0, ind) returns empty String making concatenation pointless and avoidable. >> >> There are also some other minor clean-ups possible regarding constant conditions (lines 252 and 161). >> >> The change allows to reduce significantly resource look-up costs for a very wide-spread case: >> >> @State(Scope.Benchmark) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class ClassGetResourceBenchmark { >> private final Class clazz = getClass(); >> >> @Benchmark >> public URL getResource() { >> return clazz.getResource("/application.properties"); >> } >> } >> >> The change allows to reduce memory consumption significantly: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> ClassGetResourceBenchmark.getResource avgt 100 1649,367 ? 5,904 ns/op >> ClassGetResourceBenchmark.getResource:?gc.alloc.rate avgt 100 619,204 ? 2,413 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.alloc.rate.norm avgt 100 1339,232 ? 4,909 B/op >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 627,192 ? 74,972 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 1356,681 ? 162,354 B/op >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,119 ? 0,100 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,257 ? 0,217 B/op >> ClassGetResourceBenchmark.getResource:?gc.count avgt 100 128,000 counts >> ClassGetResourceBenchmark.getResource:?gc.time avgt 100 227,000 ms >> >> after >> >> Benchmark Mode Cnt Score Error Units >> ClassGetResourceBenchmark.getResource avgt 100 1599,948 ? 4,115 ns/op >> ClassGetResourceBenchmark.getResource:?gc.alloc.rate avgt 100 358,434 ? 0,922 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.alloc.rate.norm avgt 100 752,016 ? 0,004 B/op >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 342,778 ? 76,490 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 719,264 ? 160,513 B/op >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,008 ? 0,005 MB/sec >> ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,017 ? 0,010 B/op >> ClassGetResourceBenchmark.getResource:?gc.count avgt 100 70,000 counts >> ClassGetResourceBenchmark.getResource:?gc.time avgt 100 151,000 ms > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8267840: Improve URLStreamHandler.parseURL() - remove unnecessary String.concat() call LGTM ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4526 From github.com+10835776+stsypanov at openjdk.java.net Thu Aug 5 14:57:38 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 5 Aug 2021 14:57:38 GMT Subject: Integrated: 8267840: Improve URLStreamHandler.parseURL() In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 07:31:14 GMT, ?????? ??????? wrote: > There is an optimization opportunity for the widespread use-case when a resource is read from classpath using `getClass().getClassLoader().getResource()` or `getClass().getClassLoader().getResourceAsStream()`. > > Pay attention to lines starting from 261. In case I run something like > > var props = getClass().getClassLoader().getResource("/application.properties"); > > I get into the if-else block starting from 251 and here 'separator' variable is an empty String. In this case we can skip 'separator' from concatenation chain and use `String.concat()` as there are only two items concatenated. > > In the opposite case `separator` variable is `"/"` and at the same time `ind` variable is `-1`. This means that expression `path.substring(0, ind + 1)` always returns an empty String and again can be excluded from concatenation chain allowing usage of `String.concat()` which allows to dodge utilization of `StringBuilder` (here `StringConcatFactory` is not available, see https://github.com/openjdk/jdk/pull/3627) > > In the next else-block, starting from 274, again, `String.concat()` is applicable. > > In another if-else block, starting from 277, when id is 0 again path.substring(0, ind) returns empty String making concatenation pointless and avoidable. > > There are also some other minor clean-ups possible regarding constant conditions (lines 252 and 161). > > The change allows to reduce significantly resource look-up costs for a very wide-spread case: > > @State(Scope.Benchmark) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class ClassGetResourceBenchmark { > private final Class clazz = getClass(); > > @Benchmark > public URL getResource() { > return clazz.getResource("/application.properties"); > } > } > > The change allows to reduce memory consumption significantly: > > before > > Benchmark Mode Cnt Score Error Units > ClassGetResourceBenchmark.getResource avgt 100 1649,367 ? 5,904 ns/op > ClassGetResourceBenchmark.getResource:?gc.alloc.rate avgt 100 619,204 ? 2,413 MB/sec > ClassGetResourceBenchmark.getResource:?gc.alloc.rate.norm avgt 100 1339,232 ? 4,909 B/op > ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 627,192 ? 74,972 MB/sec > ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 1356,681 ? 162,354 B/op > ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,119 ? 0,100 MB/sec > ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,257 ? 0,217 B/op > ClassGetResourceBenchmark.getResource:?gc.count avgt 100 128,000 counts > ClassGetResourceBenchmark.getResource:?gc.time avgt 100 227,000 ms > > after > > Benchmark Mode Cnt Score Error Units > ClassGetResourceBenchmark.getResource avgt 100 1599,948 ? 4,115 ns/op > ClassGetResourceBenchmark.getResource:?gc.alloc.rate avgt 100 358,434 ? 0,922 MB/sec > ClassGetResourceBenchmark.getResource:?gc.alloc.rate.norm avgt 100 752,016 ? 0,004 B/op > ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space avgt 100 342,778 ? 76,490 MB/sec > ClassGetResourceBenchmark.getResource:?gc.churn.G1_Eden_Space.norm avgt 100 719,264 ? 160,513 B/op > ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space avgt 100 0,008 ? 0,005 MB/sec > ClassGetResourceBenchmark.getResource:?gc.churn.G1_Survivor_Space.norm avgt 100 0,017 ? 0,010 B/op > ClassGetResourceBenchmark.getResource:?gc.count avgt 100 70,000 counts > ClassGetResourceBenchmark.getResource:?gc.time avgt 100 151,000 ms This pull request has now been integrated. Changeset: d7fc9e41 Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/d7fc9e4171efa4154951cf353df10f9bacbed7ab Stats: 25 lines in 1 file changed: 3 ins; 8 del; 14 mod 8267840: Improve URLStreamHandler.parseURL() Reviewed-by: dfuchs, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/4526 From jdowland at openjdk.java.net Fri Aug 6 19:50:48 2021 From: jdowland at openjdk.java.net (Jonathan Dowland) Date: Fri, 6 Aug 2021 19:50:48 GMT Subject: RFR: 8270553: Tests should not use (real, in-use, routable) 1.1.1.1 as dummy IP value [v2] In-Reply-To: References: Message-ID: > The tests `test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java` uses the IP address "1.1.1.1" as a value. I think at the time the address was picked, the assumption was the address was not valid / not routable. Since April 2018 the address is part of CloudFlare's "Free" DNS product: . (this test was originally written in 2016, before the service was launched) > > I've verified using local packet captures that running the test does result in IP traffic being sent to 1.1.1.1. (Several other tests in JDK use 1.1.1.1 as a placeholder IP. I've checked them all and none of the others connect out to the IP like this one) > > This PR substitutes that IP address value (and two others) for ones from a reserved IP range (240.0.0.0/4 according to RFC 6761) which will not result in runners of the test suit inadvertently sending IP packets to the CloudFlare service. > > This could be invalidated again if that address range is allocated at some point in the future. A more future-proof fix would be to bind to random ports on localhost for each dummy proxy (as done for the target HTTP server in the test already). I can do that if preferred. > > Jonathan Dowland has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8270553: Tests should not use (real, in-use, routable) 1.1.1.1 as dummy IP value ------------- Changes: https://git.openjdk.java.net/jdk/pull/4806/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4806&range=01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4806.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4806/head:pull/4806 PR: https://git.openjdk.java.net/jdk/pull/4806 From serb at openjdk.java.net Tue Aug 10 05:20:42 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 10 Aug 2021 05:20:42 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules Message-ID: This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. In many places standard charsets are looked up via their names, for example: absolutePath.getBytes("UTF-8"); This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: absolutePath.getBytes(StandardCharsets.UTF_8); The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. ------------- Commit messages: - Initial fix of JDK-8272120 Changes: https://git.openjdk.java.net/jdk/pull/5063/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5063&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272120 Stats: 127 lines in 15 files changed: 24 ins; 53 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/5063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5063/head:pull/5063 PR: https://git.openjdk.java.net/jdk/pull/5063 From alanb at openjdk.java.net Tue Aug 10 09:21:28 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 Aug 2021 09:21:28 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. It would be useful to get up to date performance data on using Charset vs. charset name. At least historically, the charset name versions were faster (see [JDK-6764325](https://bugs.openjdk.java.net/browse/JDK-6764325)). ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From serb at openjdk.java.net Tue Aug 10 18:09:26 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 10 Aug 2021 18:09:26 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: <9hTy8U6wk2uDoxCYlENexy2olb-8vaF49ZukcQj_bSA=.b9c53124-ea69-4cee-8698-3781b2b4acc5@github.com> On Tue, 10 Aug 2021 09:18:39 GMT, Alan Bateman wrote: > It would be useful to get up to date performance data on using Charset vs. charset name. At least historically, the charset name versions were faster (see [JDK-6764325](https://bugs.openjdk.java.net/browse/JDK-6764325)). The code in question was changed a few times since then, the last change was done by the https://github.com/openjdk/jdk/pull/2102. So currently the code for string.getBytes String/Charset uses the same code paths, except that the string version has an additional call to lookup the charset. The string version: https://github.com/openjdk/jdk/blob/66d1faa7847b645f20ab2e966adf0a523e3ffeb2/src/java.base/share/classes/java/lang/String.java#L1753 The charset version: https://github.com/openjdk/jdk/blob/66d1faa7847b645f20ab2e966adf0a523e3ffeb2/src/java.base/share/classes/java/lang/String.java#L1777 I checked the performance and the charset is always faster, depending on the string size, up to x20. @cl4es please confirm my observation since you did it already for https://github.com/openjdk/jdk/pull/2102 ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From redestad at openjdk.java.net Tue Aug 10 18:44:26 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 10 Aug 2021 18:44:26 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Yes, while I don't know exactly which changes resolved JDK-6764325, it's clear from the microbenchmarks added for #2102 that it's no longer an issue - at least not in the mainline. ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From dfuchs at openjdk.java.net Wed Aug 11 09:15:24 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 11 Aug 2021 09:15:24 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. >From my pure developer's perspective the proposed changes look good. If the performance concerns are removed I'd say it looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From naoto at openjdk.java.net Wed Aug 11 17:08:23 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 11 Aug 2021 17:08:23 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From alanb at openjdk.java.net Wed Aug 11 18:59:22 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 Aug 2021 18:59:22 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 18:41:04 GMT, Claes Redestad wrote: > Yes, while I don't know exactly which changes resolved JDK-6764325, it's clear from the microbenchmarks added for #2102 that it's no longer an issue - at least not in the mainline. Thanks for checking and for closing that issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From alanb at openjdk.java.net Wed Aug 11 18:59:22 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 Aug 2021 18:59:22 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From dfuchs at openjdk.java.net Wed Aug 11 19:04:24 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 11 Aug 2021 19:04:24 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From naoto at openjdk.java.net Wed Aug 11 19:10:26 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 11 Aug 2021 19:10:26 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From serb at openjdk.java.net Thu Aug 12 05:49:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 12 Aug 2021 05:49:28 GMT Subject: Integrated: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. This pull request has now been integrated. Changeset: ec2fc384 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/ec2fc384e50668b667335f973ffeb5a19bbcfb9b Stats: 127 lines in 15 files changed: 24 ins; 53 del; 50 mod 8272120: Avoid looking for standard encodings in "java." modules Reviewed-by: alanb, dfuchs, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From jboes at openjdk.java.net Thu Aug 12 13:55:33 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 12 Aug 2021 13:55:33 GMT Subject: RFR: 8272334: com.sun.net.httpserver.HttpExchange: Improve API doc of getRequestHeaders Message-ID: This is a doc-only fix that improves the wording of the API doc of `getRequestHeaders()`. The other changes are trivial cleanup. ------------- Commit messages: - cleanup - Add note on multiple header fields - initial commit Changes: https://git.openjdk.java.net/jdk/pull/5100/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5100&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272334 Stats: 27 lines in 1 file changed: 5 ins; 3 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/5100.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5100/head:pull/5100 PR: https://git.openjdk.java.net/jdk/pull/5100 From dfuchs at openjdk.java.net Thu Aug 12 14:17:26 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 12 Aug 2021 14:17:26 GMT Subject: RFR: 8272334: com.sun.net.httpserver.HttpExchange: Improve API doc of getRequestHeaders In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 13:44:23 GMT, Julia Boes wrote: > This is a doc-only fix that improves the wording of the API doc of `getRequestHeaders()`. The other changes are trivial cleanup. Marked as reviewed by dfuchs (Reviewer). Please have Michael review the changes too before pushing ------------- PR: https://git.openjdk.java.net/jdk/pull/5100 From naoto at openjdk.java.net Thu Aug 12 20:22:04 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 12 Aug 2021 20:22:04 GMT Subject: RFR: 8260265: UTF-8 by Default [v7] In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 Naoto Sato 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 12 additional commits since the last revision: - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Refined `file.encoding` description - Merge branch 'master' into JDK-8260265 - Reflects comments - Removed leftover `console` references in `PrintStream` - Reflects comments - Reflects review comments - ... and 2 more: https://git.openjdk.java.net/jdk/compare/387b32b3...7d5137d3 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4733/files - new: https://git.openjdk.java.net/jdk/pull/4733/files/6f9e5eb4..7d5137d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=05-06 Stats: 53933 lines in 926 files changed: 45460 ins; 4145 del; 4328 mod Patch: https://git.openjdk.java.net/jdk/pull/4733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4733/head:pull/4733 PR: https://git.openjdk.java.net/jdk/pull/4733 From michael.x.mcmahon at oracle.com Fri Aug 13 16:07:20 2021 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 13 Aug 2021 17:07:20 +0100 Subject: RFR: 8270290: NTLM authentication fails if HEAD request is used In-Reply-To: References: Message-ID: Hi, A question about this issue. Can you explain why the server/proxy is sending a response body to a HEAD request? My reading of the RFCs suggests this is not allowed. Thanks, Michael On 12/07/2021 11:54, Alex Kasko wrote: > On Mon, 12 Jul 2021 10:34:54 GMT, Alex Kasko wrote: > >> When HEAD request is used with a proxy (or a server) that requires NTLM, authentication fails when server returns large (8kb+) body along with NTLMSSP_CHALLENGE response. >> >> Proposed fix is to check for ongoing NTLM auth in `reset()` and consume the response body in this case. >> >> Alternatively the whole check for `HEAD` method in `reset()` can be dropped. > Just for the reference, `reset()` calls during NTLM auth: > > server auth: > > https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L1849 > > proxy auth with plain HTTP: > > https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L1762 > > proxy tunnel with HTTPS: > > https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L2233 > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4753 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelm at openjdk.java.net Mon Aug 16 14:04:27 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 16 Aug 2021 14:04:27 GMT Subject: RFR: 8272334: com.sun.net.httpserver.HttpExchange: Improve API doc of getRequestHeaders In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 13:44:23 GMT, Julia Boes wrote: > This is a doc-only fix that improves the wording of the API doc of `getRequestHeaders()`. The other changes are trivial cleanup. Marked as reviewed by michaelm (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5100 From chegar at openjdk.java.net Mon Aug 16 14:58:24 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 16 Aug 2021 14:58:24 GMT Subject: RFR: 8272334: com.sun.net.httpserver.HttpExchange: Improve API doc of getRequestHeaders In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 13:44:23 GMT, Julia Boes wrote: > This is a doc-only fix that improves the wording of the API doc of `getRequestHeaders()`. The other changes are trivial cleanup. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5100 From github.com+5709644+fdesu at openjdk.java.net Mon Aug 16 16:12:27 2021 From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko) Date: Mon, 16 Aug 2021 16:12:27 GMT Subject: RFR: 8253178: Replace LinkedList Impl in net.http.FilterFactory [v3] In-Reply-To: <49xBA23EM5VQU4bUhhoUQBhLXEQVzrRiPj2QDeOTlCQ=.ad8d277c-2d65-4aaf-a501-ceb558ddca95@github.com> References: <49xBA23EM5VQU4bUhhoUQBhLXEQVzrRiPj2QDeOTlCQ=.ad8d277c-2d65-4aaf-a501-ceb558ddca95@github.com> Message-ID: On Mon, 19 Jul 2021 10:24:27 GMT, Sergei Ustimenko wrote: >> This patch replaces a LinkedList data structure used in the net.http.FilterFactory class with an ArrayList. This issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in java.net.](https://bugs.openjdk.java.net/browse/JDK-8246048). >> >> The list created once per HttpClient and filled with upfront known values (3 of them in the jdk.internal.net.http.HttpClientImpl#initFilters: AuthenticationFilter.class, RedirectFilter.class and depending on the presence of a cookieHandler - a CookieFilter.class). > > Sergei Ustimenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - 8253178: Trim the size for list with headers > - 8253178: Replace LinkedList Impl in net.http.FilterFactory Hi, it would be great if anyone would have time to take a quick look on this pull request. I hope this change is still relevant and I am happy to have any feedback from you. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4721 From ewhelan at openjdk.java.net Tue Aug 17 08:52:36 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 17 Aug 2021 08:52:36 GMT Subject: RFR: 8133686: HttpURLConnection.getHeaderFields and URLConnection.getRequestProperties methods return field values in reverse order [v4] In-Reply-To: References: Message-ID: > Hi all, > > Please review this fix for which corrects the order in which field values are returned from the `HttpURLConnection.getHeaderFields` and `URLConnection.getRequestProperties` methods. > > Currently, the implementation of these methods returns the values in reverse. This does not conform with the RFC2616 spec which outlines that the order of these field values should not be changed. > > Thanks, > Evan Evan Whelan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Changed spec text to make correct use of tags - Merge branch 'master' into JDK-8133686_MessageHeader - MessageHeaderTest add comma to copyright year - URLConnection doc fixes - 8133686: 8133686: HttpURLConnection.getHeaderFields and URLConnection.getRequestProperties methods return field values in reverse order v2 - 8133686: HttpURLConnection.getHeaderFields and URLConnection.getRequestProperties methods return field values in reverse order ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2294/files - new: https://git.openjdk.java.net/jdk/pull/2294/files/4e0c96cb..160d9e33 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2294&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2294&range=02-03 Stats: 1550176 lines in 16228 files changed: 796447 ins; 678052 del; 75677 mod Patch: https://git.openjdk.java.net/jdk/pull/2294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2294/head:pull/2294 PR: https://git.openjdk.java.net/jdk/pull/2294 From dfuchs at openjdk.java.net Tue Aug 17 09:03:51 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 17 Aug 2021 09:03:51 GMT Subject: RFR: 8133686: HttpURLConnection.getHeaderFields and URLConnection.getRequestProperties methods return field values in reverse order [v4] In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 08:52:36 GMT, Evan Whelan wrote: >> Hi all, >> >> Please review this fix for which corrects the order in which field values are returned from the `HttpURLConnection.getHeaderFields` and `URLConnection.getRequestProperties` methods. >> >> Currently, the implementation of these methods returns the values in reverse. This does not conform with the RFC2616 spec which outlines that the order of these field values should not be changed. >> >> Thanks, >> Evan > > Evan Whelan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Changed spec text to make correct use of tags > - Merge branch 'master' into JDK-8133686_MessageHeader > - MessageHeaderTest add comma to copyright year > - URLConnection doc fixes > - 8133686: 8133686: HttpURLConnection.getHeaderFields and URLConnection.getRequestProperties methods return field values in reverse order v2 > - 8133686: HttpURLConnection.getHeaderFields and URLConnection.getRequestProperties methods return field values in reverse order Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2294 From jboes at openjdk.java.net Tue Aug 17 09:28:23 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 17 Aug 2021 09:28:23 GMT Subject: RFR: 8272334: com.sun.net.httpserver.HttpExchange: Improve API doc of getRequestHeaders In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 13:44:23 GMT, Julia Boes wrote: > This is a doc-only fix that improves the wording of the API doc of `getRequestHeaders()`. The other changes are trivial cleanup. CSR https://bugs.openjdk.java.net/browse/JDK-8272565 ------------- PR: https://git.openjdk.java.net/jdk/pull/5100 From jboes at openjdk.java.net Tue Aug 17 10:55:02 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 17 Aug 2021 10:55:02 GMT Subject: RFR: 8272334: com.sun.net.httpserver.HttpExchange: Improve API doc of getRequestHeaders [v2] In-Reply-To: References: Message-ID: > This is a doc-only fix that improves the wording of the API doc of `getRequestHeaders()`. The other changes are trivial cleanup. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: small fix of tense ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5100/files - new: https://git.openjdk.java.net/jdk/pull/5100/files/5fdccc32..9b87ced4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5100&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5100&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5100.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5100/head:pull/5100 PR: https://git.openjdk.java.net/jdk/pull/5100 From chegar at openjdk.java.net Tue Aug 17 11:00:33 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 17 Aug 2021 11:00:33 GMT Subject: RFR: 8272334: com.sun.net.httpserver.HttpExchange: Improve API doc of getRequestHeaders [v2] In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 10:55:02 GMT, Julia Boes wrote: >> This is a doc-only fix that improves the wording of the API doc of `getRequestHeaders()`. The other changes are trivial cleanup. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > small fix of tense Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5100 From dfuchs at openjdk.java.net Tue Aug 17 11:16:24 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 17 Aug 2021 11:16:24 GMT Subject: RFR: 8272334: com.sun.net.httpserver.HttpExchange: Improve API doc of getRequestHeaders [v2] In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 10:55:02 GMT, Julia Boes wrote: >> This is a doc-only fix that improves the wording of the API doc of `getRequestHeaders()`. The other changes are trivial cleanup. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > small fix of tense Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5100 From dfuchs at openjdk.java.net Tue Aug 17 12:34:32 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 17 Aug 2021 12:34:32 GMT Subject: RFR: 8253178: Replace LinkedList Impl in net.http.FilterFactory [v3] In-Reply-To: <49xBA23EM5VQU4bUhhoUQBhLXEQVzrRiPj2QDeOTlCQ=.ad8d277c-2d65-4aaf-a501-ceb558ddca95@github.com> References: <49xBA23EM5VQU4bUhhoUQBhLXEQVzrRiPj2QDeOTlCQ=.ad8d277c-2d65-4aaf-a501-ceb558ddca95@github.com> Message-ID: <50xlH2BVoMC7ZMaq-X9B_l88CRy4LX9HQTndpORfSQA=.ed539e75-d6b4-4152-9b78-20d360cd1a62@github.com> On Mon, 19 Jul 2021 10:24:27 GMT, Sergei Ustimenko wrote: >> This patch replaces a LinkedList data structure used in the net.http.FilterFactory class with an ArrayList. This issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in java.net.](https://bugs.openjdk.java.net/browse/JDK-8246048). >> >> The list created once per HttpClient and filled with upfront known values (3 of them in the jdk.internal.net.http.HttpClientImpl#initFilters: AuthenticationFilter.class, RedirectFilter.class and depending on the presence of a cookieHandler - a CookieFilter.class). > > Sergei Ustimenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - 8253178: Trim the size for list with headers > - 8253178: Replace LinkedList Impl in net.http.FilterFactory Hi Sergei - I will have a look. It may take some time until I come back to you (my apologies). ------------- PR: https://git.openjdk.java.net/jdk/pull/4721 From turbanoff at gmail.com Wed Aug 18 09:38:39 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Wed, 18 Aug 2021 12:38:39 +0300 Subject: Suspicious 'completed' variable in ResponseContent.UnknownLengthBodyParser#accept Message-ID: Hello During investigation of results of IDEA inspections I found suspicious code in a method 'jdk.internal.net.http.ResponseContent.UnknownLengthBodyParser#accept' https://github.com/openjdk/jdk/blob/master/src/java.net.http/share/classes/jdk/internal/net/http/ResponseContent.java#L492 boolean completed = false; try { if (debug.on()) debug.log("Parser got %d bytes ", b.remaining()); if (b.hasRemaining()) { // only reduce demand if we actually push something. // we would not have come here if there was no // demand. boolean hasDemand = sub.demand().tryDecrement(); assert hasDemand; breceived += b.remaining(); pusher.onNext(List.of(b.asReadOnlyBuffer())); } } catch (Throwable t) { if (debug.on()) debug.log("Unexpected exception", t); closedExceptionally = t; if (!completed) { onComplete.accept(t); } } Variable 'completed' has an initial value 'false' and never assigned again. Then it's checked in the 'catch' section. It seems it should be set to 'true' somewhere. Andrey Turbanov From daniel.fuchs at oracle.com Wed Aug 18 09:55:17 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 18 Aug 2021 10:55:17 +0100 Subject: Suspicious 'completed' variable in ResponseContent.UnknownLengthBodyParser#accept In-Reply-To: References: Message-ID: Hi Andrey, Thanks for the notice. I believe the variable is not needed, it's probably a copy-paste error. You will see that such a variable is also declared in the FixedLengthBodyParser where it's actually used. The UnknownLenghtParser will parse the bytes until the connection is closed (or an exception occurs) - so `completed` is not really needed there. best regards, -- daniel On 18/08/2021 10:38, Andrey Turbanov wrote: > Hello > > During investigation of results of IDEA inspections I found suspicious > code in a method > 'jdk.internal.net.http.ResponseContent.UnknownLengthBodyParser#accept' > https://github.com/openjdk/jdk/blob/master/src/java.net.http/share/classes/jdk/internal/net/http/ResponseContent.java#L492 > > boolean completed = false; > try { > if (debug.on()) > debug.log("Parser got %d bytes ", b.remaining()); > > if (b.hasRemaining()) { > // only reduce demand if we actually push something. > // we would not have come here if there was no > // demand. > boolean hasDemand = sub.demand().tryDecrement(); > assert hasDemand; > breceived += b.remaining(); > pusher.onNext(List.of(b.asReadOnlyBuffer())); > } > } catch (Throwable t) { > if (debug.on()) debug.log("Unexpected exception", t); > closedExceptionally = t; > if (!completed) { > onComplete.accept(t); > } > } > > > Variable 'completed' has an initial value 'false' and never assigned again. > Then it's checked in the 'catch' section. > It seems it should be set to 'true' somewhere. > > > Andrey Turbanov > From redestad at openjdk.java.net Wed Aug 18 10:14:46 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 18 Aug 2021 10:14:46 GMT Subject: RFR: 8272626: Avoid C-style array declarations in java.* Message-ID: C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. (Copyrights intentionally not updated due the triviality of most changes) ------------- Commit messages: - Avoid C-style array declarations in java packages Changes: https://git.openjdk.java.net/jdk/pull/5161/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5161&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272626 Stats: 140 lines in 54 files changed: 0 ins; 0 del; 140 mod Patch: https://git.openjdk.java.net/jdk/pull/5161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5161/head:pull/5161 PR: https://git.openjdk.java.net/jdk/pull/5161 From dfuchs at openjdk.java.net Wed Aug 18 10:36:22 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 18 Aug 2021 10:36:22 GMT Subject: RFR: 8272626: Avoid C-style array declarations in java.* In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5161 From alanb at openjdk.java.net Wed Aug 18 10:41:27 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 18 Aug 2021 10:41:27 GMT Subject: RFR: 8272626: Avoid C-style array declarations in java.* In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5161 From redestad at openjdk.java.net Wed Aug 18 10:50:32 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 18 Aug 2021 10:50:32 GMT Subject: Integrated: 8272626: Avoid C-style array declarations in java.* In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) This pull request has now been integrated. Changeset: 30b0f820 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/30b0f820cec12b6da62229fe78a528ab3ad0d134 Stats: 140 lines in 54 files changed: 0 ins; 0 del; 140 mod 8272626: Avoid C-style array declarations in java.* Reviewed-by: dfuchs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5161 From redestad at openjdk.java.net Wed Aug 18 10:50:32 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 18 Aug 2021 10:50:32 GMT Subject: RFR: 8272626: Avoid C-style array declarations in java.* In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) Thanks for reviewing, Daniel and Alan! ------------- PR: https://git.openjdk.java.net/jdk/pull/5161 From rriggs at openjdk.java.net Wed Aug 18 13:20:28 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 18 Aug 2021 13:20:28 GMT Subject: RFR: 8272626: Avoid C-style array declarations in java.* In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) 34 Minutes from proposed to integrated! Its hard to argue with the efficiency, but only 1 timezone of developers had a chance to review or even be aware of the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/5161 From joe.darcy at oracle.com Wed Aug 18 16:31:12 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 18 Aug 2021 09:31:12 -0700 Subject: RFR: 8272626: Avoid C-style array declarations in java.* In-Reply-To: References: Message-ID: <1eb1c8b3-dfc6-8ba3-9fe3-0df6c6ed4184@oracle.com> On 8/18/2021 6:20 AM, Roger Riggs wrote: > On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > >> C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. >> >> (Copyrights intentionally not updated due the triviality of most changes) > 34 Minutes from proposed to integrated! > Its hard to argue with the efficiency, but only 1 timezone of developers had a chance to review or even be aware of the change. > I don't think removing use of this archaic language feature, which doesn't change semantics, should be in any way controversial and is long overdue. -Joe From jboes at openjdk.java.net Thu Aug 19 09:12:27 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 19 Aug 2021 09:12:27 GMT Subject: Integrated: 8272334: com.sun.net.httpserver.HttpExchange: Improve API doc of getRequestHeaders In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 13:44:23 GMT, Julia Boes wrote: > This is a doc-only fix that improves the wording of the API doc of `getRequestHeaders()`. The other changes are trivial cleanup. This pull request has now been integrated. Changeset: 1c80f078 Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/1c80f078f61a53ee80640e76a9af86f9b16a0618 Stats: 27 lines in 1 file changed: 5 ins; 3 del; 19 mod 8272334: com.sun.net.httpserver.HttpExchange: Improve API doc of getRequestHeaders Reviewed-by: dfuchs, michaelm, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/5100 From dfuchs at openjdk.java.net Thu Aug 19 14:09:39 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 19 Aug 2021 14:09:39 GMT Subject: RFR: 8258951: java/net/httpclient/HandshakeFailureTest.java failed with "RuntimeException: Not found expected SSLHandshakeException in java.io.IOException" Message-ID: Please find here a patch that fixes intermittent failures in HandshakeFailureTest.java. The test expects an SSLException but finds an AssertionError instead. The AssertionError was too strong and was fired before the Http2Connection had a chance to raise the proper ALPNException. ------------- Commit messages: - 8258951: java/net/httpclient/HandshakeFailureTest.java failed with "RuntimeException: Not found expected SSLHandshakeException in java.io.IOException" - 8258951: java/net/httpclient/HandshakeFailureTest.java failed with "RuntimeException: Not found expected SSLHandshakeException in java.io.IOException" Changes: https://git.openjdk.java.net/jdk/pull/5184/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5184&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258951 Stats: 8 lines in 2 files changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5184.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5184/head:pull/5184 PR: https://git.openjdk.java.net/jdk/pull/5184 From chegar at openjdk.java.net Thu Aug 19 15:43:25 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 19 Aug 2021 15:43:25 GMT Subject: RFR: 8258951: java/net/httpclient/HandshakeFailureTest.java failed with "RuntimeException: Not found expected SSLHandshakeException in java.io.IOException" In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 14:02:28 GMT, Daniel Fuchs wrote: > Please find here a patch that fixes intermittent failures in HandshakeFailureTest.java. The test expects an SSLException but finds an AssertionError instead. The AssertionError was too strong and was fired before the Http2Connection had a chance to raise the proper ALPNException. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5184 From turbanoff at gmail.com Thu Aug 19 18:50:35 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Thu, 19 Aug 2021 21:50:35 +0300 Subject: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize Message-ID: Hello. During investigation of results of IDEA inspections I found a redundant call to Math.min in a method jdk.internal.net.http.Http2ClientImpl#getConnectionWindowSize https://github.com/openjdk/jdk/blob/master/src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java#L240 int defaultValue = Math.min(Integer.MAX_VALUE, Math.max(streamWindow, K*K*32)); Call of method Math.min(int, int) is redundant if one of parameters is known to be Integer.MAX_VALUE (or Integer.MIN_VALUE) Andrey Turbanov From dfuchs at openjdk.java.net Fri Aug 20 09:08:25 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 20 Aug 2021 09:08:25 GMT Subject: Integrated: 8258951: java/net/httpclient/HandshakeFailureTest.java failed with "RuntimeException: Not found expected SSLHandshakeException in java.io.IOException" In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 14:02:28 GMT, Daniel Fuchs wrote: > Please find here a patch that fixes intermittent failures in HandshakeFailureTest.java. The test expects an SSLException but finds an AssertionError instead. The AssertionError was too strong and was fired before the Http2Connection had a chance to raise the proper ALPNException. This pull request has now been integrated. Changeset: db9834ff Author: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/db9834ff82ce477e5c38c8873d39f54882627746 Stats: 8 lines in 2 files changed: 3 ins; 0 del; 5 mod 8258951: java/net/httpclient/HandshakeFailureTest.java failed with "RuntimeException: Not found expected SSLHandshakeException in java.io.IOException" Reviewed-by: chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/5184 From jai.forums2013 at gmail.com Sat Aug 21 07:17:19 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 21 Aug 2021 12:47:19 +0530 Subject: JEP-353 - Socket.connect now throws NoRouteToHostException as against ConnectException previously Message-ID: JEP-353[1] which got implemented and released in JDK13, states: "The java.net package defines many sub-classes of SocketException. The new implementation will attempt to throw the same specific SocketException as the old implementation but there may be cases where they are not the same." In one of the projects I watch, a recent issue[2] shows that the "Socket.connect(...)" call, in certain cases, now throws a "java.net.NoRouteToHostException" exception as opposed to "java.net.ConnectException" in previous versions before this change. The "Socket.connect(...)" javadoc states that this API can throw an "IOException", so this change, in theory, is still fine and doesn't break any API contract. However, as noted in [2], certain libraries (Apache HTTP client 4.5.x versions in this case) expect a certain exception type when it's dealing with decision making for HTTP request retries. Due to this change in the exception type being thrown, the Apache HTTP client library now behaves differently in Java 11 and Java 16. Is this change of exception type being thrown intentional? Or is there interest in changing back to the previous exception type to preserve backward compatibility? If not, I think the Apache HTTP client library will have to perhaps do certain changes to have this part of the code behave the same across Java versions. For the sake of reference, here's the snippet of the exception stacktrace in Java 11 and Java 16: Java 11 stacktrace: Caused by: java.net.ConnectException: No route to host (connect failed) ??? at java.base/java.net.PlainSocketImpl.socketConnect(Native Method) ??? at java.base/java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:399) ??? at java.base/java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:242) ??? at java.base/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:224) ??? at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:403) ??? at java.base/java.net.Socket.connect(Socket.java:609) ??? at org.apache.http.conn.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:75) ??? at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142) ??? ... 116 more Java 16 stacktrace: Caused by: java.net.NoRouteToHostException: No route to host ??? at java.base/sun.nio.ch.Net.connect0(Native Method) ??? at java.base/sun.nio.ch.Net.connect(Net.java:576) ??? at java.base/sun.nio.ch.Net.connect(Net.java:565) ??? at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:588) ??? at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:333) ??? at java.base/java.net.Socket.connect(Socket.java:645) ??? at org.apache.http.conn.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:75) ??? at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142) [1] https://openjdk.java.net/jeps/353 [2] https://github.com/quarkusio/quarkus/pull/19559 -Jaikiran From Alan.Bateman at oracle.com Sat Aug 21 08:51:26 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 21 Aug 2021 09:51:26 +0100 Subject: JEP-353 - Socket.connect now throws NoRouteToHostException as against ConnectException previously In-Reply-To: References: Message-ID: <47b38645-d7ff-53a8-81fd-f3124ba310c0@oracle.com> On 21/08/2021 08:17, Jaikiran Pai wrote: > JEP-353[1] which got implemented and released in JDK13, states: > > "The java.net package defines many sub-classes of SocketException. The > new implementation will attempt to throw the same specific > SocketException as the old implementation but there may be cases where > they are not the same." > > In one of the projects I watch, a recent issue[2] shows that the > "Socket.connect(...)" call, in certain cases, now throws a > "java.net.NoRouteToHostException" exception as opposed to > "java.net.ConnectException" in previous versions before this change. > The "Socket.connect(...)" javadoc states that this API can throw an > "IOException", so this change, in theory, is still fine and doesn't > break any API contract. However, as noted in [2], certain libraries > (Apache HTTP client 4.5.x versions in this case) expect a certain > exception type when it's dealing with decision making for HTTP request > retries. Due to this change in the exception type being thrown, the > Apache HTTP client library now behaves differently in Java 11 and Java > 16. > > Is this change of exception type being thrown intentional? Or is there > interest in changing back to the previous exception type to preserve > backward compatibility? If not, I think the Apache HTTP client library > will have to perhaps do certain changes to have this part of the code > behave the same across Java versions. Thanks for the mail, I haven't seen any other reports on this. Can you say which operating system and say a bit more about the conditions where this is observed? When connecting to a host that is not reachable then it's possible for the underlying connect to fail with a "Connection timed out", "No route to host", or other errors. The reason I'm asking about the OS/conditions is that the old implementation did attempt to map specific errors to NoRouteToHostException. There's an example stack stack (Windows, with JDK 9) in this bug report: ? https://bugs.openjdk.java.net/browse/JDK-8042714 In general, the mapping of connect errors to sub-classes of SocketException has always been best effort and I both both ConnectException and NoRouteToHostException are possible, all depends on the underlying error. So my initial reaction is that we shouldn't do anything right now, I think we need to know a bit more abut the environment/conditions as I'm puzzled as to why the HTTP client retry decision didn't run into this before with the old implementation. -Alan From jai.forums2013 at gmail.com Sat Aug 21 11:40:53 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 21 Aug 2021 17:10:53 +0530 Subject: JEP-353 - Socket.connect now throws NoRouteToHostException as against ConnectException previously In-Reply-To: <47b38645-d7ff-53a8-81fd-f3124ba310c0@oracle.com> References: <47b38645-d7ff-53a8-81fd-f3124ba310c0@oracle.com> Message-ID: Hello Alan, On 21/08/21 2:21 pm, Alan Bateman wrote: > On 21/08/2021 08:17, Jaikiran Pai wrote: >> JEP-353[1] which got implemented and released in JDK13, states: >> >> "The java.net package defines many sub-classes of SocketException. >> The new implementation will attempt to throw the same specific >> SocketException as the old implementation but there may be cases >> where they are not the same." >> >> In one of the projects I watch, a recent issue[2] shows that the >> "Socket.connect(...)" call, in certain cases, now throws a >> "java.net.NoRouteToHostException" exception as opposed to >> "java.net.ConnectException" in previous versions before this change. >> The "Socket.connect(...)" javadoc states that this API can throw an >> "IOException", so this change, in theory, is still fine and doesn't >> break any API contract. However, as noted in [2], certain libraries >> (Apache HTTP client 4.5.x versions in this case) expect a certain >> exception type when it's dealing with decision making for HTTP >> request retries. Due to this change in the exception type being >> thrown, the Apache HTTP client library now behaves differently in >> Java 11 and Java 16. >> >> Is this change of exception type being thrown intentional? Or is >> there interest in changing back to the previous exception type to >> preserve backward compatibility? If not, I think the Apache HTTP >> client library will have to perhaps do certain changes to have this >> part of the code behave the same across Java versions. > > Thanks for the mail, I haven't seen any other reports on this. > > Can you say which operating system and say a bit more about the > conditions where this is observed? I was able to reproduce this on a MacOS. However, the continuous integration setup project for Quarkus projects runs these tests against Linux and Windows setups and they have run into this issue at least on the Linux OS jobs (I will need to go and check if Windows jobs had failed too). I can get the specific OS versions if necessary, but I don't think that will be needed (due to the reproducer I explain below). > When connecting to a host that is not reachable then it's possible for > the underlying connect to fail with a "Connection timed out", "No > route to host", or other errors. > > The reason I'm asking about the OS/conditions is that the old > implementation did attempt to map specific errors to > NoRouteToHostException. There's an example stack stack (Windows, with > JDK 9) in this bug report: > ? https://bugs.openjdk.java.net/browse/JDK-8042714 > > In general, the mapping of connect errors to sub-classes of > SocketException has always been best effort and I both both > ConnectException and NoRouteToHostException are possible, all depends > on the underlying error. > > So my initial reaction is that we shouldn't do anything right now, I > think we need to know a bit more abut the environment/conditions as > I'm puzzled as to why the HTTP client retry decision didn't run into > this before with the old implementation. Now that you mentioned it, I decided to try and replicate this in a trivial Java program. My initial attempt didn't reproduce this. So I looked into the Apache HTTP client code and I can now reproduce this consistenly with the following trivial Java program (pasted at the end of this mail). What this program does is: - DNS resolves the IP addresses of "microprofile.io" (this is resolvable) - For each of the returned IP address, it then constructs a InetSocketAddress to port 1234. Nothing is listening on this port (on the remote end), so we do expect the connection attempts to fail. - It then instantiates a Socket instance out of this InetSocketAddress and calls connect on the socket instance. I ran this against Java 11, Java 16, Java 17 and latest upstream OpenJDK code. From what I see in the output of this program, the resolution of microprofile.io returns 4 IP addresses. 2 of them are of type IPv4 and 2 are of type IPv6. Across all Java versions, for IPv4 addresses, the connection attempts fail with the same "java.net.SocketTimeoutException: Connect timed out". However, for the IPv6 addresses, in Java 11, the connection attempts fail with "java.net.ConnectException: No route to host (connect failed)" whereas in Java 16, 17 and upstream latest, the connection attempts against the IPv6 addresses fails with "java.net.NoRouteToHostException: No route to host". Here's the trivial Java code which reproduces this for me. Let me know if you need additional details. import java.net.*; public class ConnectTest? { ??? public static void main(final String[] args) throws Exception { ??? ??? final int timeout = 10000; ??? ??? // our target host that DNS resolves correctly ??? ??? final String host = "microprofile.io"; ??? ??? // a port where nothing listens on ??? ??? final int port = 1234; ??? ??? // DNS resolve by hostname ??? ??? final InetAddress[] addrs = InetAddress.getAllByName(host); ??? ??? // try connecting to each IP on port ??? ??? for (final InetAddress addr : addrs) { ??? ??? ??? final String ip = addr.getHostAddress(); ??? ??? ??? String type = ""; ??? ??? ??? if (addr instanceof Inet4Address) { ??? ??? ??? ??? type = "IPv4"; ??? ??? ??? } else if (addr instanceof Inet6Address) { ??? ??? ??? ??? type = "IPv6"; ??? ??? ??? } ??? ??? ??? System.out.println("Trying to connect to " + type + " " + ip + " on port " + port); ??? ??? ??? try { ??? ??? ??? ??? new Socket().connect(new InetSocketAddress(addr, port), timeout); ??? ??? ??? ??? System.out.println("Connected to " + ip + " port " + port); ??? ??? ??? } catch (Exception e) { ??? ??? ??? ??? // we expect it to fail since no one listens on that port. We are interested ??? ??? ??? ??? // in the exception type that gets thrown ??? ??? ??? ??? System.out.println("Connection attempt to " + ip + " failed with following error:"); ??? ??? ??? ??? e.printStackTrace(System.out); ??? ??? ??? } ??? ??? } ??? } } -Jaikiran From Alan.Bateman at oracle.com Sat Aug 21 16:26:52 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 21 Aug 2021 17:26:52 +0100 Subject: JEP-353 - Socket.connect now throws NoRouteToHostException as against ConnectException previously In-Reply-To: References: <47b38645-d7ff-53a8-81fd-f3124ba310c0@oracle.com> Message-ID: <3e2ba401-e592-bd24-c78b-35ac159db156@oracle.com> On 21/08/2021 12:40, Jaikiran Pai wrote: > I was able to reproduce this on a MacOS. However, the continuous > integration setup project for Quarkus projects runs these tests > against Linux and Windows setups and they have run into this issue at > least on the Linux OS jobs (I will need to go and check if Windows > jobs had failed too). I can get the specific OS versions if necessary, > but I don't think that will be needed (due to the reproducer I explain > below). > > : > > From what I see in the output of this program, the resolution of > microprofile.io returns 4 IP addresses. 2 of them are of type IPv4 and > 2 are of type IPv6. Across all Java versions, for IPv4 addresses, the > connection attempts fail with the same > "java.net.SocketTimeoutException: Connect timed out". However, for the > IPv6 addresses, in Java 11, the connection attempts fail with > "java.net.ConnectException: No route to host (connect failed)" whereas > in Java 16, 17 and upstream latest, the connection attempts against > the IPv6 addresses fails with "java.net.NoRouteToHostException: No > route to host". Thanks for the additional information, I think I understand the issue now. If you extend your test to include a connect without a timeout then you'll see that old and new implementations throw NoRouteToHostException when the underlying error is EHOSTUNREACH "No route to host". However, for the connect with timeout case on Linux/macOS/Unix the old implementation doesn't correctly handle network errors when they are reported immediately. It throws ConnectException for all errors, including EHOSTUNREACH "No route to host", whereas it should map the error to a specific exception as it does for the untimed case. It's possible that this bug has existed for a long time. So while there is indeed a behavior change between the old and new implementation for the timed case where the connect fails immediately, I don't think we should attempt to change the new implementation to have this buggy behavior. Do you connections to the Apache HTTP client library and the retry code that is looking for specific exceptions? From a distance it seems very fragile and depending on very implementation specific behavior. I wonder if it has ever been tested on Windows or with an untimed connect. -Alan From jai.forums2013 at gmail.com Sun Aug 22 05:37:49 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sun, 22 Aug 2021 11:07:49 +0530 Subject: JEP-353 - Socket.connect now throws NoRouteToHostException as against ConnectException previously In-Reply-To: <3e2ba401-e592-bd24-c78b-35ac159db156@oracle.com> References: <47b38645-d7ff-53a8-81fd-f3124ba310c0@oracle.com> <3e2ba401-e592-bd24-c78b-35ac159db156@oracle.com> Message-ID: <5f8f25bb-0e40-fc58-e996-5b3dd9f75178@gmail.com> Hello Alan, On 21/08/21 9:56 pm, Alan Bateman wrote: > On 21/08/2021 12:40, Jaikiran Pai wrote: >> I was able to reproduce this on a MacOS. However, the continuous >> integration setup project for Quarkus projects runs these tests >> against Linux and Windows setups and they have run into this issue at >> least on the Linux OS jobs (I will need to go and check if Windows >> jobs had failed too). I can get the specific OS versions if >> necessary, but I don't think that will be needed (due to the >> reproducer I explain below). >> >> : >> >> From what I see in the output of this program, the resolution of >> microprofile.io returns 4 IP addresses. 2 of them are of type IPv4 >> and 2 are of type IPv6. Across all Java versions, for IPv4 addresses, >> the connection attempts fail with the same >> "java.net.SocketTimeoutException: Connect timed out". However, for >> the IPv6 addresses, in Java 11, the connection attempts fail with >> "java.net.ConnectException: No route to host (connect failed)" >> whereas in Java 16, 17 and upstream latest, the connection attempts >> against the IPv6 addresses fails with >> "java.net.NoRouteToHostException: No route to host". > > Thanks for the additional information, I think I understand the issue > now. > > If you extend your test to include a connect without a timeout then > you'll see that old and new implementations throw > NoRouteToHostException when the underlying error is EHOSTUNREACH "No > route to host". You are right - I tweaked my example to remove the timeout param being passed to the connect method and with that change, the exception that gets thrown is consistent (NoRouteToHostException) across Java version for IPv6 addresses. > However, for the connect with timeout case on Linux/macOS/Unix the old > implementation doesn't correctly handle network errors when they are > reported immediately. It throws ConnectException for all errors, > including EHOSTUNREACH "No route to host", whereas it should map the > error to a specific exception as it does for the untimed case. It's > possible that this bug has existed for a long time. > > So while there is indeed a behavior change between the old and new > implementation for the timed case where the connect fails immediately, > I don't think we should attempt to change the new implementation to > have this buggy behavior. > Thank you for that explanation and yes, what you say makes sense. > Do you connections to the Apache HTTP client library and the retry > code that is looking for specific exceptions? From a distance it seems > very fragile and depending on very implementation specific behavior. I > wonder if it has ever been tested on Windows or with an untimed connect. I am not involved in the Apache HTTP client library project. However, I will go ahead and open a discussion in their mailing list and bring this issue to their attention, so that they can decide how to deal with it. Thank you for your help and the explanation. -Jaikiran From serb at openjdk.java.net Sun Aug 22 06:28:18 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 22 Aug 2021 06:28:18 GMT Subject: RFR: 8272805: Avoid looking up standard charsets Message-ID: This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. See https://github.com/openjdk/jdk/pull/5063 and https://github.com/openjdk/jdk/pull/4951 In many places standard charsets are looked up via their names, for example: absolutePath.getBytes("UTF-8"); This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: absolutePath.getBytes(StandardCharsets.UTF_8); The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. This change includes: * demo/utils * jdk.xx packages * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. Also checked for "aliases" usage. Some performance discussion: https://github.com/openjdk/jdk/pull/5063 Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the "java.naming"(the change there is not straightforward, will do it later). Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. ------------- Commit messages: - Fix related imports - Merge branch 'master' into standard-encodings-in-non-public-modules - Cleanup UnsupportedEncodingException - Update PacketStream.java - Rollback TextTests, should be compatible with jdk1.4 - Rollback TextRenderTests, should be compatible with jdk1.4 - Cleanup the UnsupportedEncodingException - aliases for ISO_8859_1 - Update imageio - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/5210/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272805 Stats: 333 lines in 48 files changed: 91 ins; 123 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/5210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210 PR: https://git.openjdk.java.net/jdk/pull/5210 From weijun at openjdk.java.net Sun Aug 22 13:22:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 22 Aug 2021 13:22:38 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: <0eO4SD_N9lrP5k5bhEejUKXeMauRC8zuc_slUJSrc5c=.c886ae36-5039-450f-9293-5f9910ce432d@github.com> On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. The security related change looks fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5210 From alanb at openjdk.java.net Sun Aug 22 15:12:26 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 22 Aug 2021 15:12:26 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342: > 340: > 341: try { > 342: for (String line : Files.readAllLines(statusPath, UTF_8)) { The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want. ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From github.com+741251+turbanoff at openjdk.java.net Sun Aug 22 18:34:26 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 22 Aug 2021 18:34:26 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too. ![???????????](https://user-images.githubusercontent.com/741251/130366051-ef093bf1-d7d9-4ad1-91e7-5df5af8678af.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From serb at openjdk.java.net Sun Aug 22 23:02:06 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 22 Aug 2021 23:02:06 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Sergey Bylokhov 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 14 additional commits since the last revision: - Update the usage of Files.readAllLines() - Update datatransfer - Merge branch 'master' into standard-encodings-in-non-public-modules - Merge branch 'master' into standard-encodings-in-non-public-modules - Fix related imports - Merge branch 'master' into standard-encodings-in-non-public-modules - Cleanup UnsupportedEncodingException - Update PacketStream.java - Rollback TextTests, should be compatible with jdk1.4 - Rollback TextRenderTests, should be compatible with jdk1.4 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/37357100...e7127644 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5210/files - new: https://git.openjdk.java.net/jdk/pull/5210/files/2d9c80b8..e7127644 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=00-01 Stats: 3598 lines in 210 files changed: 2055 ins; 1115 del; 428 mod Patch: https://git.openjdk.java.net/jdk/pull/5210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210 PR: https://git.openjdk.java.net/jdk/pull/5210 From naoto at openjdk.java.net Mon Aug 23 00:26:31 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 23 Aug 2021 00:26:31 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/c262b06f...e7127644 Looks good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5210 From dfuchs at openjdk.java.net Mon Aug 23 09:36:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 23 Aug 2021 09:36:40 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/db47f6e1...e7127644 Changes to http server look good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5210 From dfuchs at openjdk.java.net Mon Aug 23 15:20:38 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 23 Aug 2021 15:20:38 GMT Subject: RFR: 8253178: Replace LinkedList Impl in net.http.FilterFactory [v3] In-Reply-To: <49xBA23EM5VQU4bUhhoUQBhLXEQVzrRiPj2QDeOTlCQ=.ad8d277c-2d65-4aaf-a501-ceb558ddca95@github.com> References: <49xBA23EM5VQU4bUhhoUQBhLXEQVzrRiPj2QDeOTlCQ=.ad8d277c-2d65-4aaf-a501-ceb558ddca95@github.com> Message-ID: On Mon, 19 Jul 2021 10:24:27 GMT, Sergei Ustimenko wrote: >> This patch replaces a LinkedList data structure used in the net.http.FilterFactory class with an ArrayList. This issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in java.net.](https://bugs.openjdk.java.net/browse/JDK-8246048). >> >> The list created once per HttpClient and filled with upfront known values (3 of them in the jdk.internal.net.http.HttpClientImpl#initFilters: AuthenticationFilter.class, RedirectFilter.class and depending on the presence of a cookieHandler - a CookieFilter.class). > > Sergei Ustimenko 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: > > - 8253178: Trim the size for list with headers > - 8253178: Replace LinkedList Impl in net.http.FilterFactory LGTM. I can sponsor once you have integrated . ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4721 From akashche at redhat.com Mon Aug 23 18:32:58 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 23 Aug 2021 19:32:58 +0100 Subject: RFR: 8270290: NTLM authentication fails if HEAD request is used In-Reply-To: References: Message-ID: Hi, On 8/13/21, Michael McMahon wrote: > Hi, > > A question about this issue. Can you explain why the server/proxy is > sending a response body to a HEAD request? > > My reading of the RFCs suggests this is not allowed. Thanks for your comment and sorry for the late reply. To put aside the question about the support for non-compliant proxy servers, consider the scenario with HTTPS tunneling where proxy server never sees the HEAD request (it receives CONNECT). Please see the following abridged interaction where HEAD request is initiated from java code to HTTPS host some.hostname.com with proxy enabled: Transmission Control Protocol, Src Port: 53335, Dst Port: 8080, Seq: 1, Ack: 1, Len: 185 Hypertext Transfer Protocol CONNECT some.hostname.com:443 HTTP/1.1\r\n User-Agent: Java/1.8.0_302\r\n Host: some.hostname.com\r\n Proxy-Connection: keep-alive\r\n \r\n Transmission Control Protocol, Src Port: 8080, Dst Port: 53335, Seq: 7245, Ack: 186, Len: 413 Hypertext Transfer Protocol HTTP/1.1 407 Proxy Authentication Required\r\n Proxy-Authenticate: NTLM\r\n Proxy-Connection: close\r\n Connection: close\r\n Content-Length: 7384\r\n \r\n File Data: 7384 bytes Line-based text data: text/html (39 lines) \r\n [...] Transmission Control Protocol, Src Port: 53336, Dst Port: 8080, Seq: 1, Ack: 1, Len: 281 Hypertext Transfer Protocol CONNECT some.hostname.com:443 HTTP/1.1\r\n User-Agent: Java/1.8.0_302\r\n Host: some.hostname.com\r\n Proxy-Connection: keep-alive\r\n Proxy-authorization: NTLM TlRM[...]\r\n \r\n Transmission Control Protocol, Src Port: 8080, Dst Port: 53336, Seq: 7245, Ack: 282, Len: 690 Hypertext Transfer Protocol HTTP/1.1 407 Proxy Authentication Required\r\n Proxy-Authenticate: NTLM TlRM[...]\r\n Proxy-Connection: Keep-Alive\r\n Connection: Keep-Alive\r\n Content-Length: 7401\r\n \r\n File Data: 7401 bytes Line-based text data: text/html (39 lines) \r\n [...] Transmission Control Protocol, Src Port: 53336, Dst Port: 8080, Seq: 282, Ack: 7935, Len: 781 Hypertext Transfer Protocol CONNECT some.hostname.com:443 HTTP/1.1\r\n User-Agent: Java/1.8.0_302\r\n Host: some.hostname.com\r\n Proxy-Connection: keep-alive\r\n Proxy-authorization: NTLM TlRML[...]\r\n \r\n Transmission Control Protocol, Src Port: 8080, Dst Port: 53336, Seq: 7935, Ack: 1063, Len: 39 Hypertext Transfer Protocol HTTP/1.1 200 Connection established\r\n \r\n In this case the response code from "200 Connection established" response cannot be read by jdk because response body from the last CONNECT response was not fully read from the socket, jdk master will fail with the following trace: java.util.NoSuchElementException at java.base/java.util.StringTokenizer.nextToken(StringTokenizer.java:347) at java.base/sun.net.www.protocol.http.HttpURLConnection.doTunneling0(HttpURLConnection.java:2191) [...] This can be reproduced running NTLMHeadTest.java with TUNNEL argument. SERVER and PROXY modes were added to the test for completeness, it may be better to remove them. > > [...] > >> PR: https://git.openjdk.java.net/jdk/pull/4753 > -- -Alex From serb at openjdk.java.net Mon Aug 23 19:34:38 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 Aug 2021 19:34:38 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 15:09:26 GMT, Alan Bateman wrote: >> Sergey Bylokhov 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 14 additional commits since the last revision: >> >> - Update the usage of Files.readAllLines() >> - Update datatransfer >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Fix related imports >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Cleanup UnsupportedEncodingException >> - Update PacketStream.java >> - Rollback TextTests, should be compatible with jdk1.4 >> - Rollback TextRenderTests, should be compatible with jdk1.4 >> - ... and 4 more: https://git.openjdk.java.net/jdk/compare/465eb90c...e7127644 > > src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342: > >> 340: >> 341: try { >> 342: for (String line : Files.readAllLines(statusPath, UTF_8)) { > > The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want. Thank you for the suggestion, I have fixed this and a few other places as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From serb at openjdk.java.net Mon Aug 23 19:34:34 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 Aug 2021 19:34:34 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 18:31:02 GMT, Andrey Turbanov wrote: > I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too. Updated as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From github.com+741251+turbanoff at openjdk.java.net Mon Aug 23 20:54:36 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 23 Aug 2021 20:54:36 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/aaa7beaf...e7127644 Marked as reviewed by turbanoff at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From jai.forums2013 at gmail.com Tue Aug 24 03:09:35 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 24 Aug 2021 08:39:35 +0530 Subject: JEP-353 - Socket.connect now throws NoRouteToHostException as against ConnectException previously In-Reply-To: <5f8f25bb-0e40-fc58-e996-5b3dd9f75178@gmail.com> References: <47b38645-d7ff-53a8-81fd-f3124ba310c0@oracle.com> <3e2ba401-e592-bd24-c78b-35ac159db156@oracle.com> <5f8f25bb-0e40-fc58-e996-5b3dd9f75178@gmail.com> Message-ID: <896b3eb6-7c17-2c15-9f1b-8ab36db9f964@gmail.com> > >> Do you connections to the Apache HTTP client library and the retry >> code that is looking for specific exceptions? From a distance it >> seems very fragile and depending on very implementation specific >> behavior. I wonder if it has ever been tested on Windows or with an >> untimed connect. > > I am not involved in the Apache HTTP client library project. However, > I will go ahead and open a discussion in their mailing list and bring > this issue to their attention, so that they can decide how to deal > with it. > > Thank you for your help and the explanation. This has now been fixed in the Apache HTTP client library to no longer treat these two exception types differently when it comes to retry handling logic https://github.com/apache/httpcomponents-client/pull/311 -Jaikiran From serb at openjdk.java.net Tue Aug 24 06:22:38 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 Aug 2021 06:22:38 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. The changes in the src/java.desktop/ looks fine. Filed: https://bugs.openjdk.java.net/browse/JDK-8272863 ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5229 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 06:22:38 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 06:22:38 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules Message-ID: Collections.sort is just a wrapper, so it is better to use an instance method directly. ------------- Commit messages: - [PATCH] Replace usages of Collections.sort with List.sort call in public java modules Changes: https://git.openjdk.java.net/jdk/pull/5229/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272863 Stats: 27 lines in 10 files changed: 0 ins; 8 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/5229.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229 PR: https://git.openjdk.java.net/jdk/pull/5229 From Alan.Bateman at oracle.com Tue Aug 24 06:47:37 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Aug 2021 07:47:37 +0100 Subject: JEP-353 - Socket.connect now throws NoRouteToHostException as against ConnectException previously In-Reply-To: <896b3eb6-7c17-2c15-9f1b-8ab36db9f964@gmail.com> References: <47b38645-d7ff-53a8-81fd-f3124ba310c0@oracle.com> <3e2ba401-e592-bd24-c78b-35ac159db156@oracle.com> <5f8f25bb-0e40-fc58-e996-5b3dd9f75178@gmail.com> <896b3eb6-7c17-2c15-9f1b-8ab36db9f964@gmail.com> Message-ID: On 24/08/2021 04:09, Jaikiran Pai wrote: > >> >>> Do you connections to the Apache HTTP client library and the retry >>> code that is looking for specific exceptions? From a distance it >>> seems very fragile and depending on very implementation specific >>> behavior. I wonder if it has ever been tested on Windows or with an >>> untimed connect. >> >> I am not involved in the Apache HTTP client library project. However, >> I will go ahead and open a discussion in their mailing list and bring >> this issue to their attention, so that they can decide how to deal >> with it. >> >> Thank you for your help and the explanation. > > This has now been fixed in the Apache HTTP client library to no longer > treat these two exception types differently when it comes to retry > handling logic Good. Note that BindException is possible when attempt to establish a connection because the kernel will bind the socket to a local port if not explicitly bound already. It might arise when there are no ports available. I don't know if this changes the retry logic in the HTTP client but thought I should mention it. -Alan From dfuchs at openjdk.java.net Tue Aug 24 10:59:27 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 24 Aug 2021 10:59:27 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. java/net and sun/net changes LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5229 From azvegint at openjdk.java.net Tue Aug 24 11:51:26 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 24 Aug 2021 11:51:26 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. There are a bunch of calls to `Collections.sort()` without a comparator specified (at least in java.desktop): https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/Spans.java#L144 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/DebugSettings.java#L278 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java#L787 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java#L1070 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java#L1204 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/GroupLayout.java#L2137 It is also a wrapper to `list.sort(null)`. Is there any reason to not touch them along with this fix? ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From azvegint at openjdk.java.net Tue Aug 24 13:09:37 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 24 Aug 2021 13:09:37 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8c6e27c3...e7127644 Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From github.com+5709644+fdesu at openjdk.java.net Tue Aug 24 14:53:30 2021 From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko) Date: Tue, 24 Aug 2021 14:53:30 GMT Subject: Integrated: 8253178: Replace LinkedList Impl in net.http.FilterFactory In-Reply-To: References: Message-ID: <9MYvsnQ9agYzERD7k6xzVZceApRDUMWYfUATzyvAik0=.f3090570-a982-4920-b39f-fe193c83e5d7@github.com> On Thu, 8 Jul 2021 10:38:33 GMT, Sergei Ustimenko wrote: > This patch replaces a LinkedList data structure used in the net.http.FilterFactory class with an ArrayList. This issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in java.net.](https://bugs.openjdk.java.net/browse/JDK-8246048). > > The list created once per HttpClient and filled with upfront known values (3 of them in the jdk.internal.net.http.HttpClientImpl#initFilters: AuthenticationFilter.class, RedirectFilter.class and depending on the presence of a cookieHandler - a CookieFilter.class). This pull request has now been integrated. Changeset: 2309b7d8 Author: Sergei Ustimenko Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/2309b7d8fc37e9ba8f80f7820ae2875ccc3b07fd Stats: 16 lines in 3 files changed: 2 ins; 4 del; 10 mod 8253178: Replace LinkedList Impl in net.http.FilterFactory Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/4721 From naoto at openjdk.java.net Tue Aug 24 15:55:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 24 Aug 2021 15:55:30 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. java.time changes look good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5229 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 20:21:52 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 20:21:52 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2] In-Reply-To: References: Message-ID: > Collections.sort is just a wrapper, so it is better to use an instance method directly. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8272863: Replace usages of Collections.sort with List.sort call in public java modules replace Collections.sort without comparator too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5229/files - new: https://git.openjdk.java.net/jdk/pull/5229/files/e31936a5..d6dfc8bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=00-01 Stats: 21 lines in 10 files changed: 0 ins; 4 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5229.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229 PR: https://git.openjdk.java.net/jdk/pull/5229 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 20:21:52 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 20:21:52 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 11:48:46 GMT, Alexander Zvegintsev wrote: > Is there any reason to not touch them along with this fix? Update them too. ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From akashche at redhat.com Tue Aug 24 21:24:03 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 24 Aug 2021 22:24:03 +0100 Subject: RFR: 8270290: NTLM authentication fails if HEAD request is used In-Reply-To: References: Message-ID: On 8/23/21, Alex Kashchenko wrote: > Hi, > > On 8/13/21, Michael McMahon wrote: >> Hi, >> >> A question about this issue. Can you explain why the server/proxy is >> sending a response body to a HEAD request? >> >> My reading of the RFCs suggests this is not allowed. > > Thanks for your comment and sorry for the late reply. To put aside the > question about the support for non-compliant proxy servers, consider > the scenario with HTTPS tunneling where proxy server never sees the > HEAD request (it receives CONNECT). Please see the following abridged > interaction where HEAD request is initiated from java code to HTTPS > host some.hostname.com with proxy enabled: > > [...] > > This can be reproduced running NTLMHeadTest.java with TUNNEL argument. > SERVER and PROXY modes were added to the test for completeness, it may > be better to remove them. A note on non-tunnel behaviour, I've reexamined its logic and found out that proposed patch breaks plain HTTP proxying (and server auth too) for HEAD requests, because the socket read in reset() [1] is blocking, and it blocks indefinitely for non-tunnel usage. The original problem is still valid for tunneling, I suggest to narrow the fix for tunneling only, will update the PR. [1] https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L2989 > >> >> [...] >> >>> PR: https://git.openjdk.java.net/jdk/pull/4753 >> -- -Alex From dfuchs at openjdk.java.net Wed Aug 25 08:33:26 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 25 Aug 2021 08:33:26 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 20:21:52 GMT, Andrey Turbanov wrote: >> Collections.sort is just a wrapper, so it is better to use an instance method directly. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8272863: Replace usages of Collections.sort with List.sort call in public java modules > replace Collections.sort without comparator too src/java.base/share/classes/java/net/URLPermission.java line 222: > 220: > 221: List l = normalizeMethods(methods); > 222: l.sort(null); I am not opposed to this change, but I find this is slightly more ugly than `Collections.sort(l)`; so I have to ask: Is there any noticeable benefit? ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From dfuchs at openjdk.java.net Wed Aug 25 08:49:28 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 25 Aug 2021 08:49:28 GMT Subject: RFR: 8270553: Tests should not use (real, in-use, routable) 1.1.1.1 as dummy IP value [v2] In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 19:50:48 GMT, Jonathan Dowland wrote: >> The tests `test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java` uses the IP address "1.1.1.1" as a value. I think at the time the address was picked, the assumption was the address was not valid / not routable. Since April 2018 the address is part of CloudFlare's "Free" DNS product: . (this test was originally written in 2016, before the service was launched) >> >> I've verified using local packet captures that running the test does result in IP traffic being sent to 1.1.1.1. (Several other tests in JDK use 1.1.1.1 as a placeholder IP. I've checked them all and none of the others connect out to the IP like this one) >> >> This PR substitutes that IP address value (and two others) for ones from a reserved IP range (240.0.0.0/4 according to RFC 6761) which will not result in runners of the test suit inadvertently sending IP packets to the CloudFlare service. >> >> This could be invalidated again if that address range is allocated at some point in the future. A more future-proof fix would be to bind to random ports on localhost for each dummy proxy (as done for the target HTTP server in the test already). I can do that if preferred. >> >> > > Jonathan Dowland has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8270553: Tests should not use (real, in-use, routable) 1.1.1.1 as dummy IP value LGTM. Thanks for adding the comment Jonathan! If you integrate I will sponsor this. (PS: I hadn't notice your changes because you used force-push - instead of merge - and the update sent by github let me believe the commit was a merge commit - apologies for the delay) ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4806 From daniel.fuchs at oracle.com Wed Aug 25 09:09:42 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 25 Aug 2021 10:09:42 +0100 Subject: CFV: New Networking Group Member: Patrick Concannon Message-ID: I hereby nominate Patrick Concannon to Membership in the Networking Group. Patrick is a Committer in the JDK project, and has been actively participating in the evolution and maintenance of the networking libraries for several years. Patrick was the principal contributor to the reimplementation of DatagramSocket (JEP 373), and has contributed many fixes in the networking area. Votes are due by 11:00 UTC Wednesday, 8 September 2021. Only current Members of the Networking Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. --daniel [1] https://openjdk.java.net/census#net [2] https://openjdk.java.net/groups/#member-vote From chris.hegarty at oracle.com Wed Aug 25 09:20:15 2021 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 25 Aug 2021 09:20:15 +0000 Subject: CFV: New Networking Group Member: Patrick Concannon In-Reply-To: References: Message-ID: > On 25 Aug 2021, at 10:10, Daniel Fuchs wrote: > > ?I hereby nominate Patrick Concannon to Membership in the Networking > Group. Vote: Yes -Chris From daniel.fuchs at oracle.com Wed Aug 25 09:24:01 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 25 Aug 2021 10:24:01 +0100 Subject: CFV: New Networking Group Member: Patrick Concannon In-Reply-To: References: Message-ID: Vote: yes On 25/08/2021 10:09, Daniel Fuchs wrote: > I hereby nominate Patrick Concannon to Membership in the Networking > Group. From Alan.Bateman at oracle.com Wed Aug 25 09:55:43 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 Aug 2021 10:55:43 +0100 Subject: CFV: New Networking Group Member: Patrick Concannon In-Reply-To: References: Message-ID: Vote: yes From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 12:50:27 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 12:50:27 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 08:29:57 GMT, Daniel Fuchs wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8272863: Replace usages of Collections.sort with List.sort call in public java modules >> replace Collections.sort without comparator too > > src/java.base/share/classes/java/net/URLPermission.java line 222: > >> 220: >> 221: List l = normalizeMethods(methods); >> 222: l.sort(null); > > I am not opposed to this change, but I find this is slightly more ugly than `Collections.sort(l)`; so I have to ask: Is there any noticeable benefit? Actually I agree with you. One more point is that List.sort(null) doesn't check at compile time that class implements `Comparable`. But Collections.sort have this check. I will revert last commit. @azvegint are you ok with that? ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From azvegint at openjdk.java.net Wed Aug 25 13:36:23 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Wed, 25 Aug 2021 13:36:23 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 12:47:41 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/net/URLPermission.java line 222: >> >>> 220: >>> 221: List l = normalizeMethods(methods); >>> 222: l.sort(null); >> >> I am not opposed to this change, but I find this is slightly more ugly than `Collections.sort(l)`; so I have to ask: Is there any noticeable benefit? > > Actually I agree with you. > One more point is that List.sort(null) doesn't check at compile time that class implements `Comparable`. But Collections.sort have this check. > I will revert last commit. > @azvegint are you ok with that? No objections. ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 13:55:50 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 13:55:50 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v3] In-Reply-To: References: Message-ID: <8nANT75G1bu4pd892DJuQUV-g2p7jm9m5jQb82EWjfs=.0452ad76-845c-49ed-b0f7-df6641ec2102@github.com> > Collections.sort is just a wrapper, so it is better to use an instance method directly. Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5229/files - new: https://git.openjdk.java.net/jdk/pull/5229/files/d6dfc8bf..e31936a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=01-02 Stats: 21 lines in 10 files changed: 4 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5229.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229 PR: https://git.openjdk.java.net/jdk/pull/5229 From akasko at openjdk.java.net Wed Aug 25 14:21:59 2021 From: akasko at openjdk.java.net (Alex Kasko) Date: Wed, 25 Aug 2021 14:21:59 GMT Subject: RFR: 8270290: NTLM authentication fails if HEAD request is used [v2] In-Reply-To: References: Message-ID: > When HEAD request is used with a proxy (or a server) that requires NTLM, authentication fails when server returns large (8kb+) body along with NTLMSSP_CHALLENGE response. > > Proposed fix is to check for ongoing NTLM auth in `reset()` and consume the response body in this case. > > Alternatively the whole check for `HEAD` method in `reset()` can be dropped. Alex Kasko has updated the pull request incrementally with one additional commit since the last revision: fix direct server and plain http proxy auth that became inadvertently broken ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4753/files - new: https://git.openjdk.java.net/jdk/pull/4753/files/c1c100d8..6027655d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4753&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4753&range=00-01 Stats: 133 lines in 2 files changed: 75 ins; 32 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/4753.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4753/head:pull/4753 PR: https://git.openjdk.java.net/jdk/pull/4753 From serb at openjdk.java.net Thu Aug 26 17:42:33 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 26 Aug 2021 17:42:33 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/be695a9b...e7127644 Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer? ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From github.com+5709644+fdesu at openjdk.java.net Thu Aug 26 18:33:27 2021 From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko) Date: Thu, 26 Aug 2021 18:33:27 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov wrote: >> Sergey Bylokhov 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 14 additional commits since the last revision: >> >> - Update the usage of Files.readAllLines() >> - Update datatransfer >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Fix related imports >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Cleanup UnsupportedEncodingException >> - Update PacketStream.java >> - Rollback TextTests, should be compatible with jdk1.4 >> - Rollback TextRenderTests, should be compatible with jdk1.4 >> - ... and 4 more: https://git.openjdk.java.net/jdk/compare/810191b6...e7127644 > > Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer? @mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. Here they are: - src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java - src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyURIDV.java - src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java - src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java would it make sense to go through them as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From serb at openjdk.java.net Thu Aug 26 18:38:26 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 26 Aug 2021 18:38:26 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov wrote: >> Sergey Bylokhov 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 14 additional commits since the last revision: >> >> - Update the usage of Files.readAllLines() >> - Update datatransfer >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Fix related imports >> - Merge branch 'master' into standard-encodings-in-non-public-modules >> - Cleanup UnsupportedEncodingException >> - Update PacketStream.java >> - Rollback TextTests, should be compatible with jdk1.4 >> - Rollback TextRenderTests, should be compatible with jdk1.4 >> - ... and 4 more: https://git.openjdk.java.net/jdk/compare/e5c71cd0...e7127644 > > Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer? > @mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. > would it make sense to go through them as well? Most of the cases in the XML module are related to the Xerces library, I have skipped it to make the future merges from upstream of that library simpler. ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From github.com+741251+turbanoff at openjdk.java.net Thu Aug 26 20:50:27 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 26 Aug 2021 20:50:27 GMT Subject: Integrated: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. This pull request has now been integrated. Changeset: d732c309 Author: Andrey Turbanov Committer: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/d732c3091fea0a7c6d6767227de89002564504e5 Stats: 27 lines in 10 files changed: 0 ins; 8 del; 19 mod 8272863: Replace usages of Collections.sort with List.sort call in public java modules Reviewed-by: serb, dfuchs, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From wetmore at openjdk.java.net Fri Aug 27 01:40:43 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 27 Aug 2021 01:40:43 GMT Subject: RFR: 8273045: Fix misc javadoc bugs in the java.security and javax.net.ssl code Message-ID: Did a quick sweep of some minor non-standard javadoc issues. This silences 3rd party tooling warnings and fixes some linkage issues. ------------- Commit messages: - 8273045: Fix misc javadoc bugs in the java.security and javax.net.ssl code Changes: https://git.openjdk.java.net/jdk/pull/5271/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5271&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273045 Stats: 42 lines in 10 files changed: 8 ins; 3 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/5271.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5271/head:pull/5271 PR: https://git.openjdk.java.net/jdk/pull/5271 From xuelei at openjdk.java.net Fri Aug 27 03:48:28 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 27 Aug 2021 03:48:28 GMT Subject: RFR: 8273045: Fix misc javadoc bugs in the java.security and javax.net.ssl code In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 01:35:17 GMT, Bradford Wetmore wrote: > Did a quick sweep of some minor non-standard javadoc issues. This silences 3rd party tooling warnings and fixes some linkage issues. Looks good to me. Thank you for the clean up. src/java.base/share/classes/javax/net/ssl/SNIHostName.java line 37: > 35: import java.util.Objects; > 36: import java.util.regex.Pattern; > 37: import java.util.regex.PatternSyntaxException; Does it mean that the classes introduced in java doc should also be imported? Maybe, the path package names could be removed in the createSNIMatcher() method spec. - * @throws java.util.regex.PatternSyntaxException if the regular expression's - * syntax is invalid + * @throws PatternSyntaxException if the regular expression's syntax is invalid ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5271 From wetmore at openjdk.java.net Fri Aug 27 05:08:49 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 27 Aug 2021 05:08:49 GMT Subject: RFR: 8273045: Fix misc javadoc bugs in the java.security and javax.net.ssl code [v2] In-Reply-To: References: Message-ID: > Did a quick sweep of some minor non-standard javadoc issues. This silences 3rd party tooling warnings and fixes some linkage issues. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Codereview Comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5271/files - new: https://git.openjdk.java.net/jdk/pull/5271/files/82fd00a4..705104a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5271&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5271&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5271.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5271/head:pull/5271 PR: https://git.openjdk.java.net/jdk/pull/5271 From wetmore at openjdk.java.net Fri Aug 27 05:08:50 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 27 Aug 2021 05:08:50 GMT Subject: RFR: 8273045: Fix misc javadoc bugs in the java.security and javax.net.ssl code [v2] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 03:38:55 GMT, Xue-Lei Andrew Fan wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Codereview Comment > > src/java.base/share/classes/javax/net/ssl/SNIHostName.java line 37: > >> 35: import java.util.Objects; >> 36: import java.util.regex.Pattern; >> 37: import java.util.regex.PatternSyntaxException; > > Does it mean that the classes introduced in java doc should also be imported? Maybe, the path package names could be removed in the createSNIMatcher() method spec. > > - * @throws java.util.regex.PatternSyntaxException if the regular expression's > - * syntax is invalid > + * @throws PatternSyntaxException if the regular expression's syntax is invalid Thanks for the catch. It doesn't absolutely have to be fixed to get javadoc to run (it apparently is a good guesser), but 3rd party tools like IntelliJ Idea aren't as robust, and treat this as an error. In the second update, I removed the extra package name in setSNIMatcher. Thanks for the review. I'll go ahead and push. ------------- PR: https://git.openjdk.java.net/jdk/pull/5271 From wetmore at openjdk.java.net Fri Aug 27 05:14:28 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 27 Aug 2021 05:14:28 GMT Subject: Integrated: 8273045: Fix misc javadoc bugs in the java.security and javax.net.ssl code In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 01:35:17 GMT, Bradford Wetmore wrote: > Did a quick sweep of some minor non-standard javadoc issues. This silences 3rd party tooling warnings and fixes some linkage issues. This pull request has now been integrated. Changeset: 76baace2 Author: Bradford Wetmore URL: https://git.openjdk.java.net/jdk/commit/76baace2f07cb7b5d5fd20abd1612085bdba4292 Stats: 43 lines in 10 files changed: 8 ins; 3 del; 32 mod 8273045: Fix misc javadoc bugs in the java.security and javax.net.ssl code Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/5271 From michael.x.mcmahon at oracle.com Fri Aug 27 08:01:25 2021 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 27 Aug 2021 09:01:25 +0100 Subject: CFV: New Networking Group Member: Patrick Concannon In-Reply-To: References: Message-ID: <2e0085b8-0979-bf37-e9e4-95a79edee48d@oracle.com> Vote: yes On 25/08/2021 10:09, Daniel Fuchs wrote: > I hereby nominate Patrick Concannon to Membership in the Networking > Group. > > Patrick is a Committer in the JDK project, and has been actively > participating in the evolution and maintenance of the networking > libraries for several years. > Patrick was the principal contributor to the reimplementation > of DatagramSocket (JEP 373), and has contributed many > fixes in the networking area. > > Votes are due by 11:00 UTC Wednesday, 8 September 2021. > > Only current Members of the Networking Group [1] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > --daniel > > [1] https://openjdk.java.net/census#net > [2] https://openjdk.java.net/groups/#member-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Fri Aug 27 08:10:26 2021 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 27 Aug 2021 09:10:26 +0100 Subject: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize In-Reply-To: References: Message-ID: <6bbeed5f-7cb6-4165-1645-cfd6bbe47f69@oracle.com> Thanks. I have filed https://bugs.openjdk.java.net/browse/JDK-8273059 to track this. - Michael. On 19/08/2021 19:50, Andrey Turbanov wrote: > Hello. > > During investigation of results of IDEA inspections I found a > redundant call to Math.min in a method > jdk.internal.net.http.Http2ClientImpl#getConnectionWindowSize > https://github.com/openjdk/jdk/blob/master/src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java#L240 > > int defaultValue = Math.min(Integer.MAX_VALUE, > Math.max(streamWindow, K*K*32)); > > Call of method Math.min(int, int) is redundant if one of parameters is > known to be Integer.MAX_VALUE (or Integer.MIN_VALUE) > > > > Andrey Turbanov -------------- next part -------------- An HTML attachment was scrubbed... URL: From myano at openjdk.java.net Fri Aug 27 08:46:42 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Fri, 27 Aug 2021 08:46:42 GMT Subject: RFR: 8238274: (sctp) JDK-7118373 is not fixed for SctpChannel Message-ID: Please review this change to the Unix implementations of sun.nio.ch.sctp.Sctp*ChannelImpl#implCloseSelectableChannel() to be same as SocketChannelImpl at JDK-7118373. (The preClose is missing a check for the ST_KILLED state.) ------------- Commit messages: - 8238274: (sctp) JDK-7118373 is not fixed for SctpChannel Changes: https://git.openjdk.java.net/jdk/pull/5274/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5274&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238274 Stats: 213 lines in 4 files changed: 210 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5274.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5274/head:pull/5274 PR: https://git.openjdk.java.net/jdk/pull/5274 From michaelm at openjdk.java.net Fri Aug 27 12:09:36 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 27 Aug 2021 12:09:36 GMT Subject: RFR: 8273059: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize Message-ID: Hi, Could I get the following trivial change reviewed please? It removes a redundant call to Math.min(Integer.MAX_VALUE, ....) Thanks, Michael. ------------- Commit messages: - Removed redundant Math.min() call Changes: https://git.openjdk.java.net/jdk/pull/5277/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5277&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273059 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5277.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5277/head:pull/5277 PR: https://git.openjdk.java.net/jdk/pull/5277 From dfuchs at openjdk.java.net Fri Aug 27 12:28:23 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 27 Aug 2021 12:28:23 GMT Subject: RFR: 8273059: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 12:01:25 GMT, Michael McMahon wrote: > Hi, > > Could I get the following trivial change reviewed please? > It removes a redundant call to Math.min(Integer.MAX_VALUE, ....) > > Thanks, > Michael. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5277 From michaelm at openjdk.java.net Fri Aug 27 13:28:51 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 27 Aug 2021 13:28:51 GMT Subject: RFR: 8273059: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize [v2] In-Reply-To: References: Message-ID: > Hi, > > Could I get the following trivial change reviewed please? > It removes a redundant call to Math.min(Integer.MAX_VALUE, ....) > > Thanks, > Michael. Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: Removed second chunk of redundant code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5277/files - new: https://git.openjdk.java.net/jdk/pull/5277/files/365b6a16..462020a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5277&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5277&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5277.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5277/head:pull/5277 PR: https://git.openjdk.java.net/jdk/pull/5277 From dfuchs at openjdk.java.net Fri Aug 27 14:15:27 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 27 Aug 2021 14:15:27 GMT Subject: RFR: 8273059: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize [v2] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 13:28:51 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following trivial change reviewed please? >> It removes a redundant call to Math.min(Integer.MAX_VALUE, ....) >> >> Thanks, >> Michael. > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > Removed second chunk of redundant code src/java.net.http/share/classes/jdk/internal/net/http/ResponseContent.java line 510: > 508: closedExceptionally = t; > 509: if (!completed) { > 510: onComplete.accept(t); You need to keep line 510 - since `completed` is always false this line should be executed always. ------------- PR: https://git.openjdk.java.net/jdk/pull/5277 From michaelm at openjdk.java.net Fri Aug 27 16:11:49 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 27 Aug 2021 16:11:49 GMT Subject: RFR: 8273059: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize [v3] In-Reply-To: References: Message-ID: > Hi, > > Could I get the following trivial change reviewed please? > It removes a redundant call to Math.min(Integer.MAX_VALUE, ....) > > Thanks, > Michael. Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: mistake in last commit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5277/files - new: https://git.openjdk.java.net/jdk/pull/5277/files/462020a7..c671f021 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5277&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5277&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5277.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5277/head:pull/5277 PR: https://git.openjdk.java.net/jdk/pull/5277 From erikj at openjdk.java.net Fri Aug 27 17:51:31 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 27 Aug 2021 17:51:31 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v2] In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> This change includes: >> * demo/utils >> * jdk.xx packages >> * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. >> >> Some performance discussion: https://github.com/openjdk/jdk/pull/5063 >> >> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). >> >> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. > > Sergey Bylokhov 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 14 additional commits since the last revision: > > - Update the usage of Files.readAllLines() > - Update datatransfer > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Fix related imports > - Merge branch 'master' into standard-encodings-in-non-public-modules > - Cleanup UnsupportedEncodingException > - Update PacketStream.java > - Rollback TextTests, should be compatible with jdk1.4 > - Rollback TextRenderTests, should be compatible with jdk1.4 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/6af90a19...e7127644 Build tool change looks good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5210 From naoto at openjdk.java.net Fri Aug 27 21:59:00 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 27 Aug 2021 21:59:00 GMT Subject: RFR: 8260265: UTF-8 by Default [v8] In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 Naoto Sato 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 15 additional commits since the last revision: - Removed "default" alias - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Refined `file.encoding` description - Merge branch 'master' into JDK-8260265 - Reflects comments - ... and 5 more: https://git.openjdk.java.net/jdk/compare/66c3531f...67e1d4a9 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4733/files - new: https://git.openjdk.java.net/jdk/pull/4733/files/7d5137d3..67e1d4a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=06-07 Stats: 15450 lines in 595 files changed: 11498 ins; 2067 del; 1885 mod Patch: https://git.openjdk.java.net/jdk/pull/4733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4733/head:pull/4733 PR: https://git.openjdk.java.net/jdk/pull/4733 From naoto at openjdk.java.net Fri Aug 27 23:14:58 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 27 Aug 2021 23:14:58 GMT Subject: RFR: 8260265: UTF-8 by Default [v9] In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixed a failing test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4733/files - new: https://git.openjdk.java.net/jdk/pull/4733/files/67e1d4a9..28e79d4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=07-08 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4733/head:pull/4733 PR: https://git.openjdk.java.net/jdk/pull/4733 From alanb at openjdk.java.net Sat Aug 28 06:17:28 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 28 Aug 2021 06:17:28 GMT Subject: RFR: 8260265: UTF-8 by Default [v9] In-Reply-To: References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: <1bMIQg6TIjIphxBiTDBBVEh_l8xXiKpiq3RUmed0d3w=.7322db9b-81bc-4142-b1ae-4a776cfaad9d@github.com> On Fri, 27 Aug 2021 23:14:58 GMT, Naoto Sato wrote: >> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. >> >> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a failing test Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From alanb at openjdk.java.net Sat Aug 28 07:21:24 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 28 Aug 2021 07:21:24 GMT Subject: RFR: 8238274: (sctp) JDK-7118373 is not fixed for SctpChannel In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 08:37:46 GMT, Masanori Yano wrote: > Please review this change to the Unix implementations of sun.nio.ch.sctp.Sctp*ChannelImpl#implCloseSelectableChannel() > to be same as SocketChannelImpl at JDK-7118373. (The preClose is missing a check for the ST_KILLED state.) As the equivalent of JDK-7118373 in JDK 8 then the proposed change looks okay. At some point we may have to look at aligning the SCTP channel implementations where close has been significantly re-implemented. ------------- PR: https://git.openjdk.java.net/jdk/pull/5274 From dfuchs at openjdk.java.net Mon Aug 30 08:53:30 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 30 Aug 2021 08:53:30 GMT Subject: RFR: 8273059: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize [v3] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 16:11:49 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following trivial change reviewed please? >> It removes a redundant call to Math.min(Integer.MAX_VALUE, ....) >> >> Thanks, >> Michael. > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > mistake in last commit Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5277 From michaelm at openjdk.java.net Mon Aug 30 09:00:31 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 30 Aug 2021 09:00:31 GMT Subject: Integrated: 8273059: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 12:01:25 GMT, Michael McMahon wrote: > Hi, > > Could I get the following trivial change reviewed please? > It removes a redundant call to Math.min(Integer.MAX_VALUE, ....) > > Thanks, > Michael. This pull request has now been integrated. Changeset: 16e83058 Author: Michael McMahon URL: https://git.openjdk.java.net/jdk/commit/16e83058cab4dd4d4a3fba812c8fe50e4286bd22 Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod 8273059: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5277 From naoto at openjdk.java.net Mon Aug 30 21:17:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 30 Aug 2021 21:17:41 GMT Subject: Integrated: 8260265: UTF-8 by Default In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: On Thu, 8 Jul 2021 21:23:00 GMT, Naoto Sato wrote: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 This pull request has now been integrated. Changeset: 7fc85409 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/7fc8540907e8e7483ad5729ea416167810aa8747 Stats: 409 lines in 22 files changed: 208 ins; 24 del; 177 mod 8260265: UTF-8 by Default Reviewed-by: alanb, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From serb at openjdk.java.net Mon Aug 30 23:46:15 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 30 Aug 2021 23:46:15 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v3] In-Reply-To: References: Message-ID: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Sergey Bylokhov 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 15 additional commits since the last revision: - Merge branch 'master' into standard-encodings-in-non-public-modules - Update the usage of Files.readAllLines() - Update datatransfer - Merge branch 'master' into standard-encodings-in-non-public-modules - Merge branch 'master' into standard-encodings-in-non-public-modules - Fix related imports - Merge branch 'master' into standard-encodings-in-non-public-modules - Cleanup UnsupportedEncodingException - Update PacketStream.java - Rollback TextTests, should be compatible with jdk1.4 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/22865adf...79829ec8 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5210/files - new: https://git.openjdk.java.net/jdk/pull/5210/files/e7127644..79829ec8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=01-02 Stats: 9423 lines in 339 files changed: 5247 ins; 1917 del; 2259 mod Patch: https://git.openjdk.java.net/jdk/pull/5210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210 PR: https://git.openjdk.java.net/jdk/pull/5210 From serb at openjdk.java.net Tue Aug 31 20:17:25 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 31 Aug 2021 20:17:25 GMT Subject: RFR: 8272805: Avoid looking up standard charsets [v4] In-Reply-To: References: Message-ID: <0BjXWeJE25KSeovjDycar9nGsqSQ4vehXgMBrqwWGHQ=.e83aec87-77a8-414d-9acb-bdbdd6bb27ca@github.com> > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Sergey Bylokhov 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 16 additional commits since the last revision: - Merge branch 'master' into standard-encodings-in-non-public-modules - Merge branch 'master' into standard-encodings-in-non-public-modules - Update the usage of Files.readAllLines() - Update datatransfer - Merge branch 'master' into standard-encodings-in-non-public-modules - Merge branch 'master' into standard-encodings-in-non-public-modules - Fix related imports - Merge branch 'master' into standard-encodings-in-non-public-modules - Cleanup UnsupportedEncodingException - Update PacketStream.java - ... and 6 more: https://git.openjdk.java.net/jdk/compare/7289121a...7fe0327e ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5210/files - new: https://git.openjdk.java.net/jdk/pull/5210/files/79829ec8..7fe0327e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=02-03 Stats: 949 lines in 30 files changed: 678 ins; 166 del; 105 mod Patch: https://git.openjdk.java.net/jdk/pull/5210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210 PR: https://git.openjdk.java.net/jdk/pull/5210 From isipka at openjdk.java.net Tue Aug 31 22:32:46 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Tue, 31 Aug 2021 22:32:46 GMT Subject: RFR: 8263364: sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java wedged in getInputStream [v5] In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 12:55:32 GMT, Ivan ?ipka wrote: >> @dfuch could you please review, thank you. > > Ivan ?ipka has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - 8263364: output > - 8263364: removing surplus imports > - 8263364: refactor > - 8263364: refactor > - 8263364: refactor > - 8263364: fixed headers > - JDK-8263364: initial commit extend ------------- PR: https://git.openjdk.java.net/jdk/pull/4472