From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 07:27:33 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 07:27:33 GMT Subject: RFR: 8269665: Clean-up toString() methods of some primitive wrappers [v2] In-Reply-To: References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> Message-ID: On Sun, 4 Jul 2021 21:35:31 GMT, ?????? ??????? wrote: >> As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods. >> >> Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`. >> >> Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first): >> >> public static String toString(byte b) { >> return Integer.toString((int)b, 10); >> } >> >> public String toString() { >> return Integer.toString((int)value); >> } >> >> Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark: >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class ByteToStringBenchmark { >> @Benchmark >> public String byteToString() { >> return Byte.toString((byte) 1); >> } >> } >> >> Results: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> ByteToStringBenchmark.byteToString avgt 30 11,648 ? 1,906 ns/op >> ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3288,576 ? 418,119 MB/sec >> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3301,804 ? 455,932 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 48,158 ? 2,085 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,001 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op >> ByteToStringBenchmark.byteToString:?gc.count avgt 30 202,000 counts >> ByteToStringBenchmark.byteToString:?gc.time avgt 30 413,000 ms >> >> after >> >> Benchmark Mode Cnt Score Error Units >> ByteToStringBenchmark.byteToString avgt 30 10,016 ? 0,530 ns/op >> ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3673,700 ? 167,450 MB/sec >> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3662,406 ? 205,978 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 47,870 ? 1,750 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,002 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op >> ByteToStringBenchmark.byteToString:?gc.count avgt 30 224,000 counts >> ByteToStringBenchmark.byteToString:?gc.time avgt 30 358,000 ms > > ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: > > - 8269665: Update copy-right year > - 8269665: Reuse String.valueOf(boolean) > @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! Not now ------------- PR: https://git.openjdk.java.net/jdk/pull/4633 From redestad at openjdk.java.net Mon Aug 2 11:12:35 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 11:12:35 GMT Subject: RFR: 8269665: Clean-up toString() methods of some primitive wrappers [v2] In-Reply-To: References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> Message-ID: <7j2g1YOzRIQBkqVUshU5FPE4Ic8xdighw-G4p87pSZw=.1a0f103b-1ad9-4c4c-a8fb-974cf3365f72@github.com> On Sun, 4 Jul 2021 21:35:31 GMT, ?????? ??????? wrote: >> As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods. >> >> Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`. >> >> Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first): >> >> public static String toString(byte b) { >> return Integer.toString((int)b, 10); >> } >> >> public String toString() { >> return Integer.toString((int)value); >> } >> >> Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark: >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class ByteToStringBenchmark { >> @Benchmark >> public String byteToString() { >> return Byte.toString((byte) 1); >> } >> } >> >> Results: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> ByteToStringBenchmark.byteToString avgt 30 11,648 ? 1,906 ns/op >> ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3288,576 ? 418,119 MB/sec >> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3301,804 ? 455,932 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 48,158 ? 2,085 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,001 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op >> ByteToStringBenchmark.byteToString:?gc.count avgt 30 202,000 counts >> ByteToStringBenchmark.byteToString:?gc.time avgt 30 413,000 ms >> >> after >> >> Benchmark Mode Cnt Score Error Units >> ByteToStringBenchmark.byteToString avgt 30 10,016 ? 0,530 ns/op >> ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3673,700 ? 167,450 MB/sec >> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3662,406 ? 205,978 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 47,870 ? 1,750 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,002 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op >> ByteToStringBenchmark.byteToString:?gc.count avgt 30 224,000 counts >> ByteToStringBenchmark.byteToString:?gc.time avgt 30 358,000 ms > > ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: > > - 8269665: Update copy-right year > - 8269665: Reuse String.valueOf(boolean) Changes requested by redestad (Reviewer). src/java.base/share/classes/java/lang/Byte.java line 93: > 91: */ > 92: public static String toString(byte b) { > 93: return Integer.toString(b); This change makes sense given the evidence that the radix tests in `Integer.toString(int, int)` are not elided. Same for the equivalent change in `Short.java`. src/java.base/share/classes/java/lang/Byte.java line 441: > 439: @Override > 440: public String toString() { > 441: return toString(value); I'm a bit more skeptical about these changes that re-route from `Integer.toString(int)` to the local `Byte.toString(byte)` which will then call `Integer.toString(int)` anyhow. An extra indirection will likely not be seen having an effect in micros, but can mess things up due inlining heuristics and of course slightly hamper startup, so I would prefer leaving the code as is. Adding missing `@Override`s is fine, of course. ------------- PR: https://git.openjdk.java.net/jdk/pull/4633 From redestad at openjdk.java.net Mon Aug 2 11:22:44 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 11:22:44 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v11] In-Reply-To: References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: <1tMR5seQ0nt1U7RbpVx7RNgvMl9Eov8JRVmmjASa5HQ=.b4f65b78-74ee-457b-b9db-e1acbfff80c2@github.com> On Mon, 26 Jul 2021 08:27:14 GMT, ?????? ??????? wrote: >> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). > > ?????? ??????? 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 13 additional commits since the last revision: > > - Merge branch 'master' into 8268113 > - 8270160 Revert changes in BitSet.hashCode > - Merge branch 'master' into 8268113 > - 8270160 Revert changes in BitSet.hashCode > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/1d801fa0...bd762b7d All changes look good to me, though 3rd party sources like xerces/.../DoubleDV.java should probably be dealt with in the upstream first. @AlanBateman probably knows who maintains and downstreams this usually (or whether we are now practically maintaining a fork of xerces)? ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4309 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:29:00 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:29:00 GMT Subject: RFR: 8269665: Clean-up toString() methods of some primitive wrappers [v3] In-Reply-To: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> Message-ID: > As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods. > > Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`. > > Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first): > > public static String toString(byte b) { > return Integer.toString((int)b, 10); > } > > public String toString() { > return Integer.toString((int)value); > } > > Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class ByteToStringBenchmark { > @Benchmark > public String byteToString() { > return Byte.toString((byte) 1); > } > } > > Results: > > before > > Benchmark Mode Cnt Score Error Units > ByteToStringBenchmark.byteToString avgt 30 11,648 ? 1,906 ns/op > ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3288,576 ? 418,119 MB/sec > ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3301,804 ? 455,932 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 48,158 ? 2,085 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,001 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op > ByteToStringBenchmark.byteToString:?gc.count avgt 30 202,000 counts > ByteToStringBenchmark.byteToString:?gc.time avgt 30 413,000 ms > > after > > Benchmark Mode Cnt Score Error Units > ByteToStringBenchmark.byteToString avgt 30 10,016 ? 0,530 ns/op > ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3673,700 ? 167,450 MB/sec > ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3662,406 ? 205,978 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 47,870 ? 1,750 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,002 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op > ByteToStringBenchmark.byteToString:?gc.count avgt 30 224,000 counts > ByteToStringBenchmark.byteToString:?gc.time avgt 30 358,000 ms ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8269665: Revert irrelevant changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4633/files - new: https://git.openjdk.java.net/jdk/pull/4633/files/e939d72b..b9fb156c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4633&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4633&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4633/head:pull/4633 PR: https://git.openjdk.java.net/jdk/pull/4633 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:29:03 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:29:03 GMT Subject: RFR: 8269665: Clean-up toString() methods of some primitive wrappers [v2] In-Reply-To: <7j2g1YOzRIQBkqVUshU5FPE4Ic8xdighw-G4p87pSZw=.1a0f103b-1ad9-4c4c-a8fb-974cf3365f72@github.com> References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> <7j2g1YOzRIQBkqVUshU5FPE4Ic8xdighw-G4p87pSZw=.1a0f103b-1ad9-4c4c-a8fb-974cf3365f72@github.com> Message-ID: On Mon, 2 Aug 2021 11:09:30 GMT, Claes Redestad wrote: >> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8269665: Update copy-right year >> - 8269665: Reuse String.valueOf(boolean) > > src/java.base/share/classes/java/lang/Byte.java line 441: > >> 439: @Override >> 440: public String toString() { >> 441: return toString(value); > > I'm a bit more skeptical about these changes that re-route from `Integer.toString(int)` to the local `Byte.toString(byte)` which will then call `Integer.toString(int)` anyhow. An extra indirection will likely not be seen having an effect in micros, but can mess things up due inlining heuristics and of course slightly hamper startup, so I would prefer leaving the code as is. Adding missing `@Override`s is fine, of course. Reverted ------------- PR: https://git.openjdk.java.net/jdk/pull/4633 From redestad at openjdk.java.net Mon Aug 2 12:34:35 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 12:34:35 GMT Subject: RFR: 8269665: Clean-up toString() methods of some primitive wrappers [v3] In-Reply-To: References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> Message-ID: <75kOSfsEE1Iomy8_XE5-KzHLO7TFz39YYZ0MW_mxy60=.20236468-723d-4ca5-b78b-77b34c24480a@github.com> On Mon, 2 Aug 2021 12:29:00 GMT, ?????? ??????? wrote: >> As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods. >> >> Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`. >> >> Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first): >> >> public static String toString(byte b) { >> return Integer.toString((int)b, 10); >> } >> >> public String toString() { >> return Integer.toString((int)value); >> } >> >> Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark: >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class ByteToStringBenchmark { >> @Benchmark >> public String byteToString() { >> return Byte.toString((byte) 1); >> } >> } >> >> Results: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> ByteToStringBenchmark.byteToString avgt 30 11,648 ? 1,906 ns/op >> ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3288,576 ? 418,119 MB/sec >> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3301,804 ? 455,932 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 48,158 ? 2,085 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,001 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op >> ByteToStringBenchmark.byteToString:?gc.count avgt 30 202,000 counts >> ByteToStringBenchmark.byteToString:?gc.time avgt 30 413,000 ms >> >> after >> >> Benchmark Mode Cnt Score Error Units >> ByteToStringBenchmark.byteToString avgt 30 10,016 ? 0,530 ns/op >> ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3673,700 ? 167,450 MB/sec >> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3662,406 ? 205,978 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 47,870 ? 1,750 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,002 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op >> ByteToStringBenchmark.byteToString:?gc.count avgt 30 224,000 counts >> ByteToStringBenchmark.byteToString:?gc.time avgt 30 358,000 ms > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8269665: Revert irrelevant changes Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4633 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:49: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: Mon, 2 Aug 2021 12:49:38 GMT Subject: Integrated: 8269665: Clean-up toString() methods of some primitive wrappers In-Reply-To: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> Message-ID: On Wed, 30 Jun 2021 08:40:21 GMT, ?????? ??????? wrote: > As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods. > > Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`. > > Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first): > > public static String toString(byte b) { > return Integer.toString((int)b, 10); > } > > public String toString() { > return Integer.toString((int)value); > } > > Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class ByteToStringBenchmark { > @Benchmark > public String byteToString() { > return Byte.toString((byte) 1); > } > } > > Results: > > before > > Benchmark Mode Cnt Score Error Units > ByteToStringBenchmark.byteToString avgt 30 11,648 ? 1,906 ns/op > ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3288,576 ? 418,119 MB/sec > ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3301,804 ? 455,932 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 48,158 ? 2,085 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,001 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op > ByteToStringBenchmark.byteToString:?gc.count avgt 30 202,000 counts > ByteToStringBenchmark.byteToString:?gc.time avgt 30 413,000 ms > > after > > Benchmark Mode Cnt Score Error Units > ByteToStringBenchmark.byteToString avgt 30 10,016 ? 0,530 ns/op > ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3673,700 ? 167,450 MB/sec > ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3662,406 ? 205,978 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 47,870 ? 1,750 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,002 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op > ByteToStringBenchmark.byteToString:?gc.count avgt 30 224,000 counts > ByteToStringBenchmark.byteToString:?gc.time avgt 30 358,000 ms This pull request has now been integrated. Changeset: 72145f3b Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/72145f3b9472c8f5f64f9b9ac93e3331e646f15a Stats: 13 lines in 4 files changed: 4 ins; 0 del; 9 mod 8269665: Clean-up toString() methods of some primitive wrappers Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/4633 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:52: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 12:52:34 GMT Subject: Integrated: 8268113: Re-use Long.hashCode() where possible In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: On Wed, 2 Jun 2021 14:10:38 GMT, ?????? ??????? wrote: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). This pull request has now been integrated. Changeset: 6a3f8343 Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/6a3f8343bc0e92c29a87c5840cbef9ab2988f153 Stats: 10 lines in 6 files changed: 0 ins; 4 del; 6 mod 8268113: Re-use Long.hashCode() where possible Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/4309 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 naoto at openjdk.java.net Fri Aug 6 16:45:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 6 Aug 2021 16:45:41 GMT Subject: RFR: 8264792: The NumberFormat for locale sq_XK formats price incorrectly. Message-ID: Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequently is supported by the JDK since JDK9. Adding the data `EUR` for the country code `XK` will fix the issue. ------------- Commit messages: - 8264792: The NumberFormat for locale sq_XK formats price incorrectly. Changes: https://git.openjdk.java.net/jdk/pull/5033/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5033&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264792 Stats: 13 lines in 3 files changed: 6 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5033.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5033/head:pull/5033 PR: https://git.openjdk.java.net/jdk/pull/5033 From joehw at openjdk.java.net Fri Aug 6 17:31:33 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 6 Aug 2021 17:31:33 GMT Subject: RFR: 8264792: The NumberFormat for locale sq_XK formats price incorrectly. In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 16:39:34 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequently is supported by the JDK since JDK9. Adding the data `EUR` for the country code `XK` will fix the issue. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5033 From iris at openjdk.java.net Fri Aug 6 21:09:28 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 6 Aug 2021 21:09:28 GMT Subject: RFR: 8264792: The NumberFormat for locale sq_XK formats price incorrectly. In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 16:39:34 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequently is supported by the JDK since JDK9. Adding the data `EUR` for the country code `XK` will fix the issue. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5033 From github.com+741251+turbanoff at openjdk.java.net Mon Aug 9 07:21:47 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 9 Aug 2021 07:21:47 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop Message-ID: Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. I checked only places where `Vector` was used as local variable. ------------- Commit messages: - [PATCH] Unnecessary Vector usage in java.desktop - [PATCH] Unnecessary Vector usage in java.desktop Changes: https://git.openjdk.java.net/jdk/pull/4680/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271603 Stats: 51 lines in 5 files changed: 3 ins; 16 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/4680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4680/head:pull/4680 PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 9 07:21: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, 9 Aug 2021 07:21:47 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. @turbanoff hi, I've filed an issue for this: https://bugs.openjdk.java.net/browse/JDK-8271603 src/java.desktop/share/classes/java/awt/Menu.java line 489: > 487: } > 488: > 489: synchronized Enumeration shortcuts() { I'm not sure whether it's ok to change return type here, probably it'd be better to keep `Enumeration` and use `return Collections.enumeration(shortcuts);` in the last line src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java line 244: > 242: } > 243: > 244: return list.toArray(new Line.Info[list.size()]); Shouldn't it be `new Line.Info[0]` as in the class below? ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Mon Aug 9 07:21:48 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 9 Aug 2021 07:21:48 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 14:03:18 GMT, ?????? ??????? wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > src/java.desktop/share/classes/java/awt/Menu.java line 489: > >> 487: } >> 488: >> 489: synchronized Enumeration shortcuts() { > > I'm not sure whether it's ok to change return type here, probably it'd be better to keep `Enumeration` and use `return Collections.enumeration(shortcuts);` in the last line It's not a public API. As I see from other PR/commits changing package-private methods shouldn't be a problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 9 07:21:49 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, 9 Aug 2021 07:21:49 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 19:03:49 GMT, Andrey Turbanov wrote: >> src/java.desktop/share/classes/java/awt/Menu.java line 489: >> >>> 487: } >>> 488: >>> 489: synchronized Enumeration shortcuts() { >> >> I'm not sure whether it's ok to change return type here, probably it'd be better to keep `Enumeration` and use `return Collections.enumeration(shortcuts);` in the last line > > It's not a public API. As I see from other PR/commits changing package-private methods shouldn't be a problem. Even non-public method can be called via reflection, so I'd be cautios about changing return type ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From serb at openjdk.java.net Mon Aug 9 07:21:49 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 9 Aug 2021 07:21:49 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. src/java.desktop/share/classes/java/awt/MenuBar.java line 348: > 346: Iterator e = getMenu(i).shortcuts(); > 347: while (e.hasNext()) { > 348: shortcuts.addElement(e.next()); I think it is fine to replace the Enumeration with the Iterator in most of the places, but here we will get a kind of mix of both, since we cannot remove the usage of Enumeration in the return time. src/java.desktop/share/classes/javax/print/MimeType.java line 576: > 574: ArrayList thePieces = new ArrayList<>(); > 575: boolean mediaTypeIsText; > 576: boolean parameterNameIsCharset; Default values might be removed as a separate cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From serb at openjdk.java.net Mon Aug 9 07:21:50 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 9 Aug 2021 07:21:50 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 14:00:07 GMT, ?????? ??????? wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java line 244: > >> 242: } >> 243: >> 244: return list.toArray(new Line.Info[list.size()]); > > Shouldn't it be `new Line.Info[0]` as in the class below? It looks fine to change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From naoto at openjdk.java.net Mon Aug 9 16:25:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 9 Aug 2021 16:25:37 GMT Subject: Integrated: 8264792: The NumberFormat for locale sq_XK formats price incorrectly. In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 16:39:34 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequently is supported by the JDK since JDK9. Adding the data `EUR` for the country code `XK` will fix the issue. This pull request has now been integrated. Changeset: 41dc795d Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/41dc795d6c08af84aa6544cc5a5704dcf99386cf Stats: 13 lines in 3 files changed: 6 ins; 0 del; 7 mod 8264792: The NumberFormat for locale sq_XK formats price incorrectly. Reviewed-by: joehw, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5033 From prr at openjdk.java.net Tue Aug 10 00:08:32 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 10 Aug 2021 00:08:32 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: <6aLgG4zX_4XfiEmKpjHSYsUxPUKP50F5S4oJWSpdt4Y=.84c7399e-c0dc-46f6-a659-53969ad8b182@github.com> On Tue, 6 Jul 2021 11:32:18 GMT, ?????? ??????? wrote: >> It's not a public API. As I see from other PR/commits changing package-private methods shouldn't be a problem. > > Even non-public method can be called via reflection, so I'd be cautios about changing return type Apps should not be doing that and the desktop module along with most of the rest of the JDK is strongly encapsulated and illegal access will be denied. But given the relationship with the sole (?) caller I think this is not worth the churn. Not exactly an MT hotspot. I'd revert the changes here and in MenuBar. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From prr at openjdk.java.net Tue Aug 10 00:08:31 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 10 Aug 2021 00:08:31 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: <_jCZjHKPkgh1QTGI_xpoQs0U6tFb9jgDSzav3DK9t8I=.cb2a0c00-48dc-4946-abef-6b2f4877149b@github.com> On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. Changes requested by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From igraves at openjdk.java.net Wed Aug 11 18:29:40 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 11 Aug 2021 18:29:40 GMT Subject: RFR: 8271302: Regex Test Refresh In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 18:22:42 GMT, Ian Graves wrote: > 8271302: Regex Test Refresh This PR migrates all regular expression tests in the jdk/java/util/regex directory to use TestNG assertions and annotations. The assertions utilized for this refresh are shared in common with standard ones from JUnit5 should such a migration occur in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Wed Aug 11 18:29:40 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 11 Aug 2021 18:29:40 GMT Subject: RFR: 8271302: Regex Test Refresh Message-ID: 8271302: Regex Test Refresh ------------- Commit messages: - Migrating regular expression tests to TestNG Changes: https://git.openjdk.java.net/jdk/pull/5092/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271302 Stats: 2226 lines in 3 files changed: 225 ins; 965 del; 1036 mod Patch: https://git.openjdk.java.net/jdk/pull/5092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5092/head:pull/5092 PR: https://git.openjdk.java.net/jdk/pull/5092 From bchristi at openjdk.java.net Fri Aug 13 20:22:28 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 13 Aug 2021 20:22:28 GMT Subject: RFR: 8271302: Regex Test Refresh In-Reply-To: References: Message-ID: <_jpkGZFcS9zL0JKgTHBD4-1eKEAKTP76i0evJd073bc=.8172da72-d099-4129-83ed-f028fd8e1e18@github.com> On Wed, 11 Aug 2021 18:22:42 GMT, Ian Graves wrote: > 8271302: Regex Test Refresh Changes requested by bchristi (Reviewer). In the JBS issue, it looks like the Description was put in the Environment. :) test/jdk/java/util/regex/RegExTest.java line 291: > 289: > 290: int resultStart1 = mr.start(); > 291: assertEquals(matcherStart1, resultStart1, "equal matchers have equal start indices"); Should the message be that they *don't* have equal start indices ? test/jdk/java/util/regex/RegExTest.java line 2362: > 2360: > 2361: { "test\ud834\uddc0", "test\ud834\uddc0", "m", true }, > 2362: //{ "test\ud834\uddbc\ud834\udd6f", "test\ud834\uddc0", "m", true }, //problem Should an issue be filed for these //problems ? test/jdk/java/util/regex/RegExTest.java line 3952: > 3950: > 3951: m = Pattern.compile("\\H").matcher(matcherSubstring); > 3952: assertTrue(m.find() || ng.equals(m.group())); Should this be: `assertTrue(m.find() && ng.equals(m.group()));` ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 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 igraves at openjdk.java.net Wed Aug 18 18:19:32 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 18 Aug 2021 18:19:32 GMT Subject: RFR: 8271302: Regex Test Refresh In-Reply-To: <_jpkGZFcS9zL0JKgTHBD4-1eKEAKTP76i0evJd073bc=.8172da72-d099-4129-83ed-f028fd8e1e18@github.com> References: <_jpkGZFcS9zL0JKgTHBD4-1eKEAKTP76i0evJd073bc=.8172da72-d099-4129-83ed-f028fd8e1e18@github.com> Message-ID: On Fri, 13 Aug 2021 20:16:22 GMT, Brent Christian wrote: >> 8271302: Regex Test Refresh > > test/jdk/java/util/regex/RegExTest.java line 2362: > >> 2360: >> 2361: { "test\ud834\uddc0", "test\ud834\uddc0", "m", true }, >> 2362: //{ "test\ud834\uddbc\ud834\udd6f", "test\ud834\uddc0", "m", true }, //problem > > Should an issue be filed for these //problems ? Yessir! https://bugs.openjdk.java.net/browse/JDK-8271919 ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Wed Aug 18 18:35:53 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 18 Aug 2021 18:35:53 GMT Subject: RFR: 8271302: Regex Test Refresh [v2] In-Reply-To: References: Message-ID: > 8271302: Regex Test Refresh Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Couple of fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5092/files - new: https://git.openjdk.java.net/jdk/pull/5092/files/1426e323..0e9fa209 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5092/head:pull/5092 PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Wed Aug 18 18:35:55 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 18 Aug 2021 18:35:55 GMT Subject: RFR: 8271302: Regex Test Refresh [v2] In-Reply-To: <_jpkGZFcS9zL0JKgTHBD4-1eKEAKTP76i0evJd073bc=.8172da72-d099-4129-83ed-f028fd8e1e18@github.com> References: <_jpkGZFcS9zL0JKgTHBD4-1eKEAKTP76i0evJd073bc=.8172da72-d099-4129-83ed-f028fd8e1e18@github.com> Message-ID: On Fri, 13 Aug 2021 20:17:56 GMT, Brent Christian wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Couple of fixes > > test/jdk/java/util/regex/RegExTest.java line 3952: > >> 3950: >> 3951: m = Pattern.compile("\\H").matcher(matcherSubstring); >> 3952: assertTrue(m.find() || ng.equals(m.group())); > > Should this be: > `assertTrue(m.find() && ng.equals(m.group()));` Good catch. De Morgan's mistake ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From bchristi at openjdk.java.net Wed Aug 18 20:32:25 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 18 Aug 2021 20:32:25 GMT Subject: RFR: 8271302: Regex Test Refresh [v2] In-Reply-To: References: Message-ID: <7SGDf5W7Ll9Rk5GWKumSVWdnhph9MqR0iTWbyC_mXyQ=.65c2a8f3-07e2-445d-b31f-6fb7a2c0a7a2@github.com> On Wed, 18 Aug 2021 18:35:53 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Couple of fixes Marked as reviewed by bchristi (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From github.com+741251+turbanoff at openjdk.java.net Wed Aug 18 21:04:35 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 18 Aug 2021 21:04:35 GMT Subject: RFR: 8272616: Strange code in java.text.DecimalFormat#applyPattern Message-ID: remove redundant if ------------- Commit messages: - 8272616: Strange code in java.text.DecimalFormat#applyPattern Changes: https://git.openjdk.java.net/jdk/pull/5171/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5171&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272616 Stats: 11 lines in 1 file changed: 1 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5171/head:pull/5171 PR: https://git.openjdk.java.net/jdk/pull/5171 From bpb at openjdk.java.net Wed Aug 18 21:17:27 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 18 Aug 2021 21:17:27 GMT Subject: RFR: 8272616: Strange code in java.text.DecimalFormat#applyPattern In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 20:59:20 GMT, Andrey Turbanov wrote: > remove redundant if Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5171 From naoto at openjdk.java.net Wed Aug 18 21:52:23 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 18 Aug 2021 21:52:23 GMT Subject: RFR: 8272616: Strange code in java.text.DecimalFormat#applyPattern In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 20:59:20 GMT, Andrey Turbanov wrote: > remove redundant if Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5171 From iris at openjdk.java.net Wed Aug 18 22:41:25 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 18 Aug 2021 22:41:25 GMT Subject: RFR: 8272616: Strange code in java.text.DecimalFormat#applyPattern In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 20:59:20 GMT, Andrey Turbanov wrote: > remove redundant if Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5171 From github.com+741251+turbanoff at openjdk.java.net Thu Aug 19 16:00:27 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 19 Aug 2021 16:00:27 GMT Subject: Integrated: 8272616: Strange code in java.text.DecimalFormat#applyPattern In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 20:59:20 GMT, Andrey Turbanov wrote: > remove redundant if This pull request has now been integrated. Changeset: 51c1b9a6 Author: Andrey Turbanov Committer: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/51c1b9a6870bd9644e92227e47082a53e2d1c066 Stats: 11 lines in 1 file changed: 1 ins; 3 del; 7 mod 8272616: Strange code in java.text.DecimalFormat#applyPattern Reviewed-by: bpb, naoto, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5171 From github.com+10835776+stsypanov at openjdk.java.net Fri Aug 20 09:48:36 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: Fri, 20 Aug 2021 09:48:36 GMT Subject: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop Message-ID: This is a continuation of - https://bugs.openjdk.java.net/browse/JDK-6736490 - https://bugs.openjdk.java.net/browse/JDK-8035284 - https://bugs.openjdk.java.net/browse/JDK-8145680 - https://bugs.openjdk.java.net/browse/JDK-8251548 As mentioned in JDK-6736490: _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._ ------------- Commit messages: - 8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop Changes: https://git.openjdk.java.net/jdk/pull/5197/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5197&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272756 Stats: 50 lines in 25 files changed: 0 ins; 0 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/5197.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5197/head:pull/5197 PR: https://git.openjdk.java.net/jdk/pull/5197 From prappo at openjdk.java.net Fri Aug 20 13:57:32 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 20 Aug 2021 13:57:32 GMT Subject: RFR: 8271302: Regex Test Refresh [v2] In-Reply-To: References: Message-ID: <4gsqMFxqlgphTRZQR7uc1V2nm8eHSG8RNSjgOGYuS90=.b86723df-0de5-4e09-bd76-e302b9a6f682@github.com> On Wed, 18 Aug 2021 18:35:53 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Couple of fixes test/jdk/java/util/regex/NegativeArraySize.java line 2: > 1: /* > 2: * Copyright (c) 2019, 2021 Oracle and/or its affiliates. All rights reserved. Add comma after 2021, or the copyright headers check won't pass. test/jdk/java/util/regex/NegativeArraySize.java line 29: > 27: * @summary Pattern.compile() can throw confusing NegativeArraySizeException > 28: * @requires os.maxMemory >= 5g > 29: * @run testng/othervm -Xms5G -Xmx5G NegativeArraySize I note that the order of the arguments has changed. Will that work as expected? Had it worked as expected before? test/jdk/java/util/regex/NegativeArraySize.java line 40: > 38: @Test > 39: public static void testNegativeArraySize() { > 40: assertThrows(OutOfMemoryError.class, () -> Pattern.compile("\\Q" + "a".repeat(42 + Integer.MAX_VALUE / 3))); One observation on this regex. Although the regex looks invalid because `\\Q` misses the pairing `\\E`, it can still be compiled (with a reasonable number of a's, of course). Moreover, the resulting pattern matches strings in a surprising way: jshell> Pattern.compile("\\Qaaa").matcher("aaa").matches() $1 ==> true test/jdk/java/util/regex/RegExTest.java line 27: > 25: * @test > 26: * @summary tests RegExp framework (use -Dseed=X to set PRNG seed) > 27: * @author Mike McCloskey What happened to Mike here? :-) test/jdk/java/util/regex/RegExTest.java line 121: > 119: private static void check(String p, String s, boolean expected) { > 120: Matcher matcher = Pattern.compile(p).matcher(s); > 121: assertSame(matcher.find(), expected); Why use `assertSame(Object, Object)`? I would expect `assertEquals(boolean, boolean)`. test/jdk/java/util/regex/RegExTest.java line 206: > 204: } > 205: > 206: // Regular expression test// Most of the tests are in a file Mistakenly joined comment lines? ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From prappo at openjdk.java.net Fri Aug 20 14:28:25 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 20 Aug 2021 14:28:25 GMT Subject: RFR: 8271302: Regex Test Refresh [v2] In-Reply-To: <4gsqMFxqlgphTRZQR7uc1V2nm8eHSG8RNSjgOGYuS90=.b86723df-0de5-4e09-bd76-e302b9a6f682@github.com> References: <4gsqMFxqlgphTRZQR7uc1V2nm8eHSG8RNSjgOGYuS90=.b86723df-0de5-4e09-bd76-e302b9a6f682@github.com> Message-ID: On Fri, 20 Aug 2021 13:46:39 GMT, Pavel Rappo wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Couple of fixes > > test/jdk/java/util/regex/NegativeArraySize.java line 40: > >> 38: @Test >> 39: public static void testNegativeArraySize() { >> 40: assertThrows(OutOfMemoryError.class, () -> Pattern.compile("\\Q" + "a".repeat(42 + Integer.MAX_VALUE / 3))); > > One observation on this regex. Although the regex looks invalid because `\\Q` misses the pairing `\\E`, it can still be compiled (with a reasonable number of a's, of course). Moreover, the resulting pattern matches strings in a surprising way: > > > jshell> Pattern.compile("\\Qaaa").matcher("aaa").matches() > $1 ==> true Maybe that behavior is expected after all. From "Mastering Regular Expressions" by Jeffrey E.F. Friedl, 3rd Edition, p. 136: > Literal-text span: `\Q...\E` > > First introduced with Perl, the special sequence `\Q...\E` turns off all regex meta-characters between them, except for `\E` itself. (If the `\E` is omitted, they are turned off until the end of the regex.) ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Fri Aug 20 15:49:27 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 20 Aug 2021 15:49:27 GMT Subject: RFR: 8271302: Regex Test Refresh [v2] In-Reply-To: <4gsqMFxqlgphTRZQR7uc1V2nm8eHSG8RNSjgOGYuS90=.b86723df-0de5-4e09-bd76-e302b9a6f682@github.com> References: <4gsqMFxqlgphTRZQR7uc1V2nm8eHSG8RNSjgOGYuS90=.b86723df-0de5-4e09-bd76-e302b9a6f682@github.com> Message-ID: On Fri, 20 Aug 2021 13:32:24 GMT, Pavel Rappo wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Couple of fixes > > test/jdk/java/util/regex/NegativeArraySize.java line 29: > >> 27: * @summary Pattern.compile() can throw confusing NegativeArraySizeException >> 28: * @requires os.maxMemory >= 5g >> 29: * @run testng/othervm -Xms5G -Xmx5G NegativeArraySize > > I note that the order of the arguments has changed. Will that work as expected? Had it worked as expected before? The new order is consistent with other tests. I had difficulty getting it to run in the original configuration. Perhaps jtreg is more sensitive on order with the testng runner. > test/jdk/java/util/regex/RegExTest.java line 121: > >> 119: private static void check(String p, String s, boolean expected) { >> 120: Matcher matcher = Pattern.compile(p).matcher(s); >> 121: assertSame(matcher.find(), expected); > > Why use `assertSame(Object, Object)`? I would expect `assertEquals(boolean, boolean)`. Artifacting because of the use of `==` I'll make it more readable. ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Fri Aug 20 16:27:53 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 20 Aug 2021 16:27:53 GMT Subject: RFR: 8271302: Regex Test Refresh [v3] In-Reply-To: References: Message-ID: > 8271302: Regex Test Refresh Ian Graves has updated the pull request incrementally with one additional commit since the last revision: some quick fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5092/files - new: https://git.openjdk.java.net/jdk/pull/5092/files/0e9fa209..3937bf8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=01-02 Stats: 8 lines in 2 files changed: 1 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5092/head:pull/5092 PR: https://git.openjdk.java.net/jdk/pull/5092 From prappo at openjdk.java.net Fri Aug 20 16:55:26 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 20 Aug 2021 16:55:26 GMT Subject: RFR: 8271302: Regex Test Refresh [v3] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 16:27:53 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > some quick fixes test/jdk/java/util/regex/RegExTest.java line 4270: > 4268: String s = (String)pm[1]; > 4269: boolean r = (Boolean)pm[2]; > 4270: assertSame(r, Pattern.compile(p).matcher(s).matches()); `assertEquals(boolean, boolean)` might be better. test/jdk/java/util/regex/RegExTest.java line 4270: > 4268: String s = (String)pm[1]; > 4269: boolean r = (Boolean)pm[2]; > 4270: assertSame(r, Pattern.compile(p).matcher(s).matches()); `expectThrows(PatternSyntaxException.class, ...)` might suit better for this and similar cases in this file. Not only does `expectThrows` test for expected exception, it also returns an exception which you can further inspect. Now, if we only had `assertThat` or similar functionality for compound assertions, the complete test might've looked nicely. ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From prappo at openjdk.java.net Fri Aug 20 17:01:28 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 20 Aug 2021 17:01:28 GMT Subject: RFR: 8271302: Regex Test Refresh [v3] In-Reply-To: References: Message-ID: <_DOJNVzi4RCF1GO1UwUDLFvInQTX0YzybumZLX24oss=.c35fd18b-df03-4184-b071-c3ae5624112b@github.com> On Fri, 20 Aug 2021 16:49:15 GMT, Pavel Rappo wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> some quick fixes > > test/jdk/java/util/regex/RegExTest.java line 4270: > >> 4268: String s = (String)pm[1]; >> 4269: boolean r = (Boolean)pm[2]; >> 4270: assertSame(r, Pattern.compile(p).matcher(s).matches()); > > `expectThrows(PatternSyntaxException.class, ...)` might suit better for this and similar cases in this file. Not only does `expectThrows` test for expected exception, it also returns an exception which you can further inspect. Now, if we only had `assertThat` or similar functionality for compound assertions, the complete test might've looked nicely. The latter comment referred to hand-rolled try-fail constructs like this: https://github.com/openjdk/jdk/blob/3937bf8f9921395d6fcbdc2bb00a4a98dc2aaf62/test/jdk/java/util/regex/RegExTest.java#L4281-L4289 Not sure why my IDE plugin messed up the comment position. ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Fri Aug 20 21:17:50 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 20 Aug 2021 21:17:50 GMT Subject: RFR: 8271302: Regex Test Refresh [v4] In-Reply-To: References: Message-ID: > 8271302: Regex Test Refresh Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Additional cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5092/files - new: https://git.openjdk.java.net/jdk/pull/5092/files/3937bf8f..3f01c172 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=02-03 Stats: 46 lines in 1 file changed: 1 ins; 27 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/5092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5092/head:pull/5092 PR: https://git.openjdk.java.net/jdk/pull/5092 From serb at openjdk.java.net Fri Aug 20 21:29:25 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 20 Aug 2021 21:29:25 GMT Subject: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop In-Reply-To: References: Message-ID: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com> On Fri, 20 Aug 2021 09:41:15 GMT, ?????? ??????? wrote: > This is a continuation of > > - https://bugs.openjdk.java.net/browse/JDK-6736490 > - https://bugs.openjdk.java.net/browse/JDK-8035284 > - https://bugs.openjdk.java.net/browse/JDK-8145680 > - https://bugs.openjdk.java.net/browse/JDK-8251548 > > As mentioned in JDK-6736490: > > _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._ src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java line 64: > 62: Set tags = essentialTags; > 63: if (tags == null) { > 64: essentialTags = Set.of( What is the purpose of the local tags here? ------------- PR: https://git.openjdk.java.net/jdk/pull/5197 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 23 06:38:27 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, 23 Aug 2021 06:38:27 GMT Subject: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop In-Reply-To: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com> References: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com> Message-ID: On Fri, 20 Aug 2021 21:26:41 GMT, Sergey Bylokhov wrote: >> This is a continuation of >> >> - https://bugs.openjdk.java.net/browse/JDK-6736490 >> - https://bugs.openjdk.java.net/browse/JDK-8035284 >> - https://bugs.openjdk.java.net/browse/JDK-8145680 >> - https://bugs.openjdk.java.net/browse/JDK-8251548 >> >> As mentioned in JDK-6736490: >> >> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._ > > src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java line 64: > >> 62: Set tags = essentialTags; >> 63: if (tags == null) { >> 64: essentialTags = Set.of( > > What is the purpose of the local tags here? Looks like there's no purpose, `tags` is not used after assignment ------------- PR: https://git.openjdk.java.net/jdk/pull/5197 From aivanov at openjdk.java.net Mon Aug 23 13:11:29 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 23 Aug 2021 13:11:29 GMT Subject: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop In-Reply-To: References: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com> Message-ID: On Mon, 23 Aug 2021 06:35:34 GMT, ?????? ??????? wrote: >> src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java line 64: >> >>> 62: Set tags = essentialTags; >>> 63: if (tags == null) { >>> 64: essentialTags = Set.of( >> >> What is the purpose of the local tags here? > > Looks like there's no purpose, `tags` is not used after assignment Maybe it's kind of a protection from a race. Yet it's possible either way: another thread could see `essentialTags == null` before this one initialises the field. ------------- PR: https://git.openjdk.java.net/jdk/pull/5197 From naoto at openjdk.java.net Mon Aug 23 16:48:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 23 Aug 2021 16:48:37 GMT Subject: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong Message-ID: Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. ------------- Commit messages: - 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong Changes: https://git.openjdk.java.net/jdk/pull/5225/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5225&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272473 Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5225/head:pull/5225 PR: https://git.openjdk.java.net/jdk/pull/5225 From serb at openjdk.java.net Mon Aug 23 18:00:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 Aug 2021 18:00:28 GMT Subject: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop In-Reply-To: References: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com> Message-ID: On Mon, 23 Aug 2021 13:08:02 GMT, Alexey Ivanov wrote: >> Looks like there's no purpose, `tags` is not used after assignment > > Maybe it's kind of a protection from a race. Yet it's possible either way: another thread could see `essentialTags == null` before this one initialises the field. I think we can drop it completely. ------------- PR: https://git.openjdk.java.net/jdk/pull/5197 From aivanov at openjdk.java.net Mon Aug 23 18:34:24 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 23 Aug 2021 18:34:24 GMT Subject: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop In-Reply-To: References: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com> Message-ID: On Mon, 23 Aug 2021 17:57:52 GMT, Sergey Bylokhov wrote: >> Maybe it's kind of a protection from a race. Yet it's possible either way: another thread could see `essentialTags == null` before this one initialises the field. > > I think we can drop it completely. Agree. ------------- PR: https://git.openjdk.java.net/jdk/pull/5197 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 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 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 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 github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 21:13:59 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 21:13:59 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: <6aLgG4zX_4XfiEmKpjHSYsUxPUKP50F5S4oJWSpdt4Y=.84c7399e-c0dc-46f6-a659-53969ad8b182@github.com> References: <6aLgG4zX_4XfiEmKpjHSYsUxPUKP50F5S4oJWSpdt4Y=.84c7399e-c0dc-46f6-a659-53969ad8b182@github.com> Message-ID: On Mon, 9 Aug 2021 23:46:09 GMT, Phil Race wrote: >> Even non-public method can be called via reflection, so I'd be cautios about changing return type > > Apps should not be doing that and the desktop module along with most of the rest of the JDK is strongly encapsulated and illegal access will be denied. But given the relationship with the sole (?) caller I think this is not worth the churn. Not exactly an MT hotspot. I'd revert the changes here and in MenuBar. reverted ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 21:13:57 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 21:13:57 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: References: Message-ID: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8271603: Unnecessary Vector usage in java.desktop revert back to Enumeration bring back default values ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4680/files - new: https://git.openjdk.java.net/jdk/pull/4680/files/12e39834..7a2393eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=00-01 Stats: 15 lines in 4 files changed: 1 ins; 2 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/4680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4680/head:pull/4680 PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 21:14:06 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 21:14:06 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 05:19:32 GMT, Sergey Bylokhov wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8271603: Unnecessary Vector usage in java.desktop >> revert back to Enumeration >> bring back default values > > src/java.desktop/share/classes/java/awt/MenuBar.java line 348: > >> 346: Iterator e = getMenu(i).shortcuts(); >> 347: while (e.hasNext()) { >> 348: shortcuts.addElement(e.next()); > > I think it is fine to replace the Enumeration with the Iterator in most of the places, but here we will get a kind of mix of both, since we cannot remove the usage of Enumeration in the return time. reverted back to Vector here > src/java.desktop/share/classes/javax/print/MimeType.java line 576: > >> 574: ArrayList thePieces = new ArrayList<>(); >> 575: boolean mediaTypeIsText; >> 576: boolean parameterNameIsCharset; > > Default values might be removed as a separate cleanup. reverted ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From serb at openjdk.java.net Tue Aug 24 23:12:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 Aug 2021 23:12:28 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 21:13:57 GMT, Andrey Turbanov wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8271603: Unnecessary Vector usage in java.desktop > revert back to Enumeration > bring back default values src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java line 244: > 242: } > 243: > 244: return list.toArray(new Line.Info[0]); I thought we already covered such changed under JDK-8269130, is there are any other missed cases? If yes then probably it will be good to extract such changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From joehw at openjdk.java.net Tue Aug 24 23:14:25 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 24 Aug 2021 23:14:25 GMT Subject: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5225 From prr at openjdk.java.net Wed Aug 25 00:08:28 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 25 Aug 2021 00:08:28 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 21:13:57 GMT, Andrey Turbanov wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8271603: Unnecessary Vector usage in java.desktop > revert back to Enumeration > bring back default values Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 08:01:59 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 08:01:59 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 21:13:57 GMT, Andrey Turbanov wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8271603: Unnecessary Vector usage in java.desktop > revert back to Enumeration > bring back default values I found many new places in java.desktop which can be migrated easily. Not sure how I did miss them in the first place. Sorry for inconvenience. Please re-review PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 08:02:03 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 08:02:03 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 23:09:52 GMT, Sergey Bylokhov wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8271603: Unnecessary Vector usage in java.desktop >> revert back to Enumeration >> bring back default values > > src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java line 244: > >> 242: } >> 243: >> 244: return list.toArray(new Line.Info[0]); > > I thought we already covered such changed under JDK-8269130, is there are any other missed cases? If yes then probably it will be good to extract such changes. In JDK-8269130 I fixed only usages of Collections.toArray. and didn't touch manual copying. Reverted usage of toArray where it wasn't used before. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 08:01:55 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 08:01:55 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v3] In-Reply-To: References: Message-ID: <9rIUQGHMrydeLPZaYstCKjRH_ODj9rob0a3CGfmGONo=.beafecab-48dd-4686-a5f0-9f2e7501f8dd@github.com> > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. Andrey Turbanov has updated the pull request incrementally with two additional commits since the last revision: - 8271603: Unnecessary Vector usage in java.desktop migrate more usages. Not sure how I missed them - 8271603: Unnecessary Vector usage in java.desktop revert back to use cycle to copy into array ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4680/files - new: https://git.openjdk.java.net/jdk/pull/4680/files/7a2393eb..97ca8477 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=01-02 Stats: 214 lines in 24 files changed: 26 ins; 11 del; 177 mod Patch: https://git.openjdk.java.net/jdk/pull/4680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4680/head:pull/4680 PR: https://git.openjdk.java.net/jdk/pull/4680 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 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 rriggs at openjdk.java.net Wed Aug 25 14:46:26 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 25 Aug 2021 14:46:26 GMT Subject: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5225 From iris at openjdk.java.net Wed Aug 25 16:28:23 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 25 Aug 2021 16:28:23 GMT Subject: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5225 From lancea at openjdk.java.net Wed Aug 25 17:10:27 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 25 Aug 2021 17:10:27 GMT Subject: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5225 From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 17:53:00 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 17:53:00 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v4] In-Reply-To: References: Message-ID: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8271603: Unnecessary Vector usage in java.desktop migrate even more usages ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4680/files - new: https://git.openjdk.java.net/jdk/pull/4680/files/97ca8477..5727f6f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=02-03 Stats: 30 lines in 7 files changed: 3 ins; 2 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/4680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4680/head:pull/4680 PR: https://git.openjdk.java.net/jdk/pull/4680 From scolebourne at openjdk.java.net Thu Aug 26 09:06:26 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Thu, 26 Aug 2021 09:06:26 GMT Subject: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. LGTM ------------- Marked as reviewed by scolebourne (Author). PR: https://git.openjdk.java.net/jdk/pull/5225 From naoto at openjdk.java.net Thu Aug 26 16:24:27 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 26 Aug 2021 16:24:27 GMT Subject: Integrated: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. This pull request has now been integrated. Changeset: fe7d7088 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/fe7d70886cc9985478c5810eff0790648a9aae41 Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong Reviewed-by: joehw, rriggs, iris, lancea, scolebourne ------------- PR: https://git.openjdk.java.net/jdk/pull/5225 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 serb at openjdk.java.net Fri Aug 27 17:10:30 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 27 Aug 2021 17:10:30 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v4] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 17:53:00 GMT, Andrey Turbanov wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8271603: Unnecessary Vector usage in java.desktop > migrate even more usages src/java.desktop/share/classes/javax/swing/JMenu.java line 1340: > 1338: } > 1339: MenuElement[] me = new MenuElement[elements.size()]; > 1340: elements.toArray(me); Implementation of the "toArray([])" is not equivalent of "copyInto([])". Maybe no-arg "return elements.toArray()" will look better. Same comment about other removed usage of copyInto ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Fri Aug 27 17:55:24 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 27 Aug 2021 17:55:24 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v4] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 17:04:33 GMT, Sergey Bylokhov wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8271603: Unnecessary Vector usage in java.desktop >> migrate even more usages > > src/java.desktop/share/classes/javax/swing/JMenu.java line 1340: > >> 1338: } >> 1339: MenuElement[] me = new MenuElement[elements.size()]; >> 1340: elements.toArray(me); > > Implementation of the "toArray([])" is not equivalent of "copyInto([])". Maybe no-arg "return elements.toArray()" will look better. Same comment about other removed usage of copyInto Can you please elaborate? As I can see if size of array is exactly the same as size of vector/arraylist, implementations are similar - they just call System.arraycopy ![???????????](https://user-images.githubusercontent.com/741251/131168809-480c05d6-2775-4812-91f5-c73833f9a396.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From serb at openjdk.java.net Fri Aug 27 18:32:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 27 Aug 2021 18:32:28 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v4] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 17:52:19 GMT, Andrey Turbanov wrote: >> src/java.desktop/share/classes/javax/swing/JMenu.java line 1340: >> >>> 1338: } >>> 1339: MenuElement[] me = new MenuElement[elements.size()]; >>> 1340: elements.toArray(me); >> >> Implementation of the "toArray([])" is not equivalent of "copyInto([])". Maybe no-arg "return elements.toArray()" will look better. Same comment about other removed usage of copyInto > > Can you please elaborate? > As I can see if size of array is exactly the same as size of vector/arraylist, implementations are similar - they just call System.arraycopy > ![???????????](https://user-images.githubusercontent.com/741251/131168809-480c05d6-2775-4812-91f5-c73833f9a396.png) To confirm this you need to do the same check on every usage of added toArray([]), the simpler version like "return toArray()" or return toArray(new MenuElement[elements.size()]) is simpler, no need to check something. I guess in some previouse fixes it was confirmed that the "return toArray(new MenuElement[0])" is even faster. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From smarks at openjdk.java.net Fri Aug 27 23:22:30 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 27 Aug 2021 23:22:30 GMT Subject: RFR: 8271302: Regex Test Refresh [v4] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 21:17:50 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Additional cleanup Marked as reviewed by smarks (Reviewer). Whew! Changes to GraphemeTest.java and NegativeArraySize.java look fine. I finally figured out how to look at RegExTest.java effectively -- none of the diff views were helpful at all. I just brought up the old and new versions in windows side by side and just scrolled through them. Overall it looks good, mostly a replacement of the ad hoc internal framework (failCount++) with assertX from testng, and some minor reorganizations here and there, such as the splitting of `stringBufferSubstitute` into several tests. Overall it looks like most things here got about 15% shorter, which is pretty good since it reduces the overall bulk. (However, there's so much more to do....) One observation about this technique is that using the "failCount++" approach, if there is a failure, the tests in the same method will continue to run. With the assertX approach, the test will stop at that point, and any assertions later in the same method won't get run at all. Since we expect all the tests to pass all the time, this has no effect in the normal case. If there is a bug, though, the assertX approach might result in a single failure whereas the failCount++ approach might result in several failures. While this bothers some people, it doesn't bother me; it's likely only to occur at development time, and it's like to be only a minor impediment to development. Indeed, it's commonly viewed as a testing antipattern to have a single test method test multiple cases. The solution is to fix that, and not worry about failCount++ vs assertX. I think the long run solution here is to continue cleaning up these tests, possibly breaking down test methods further, eventually driving things into a purely table-driven or data generator/provider approach. test/jdk/java/util/regex/RegExTest.java line 85: > 83: import static org.testng.Assert.fail; > 84: import static org.testng.Assert.expectThrows; //Replaced by assertThrows in JUnit5 > 85: Slightly odd to mention JUnit 5 here, since this is being converted to a TestNG test. Are these notes for yourself for future work? ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Mon Aug 30 15:44:41 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 30 Aug 2021 15:44:41 GMT Subject: RFR: 8271302: Regex Test Refresh [v4] In-Reply-To: References: Message-ID: <77EKNvY_VzhlqJkpCEg-7pLRuVUu9Gp3__FxxSePCgY=.8b4765bc-332d-4ab4-8907-07b7ac40bc2d@github.com> On Fri, 27 Aug 2021 23:18:34 GMT, Stuart Marks wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Additional cleanup > > test/jdk/java/util/regex/RegExTest.java line 85: > >> 83: import static org.testng.Assert.fail; >> 84: import static org.testng.Assert.expectThrows; //Replaced by assertThrows in JUnit5 >> 85: > > Slightly odd to mention JUnit 5 here, since this is being converted to a TestNG test. Are these notes for yourself for future work? Ah yes. I'll pull that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Mon Aug 30 15:52:05 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 30 Aug 2021 15:52:05 GMT Subject: RFR: 8271302: Regex Test Refresh [v5] In-Reply-To: References: Message-ID: > 8271302: Regex Test Refresh Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Removing some notes re JUnit5 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5092/files - new: https://git.openjdk.java.net/jdk/pull/5092/files/3f01c172..0845a56f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5092/head:pull/5092 PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Mon Aug 30 17:40:40 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 30 Aug 2021 17:40:40 GMT Subject: Integrated: 8271302: Regex Test Refresh In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 18:22:42 GMT, Ian Graves wrote: > 8271302: Regex Test Refresh This pull request has now been integrated. Changeset: fecefb85 Author: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/fecefb8541d5056b1a8b105126ac9c566875e056 Stats: 2253 lines in 3 files changed: 220 ins; 989 del; 1044 mod 8271302: Regex Test Refresh Reviewed-by: bchristi, smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From serb at openjdk.java.net Tue Aug 31 08:20:33 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 31 Aug 2021 08:20:33 GMT Subject: RFR: 8271302: Regex Test Refresh [v5] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 15:52:05 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Removing some notes re JUnit5 Looks like it was missed that the test fails oi a github actions: https://github.com/igraves/jdk/runs/3463998089 Run if ! grep --include=test-summary.txt -lqr build/*/test-results -e "TEST SUCCESS" ; then newfailures.txt java/util/regex/NegativeArraySize.java Error: Process completed with exit code 1. Invalid initial heap size: -Xms5G The specified size exceeds the maximum representable size. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From github.com+7837910+xpbob at openjdk.java.net Tue Aug 31 09:35:34 2021 From: github.com+7837910+xpbob at openjdk.java.net (xpbob) Date: Tue, 31 Aug 2021 09:35:34 GMT Subject: RFR: 8271302: Regex Test Refresh [v5] In-Reply-To: References: Message-ID: <1GZ2-BKuJbJOZITqE3I_czluAucGXIN8_nL_K8mhhos=.89d087b8-e2d6-434c-a2de-bd0453976bb2@github.com> On Mon, 30 Aug 2021 15:52:05 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Removing some notes re JUnit5 https://bugs.openjdk.java.net/browse/JDK-8273169 I'd like to fix it. --- a/test/jdk/java/util/regex/NegativeArraySize.java +++ b/test/jdk/java/util/regex/NegativeArraySize.java @@ -25,7 +25,7 @@ * @test * @bug 8223174 * @summary Pattern.compile() can throw confusing NegativeArraySizeException - * @requires os.maxMemory >= 5g + * @requires os.maxMemory >= 5g & vm.bits == 64 * @run testng/othervm -Xms5G -Xmx5G NegativeArraySize */ ------------- PR: https://git.openjdk.java.net/jdk/pull/5092