From tschatzl at openjdk.java.net Wed Sep 1 08:14:47 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 1 Sep 2021 08:14:47 GMT Subject: [OpenJDK 2D-Dev] RFR: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible [v4] In-Reply-To: References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> Message-ID: On Tue, 31 Aug 2021 20:04:23 GMT, ?????? ??????? wrote: >> Just a very tiny clean-up. >> >> There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access: >> >> public T[] getEnumConstants() { >> T[] values = getEnumConstantsShared(); >> return (values != null) ? values.clone() : null; >> } >> >> private transient volatile T[] enumConstants; >> >> T[] getEnumConstantsShared() { >> T[] constants = enumConstants; >> if (constants == null) { /* ... */ } >> return constants; >> } >> >> Calling values() method is slightly faster: >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class EnumBenchmark { >> >> @Benchmark >> public Enum[] values() { >> return Enum.values(); >> } >> >> @Benchmark >> public Enum[] getEnumConstants() { >> return Enum.class.getEnumConstants(); >> } >> >> private enum Enum { >> A, >> B >> } >> } >> >> >> Benchmark Mode Cnt Score Error Units >> EnumBenchmark.getEnumConstants avgt 15 6,265 ? 0,051 ns/op >> EnumBenchmark.getEnumConstants:?gc.alloc.rate avgt 15 2434,075 ? 19,568 MB/sec >> EnumBenchmark.getEnumConstants:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op >> EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space avgt 15 2433,709 ? 70,216 MB/sec >> EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space.norm avgt 15 23,998 ? 0,659 B/op >> EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space avgt 15 0,009 ? 0,003 MB/sec >> EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op >> EnumBenchmark.getEnumConstants:?gc.count avgt 15 210,000 counts >> EnumBenchmark.getEnumConstants:?gc.time avgt 15 119,000 ms >> >> EnumBenchmark.values avgt 15 4,164 ? 0,134 ns/op >> EnumBenchmark.values:?gc.alloc.rate avgt 15 3665,341 ? 120,721 MB/sec >> EnumBenchmark.values:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op >> EnumBenchmark.values:?gc.churn.G1_Eden_Space avgt 15 3660,512 ? 137,250 MB/sec >> EnumBenchmark.values:?gc.churn.G1_Eden_Space.norm avgt 15 23,972 ? 0,529 B/op >> EnumBenchmark.values:?gc.churn.G1_Survivor_Space avgt 15 0,017 ? 0,003 MB/sec >> EnumBenchmark.values:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op >> EnumBenchmark.values:?gc.count avgt 15 262,000 counts >> EnumBenchmark.values:?gc.time avgt 15 155,000 ms > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8273140: Fix copyright year Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5303 From github.com+741251+turbanoff at openjdk.java.net Wed Sep 1 10:44:07 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 1 Sep 2021 10:44:07 GMT Subject: [OpenJDK 2D-Dev] RFR: 8273168: Remove superfluous use of boxing in java.desktop [v2] In-Reply-To: References: Message-ID: > parseInt/parseLong/parseShort/parseByte/parseFloat should be preferred, as they return primitives. While valueOf returns boxed object. Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into redundant_boxing_in_java.desktop - [PATCH] Cleanup redundant boxing in java.desktop module parseInt/parseLong/parseShort/parseByte/parseFloat should be preferred, as they return primitives. While valueOf returns boxed object. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5313/files - new: https://git.openjdk.java.net/jdk/pull/5313/files/c24b15a5..a6bdbb7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5313&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5313&range=00-01 Stats: 995 lines in 34 files changed: 688 ins; 181 del; 126 mod Patch: https://git.openjdk.java.net/jdk/pull/5313.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5313/head:pull/5313 PR: https://git.openjdk.java.net/jdk/pull/5313 From github.com+741251+turbanoff at openjdk.java.net Wed Sep 1 19:30:11 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 1 Sep 2021 19:30:11 GMT Subject: [OpenJDK 2D-Dev] RFR: 8271603: Unnecessary Vector usage in java.desktop [v4] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 18:28:58 GMT, Sergey Bylokhov wrote: >> 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. Ok. Simplified ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Wed Sep 1 19:30:10 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 1 Sep 2021 19:30:10 GMT Subject: [OpenJDK 2D-Dev] RFR: 8271603: Unnecessary Vector usage in java.desktop [v5] In-Reply-To: References: Message-ID: <2uvW-RV4K6LMrM5QpOJF2v_FjDJVZpkj1746Q_GAY9A=.b94c87be-ebd8-4ea8-aede-cf84126a6290@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 one additional commit since the last revision: 8271603: Unnecessary Vector usage in java.desktop use toArray with zero sized array in places where Vector.copyInto was used ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4680/files - new: https://git.openjdk.java.net/jdk/pull/4680/files/5727f6f2..1f0ebd1c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=03-04 Stats: 22 lines in 9 files changed: 0 ins; 13 del; 9 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 Wed Sep 1 19:46:51 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 1 Sep 2021 19:46:51 GMT Subject: [OpenJDK 2D-Dev] RFR: 8271603: Unnecessary Vector usage in java.desktop [v6] In-Reply-To: References: Message-ID: <7f4YqmkdSFHfBZVEG_zH7YlHgaXXTH946MURedTeMIs=.21591a2f-7139-49d3-a9cb-90acd423c49f@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 with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge remote-tracking branch 'origin/master' into avoid-unnecessary-vector-usage-in-java.desktop # Conflicts: # src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java - 8271603: Unnecessary Vector usage in java.desktop use toArray with zero sized array in places where Vector.copyInto was used - 8271603: Unnecessary Vector usage in java.desktop migrate even more usages - 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 - 8271603: Unnecessary Vector usage in java.desktop revert back to Enumeration bring back default values - [PATCH] Unnecessary Vector usage in java.desktop use zero-length array - [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=05 Stats: 270 lines in 34 files changed: 19 ins; 30 del; 221 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 philip.race at oracle.com Wed Sep 1 22:04:36 2021 From: philip.race at oracle.com (Philip Race) Date: Wed, 1 Sep 2021 15:04:36 -0700 Subject: [OpenJDK 2D-Dev] Fwd: Project Wakefield announcement and welcome In-Reply-To: <09dddbdd-d4d2-c6f4-1622-583239d91e4a@oracle.com> References: <09dddbdd-d4d2-c6f4-1622-583239d91e4a@oracle.com> Message-ID: <7c2dea5f-e3b2-c030-4802-10725c7bae35@oracle.com> FYI -------- Forwarded Message -------- Subject: Project Wakefield announcement and welcome Date: Wed, 1 Sep 2021 14:59:30 -0700 From: Philip Race To: wakefield-dev at openjdk.java.net Hi all, The project has been recorded in the OpenJDK census : https://openjdk.java.net/census#wakefield The email list (to which I sent this) https://mail.openjdk.java.net/mailman/listinfo/wakefield-dev has been set up pre-populated with the initial committers. If you are a committer who did not previously have an OpenJDK ID you should have received an invitation to register. Don't ignore it - it will expire in 14 days from when it was sent. We also have a web page https://openjdk.java.net/projects/wakefield/ which is still just pro-forma I'll add something more once we have it :-) The wiki is also being set up : https://wiki.openjdk.java.net/display/wakefield Unlike the Project Page everyone who is a committer will be able to edit the wiki The project repo has not yet been created but is expected to be created this week. I will send a follow up on that once it is done. I'll also inform the various client lists (forward please do NOT cross post !)? of the new mailing list -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+10835776+stsypanov at openjdk.java.net Thu Sep 2 08:13: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: Thu, 2 Sep 2021 08:13:37 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible In-Reply-To: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> Message-ID: <43jcu3pT9PMTk266WJaSVQ_4Yyv1FV3rhR6efbpxjPA=.5e1cec47-2d47-4b27-a5a6-8e6cd2467b48@github.com> On Mon, 30 Aug 2021 14:26:56 GMT, ?????? ??????? wrote: > Just a very tiny clean-up. > > There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access: > > public T[] getEnumConstants() { > T[] values = getEnumConstantsShared(); > return (values != null) ? values.clone() : null; > } > > private transient volatile T[] enumConstants; > > T[] getEnumConstantsShared() { > T[] constants = enumConstants; > if (constants == null) { /* ... */ } > return constants; > } > > Calling values() method is slightly faster: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class EnumBenchmark { > > @Benchmark > public Enum[] values() { > return Enum.values(); > } > > @Benchmark > public Enum[] getEnumConstants() { > return Enum.class.getEnumConstants(); > } > > private enum Enum { > A, > B > } > } > > > Benchmark Mode Cnt Score Error Units > EnumBenchmark.getEnumConstants avgt 15 6,265 ? 0,051 ns/op > EnumBenchmark.getEnumConstants:?gc.alloc.rate avgt 15 2434,075 ? 19,568 MB/sec > EnumBenchmark.getEnumConstants:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op > EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space avgt 15 2433,709 ? 70,216 MB/sec > EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space.norm avgt 15 23,998 ? 0,659 B/op > EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space avgt 15 0,009 ? 0,003 MB/sec > EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op > EnumBenchmark.getEnumConstants:?gc.count avgt 15 210,000 counts > EnumBenchmark.getEnumConstants:?gc.time avgt 15 119,000 ms > > EnumBenchmark.values avgt 15 4,164 ? 0,134 ns/op > EnumBenchmark.values:?gc.alloc.rate avgt 15 3665,341 ? 120,721 MB/sec > EnumBenchmark.values:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op > EnumBenchmark.values:?gc.churn.G1_Eden_Space avgt 15 3660,512 ? 137,250 MB/sec > EnumBenchmark.values:?gc.churn.G1_Eden_Space.norm avgt 15 23,972 ? 0,529 B/op > EnumBenchmark.values:?gc.churn.G1_Survivor_Space avgt 15 0,017 ? 0,003 MB/sec > EnumBenchmark.values:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op > EnumBenchmark.values:?gc.count avgt 15 262,000 counts > EnumBenchmark.values:?gc.time avgt 15 155,000 ms This pull request has now been integrated. Changeset: 152e6692 Author: Sergey Tsypanov Committer: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/152e66923dc36cfd83cdfe18e96631abc06b9199 Stats: 13 lines in 4 files changed: 0 ins; 2 del; 11 mod 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible Reviewed-by: tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/5303 From serb at openjdk.java.net Thu Sep 2 22:59:31 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 2 Sep 2021 22:59:31 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. This pull request has now been integrated. Changeset: 7fff22af Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/7fff22afe711c8c04dbf4cf5b4938d40632e4987 Stats: 364 lines in 53 files changed: 98 ins; 128 del; 138 mod 8272805: Avoid looking up standard charsets Reviewed-by: weijun, naoto, dfuchs, azvegint, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/5210 From github.com+178883+gredler at openjdk.java.net Fri Sep 3 02:50:33 2021 From: github.com+178883+gredler at openjdk.java.net (Daniel Gredler) Date: Fri, 3 Sep 2021 02:50:33 GMT Subject: [OpenJDK 2D-Dev] RFR: 8272878: JEP 381 cleanup: Remove unused Solaris code in sun.font.TrueTypeGlyphMapper In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 22:05:13 GMT, Daniel Gredler wrote: > During the recent JEP 381 removal of Solaris code, a few Solaris-specific constants and private methods were left behind in sun.font.TrueTypeGlyphMapper. This PR removes these unused odds and ends. I think LittleCMS explicitly supports Solaris, so I doubt a patch removing Solaris support would be accepted upstream. It does look like XScrollbarPeer should be cleaned up, but should it be done as part of this PR? Let me know either way. I'm also looking for a sponsor for this PR, would either @prrace or @prsadhuk have some time to spare? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5232 From serb at openjdk.java.net Fri Sep 3 03:20:38 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 3 Sep 2021 03:20:38 GMT Subject: [OpenJDK 2D-Dev] RFR: 8271603: Unnecessary Vector usage in java.desktop [v6] In-Reply-To: <7f4YqmkdSFHfBZVEG_zH7YlHgaXXTH946MURedTeMIs=.21591a2f-7139-49d3-a9cb-90acd423c49f@github.com> References: <7f4YqmkdSFHfBZVEG_zH7YlHgaXXTH946MURedTeMIs=.21591a2f-7139-49d3-a9cb-90acd423c49f@github.com> Message-ID: On Wed, 1 Sep 2021 19:46:51 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge remote-tracking branch 'origin/master' into avoid-unnecessary-vector-usage-in-java.desktop > > # Conflicts: > # src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java > - 8271603: Unnecessary Vector usage in java.desktop > use toArray with zero sized array in places where Vector.copyInto was used > - 8271603: Unnecessary Vector usage in java.desktop > migrate even more usages > - 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 > - 8271603: Unnecessary Vector usage in java.desktop > revert back to Enumeration > bring back default values > - [PATCH] Unnecessary Vector usage in java.desktop > use zero-length array > - [PATCH] Unnecessary Vector usage in java.desktop src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1578: > 1576: } > 1577: String[] retValue = new String[temp.size()]; > 1578: temp.toArray(retValue); Why not `return temp.toArray(new String[0]);` like in other places in the last commit? ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From prr at openjdk.java.net Fri Sep 3 04:00:47 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 3 Sep 2021 04:00:47 GMT Subject: [OpenJDK 2D-Dev] RFR: 8272878: JEP 381 cleanup: Remove unused Solaris code in sun.font.TrueTypeGlyphMapper In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 22:05:13 GMT, Daniel Gredler wrote: > During the recent JEP 381 removal of Solaris code, a few Solaris-specific constants and private methods were left behind in sun.font.TrueTypeGlyphMapper. This PR removes these unused odds and ends. Completely out of scope by a country mile to get anywhere near the LCMS support for Solaris. In fact a really bad idea. Current JDK does not support Solaris but current LCMS may want to support older Solaris I will sponsor this if it is ready. The submitter needs to type /integrate and only after that does /sponsor do anything. ------------- PR: https://git.openjdk.java.net/jdk/pull/5232 From github.com+741251+turbanoff at openjdk.java.net Fri Sep 3 08:05:00 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 3 Sep 2021 08:05:00 GMT Subject: [OpenJDK 2D-Dev] RFR: 8271603: Unnecessary Vector usage in java.desktop [v6] In-Reply-To: References: <7f4YqmkdSFHfBZVEG_zH7YlHgaXXTH946MURedTeMIs=.21591a2f-7139-49d3-a9cb-90acd423c49f@github.com> Message-ID: On Fri, 3 Sep 2021 03:17:02 GMT, Sergey Bylokhov wrote: >> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge remote-tracking branch 'origin/master' into avoid-unnecessary-vector-usage-in-java.desktop >> >> # Conflicts: >> # src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java >> - 8271603: Unnecessary Vector usage in java.desktop >> use toArray with zero sized array in places where Vector.copyInto was used >> - 8271603: Unnecessary Vector usage in java.desktop >> migrate even more usages >> - 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 >> - 8271603: Unnecessary Vector usage in java.desktop >> revert back to Enumeration >> bring back default values >> - [PATCH] Unnecessary Vector usage in java.desktop >> use zero-length array >> - [PATCH] Unnecessary Vector usage in java.desktop > > src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1578: > >> 1576: } >> 1577: String[] retValue = new String[temp.size()]; >> 1578: temp.toArray(retValue); > > Why not `return temp.toArray(new String[0]);` like in other places in the last commit? Good catch! Update here too. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Fri Sep 3 08:04:52 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 3 Sep 2021 08:04:52 GMT Subject: [OpenJDK 2D-Dev] RFR: 8271603: Unnecessary Vector usage in java.desktop [v7] 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 one more place to call toArray with zero-sized array ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4680/files - new: https://git.openjdk.java.net/jdk/pull/4680/files/2fb05a2c..f0ab7f17 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 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+178883+gredler at openjdk.java.net Fri Sep 3 16:53:27 2021 From: github.com+178883+gredler at openjdk.java.net (Daniel Gredler) Date: Fri, 3 Sep 2021 16:53:27 GMT Subject: [OpenJDK 2D-Dev] RFR: 8272878: JEP 381 cleanup: Remove unused Solaris code in sun.font.TrueTypeGlyphMapper In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 05:07:56 GMT, Prasanta Sadhukhan wrote: >> During the recent JEP 381 removal of Solaris code, a few Solaris-specific constants and private methods were left behind in sun.font.TrueTypeGlyphMapper. This PR removes these unused odds and ends. > > I do not have any objection to this looking into comments in future and not in this PR. > What about the code that has solaris in it? > https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java#L37 > https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/liblcms/lcms2.h#L534 [it might need change in upstream though] @prsadhuk I will raise a separate PR in the coming days to address the XScrollbarPeer cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/5232 From serb at openjdk.java.net Sat Sep 4 00:40:54 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 4 Sep 2021 00:40:54 GMT Subject: [OpenJDK 2D-Dev] RFR: 8271603: Unnecessary Vector usage in java.desktop [v7] In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 08:04:52 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 > one more place to call toArray with zero-sized array Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From jdv at openjdk.java.net Mon Sep 6 05:12:45 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Mon, 6 Sep 2021 05:12:45 GMT Subject: [OpenJDK 2D-Dev] RFR: 8272878: JEP 381 cleanup: Remove unused Solaris code in sun.font.TrueTypeGlyphMapper In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 22:05:13 GMT, Daniel Gredler wrote: > During the recent JEP 381 removal of Solaris code, a few Solaris-specific constants and private methods were left behind in sun.font.TrueTypeGlyphMapper. This PR removes these unused odds and ends. Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5232 From github.com+178883+gredler at openjdk.java.net Mon Sep 6 08:18:04 2021 From: github.com+178883+gredler at openjdk.java.net (Daniel Gredler) Date: Mon, 6 Sep 2021 08:18:04 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8272878: JEP 381 cleanup: Remove unused Solaris code in sun.font.TrueTypeGlyphMapper In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 22:05:13 GMT, Daniel Gredler wrote: > During the recent JEP 381 removal of Solaris code, a few Solaris-specific constants and private methods were left behind in sun.font.TrueTypeGlyphMapper. This PR removes these unused odds and ends. This pull request has now been integrated. Changeset: 70ed6c5b Author: Daniel Gredler Committer: Jayathirth D V URL: https://git.openjdk.java.net/jdk/commit/70ed6c5b8c52dc1c1c25967a09164a013bdb4bdd Stats: 17 lines in 1 file changed: 0 ins; 17 del; 0 mod 8272878: JEP 381 cleanup: Remove unused Solaris code in sun.font.TrueTypeGlyphMapper Reviewed-by: prr, jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/5232 From jdv at openjdk.java.net Mon Sep 6 09:20:02 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Mon, 6 Sep 2021 09:20:02 GMT Subject: [OpenJDK 2D-Dev] RFR: 8273375: Remove redundant 'new String' calls after concatenation in java.desktop In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 07:53:21 GMT, Andrey Turbanov wrote: > Result of string concatenation is a newly created `String` object. There is no need it wrap it in another `new String` call. > Such calls are confusing and produce warnings in IDE. Without them code is easier to read. Link this PR to bug in JBS. Otherwise change looks fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/5356 From github.com+741251+turbanoff at openjdk.java.net Mon Sep 6 09:20:01 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 6 Sep 2021 09:20:01 GMT Subject: [OpenJDK 2D-Dev] RFR: 8273375: Remove redundant 'new String' calls after concatenation in java.desktop Message-ID: Result of string concatenation is a newly created `String` object. There is no need it wrap it in another `new String` call. Such calls are confusing and produce warnings in IDE. Without them code is easier to read. ------------- Commit messages: - [PATCH] Remove redundant 'new String' calls after concatenation in java.desktop Changes: https://git.openjdk.java.net/jdk/pull/5356/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5356&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273375 Stats: 91 lines in 15 files changed: 8 ins; 2 del; 81 mod Patch: https://git.openjdk.java.net/jdk/pull/5356.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5356/head:pull/5356 PR: https://git.openjdk.java.net/jdk/pull/5356 From aivanov at openjdk.java.net Tue Sep 7 19:13:36 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 7 Sep 2021 19:13:36 GMT Subject: [OpenJDK 2D-Dev] RFR: 8273102: Delete deprecated for removal the empty finalize() in java.desktop module In-Reply-To: References: Message-ID: On Sun, 29 Aug 2021 01:09:36 GMT, Sergey Bylokhov wrote: > The "java.desktop" module has a few implementations of the finalize() which do nothing, deprecated since jdk9, and are marked "forRemoval = true" since jdk16. > > This is a request to delete such empty methods. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8273103 Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5292 From philip.race at oracle.com Wed Sep 15 18:08:45 2021 From: philip.race at oracle.com (Philip Race) Date: Wed, 15 Sep 2021 11:08:45 -0700 Subject: [OpenJDK 2D-Dev] Retiring this 2d-dev list on 30th September 2021 In-Reply-To: References: Message-ID: As described below -Phil. -------- Forwarded Message -------- Subject: Retiring 2d, awt, beans, sound and swing mailing lists on 30th September 2021 Date: Wed, 15 Sep 2021 11:05:09 -0700 From: Philip Race To: client-libs-dev at openjdk.java.net Since : 1) The old client groups mailing lists were consolidated into client-libs-dev at openjdk dot java dot net [1], including subscribing all subscribers to the old invividual lists to the new consolidated list, and 2) The skara github tooling has also migrated to that new list and 3) Folks are already using the new list for questions etc Then : I think it is time to plan the retirement of all the old lists : 2d-dev [2], awt-dev [3], beans-dev [4], sound-dev [5], and swing-dev [6] Accordingly I propose that these five old lists become archived and read-only as of 12pm PDT 30th September 2021 and will ask the mail server adminstrators to plan to implement this at that time. I will also forward this information to each of those individual lists. -Phil Race Client Libs Group Lead. [1] https://mail.openjdk.java.net/mailman/listinfo/client-libs-dev [2] https://mail.openjdk.java.net/mailman/listinfo/2d-dev [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev [4] https://mail.openjdk.java.net/mailman/listinfo/beans-dev [5] https://mail.openjdk.java.net/mailman/listinfo/sound-dev [6] https://mail.openjdk.java.net/mailman/listinfo/swing-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Sep 29 04:02:36 2021 From: philip.race at oracle.com (Philip Race) Date: Tue, 28 Sep 2021 21:02:36 -0700 Subject: [OpenJDK 2D-Dev] Retiring this 2d-dev list on 30th September 2021 In-Reply-To: References: Message-ID: Reminder. -phil On 9/15/21 11:08 AM, Philip Race wrote: > As described below > > -Phil. > > > -------- Forwarded Message -------- > Subject: Retiring 2d, awt, beans, sound and swing mailing lists on > 30th September 2021 > Date: Wed, 15 Sep 2021 11:05:09 -0700 > From: Philip Race > To: client-libs-dev at openjdk.java.net > > > > Since : > 1) The old client groups mailing lists were consolidated into > client-libs-dev at openjdk dot java dot net [1], > including subscribing all subscribers to the old invividual lists to > the new consolidated list, and > 2) The skara github tooling has also migrated to that new list and > 3) Folks are already using the new list for questions etc > > Then : > I think it is time to plan the retirement of all the old lists : > 2d-dev [2], awt-dev [3], beans-dev [4], sound-dev [5], and swing-dev [6] > > Accordingly I propose that these five old lists become archived and > read-only as of 12pm PDT 30th September 2021 > and will ask the mail server adminstrators to plan to implement this > at that time. > > I will also forward this information to each of those individual lists. > > -Phil Race > Client Libs Group Lead. > > [1] https://mail.openjdk.java.net/mailman/listinfo/client-libs-dev > [2] https://mail.openjdk.java.net/mailman/listinfo/2d-dev > [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev > [4] https://mail.openjdk.java.net/mailman/listinfo/beans-dev > [5] https://mail.openjdk.java.net/mailman/listinfo/sound-dev > [6] https://mail.openjdk.java.net/mailman/listinfo/swing-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: