From naoto at openjdk.java.net  Wed Apr  6 17:52:08 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Apr 2022 17:52:08 GMT
Subject: jmx-dev RFR: 8283698: Refactor Locale constructors used in src/test
Message-ID: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>

This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

-------------

Commit messages:
 - 8283698: Refactor Locale constructors used in src/test

Changes: https://git.openjdk.java.net/jdk/pull/8130/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8130&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283698
  Stats: 750 lines in 182 files changed: 3 ins; 3 del; 744 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8130.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8130/head:pull/8130

PR: https://git.openjdk.java.net/jdk/pull/8130

From iris at openjdk.java.net  Wed Apr  6 19:36:40 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 6 Apr 2022 19:36:40 GMT
Subject: jmx-dev RFR: 8283698: Refactor Locale constructors used in
 src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <r5RSuZEt-YT0EOWQmAH1kV7c1apKvBn-ss866xTyF5E=.903a7419-865c-472e-9e20-632d882293e7@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 00:13:45 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 00:13:45 GMT
Subject: jmx-dev RFR: 8283698: Refactor Locale constructors used in
 src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:

> 79: 
> 80:     /**
> 81:      * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");

Locale.France?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 00:20:31 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 00:20:31 GMT
Subject: jmx-dev RFR: 8283698: Refactor Locale constructors used in
 src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <oWowG5ZF6uQhqEOWoDSp17TbGHZqZjmcaxL_5_yGxuU=.b7e9daaf-b3eb-4620-a0a6-01635f37e8ec@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

test/jdk/java/text/Format/DateFormat/NonGregorianFormatTest.java line 131:

> 129: 
> 130:         // Tests with the Japanese imperial calendar
> 131:         Locale calendarLocale = Locale.of("ja", "JP", "JP");

Locale.JAPAN?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 00:31:55 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 00:31:55 GMT
Subject: jmx-dev RFR: 8283698: Refactor Locale constructors used in
 src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <UYhQLIeSUDpGNeR1pFuD9ll9SIPZFAnzvRiX-rft8f8=.bdb3a956-ca7a-4523-87d6-71e9a12e5a76@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:

> 61:             Locale.of("it", "IT", "EURO"),
> 62:             Locale.forLanguageTag("de-AT"),
> 63:             Locale.forLanguageTag("fr-CH"),

Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways.

test/jdk/java/text/Format/common/Bug6215962.java line 58:

> 56:         check(mf1, mf2, false);
> 57: 
> 58:         mf1 = new MessageFormat("{0}", Locale.of("ja", "JP"));

Locale.JAPAN?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From naoto at openjdk.java.net  Thu Apr  7 01:19:35 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 7 Apr 2022 01:19:35 GMT
Subject: jmx-dev RFR: 8283698: Refactor Locale constructors used in
 src/test
In-Reply-To: <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
 <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
Message-ID: <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>

On Thu, 7 Apr 2022 00:09:58 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.
>
> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
> 
>> 79: 
>> 80:     /**
>> 81:      * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
> 
> Locale.France?

The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, `country`, and `variant`, then create a `Locale` using those 3 elements. Changing it to `Locale.FRANCE` does not seem right here.

> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
> 
>> 61:             Locale.of("it", "IT", "EURO"),
>> 62:             Locale.forLanguageTag("de-AT"),
>> 63:             Locale.forLanguageTag("fr-CH"),
> 
> Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways.

`Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it validates the input language tag, while `Locale.of()` doesn't as well as Locale constructors.

> test/jdk/java/text/Format/common/Bug6215962.java line 58:
> 
>> 56:         check(mf1, mf2, false);
>> 57: 
>> 58:         mf1 = new MessageFormat("{0}", Locale.of("ja", "JP"));
> 
> Locale.JAPAN?

The test intends to compare the generated `MessageFormat` objects (`mf2` & `mf1`) from using a constant `Locale.JAPAN` and the factory method. So I believe leaving it as `Locale.of()` makes sense.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 04:51:38 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 04:51:38 GMT
Subject: jmx-dev RFR: 8283698: Refactor Locale constructors used in
 src/test
In-Reply-To: <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
 <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
 <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
Message-ID: <0Zxp9nACKCy12wn8Viwd5lYHz3KXojuy02cZLiz8Wiw=.f1a9f3b3-8cfb-4845-87e7-bef9b69ada8a@github.com>

On Thu, 7 Apr 2022 01:16:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
>> 
>>> 79: 
>>> 80:     /**
>>> 81:      * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
>> 
>> Locale.France?
>
> The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, `country`, and `variant`, then create a `Locale` using those 3 elements. Changing it to `Locale.FRANCE` does not seem right here.

I see.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 04:59:39 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 04:59:39 GMT
Subject: jmx-dev RFR: 8283698: Refactor Locale constructors used in
 src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <c7WnJL_FTC92jBi5LhA8s1EA-5LMgBW7ucldQb0GQVk=.aa5aa4d7-07a4-4f44-ab61-e89f54adb1ec@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 04:59:40 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 04:59:40 GMT
Subject: jmx-dev RFR: 8283698: Refactor Locale constructors used in
 src/test
In-Reply-To: <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
 <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
 <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
Message-ID: <VhDD3losQJHv-SpTfyDeEG5Jb3lX9kYSQ9CoOMD2YIU=.47de2cb7-1289-4f2d-8648-c75320e44ac9@github.com>

On Thu, 7 Apr 2022 01:16:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
>> 
>>> 61:             Locale.of("it", "IT", "EURO"),
>>> 62:             Locale.forLanguageTag("de-AT"),
>>> 63:             Locale.forLanguageTag("fr-CH"),
>> 
>> Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways.
>
> `Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it validates the input language tag, while `Locale.of()` doesn't as well as Locale constructors.

Ok, I didn't realize the existing method is preferred over the new method in creating a Locale. The javadoc does state that it does not make any syntactic checks. That's good to know.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From naoto at openjdk.java.net  Fri Apr  8 15:26:35 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 8 Apr 2022 15:26:35 GMT
Subject: jmx-dev Integrated: 8283698: Refactor Locale constructors used in
 src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <r6its8TfgpC32jQ7YIdERQEA2ElBz-DOEd9zkKv5vGY=.38b6000b-7b2b-4180-8981-19fc570c322a@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

This pull request has now been integrated.

Changeset: d6b4693c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d6b4693c0527385f8999089b3f8b2120548efecb
Stats:     750 lines in 182 files changed: 3 ins; 3 del; 744 mod

8283698: Refactor Locale constructors used in src/test

Reviewed-by: iris, joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From duke at openjdk.java.net  Wed Apr 20 16:03:49 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:03:49 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int)
Message-ID: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>

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&pr=8301&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285149
  Stats: 36 lines in 20 files changed: 0 ins; 0 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301

PR: https://git.openjdk.java.net/jdk/pull/8301

From duke at openjdk.java.net  Wed Apr 20 16:27:36 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 20 Apr 2022 16:27:36 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int)
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <LNr5eBXHxyrGXyQlFUv2XMd1MjqR6IXTM6IK8iI8lbY=.0c03ce0e-587b-40f7-b145-5eb1a32c902f@github.com>

On Tue, 19 Apr 2022 17:44:10 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> These are the changes that too many to be reviewed in 8186958, thus split some of them out.

Would you consider replacing usages of `new HashMap<>(size, 1)`, such as in `AnnotationInvocationHandler`, as well? Such maps have a smaller table and are more likely to have collisions than `HashMap.newHashMap(size)`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301

From duke at openjdk.java.net  Wed Apr 20 18:32:22 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 18:32:22 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int) [v2]
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <vosOPRVEkanQrHXgADYyNl1zqUSskcEvnQKJsDt1lkE=.0f13b7c5-935c-4706-bfbe-338a2255a173@github.com>

> 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: https://git.openjdk.java.net/jdk/pull/8301/files
  - new: https://git.openjdk.java.net/jdk/pull/8301/files/2ac4d7bc..28afb90b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=00-01

  Stats: 109 lines in 64 files changed: 0 ins; 10 del; 99 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301

PR: https://git.openjdk.java.net/jdk/pull/8301

From duke at openjdk.java.net  Wed Apr 20 19:24:25 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 19:24:25 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int) [v3]
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <K5smO4U1soQAppd1LY9JqanDnB5mXk6GccdIh_0xrxQ=.44138af7-abb8-4a9d-9a21-9258befa0ee9@github.com>

> 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/jdk/pull/8301/files
  - new: https://git.openjdk.java.net/jdk/pull/8301/files/28afb90b..4f2d4838

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301

PR: https://git.openjdk.java.net/jdk/pull/8301

From ihse at openjdk.java.net  Thu Apr 21 11:30:48 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 21 Apr 2022 11:30:48 GMT
Subject: jmx-dev RFR: 8285366: Fix typos in serviceability
Message-ID: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>

I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.


I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).

The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

-------------

Commit messages:
 - Pass #2
 - Pass #1

Changes: https://git.openjdk.java.net/jdk/pull/8334/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8334&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285366
  Stats: 203 lines in 137 files changed: 0 ins; 0 del; 203 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8334.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8334/head:pull/8334

PR: https://git.openjdk.java.net/jdk/pull/8334

From dfuchs at openjdk.java.net  Thu Apr 21 14:06:36 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 21 Apr 2022 14:06:36 GMT
Subject: jmx-dev RFR: 8285366: Fix typos in serviceability
In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
Message-ID: <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com>

On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
> 
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

LGTM. I spotted one fix in a exception message. I don't expect that there will be tests depending on that, but it might still be a good idea to run the serviceability tests to double check. Although I guess the test would have had the same typo and would have been fixed too were it the case :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From ihse at openjdk.java.net  Thu Apr 21 15:40:28 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 21 Apr 2022 15:40:28 GMT
Subject: jmx-dev RFR: 8285366: Fix typos in serviceability
In-Reply-To: <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
 <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com>
Message-ID: <R3xjAu-kYS2cCP8laV7KJ-yPSiCZdFRndiW2fXeXb7k=.263b953f-2740-40c3-937c-83c6cac62d99@github.com>

On Thu, 21 Apr 2022 14:03:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
>> 
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> LGTM. I spotted one fix in a exception message. I don't expect that there will be tests depending on that, but it might still be a good idea to run the serviceability tests to double check. Although I guess the test would have had the same typo and would have been fixed too were it the case :-)

@dfuch I have only updated files in `src`, so if the incorrect spelling is tested, that test will now fail. I'm unfortunately not well versed in what tests cover serviceability code. Can you suggest a suitable set of tests to run?

And yes, ideally the tests should be spell checked as well. It's just that:
1) the product source is (imho) more important to begin with,
2) test comments are generally of a lower quality and more likely to contain more typos (imho), meaning even more work for me to publish a PR i believe is correct, and
3) the tests in the JDK are so intertwined and messy that I'm having a hard time understanding what groups to post reviews to. I could make one mega-PR touching the entire test code base, but I doubt it would be very popular. :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From kevinw at openjdk.java.net  Thu Apr 21 16:21:26 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 21 Apr 2022 16:21:26 GMT
Subject: jmx-dev RFR: 8285366: Fix typos in serviceability
In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
Message-ID: <qWssE0yWozCIm3dC8R-jRj6wzC-9wSNBKxPddBWQqPQ=.6946be24-6b22-4ed1-80a8-9f0a57c35f64@github.com>

On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
> 
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

All looks good to me, just the invokable which you might want to leave as is, unless there are other strong feelings. 8-)

src/jdk.jdwp.agent/share/native/libjdwp/invoker.h line 38:

> 36:     jboolean pending;      /* Is an invoke requested? */
> 37:     jboolean started;      /* Is an invoke happening? */
> 38:     jboolean available;    /* Is the thread in an invocable state? */

invocable could perhaps stay as invokable ?
Elsewhere we have a filename com/sun/tools/jdi/InvokableTypeImpl.java which we clearly don't want to change,  and I see Internet dictionary evidence of invokable being acceptable.

-------------

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8334

From dfuchs at openjdk.java.net  Thu Apr 21 16:34:29 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 21 Apr 2022 16:34:29 GMT
Subject: jmx-dev RFR: 8285366: Fix typos in serviceability
In-Reply-To: <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
 <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com>
Message-ID: <EoBxw8WGZhBJJWkHsOC6cRnC_mB95gukPslfoUr0Pmk=.b095085e-238f-4424-ba87-c940d4a229ca@github.com>

On Thu, 21 Apr 2022 14:03:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
>> 
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> LGTM. I spotted one fix in a exception message. I don't expect that there will be tests depending on that, but it might still be a good idea to run the serviceability tests to double check. Although I guess the test would have had the same typo and would have been fixed too were it the case :-)

> @dfuch I have only updated files in `src`, so if the incorrect spelling is tested, that test will now fail. I'm unfortunately not well versed in what tests cover serviceability code. Can you suggest a suitable set of tests to run?

Folks from serviceability-dev will be more able to answer that - but I would suggest running tier2-tier3 as a precaution.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From ihse at openjdk.java.net  Thu Apr 21 17:25:23 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 21 Apr 2022 17:25:23 GMT
Subject: jmx-dev RFR: 8285366: Fix typos in serviceability
In-Reply-To: <qWssE0yWozCIm3dC8R-jRj6wzC-9wSNBKxPddBWQqPQ=.6946be24-6b22-4ed1-80a8-9f0a57c35f64@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
 <qWssE0yWozCIm3dC8R-jRj6wzC-9wSNBKxPddBWQqPQ=.6946be24-6b22-4ed1-80a8-9f0a57c35f64@github.com>
Message-ID: <E3cvDYPFpkc9jORIcxO6REaQJ6NLBVRJXYDHekKwf1Y=.5d039bab-f1e5-4959-b63c-1b5143b92184@github.com>

On Thu, 21 Apr 2022 16:17:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
>> 
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> src/jdk.jdwp.agent/share/native/libjdwp/invoker.h line 38:
> 
>> 36:     jboolean pending;      /* Is an invoke requested? */
>> 37:     jboolean started;      /* Is an invoke happening? */
>> 38:     jboolean available;    /* Is the thread in an invocable state? */
> 
> invocable could perhaps stay as invokable ?
> Elsewhere we have a filename com/sun/tools/jdi/InvokableTypeImpl.java which we clearly don't want to change,  and I see Internet dictionary evidence of invokable being acceptable.

But on the other hand we have `javax.script.Invocable`. :-) 

Codespell suggested this change, and I based my decision to keep it based on [Merriam-Webster](https://www.merriam-webster.com/dictionary/invocable) not even listing "invokable" as an alternate spelling, and that "invocable" has about 3x the number of Google hits than "invokable". 

But sure, there is perhaps reason to consider "invokable" an acceptable alternative and keep it. I guess it depends on if you consider the word to be based on "invoke" with a suffix, or a latinized form, like "invocation". 

I'll wait a while for others to chime in, otherwise I'll revert the "invokable" changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From kevinw at openjdk.java.net  Thu Apr 21 18:11:29 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 21 Apr 2022 18:11:29 GMT
Subject: jmx-dev RFR: 8285366: Fix typos in serviceability
In-Reply-To: <E3cvDYPFpkc9jORIcxO6REaQJ6NLBVRJXYDHekKwf1Y=.5d039bab-f1e5-4959-b63c-1b5143b92184@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
 <qWssE0yWozCIm3dC8R-jRj6wzC-9wSNBKxPddBWQqPQ=.6946be24-6b22-4ed1-80a8-9f0a57c35f64@github.com>
 <E3cvDYPFpkc9jORIcxO6REaQJ6NLBVRJXYDHekKwf1Y=.5d039bab-f1e5-4959-b63c-1b5143b92184@github.com>
Message-ID: <xvcZ6swFp4vBB2HF9szyj4a_J0gELEFEh8Od2DSbrKg=.5332082e-c511-4468-8a23-e380877069a8@github.com>

On Thu, 21 Apr 2022 17:22:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/invoker.h line 38:
>> 
>>> 36:     jboolean pending;      /* Is an invoke requested? */
>>> 37:     jboolean started;      /* Is an invoke happening? */
>>> 38:     jboolean available;    /* Is the thread in an invocable state? */
>> 
>> invocable could perhaps stay as invokable ?
>> Elsewhere we have a filename com/sun/tools/jdi/InvokableTypeImpl.java which we clearly don't want to change,  and I see Internet dictionary evidence of invokable being acceptable.
>
> But on the other hand we have `javax.script.Invocable`. :-) 
> 
> Codespell suggested this change, and I based my decision to keep it based on [Merriam-Webster](https://www.merriam-webster.com/dictionary/invocable) not even listing "invokable" as an alternate spelling, and that "invocable" has about 3x the number of Google hits than "invokable". 
> 
> But sure, there is perhaps reason to consider "invokable" an acceptable alternative and keep it. I guess it depends on if you consider the word to be based on "invoke" with a suffix, or a latinized form, like "invocation". 
> 
> I'll wait a while for others to chime in, otherwise I'll revert the "invokable" changes.

Sure, I just thought there was enough evidence that invokable is not definitely wrong, even if invocable is more correct and popular, so it's not obvious it should be changed.  Don't lose sleep over it. 8-)

More importantly, on the tests -- I see the changes in exception messages searched for the wrong text in the test directories, and didn't find any matches that looked like checks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From cjplummer at openjdk.java.net  Thu Apr 21 20:24:29 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 21 Apr 2022 20:24:29 GMT
Subject: jmx-dev RFR: 8285366: Fix typos in serviceability
In-Reply-To: <EoBxw8WGZhBJJWkHsOC6cRnC_mB95gukPslfoUr0Pmk=.b095085e-238f-4424-ba87-c940d4a229ca@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
 <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com>
 <EoBxw8WGZhBJJWkHsOC6cRnC_mB95gukPslfoUr0Pmk=.b095085e-238f-4424-ba87-c940d4a229ca@github.com>
Message-ID: <ZEcDPIeEzMkagprPtPK-27vR80k4NOBWpvWOH9LAucM=.d451d890-25af-4206-8eb1-a99ef33f65cd@github.com>

On Thu, 21 Apr 2022 16:30:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > @dfuch I have only updated files in `src`, so if the incorrect spelling is tested, that test will now fail. I'm unfortunately not well versed in what tests cover serviceability code. Can you suggest a suitable set of tests to run?
> 
> Folks from serviceability-dev will be more able to answer that - but I would suggest running tier2-tier3 as a precaution.

I sent Magnus a PM with info on all the svc tests that can be run.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From sspitsyn at openjdk.java.net  Fri Apr 22 23:44:27 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 22 Apr 2022 23:44:27 GMT
Subject: jmx-dev RFR: 8285366: Fix typos in serviceability
In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
Message-ID: <jCPFRFJyh5d_fV1zY9l6PVhFnRpPun1YejB90ki0lM8=.2a7c19f6-0d5f-45a7-b9ec-a413b9028f08@github.com>

On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
> 
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Hi Magnus,
Great job, thank you for doing this!
It looks good to me.
These findings are pretty interesting.
Some are funny and some seems to be typical.
Good examples of typical typos are:
 - double letter instead of single
 - single or even triple letter instead of double
 
 Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8334

From serb at openjdk.java.net  Fri Apr 22 23:45:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Apr 2022 23:45:27 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int) [v3]
In-Reply-To: <K5smO4U1soQAppd1LY9JqanDnB5mXk6GccdIh_0xrxQ=.44138af7-abb8-4a9d-9a21-9258befa0ee9@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <K5smO4U1soQAppd1LY9JqanDnB5mXk6GccdIh_0xrxQ=.44138af7-abb8-4a9d-9a21-9258befa0ee9@github.com>
Message-ID: <c5sN9QCc34gf8MlSn2U5w6eEnJegb1CxrI9Vm06U3Yg=.3f23a70e-bf36-44df-a0ab-ff3c3b9d9447@github.com>

On Wed, 20 Apr 2022 19:24:25 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 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

src/demo/share/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java line 291:

> 289: 
> 290: 
> 291:     static HashMap strcache = HashMap.newHashMap(tscripts.length);

This code maintains compatibility with jdk1.4, not necessary to change it.

src/java.datatransfer/share/classes/java/awt/datatransfer/SystemFlavorMap.java line 815:

> 813:         }
> 814: 
> 815:         Map<String, DataFlavor> retval =HashMap.newHashMap(natives.length);

missed space after '='

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301

From dholmes at openjdk.java.net  Sat Apr 23 06:12:29 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 23 Apr 2022 06:12:29 GMT
Subject: jmx-dev RFR: 8285366: Fix typos in serviceability
In-Reply-To: <xvcZ6swFp4vBB2HF9szyj4a_J0gELEFEh8Od2DSbrKg=.5332082e-c511-4468-8a23-e380877069a8@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
 <qWssE0yWozCIm3dC8R-jRj6wzC-9wSNBKxPddBWQqPQ=.6946be24-6b22-4ed1-80a8-9f0a57c35f64@github.com>
 <E3cvDYPFpkc9jORIcxO6REaQJ6NLBVRJXYDHekKwf1Y=.5d039bab-f1e5-4959-b63c-1b5143b92184@github.com>
 <xvcZ6swFp4vBB2HF9szyj4a_J0gELEFEh8Od2DSbrKg=.5332082e-c511-4468-8a23-e380877069a8@github.com>
Message-ID: <i8HhcmdDFktsEGg93rAGBehfsoKxWAXjZpF1Rj-pVc8=.782315bc-a31a-4367-9435-1f1c14793b94@github.com>

On Thu, 21 Apr 2022 18:08:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> But on the other hand we have `javax.script.Invocable`. :-) 
>> 
>> Codespell suggested this change, and I based my decision to keep it based on [Merriam-Webster](https://www.merriam-webster.com/dictionary/invocable) not even listing "invokable" as an alternate spelling, and that "invocable" has about 3x the number of Google hits than "invokable". 
>> 
>> But sure, there is perhaps reason to consider "invokable" an acceptable alternative and keep it. I guess it depends on if you consider the word to be based on "invoke" with a suffix, or a latinized form, like "invocation". 
>> 
>> I'll wait a while for others to chime in, otherwise I'll revert the "invokable" changes.
>
> Sure, I just thought there was enough evidence that invokable is not definitely wrong, even if invocable is more correct and popular, so it's not obvious it should be changed.  Don't lose sleep over it. 8-)
> 
> More importantly, on the tests -- I saw the changes in exception messages, searched for the wrong text in the test directories, and didn't find any matches that looked like checks.

Invocable, Invokable and Invokeable are all used in practice. We have a mix of invocable and invokable throughout our codebase, with more of the former than the latter - and in prose "invocable" is probably best.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From duke at openjdk.java.net  Sat Apr 23 14:34:58 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Sat, 23 Apr 2022 14:34:58 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int) [v4]
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <zFlFjdt_WK9VyWsAxqnfhvu-MmJe1IKc7WtyBNkPE5A=.ec807db1-ad90-4e27-99d7-8a1ea145aa71@github.com>

> 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 after '='

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8301/files
  - new: https://git.openjdk.java.net/jdk/pull/8301/files/4f2d4838..684d1528

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301

PR: https://git.openjdk.java.net/jdk/pull/8301

From duke at openjdk.java.net  Sat Apr 23 14:35:00 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Sat, 23 Apr 2022 14:35:00 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int) [v3]
In-Reply-To: <c5sN9QCc34gf8MlSn2U5w6eEnJegb1CxrI9Vm06U3Yg=.3f23a70e-bf36-44df-a0ab-ff3c3b9d9447@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <K5smO4U1soQAppd1LY9JqanDnB5mXk6GccdIh_0xrxQ=.44138af7-abb8-4a9d-9a21-9258befa0ee9@github.com>
 <c5sN9QCc34gf8MlSn2U5w6eEnJegb1CxrI9Vm06U3Yg=.3f23a70e-bf36-44df-a0ab-ff3c3b9d9447@github.com>
Message-ID: <rdVSOTyOu5G4qCiqJvK5w1_8xBgS62FcEZzco7j6eGE=.15f860a9-c29b-4a15-bae9-ab373509e775@github.com>

On Fri, 22 Apr 2022 23:31:41 GMT, Sergey Bylokhov <serb at openjdk.org> 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/TextTests.java line 291:
> 
>> 289: 
>> 290: 
>> 291:     static HashMap strcache = HashMap.newHashMap(tscripts.length);
> 
> This code maintains compatibility with jdk1.4, not necessary to change it.

@mrserb done.

> src/java.datatransfer/share/classes/java/awt/datatransfer/SystemFlavorMap.java line 815:
> 
>> 813:         }
>> 814: 
>> 815:         Map<String, DataFlavor> retval =HashMap.newHashMap(natives.length);
> 
> missed space after '='

@mrserb done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301

From prr at openjdk.java.net  Wed Apr 27 04:39:43 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 04:39:43 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int) [v4]
In-Reply-To: <zFlFjdt_WK9VyWsAxqnfhvu-MmJe1IKc7WtyBNkPE5A=.ec807db1-ad90-4e27-99d7-8a1ea145aa71@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <zFlFjdt_WK9VyWsAxqnfhvu-MmJe1IKc7WtyBNkPE5A=.ec807db1-ad90-4e27-99d7-8a1ea145aa71@github.com>
Message-ID: <S9LU83ceTWEKtLvzA4D63u3Qysv4rk6f83rZ7QvfR5E=.936ea9b1-c42b-47c7-8a98-4c8803c67fe8@github.com>

On Sat, 23 Apr 2022 14:34:58 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 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 after '='

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 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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301

From duke at openjdk.java.net  Wed Apr 27 05:18:43 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 27 Apr 2022 05:18:43 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int) [v4]
In-Reply-To: <S9LU83ceTWEKtLvzA4D63u3Qysv4rk6f83rZ7QvfR5E=.936ea9b1-c42b-47c7-8a98-4c8803c67fe8@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <zFlFjdt_WK9VyWsAxqnfhvu-MmJe1IKc7WtyBNkPE5A=.ec807db1-ad90-4e27-99d7-8a1ea145aa71@github.com>
 <S9LU83ceTWEKtLvzA4D63u3Qysv4rk6f83rZ7QvfR5E=.936ea9b1-c42b-47c7-8a98-4c8803c67fe8@github.com>
Message-ID: <xW_IMRaU3A70QAxx5vnH990FVkxQnTq1EAf-F7rz3Nw=.17ca4b0e-ee2b-45bb-8cd1-c380bb6a0990@github.com>

On Wed, 27 Apr 2022 04:36:37 GMT, Phil Race <prr at openjdk.org> 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 = 10.

I felt my eyes widen and likes seeing a new world or something, then I suddenly notice that he the writer might not have the ability to use HashMap, but use it just as HashTable.

Nevermind.

> Delete all changes in desktop from this PR and re-submit them as a separate PR.
> 
> 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.

Will do 10+ hours later when I off work.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301

From duke at openjdk.java.net  Thu Apr 28 16:36:39 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 28 Apr 2022 16:36:39 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int) [v4]
In-Reply-To: <xW_IMRaU3A70QAxx5vnH990FVkxQnTq1EAf-F7rz3Nw=.17ca4b0e-ee2b-45bb-8cd1-c380bb6a0990@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <zFlFjdt_WK9VyWsAxqnfhvu-MmJe1IKc7WtyBNkPE5A=.ec807db1-ad90-4e27-99d7-8a1ea145aa71@github.com>
 <S9LU83ceTWEKtLvzA4D63u3Qysv4rk6f83rZ7QvfR5E=.936ea9b1-c42b-47c7-8a98-4c8803c67fe8@github.com>
 <xW_IMRaU3A70QAxx5vnH990FVkxQnTq1EAf-F7rz3Nw=.17ca4b0e-ee2b-45bb-8cd1-c380bb6a0990@github.com>
Message-ID: <4K3rhX2RGM_yaCKKJALcP7EplXS2pJXM8zYGNGEg-6Y=.c03f7730-b26a-459a-8d60-ea8ab9149603@github.com>

On Wed, 27 Apr 2022 05:11:54 GMT, XenoAmess <duke at openjdk.java.net> 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 version for now. please recheck. thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301

From duke at openjdk.java.net  Thu Apr 28 16:56:38 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 28 Apr 2022 16:56:38 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int) [v5]
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <vKFnwzOHGA2_EV-6k5nWOsrhZk2VOG8e-NIRVxdt8lk=.16f88bc5-87fe-4945-9978-f4ba1439ef9e@github.com>

> 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: https://git.openjdk.java.net/jdk/pull/8301/files
  - new: https://git.openjdk.java.net/jdk/pull/8301/files/684d1528..c9cfb50a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=03-04

  Stats: 56 lines in 30 files changed: 8 ins; 0 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301

PR: https://git.openjdk.java.net/jdk/pull/8301

From weijun at openjdk.java.net  Thu Apr 28 17:43:43 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 28 Apr 2022 17:43:43 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int) [v5]
In-Reply-To: <vKFnwzOHGA2_EV-6k5nWOsrhZk2VOG8e-NIRVxdt8lk=.16f88bc5-87fe-4945-9978-f4ba1439ef9e@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <vKFnwzOHGA2_EV-6k5nWOsrhZk2VOG8e-NIRVxdt8lk=.16f88bc5-87fe-4945-9978-f4ba1439ef9e@github.com>
Message-ID: <l6_Ksx45t5ahkJuwy7OzkuYtMzEwLYcb2Kzq7wkoE3c=.8d719712-3600-4688-8909-2eabc90682d5@github.com>

On Thu, 28 Apr 2022 16:56:38 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 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

src/java.base/share/classes/sun/security/rsa/SunRsaSignEntries.java line 58:

> 56:         // start populating content using the specified provider
> 57:         // common attribute map
> 58:         HashMap<String, String> attrs = HashMap.newHashMap(3);

Looks like 1 is enough.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301

From duke at openjdk.java.net  Thu Apr 28 18:07:36 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 28 Apr 2022 18:07:36 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int) [v6]
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <WJ5kczxQoTQXG_mbbibVt9GfzhPMZDds-RyVRlBdAO0=.3c80fbab-038e-447b-a1e4-01759199d96b@github.com>

> 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: https://git.openjdk.java.net/jdk/pull/8301/files
  - new: https://git.openjdk.java.net/jdk/pull/8301/files/c9cfb50a..1b4bac0f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301

PR: https://git.openjdk.java.net/jdk/pull/8301

From duke at openjdk.java.net  Thu Apr 28 18:07:37 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 28 Apr 2022 18:07:37 GMT
Subject: jmx-dev RFR: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int) [v5]
In-Reply-To: <l6_Ksx45t5ahkJuwy7OzkuYtMzEwLYcb2Kzq7wkoE3c=.8d719712-3600-4688-8909-2eabc90682d5@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <vKFnwzOHGA2_EV-6k5nWOsrhZk2VOG8e-NIRVxdt8lk=.16f88bc5-87fe-4945-9978-f4ba1439ef9e@github.com>
 <l6_Ksx45t5ahkJuwy7OzkuYtMzEwLYcb2Kzq7wkoE3c=.8d719712-3600-4688-8909-2eabc90682d5@github.com>
Message-ID: <dLQrR1ArbwoHp6fRARMGoQhPnAJ4hgFnp-73a-_Jz5s=.b9e88df7-ba41-472c-8efe-a63b5b0d9fe8@github.com>

On Thu, 28 Apr 2022 17:36:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Looks like 1 is enough.

@wangweij done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8301