Re: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v4]

2022-06-08 Thread XenoAmess
On Thu, 28 Apr 2022 16:33:48 GMT, XenoAmess wrote: >> I'm getting a bit tired of seeing these JDK wide changes with lots of files >> touched. >> Delete all changes in desktop from this PR and re-submit them as a separate >> PR. >> >> Also do not cha

Re: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v5]

2022-04-28 Thread XenoAmess
On Thu, 28 Apr 2022 17:36:41 GMT, Weijun Wang wrote: > Looks like 1 is enough. @wangweij done. - PR: https://git.openjdk.java.net/jdk/pull/8301

Re: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v6]

2022-04-28 Thread XenoAmess
> These are the changes that too many to be reviewed in 8186958, thus split > some of them out. XenoAmess has updated the pull request incrementally with one additional commit since the last revision: change from 3 to 1 according to wangweij - Changes: - all:

Re: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v5]

2022-04-28 Thread XenoAmess
> These are the changes that too many to be reviewed in 8186958, thus split > some of them out. XenoAmess has updated the pull request incrementally with one additional commit since the last revision: revert changes to java.desktop as prrace said - Changes: - all:

Re: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v4]

2022-04-28 Thread XenoAmess
On Wed, 27 Apr 2022 05:11:54 GMT, XenoAmess wrote: > Also do not change J2DBench. We deliberately avoid using new API so that we > can take it and run it on very old JDK versions to help track regressions. For J2DBench, I don't see any changes that not complicated with older jdk

Re: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v4]

2022-04-26 Thread XenoAmess
On Wed, 27 Apr 2022 04:36:37 GMT, Phil Race wrote: > I'm getting a bit tired of seeing these JDK wide changes with lots of files > touched. @prrace I'm also a bit tired of seeing so many amazing mis-use in existed codes in jdk. In some place I even see somebody creates a HashMap with factor

Re: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v3]

2022-04-23 Thread XenoAmess
On Fri, 22 Apr 2022 23:31:41 GMT, Sergey Bylokhov wrote: >> XenoAmess has updated the pull request incrementally with one additional >> commit since the last revision: >> >> add more replaces > > src/demo/share/java2d/J2DBench/src/j2dbench/tests/text/TextTes

Re: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v4]

2022-04-23 Thread XenoAmess
> These are the changes that too many to be reviewed in 8186958, thus split > some of them out. XenoAmess has updated the pull request incrementally with two additional commits since the last revision: - maintains compatibility with jdk1.4 for TextTests - fix missed space

Re: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v3]

2022-04-20 Thread XenoAmess
> These are the changes that too many to be reviewed in 8186958, thus split > some of them out. XenoAmess has updated the pull request incrementally with one additional commit since the last revision: add more replaces - Changes: - all: https://git.openjdk.java.net/jd

Re: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v2]

2022-04-20 Thread XenoAmess
> These are the changes that too many to be reviewed in 8186958, thus split > some of them out. XenoAmess has updated the pull request incrementally with two additional commits since the last revision: - add more replaces - add more replaces - Changes: - all:

RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)

2022-04-20 Thread XenoAmess
These are the changes that too many to be reviewed in 8186958, thus split some of them out. - Commit messages: - 9073085: ues HashMap.newHashMap to replace new HashMap(int) Changes: https://git.openjdk.java.net/jdk/pull/8301/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk

Re: RFR: 8284903: Fix typos in hotspot

2022-04-19 Thread XenoAmess
On Tue, 19 Apr 2022 08:49:28 GMT, Doug Simon wrote: > Are there plans to add `codespell` to the make system to somehow > catch/prevent spelling regressions in future? I understand this may not be > feasible. IMO all spell checking mechanisms suffers from false positive and need human manual j