From achung at openjdk.java.net  Wed Mar  9 21:16:48 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 9 Mar 2022 21:16:48 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
Message-ID: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>

msg drop for jdk19, Mar 9, 2022

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

Commit messages:
 - open jdk19 l10n msg drop

Changes: https://git.openjdk.java.net/jdk/pull/7765/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280400
  Stats: 13775 lines in 142 files changed: 12170 ins; 1249 del; 356 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

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

From naoto at openjdk.java.net  Wed Mar  9 22:29:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 9 Mar 2022 22:29:44 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <PBk3nk8e8eclzDy8yKIrJOgKLqveAK3NoSqrAzra6fg=.3dbfe55e-2394-4ee6-bd3b-43b558c02ef7@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

`src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties`
`src/java.base/share/classes/sun/util/resources/CurrencyNames_ja.properties`
`src/java.base/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties`

These are part of `jdk.localedata` module. Should be excluded from `java.base` module and apply the diffs to `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_xx.properties` manually. (Note that the first half of it is not necessary when merging).

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

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

From joehw at openjdk.java.net  Thu Mar 10 00:46:44 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 10 Mar 2022 00:46:44 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <8oYKi_L4IgNDFUfJ9uXlSl47KULO4j1HudfJg3kVeCU=.90fa019e-8b6f-4a69-870b-cd53c8802490@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

For the bundles in java.xml:

For files with Oracle copyright, update the year to 2022 and @LastModified Mar 2022. Take XPATHErrorResources_ja.java as an example, the copyright year was updated to 2021 and @LastModified: Nov 2021. That's probably the date it was last modified, but as we updating them now along with a number of other files, it would be good to be consistent and change all of them to the current date.

For files with the reserved comment block such as SerializerMessages_de.java, do the same as did in XPATHErrorResources_de.java, add the copyright header and LastModified tag with the current date. 

For files with the Oracle GPL license such as message_zh_CN.properties, do not delete the license header. Instead, update the copyright year to 2022 if there are changes. I don't see any changes were made for many of these files, for example from msg/XMLSchemaMessages_ja.properties to regex/message_zh_CN.properties, the only change was the removal of the header.

In the webrev view, some files have the word "undefined" right under the license header, hopefully once the license header is fixed, that would go away as well.

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

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

From dfuchs at openjdk.java.net  Thu Mar 10 10:34:43 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 10:34:43 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <p1RcBIafcDBf0k6FeY60oiHc94CG5wc5mJMDaNAO7js=.1bce7a1c-81cd-475d-bcbb-4423a5040b6b@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

For simple webserver resource files - should the copyright year be 2022?

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

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

From naoto at openjdk.java.net  Thu Mar 10 17:03:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Mar 2022 17:03:45 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <TdJhSkQwWvukmhDKrxi5K9E0-pzh1UxqBFSKi0a1r18=.3eb1eada-4b4e-4856-85df-a1c7d04f92ed@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment.

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

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

From dfuchs at openjdk.java.net  Thu Mar 10 17:09:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 17:09:44 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <TdJhSkQwWvukmhDKrxi5K9E0-pzh1UxqBFSKi0a1r18=.3eb1eada-4b4e-4856-85df-a1c7d04f92ed@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <TdJhSkQwWvukmhDKrxi5K9E0-pzh1UxqBFSKi0a1r18=.3eb1eada-4b4e-4856-85df-a1c7d04f92ed@github.com>
Message-ID: <eFN7SFB4835Ai-NMuO6yzfs0cdy5aM90VdU3qr7ctpQ=.52d046e1-33b6-407f-905f-1ca762f286d7@github.com>

On Thu, 10 Mar 2022 17:00:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment.

Thanks Naoto! I have no objection then.

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

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

From achung at openjdk.java.net  Thu Mar 10 17:55:44 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 10 Mar 2022 17:55:44 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  moved CurrencyNames changes to jdk.localedata

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/fb51cf60..4735722d

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

  Stats: 2807 lines in 6 files changed: 693 ins; 1527 del; 587 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

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

From cjplummer at openjdk.java.net  Thu Mar 10 19:06:43 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 10 Mar 2022 19:06:43 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 305:

> 303:         {"Thread not suspended", "Thread nicht unterbrochen"},
> 304:         {"thread group number description name", "{0,number,integer}. {1} {2}"},
> 305:         {"Threadgroup name not specified.", "Name der Threadgruppe nicht angegeben."},

Same comment here as mentioned in TTYResources_ja.java.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 342:

> 340:         {"watch modification of", "\u00C4nderung von {0}.{1} \u00FCberwachen"},
> 341:         {"zz help text",
> 342:              "** Befehlsliste **\nconnectors                -- Listet verf\u00FCgbare Connectors und Transporte in dieser VM auf\n\nrun [class [args]]        -- Startet die Ausf\u00FChrung der Hauptklasse der Anwendung\n\nthreads [threadgroup]     -- Listet Threads auf\nthread <Thread-ID>        -- Legt den Standardthread fest\nsuspend [thread id(s)]    -- Unterbricht Threads (Standard: all)\nresume [thread id(s)]    -- Nimmt Threads wieder auf (Standard: all)\nwhere [<Thread-ID> | all] -- Gibt den Stack eines Threads aus\nwherei [<Thread-ID> | all] -- Gibt den Stack eines Threads mit PC-Informationen aus\nup [n frames]             -- Verschiebt den Stack eines Threads nach oben\ndown [n frames]             -- Verschiebt den Stack eines Threads nach unten\nkill <Thread-ID> <Ausdruck>   -- Bricht einen Thread mit dem angegebenen Ausnahmeobjekt ab\ninterrupt <Thread-ID>     -- Unterbricht einen Thread\n\nprint <Ausdruck>              -- Gibt den Wert eines Ausdrucks aus\ndump <A
 usdruck>               -- Gibt alle Objektinformationen aus\neval <Ausdruck>               -- Bewertet einen Ausdruck (wie \"print\")\nset <lvalue> = <Ausdruck>     -- Weist einem Feld/einer Variablen/einem Arrayelement einen neuen Wert zu\nlocals                    -- Gibt alle lokalen Variablen im aktuellen Stackframe aus\n\nclasses                   -- Listet derzeit bekannte Klassen auf\nclass <Klassen-ID>          -- Zeigt Details einer benannten Klasse an\nmethods <Klassen-ID>        -- Listet die Methoden einer Klasse auf\nfields <Klassen-ID>        -- Listet die Felder einer Klasse auf\n\nthreadgroups              -- Listet Threadgruppen auf\nthreadgroup <Name>        -- Legt die aktuelle Threadgruppe fest\n\nstop [go|thread] [<thread_id>] <at|in> <Position>\n                          -- Legt einen Breakpoint fest\n                          -- Wenn Sie keine Optionen angeben, wird die aktuelle Breakpoint-Liste ausgegeben\n                          -- Wenn Sie \"go\" angeben,
  wird der Vorgang nach dem Stoppen sofort wiederaufgenommen\n                          -- Wenn Sie \"thread\" angeben, wird nur der Thread unterbrochen, in dem gestoppt wurde\n                          -- Wenn Sie weder \"go\" noch \"thread\" angeben, werden alle Threads unterbrochen\n                          -- Wenn Sie eine ganzzahlige <thread_id> angeben, wird der Vorgang nur im angegebenen Thread gestoppt\n                          -- \"at\" und \"in\" haben die gleiche Bedeutung\n                          -- <Position> kann eine Zeilennummer oder eine Methode sein:\n                          --   <class_id>:<line_number>\n                          --   <class_id>.<Methode>[(argument_type,...)]\nclear <class id>.<Methode>[(argument_type,...)]\n                          -- L\u00F6scht einen Breakpoint in einer Methode\nclear <Klassen-ID>:<Zeile>   -- L\u00F6scht einen Breakpoint bei einer Zeile\nclear                     -- Listet Breakpoints auf\ncatch [uncaught|caught|all] <Kl
 assen-ID>|<Klassenmuster>\n                          -- Break bei der angegebenen Ausnahme\nignore [uncaught|caught|all] <Klassen-ID>|<Klassenmuster>\n                          -- Bricht \"catch\" f\u00FCr die angegebene Ausnahme ab\nwatch [access|all] <Klassen-ID>.<Feldname>\n                          -- \u00DCberwacht Zugriffe/\u00C4nderungen eines Feldes\nunwatch [access|all] <Klassen-ID>.<Feldname>\n                          -- Hebt die \u00DCberwachung der Zugriffe/\u00C4nderungen eines Feldes auf\ntrace [go] methods [thread]\n                          -- Verfolgt Methodenstarts und -beendigungen.\n                          -- Alle Threads werden unterbrochen, es sei denn, \"go\" ist angegeben\ntrace [go] method exit | exits [thread]\n                          -- Verfolgt die Beendigung der aktuellen Methode oder die Beendigungen aller Methoden\n                          -- Alle Threads werden unterbrochen, es sei denn, \"go\" ist angegeben\nuntrace [methods]         -- Stoppt 
 das Tracing von Methodenstarts und/oder -beendigungen\nstep                      -- F\u00FChrt die aktuelle Zeile aus\nstep up                   -- Ausf\u00FChren, bis die aktuelle Methode an den Aufrufer zur\u00FCckgegeben wird\nstepi                     -- F\u00FChrt die aktuelle Anweisung aus\nnext                      -- Eine Zeile weiter (Aufrufe auslassen)\ncont                      -- Setzt die Ausf\u00FChrung ab dem Breakpoint fort\n\nlist [line number|method] -- Gibt den Quellcode aus\nuse (or sourcepath) [source file path]\n                          -- Zeigt den Quellpfad an oder \u00E4ndert diesen\nexclude [<Klassenmuster>, ... | \"none\"]\n                          -- Meldet keine Schritt- oder Methodenereignisse f\u00FCr angegebene Klassen\nclasspath                 -- Gibt Classpath-Informationen aus der Ziel-VM aus\n\nmonitor <Befehl>         -- F\u00FChrt bei jedem Programmstopp einen Befehl aus\nmonitor                   -- Listet Monitore auf\nunmonitor <Monitornum
 mer>      -- L\u00F6scht einen Monitor\nread <Dateiname>           -- Liest eine Befehlsdatei und f\u00FChrt diese aus\n\nlock <Ausdruck>               -- Gibt Sperrinformationen f\u00FCr ein Objekt aus\nthreadlocks [thread id]   -- Gibt Sperrinformationen f\u00FCr einen Thread aus\n\npop                       -- Holt den Stack bis zum aktuellen Frame (einschlie\u00DFlich)\nreenter                   -- Wie \"pop\", aber der aktuelle Frame wird wieder eingegeben\nredefine <Klassen-ID> <Klassendateiname>\n                          -- Definiert den Code f\u00FCr eine Klasse neu\n\ndisablegc <Ausdruck>          -- Verhindert die Garbage Collection eines Objekts\nenablegc <Ausdruck>          -- L\u00E4sst die Garbage Collection eines Objekts zu\n\n!!                        -- Wiederholt den letzten Befehl\n<n> <Befehl>             -- Wiederholt einen Befehl n-mal\nrepeat                    -- Zeigt an, ob die Wiederholung durch leeren Befehl im GDB-Stil aktiviert ist\nrepeat <on|off>    
        -- Aktiviert/deaktiviert die Wiederholung im GDB-Stil\n# <Befehl>               -- Verwerfen (kein Vorgang)\nhelp (oder ?)               -- Listet Befehle auf\ndbgtrace [flag]           -- Identisch mit der Befehlszeilenoption \"dbgtrace\"\nversion                   -- Gibt Versionsinformationen aus\nexit (oder quit)            -- Beendet den Debugger\n\n<Klassen-ID>: Ein vollst\u00E4ndiger Klassenname mit Package-Qualifiers\n<Klassenmuster>: Ein Klassenname mit einem Platzhalter am Anfang oder Ende (\"*\")\n<Thread-ID>: Threadnummer aus dem Befehl \"threads\"\n<Ausdruck>: Ein Ausdruck der Java(TM)-Programmiersprache.\nDer Gro\u00DFteil der g\u00E4ngigen Syntax wird unterst\u00FCtzt.\n\nStartbefehle k\u00F6nnen in \"jdb.ini\" oder \".jdbrc\" abgelegt werden\nin user.home oder user.dir"},

Same comment here as mentioned in TTYResources_ja.java.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 305:

> 303:         {"Thread not suspended", "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"},
> 304:         {"thread group number description name", "{0,number,integer}. {1} {2}"},
> 305:         {"Threadgroup name not specified.", "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"},

I'm not sure what happened here. This resource was just removed yesterday as part of #7687. It had been around for a long time before that (probably from the beginning of this file), so I'm not sure what triggered getting it re-added.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 342:

> 340:         {"watch modification of", "{0}.{1}\u306E\u5909\u66F4\u306E\u30A6\u30A9\u30C3\u30C1"},
> 341:         {"zz help text",
> 342:              "** \u30B3\u30DE\u30F3\u30C9\u30FB\u30EA\u30B9\u30C8 **\nconnectors                -- \u3053\u306EVM\u5185\u306E\u4F7F\u7528\u53EF\u80FD\u306A\u30B3\u30CD\u30AF\u30BF\u3068\u30C8\u30E9\u30F3\u30B9\u30DD\u30FC\u30C8\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\n\nrun [class [args]]        -- \u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u306E\u30E1\u30A4\u30F3\u30FB\u30AF\u30E9\u30B9\u306E\u5B9F\u884C\u3092\u958B\u59CB\u3057\u307E\u3059\n\nthreads [threadgroup]     -- \u30B9\u30EC\u30C3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nthread <thread id>        -- \u30C7\u30D5\u30A9\u30EB\u30C8\u306E\u30B9\u30EC\u30C3\u30C9\u3092\u8A2D\u5B9A\u3057\u307E\u3059\nsuspend [thread id(s)]    -- \u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059(\u30C7\u30D5\u30A9\u30EB\u30C8: \u3059\u3079\u3066)\nresume [thread id(s)]     -- \u30B9\u30EC\u30C3\u30C9\u3092\u518D\u958B\u3057\u307E\u3059(\u30C7\u30D5\u30A9\u30EB\u30C8: \u3059\u3079\u3066)\nwhere [<thread id> | all]
  -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u30C0\u30F3\u30D7\u3057\u307E\u3059\nwherei [<thread id> | all]-- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092pc\u60C5\u5831\u3068\u3068\u3082\u306B\u30C0\u30F3\u30D7\u3057\u307E\u3059\nup [n frames]             -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u4E0A\u306B\u79FB\u52D5\u3057\u307E\u3059\ndown [n frames]           -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u4E0B\u306B\u79FB\u52D5\u3057\u307E\u3059\nkill <thread id> <expr>   -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u3067\u30B9\u30EC\u30C3\u30C9\u3092\u5F37\u5236\u7D42\u4E86\u3057\u307E\u3059\ninterrupt <thread id>     -- \u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059\n\nprint <expr>              -- \u5F0F\u306E\u5024\u3092\u51FA\u529B\u3057\u307E\u3059\ndump <expr>               -- \u3059\u3079\u3066\u306E\u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u60C5\u58
 31\u3092\u51FA\u529B\u3057\u307E\u3059\neval <expr>               -- \u5F0F\u3092\u8A55\u4FA1\u3057\u307E\u3059(print\u3068\u540C\u3058)\nset <lvalue> = <expr>     -- \u65B0\u3057\u3044\u5024\u3092\u30D5\u30A3\u30FC\u30EB\u30C9/\u5909\u6570/\u914D\u5217\u8981\u7D20\u306B\u4EE3\u5165\u3057\u307E\u3059\nlocals                    -- \u73FE\u5728\u306E\u30B9\u30BF\u30C3\u30AF\u30FB\u30D5\u30EC\u30FC\u30E0\u5185\u306E\u3059\u3079\u3066\u306E\u30ED\u30FC\u30AB\u30EB\u5909\u6570\u3092\u51FA\u529B\u3057\u307E\u3059\n\nclasses                   -- \u73FE\u5728\u65E2\u77E5\u306E\u30AF\u30E9\u30B9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nclass <class id>          -- \u6307\u5B9A\u3057\u305F\u30AF\u30E9\u30B9\u306E\u8A73\u7D30\u3092\u8868\u793A\u3057\u307E\u3059\nmethods <class id>        -- \u30AF\u30E9\u30B9\u306E\u30E1\u30BD\u30C3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nfields <class id>         -- \u30AF\u30E9\u30B9\u306E\u30D5\u30A3\u30FC\u30EB\u30C9\u3092\u30EA\u30B9\u30C8\u305
 7\u307E\u3059\n\nthreadgroups              -- \u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nthreadgroup <name>        -- \u73FE\u5728\u306E\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u3092\u8A2D\u5B9A\u3057\u307E\u3059\n\nstop [go|thread] [<thread_id>] <at|in> <location>\n                          -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u8A2D\u5B9A\u3057\u307E\u3059\n                          -- \u30AA\u30D7\u30B7\u30E7\u30F3\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u306A\u3044\u5834\u5408\u306F\u3001\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u306E\u73FE\u5728\u306E\u30EA\u30B9\u30C8\u304C\u51FA\u529B\u3055\u308C\u307E\u3059\n                          -- \"go\"\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u505C\u6B62\u5F8C\u3059\u3050\u306B\u518D\u958B\u3057\u307E\u3059\n                          -- \"thread\"\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\
 u505C\u6B62\u3057\u305F\u30B9\u30EC\u30C3\u30C9\u306E\u307F\u4E2D\u65AD\u3057\u307E\u3059\n                          -- \"go\"\u3082\"thread\"\u3082\u6307\u5B9A\u3055\u308C\u3066\u3044\u306A\u3044\u5834\u5408\u306F\u3001\u3059\u3079\u3066\u306E\u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059\n                          -- \u6574\u6570\u306E<thread_id>\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u6307\u5B9A\u3055\u308C\u305F\u30B9\u30EC\u30C3\u30C9\u3067\u306E\u307F\u505C\u6B62\u3057\u307E\u3059\n                          -- \"at\"\u3068\"in\"\u306F\u540C\u3058\u610F\u5473\u3092\u6301\u3061\u307E\u3059\n                          -- <location>\u306F\u884C\u756A\u53F7\u307E\u305F\u306F\u30E1\u30BD\u30C3\u30C9\u306B\u3059\u308B\u3053\u3068\u304C\u3067\u304D\u307E\u3059:\n                          --   <class_id>:<line_number>\n                          --   <class_id>.<method>[(argument_type,...)]\nclear <class id>.<method>[(argument_type,...)]\n  
                         -- \u30E1\u30BD\u30C3\u30C9\u5185\u306E\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30AF\u30EA\u30A2\u3057\u307E\u3059\nclear <class id>:<line>   -- \u884C\u306E\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30AF\u30EA\u30A2\u3057\u307E\u3059\nclear                     -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\ncatch [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u304C\u767A\u751F\u3057\u305F\u3068\u304D\u306B\u30D6\u30EC\u30FC\u30AF\u3057\u307E\u3059\nignore [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u306E'catch'\u3092\u53D6\u308A\u6D88\u3057\u307E\u3059\nwatch [access|all] <class id>.<field name>\n                          -- \u30D5\u30A3\u30FC\u30EB\u30C9\u3078\u306E\u30A2\u30AF\u30BB\u30B9\u307E\u305F\u306F\u5909\u66F4\u3092\u30A6\u3
 0A9\u30C3\u30C1\u3057\u307E\u3059\nunwatch [access|all] <class id>.<field name>\n                          -- \u30D5\u30A3\u30FC\u30EB\u30C9\u3078\u306E\u30A2\u30AF\u30BB\u30B9\u307E\u305F\u306F\u5909\u66F4\u306E\u30A6\u30A9\u30C3\u30C1\u3092\u4E2D\u6B62\u3057\u307E\u3059\ntrace [go] methods [thread]\n                          -- \u30E1\u30BD\u30C3\u30C9\u306E\u5165\u308A\u53E3\u3068\u51FA\u53E3\u3092\u30C8\u30EC\u30FC\u30B9\u3057\u307E\u3059\u3002\n                          -- 'go'\u304C\u6307\u5B9A\u3055\u308C\u308B\u307E\u3067\u3059\u3079\u3066\u306E\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u307E\u3059\ntrace [go] method exit | exits [thread]\n                          -- \u73FE\u5728\u306E\u30E1\u30BD\u30C3\u30C9\u306E\u51FA\u53E3\u307E\u305F\u306F\u3059\u3079\u3066\u306E\u30E1\u30BD\u30C3\u30C9\u306E\u51FA\u53E3\u3092\u30C8\u30EC\u30FC\u30B9\u3057\u307E\u3059\n                          -- 'go'\u304C\u6307\u5B9A\u3055\u308C\u308B\u307E\u3067\u3059\u3079\u3066\u306E\u30B9\
 u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u307E\u3059\nuntrace [methods]         -- \u30E1\u30BD\u30C3\u30C9\u306E\u958B\u59CB\u307E\u305F\u306F\u7D42\u4E86\u306E\u30C8\u30EC\u30FC\u30B9\u3092\u505C\u6B62\u3057\u307E\u3059\nstep                      -- \u73FE\u5728\u306E\u884C\u3092\u5B9F\u884C\u3057\u307E\u3059\nstep up                   -- \u73FE\u5728\u306E\u30E1\u30BD\u30C3\u30C9\u304C\u30E1\u30BD\u30C3\u30C9\u306E\u547C\u51FA\u3057\u5143\u306B\u623B\u308B\u307E\u3067\u5B9F\u884C\u3057\u307E\u3059\nstepi                     -- \u73FE\u5728\u306E\u547D\u4EE4\u3092\u5B9F\u884C\u3057\u307E\u3059\nnext                      -- 1\u884C\u3092\u30B9\u30C6\u30C3\u30D7\u5B9F\u884C\u3057\u307E\u3059(\u547C\u51FA\u3057\u3092\u30B9\u30C6\u30C3\u30D7\u30AA\u30FC\u30D0\u30FC)\ncont                      -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u304B\u3089\u5B9F\u884C\u3092\u7D9A\u884C\u3057\u307E\u3059\n\nlist [line number|method] -- \u30BD\u30FC\u30B9\u30FB\u30B3\u30FC\u30C9\u3092\u
 51FA\u529B\u3057\u307E\u3059\nuse (or sourcepath) [source file path]\n                          -- \u30BD\u30FC\u30B9\u30FB\u30D1\u30B9\u3092\u8868\u793A\u307E\u305F\u306F\u5909\u66F4\u3057\u307E\u3059\nexclude [<class pattern>, ... | \"none\"]\n                          -- \u6307\u5B9A\u3057\u305F\u30AF\u30E9\u30B9\u306E\u30B9\u30C6\u30C3\u30D7\u3084\u30E1\u30BD\u30C3\u30C9\u30FB\u30A4\u30D9\u30F3\u30C8\u3092\u5831\u544A\u3057\u307E\u305B\u3093\nclasspath                 -- \u30BF\u30FC\u30B2\u30C3\u30C8VM\u304B\u3089\u30AF\u30E9\u30B9\u30D1\u30B9\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\n\nmonitor <command>         -- \u30D7\u30ED\u30B0\u30E9\u30E0\u304C\u505C\u6B62\u3059\u308B\u305F\u3073\u306B\u30B3\u30DE\u30F3\u30C9\u3092\u5B9F\u884C\u3057\u307E\u3059\nmonitor                   -- \u30E2\u30CB\u30BF\u30FC\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nunmonitor <monitor#>      -- \u30E2\u30CB\u30BF\u30FC\u3092\u524A\u9664\u3057\u307E\u3059\nread <filename>           -- \u30B
 3\u30DE\u30F3\u30C9\u30FB\u30D5\u30A1\u30A4\u30EB\u3092\u8AAD\u307F\u53D6\u3063\u3066\u5B9F\u884C\u3057\u307E\u3059\n\nlock <expr>               -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30ED\u30C3\u30AF\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\nthreadlocks [thread id]   -- \u30B9\u30EC\u30C3\u30C9\u306E\u30ED\u30C3\u30AF\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\n\npop                       -- \u73FE\u5728\u306E\u30D5\u30EC\u30FC\u30E0\u307E\u3067\u306E\u3059\u3079\u3066\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u30DD\u30C3\u30D7\u3057\u307E\u3059\nreenter                   -- pop\u3068\u540C\u3058\u3067\u3059\u304C\u3001\u73FE\u5728\u306E\u30D5\u30EC\u30FC\u30E0\u304C\u518D\u5165\u529B\u3055\u308C\u307E\u3059\nredefine <class id> <class file name>\n                          -- \u30AF\u30E9\u30B9\u306E\u30B3\u30FC\u30C9\u3092\u518D\u5B9A\u7FA9\u3057\u307E\u3059\n\ndisablegc <expr>          -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30AC\u30D9\u30FC\u30B8\u30FB\u30B3
 \u30EC\u30AF\u30B7\u30E7\u30F3\u3092\u6291\u5236\u3057\u307E\u3059\nenablegc <expr>           -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30AC\u30D9\u30FC\u30B8\u30FB\u30B3\u30EC\u30AF\u30B7\u30E7\u30F3\u3092\u8A31\u53EF\u3057\u307E\u3059\n\n!!                        -- \u6700\u5F8C\u306E\u30B3\u30DE\u30F3\u30C9\u3092\u7E70\u308A\u8FD4\u3057\u307E\u3059\n<n> <command>             -- \u30B3\u30DE\u30F3\u30C9\u3092n\u56DE\u7E70\u308A\u8FD4\u3057\u307E\u3059\nrepeat                    -- GDB\u5F62\u5F0F\u306E\u7A7A\u306E\u30B3\u30DE\u30F3\u30C9\u306E\u7E70\u8FD4\u3057\u304C\u6709\u52B9\u306B\u306A\u3063\u3066\u3044\u308B\u304B\u3069\u3046\u304B\u3092\u793A\u3057\u307E\u3059\nrepeat <on|off>           -- GDB\u5F62\u5F0F\u306E\u7E70\u8FD4\u3057\u3092\u6709\u52B9/\u7121\u52B9\u306B\u3057\u307E\u3059\n# <command>               -- \u7834\u68C4\u3057\u307E\u3059(\u64CD\u4F5C\u306A\u3057)\nhelp (\u307E\u305F\u306F?)               -- \u30B3\u30DE\u30F3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u3
 07E\u3059\ndbgtrace [flag]           -- dbgtrace\u30B3\u30DE\u30F3\u30C9\u30FB\u30E9\u30A4\u30F3\u30FB\u30AA\u30D7\u30B7\u30E7\u30F3\u3068\u540C\u3058\u3067\u3059\nversion                   -- \u30D0\u30FC\u30B8\u30E7\u30F3\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\nexit (\u307E\u305F\u306Fquit)            -- \u30C7\u30D0\u30C3\u30AC\u3092\u7D42\u4E86\u3057\u307E\u3059\n\n<class id>: \u30D1\u30C3\u30B1\u30FC\u30B8\u4FEE\u98FE\u5B50\u3092\u542B\u3080\u5B8C\u5168\u30AF\u30E9\u30B9\u540D\n<class pattern>: \u5148\u982D\u307E\u305F\u306F\u672B\u5C3E\u306E\u30EF\u30A4\u30EB\u30C9\u30AB\u30FC\u30C9('*')\u3092\u542B\u3080\u30AF\u30E9\u30B9\u540D\n<thread id>: 'threads'\u30B3\u30DE\u30F3\u30C9\u3067\u5831\u544A\u3055\u308C\u308B\u30B9\u30EC\u30C3\u30C9\u756A\u53F7\n<expr>: Java(TM)\u30D7\u30ED\u30B0\u30E9\u30DF\u30F3\u30B0\u8A00\u8A9E\u306E\u5F0F\u3002\n\u307B\u3068\u3093\u3069\u306E\u4E00\u822C\u7684\u306A\u69CB\u6587\u304C\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u307E\u3059\u
 3002\n\n\u8D77\u52D5\u30B3\u30DE\u30F3\u30C9\u306F\u3001\"jdb.ini\"\u307E\u305F\u306F\".jdbrc\"\u306B\u914D\u7F6E\u3067\u304D\u307E\u3059\n(user.home\u307E\u305F\u306Fuser.dir\u5185)"},

Also as part of #7687 there is a new entry for the `threadgroup` command without any argument. This used to produce the "Threadgroup name not specified" error message which is I mentioned above was removed. It now has supported functionality, so there should be two `threadgroup` entries:

             "threadgroup <name>        -- set current threadgroup to <name>\n" +
             "threadgroup               -- set current threadgroup back to the top level threadgroup\n" +

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java line 305:

> 303:         {"Thread not suspended", "\u672A\u6302\u8D77\u7EBF\u7A0B"},
> 304:         {"thread group number description name", "{0,number,integer}\u3002{1} {2}"},
> 305:         {"Threadgroup name not specified.", "\u672A\u6307\u5B9A\u7EBF\u7A0B\u7EC4\u540D\u3002"},

Same comment here as mentioned in TTYResources_ja.java.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java line 342:

> 340:         {"watch modification of", "\u76D1\u89C6{0}.{1}\u7684\u4FEE\u6539"},
> 341:         {"zz help text",
> 342:              "** \u547D\u4EE4\u5217\u8868 **\nconnectors                -- \u5217\u51FA\u6B64 VM \u4E2D\u53EF\u7528\u7684\u8FDE\u63A5\u5668\u548C\u4F20\u8F93\n\nrun [class [args]]        -- \u5F00\u59CB\u6267\u884C\u5E94\u7528\u7A0B\u5E8F\u7684\u4E3B\u7C7B\n\nthreads [threadgroup]     -- \u5217\u51FA\u7EBF\u7A0B\nthread <thread id>        -- \u8BBE\u7F6E\u9ED8\u8BA4\u7EBF\u7A0B\nsuspend [thread id(s)]    -- \u6302\u8D77\u7EBF\u7A0B (\u9ED8\u8BA4\u503C: all)\nresume [thread id(s)]     -- \u6062\u590D\u7EBF\u7A0B (\u9ED8\u8BA4\u503C: all)\nwhere [<thread id> | all] -- \u8F6C\u50A8\u7EBF\u7A0B\u7684\u5806\u6808\nwherei [<thread id> | all]-- \u8F6C\u50A8\u7EBF\u7A0B\u7684\u5806\u6808, \u4EE5\u53CA pc \u4FE1\u606F\nup [n frames]             -- \u4E0A\u79FB\u7EBF\u7A0B\u7684\u5806\u6808\ndown [n frames]           -- \u4E0B\u79FB\u7EBF\u7A0B\u7684\u5806\u6808\nkill <thread id> <expr>   -- \u7EC8\u6B62\u5177\u6709\u7ED9\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF\u5BF9\u8C61\u7684\u7EBF\u7A0B
 \ninterrupt <thread id>     -- \u4E2D\u65AD\u7EBF\u7A0B\n\nprint <expr>              -- \u8F93\u51FA\u8868\u8FBE\u5F0F\u7684\u503C\ndump <expr>               -- \u8F93\u51FA\u6240\u6709\u5BF9\u8C61\u4FE1\u606F\neval <expr>               -- \u5BF9\u8868\u8FBE\u5F0F\u6C42\u503C (\u4E0E print \u76F8\u540C)\nset <lvalue> = <expr>     -- \u5411\u5B57\u6BB5/\u53D8\u91CF/\u6570\u7EC4\u5143\u7D20\u5206\u914D\u65B0\u503C\nlocals                    -- \u8F93\u51FA\u5F53\u524D\u5806\u6808\u5E27\u4E2D\u7684\u6240\u6709\u672C\u5730\u53D8\u91CF\n\nclasses                   -- \u5217\u51FA\u5F53\u524D\u5DF2\u77E5\u7684\u7C7B\nclass <class id>          -- \u663E\u793A\u5DF2\u547D\u540D\u7C7B\u7684\u8BE6\u7EC6\u8D44\u6599\nmethods <class id>        -- \u5217\u51FA\u7C7B\u7684\u65B9\u6CD5\nfields <class id>         -- \u5217\u51FA\u7C7B\u7684\u5B57\u6BB5\n\nthreadgroups              -- \u5217\u51FA\u7EBF\u7A0B\u7EC4\nthreadgroup <name>        -- \u8BBE\u7F6E\u5F53\u524D\u7EBF\u7A0B\u7EC4\n\nstop [go|
 thread] [<thread_id>] <at|in> <location>\n                          -- \u8BBE\u7F6E\u65AD\u70B9\n                          -- \u5982\u679C\u672A\u63D0\u4F9B\u4EFB\u4F55\u9009\u9879\uFF0C\u5219\u5C06\u6253\u5370\u5F53\u524D\u65AD\u70B9\u5217\u8868\n                          -- \u5982\u679C\u6307\u5B9A \"go\"\uFF0C\u5219\u5728\u505C\u6B62\u540E\u7ACB\u5373\u6062\u590D\n                          -- \u5982\u679C\u6307\u5B9A \"thread\"\uFF0C\u5219\u4EC5\u6302\u8D77\u5728\u5176\u4E2D\u505C\u6B62\u7684\u7EBF\u7A0B\n                          -- \u5982\u679C\u65E2\u672A\u6307\u5B9A \"go\" \u4E5F\u672A\u6307\u5B9A \"thread\"\uFF0C\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\n                          -- \u5982\u679C\u6307\u5B9A\u4EE5\u6574\u6570\u8868\u793A\u7684 <thread_id>\uFF0C\u5219\u4EC5\u5728\u6307\u5B9A\u7684\u7EBF\u7A0B\u4E2D\u505C\u6B62\n                          -- \"at\" \u548C \"in\" \u7684\u542B\u4E49\u76F8\u540C\n                          -- <location> \u53EF\u4EE5\u662F\u884C\u53
 F7\u6216\u65B9\u6CD5\uFF1A\n                          --   <class_id>:<line_number>\n                          --   <class_id>.<method>[(argument_type,...)]\nclear <class id>.<method>[(argument_type,...)]\n                          -- \u6E05\u9664\u65B9\u6CD5\u4E2D\u7684\u65AD\u70B9\nclear <class id>:<line>   -- \u6E05\u9664\u884C\u4E2D\u7684\u65AD\u70B9\nclear                     -- \u5217\u51FA\u65AD\u70B9\ncatch [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u51FA\u73B0\u6307\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF\u65F6\u4E2D\u65AD\nignore [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u5BF9\u4E8E\u6307\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF, \u53D6\u6D88 'catch'\nwatch [access|all] <class id>.<field name>\n                          -- \u76D1\u89C6\u5BF9\u5B57\u6BB5\u7684\u8BBF\u95EE/\u4FEE\u6539\nunwatch [access|all] <class id>.<field name>\n                          -- \u505C\u6B62\u76D1\u89C6\u5BF9\u5B57\u6BB5\u7684\u
 8BBF\u95EE/\u4FEE\u6539\ntrace [go] methods [thread]\n                          -- \u8DDF\u8E2A\u65B9\u6CD5\u8FDB\u5165\u548C\u9000\u51FA\u3002\n                          -- \u9664\u975E\u6307\u5B9A 'go', \u5426\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\ntrace [go] method exit | exits [thread]\n                          -- \u8DDF\u8E2A\u5F53\u524D\u65B9\u6CD5\u7684\u9000\u51FA, \u6216\u8005\u6240\u6709\u65B9\u6CD5\u7684\u9000\u51FA\n                          -- \u9664\u975E\u6307\u5B9A 'go', \u5426\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\nuntrace [methods]         -- \u505C\u6B62\u8DDF\u8E2A\u65B9\u6CD5\u8FDB\u5165\u548C/\u6216\u9000\u51FA\nstep                      -- \u6267\u884C\u5F53\u524D\u884C\nstep up                   -- \u4E00\u76F4\u6267\u884C, \u76F4\u5230\u5F53\u524D\u65B9\u6CD5\u8FD4\u56DE\u5230\u5176\u8C03\u7528\u65B9\nstepi                     -- \u6267\u884C\u5F53\u524D\u6307\u4EE4\n\u4E0B\u4E00\u6B65                      -- \u6B65\u8FDB\u4E00\u884C (\u6B65\u8FC7\u
 8C03\u7528)\ncont                      -- \u4ECE\u65AD\u70B9\u5904\u7EE7\u7EED\u6267\u884C\n\nlist [line number|method] -- \u8F93\u51FA\u6E90\u4EE3\u7801\nuse (\u6216 sourcepath) [source file path]\n                          -- \u663E\u793A\u6216\u66F4\u6539\u6E90\u8DEF\u5F84\nexclude [<class pattern>, ... | \"none\"]\n                          -- \u5BF9\u4E8E\u6307\u5B9A\u7684\u7C7B, \u4E0D\u62A5\u544A\u6B65\u9AA4\u6216\u65B9\u6CD5\u4E8B\u4EF6\nclasspath                 -- \u4ECE\u76EE\u6807 VM \u8F93\u51FA\u7C7B\u8DEF\u5F84\u4FE1\u606F\n\nmonitor <command>         -- \u6BCF\u6B21\u7A0B\u5E8F\u505C\u6B62\u65F6\u6267\u884C\u547D\u4EE4\nmonitor                   -- \u5217\u51FA\u76D1\u89C6\u5668\nunmonitor <monitor#>      -- \u5220\u9664\u76D1\u89C6\u5668\nread <filename>           -- \u8BFB\u53D6\u5E76\u6267\u884C\u547D\u4EE4\u6587\u4EF6\n\nlock <expr>               -- \u8F93\u51FA\u5BF9\u8C61\u7684\u9501\u4FE1\u606F\nthreadlocks [thread id]   -- \u8F93\u51FA\u7EBF\u7A0B\u7684\u9501
 \u4FE1\u606F\n\npop                       -- \u901A\u8FC7\u5F53\u524D\u5E27\u51FA\u6808, \u4E14\u5305\u542B\u5F53\u524D\u5E27\nreenter                   -- \u4E0E pop \u76F8\u540C, \u4F46\u91CD\u65B0\u8FDB\u5165\u5F53\u524D\u5E27\nredefine <class id> <class file name>\n                          -- \u91CD\u65B0\u5B9A\u4E49\u7C7B\u7684\u4EE3\u7801\n\ndisablegc <expr>          -- \u7981\u6B62\u5BF9\u8C61\u7684\u5783\u573E\u6536\u96C6\nenablegc <expr>           -- \u5141\u8BB8\u5BF9\u8C61\u7684\u5783\u573E\u6536\u96C6\n\n!!                        -- \u91CD\u590D\u6267\u884C\u6700\u540E\u4E00\u4E2A\u547D\u4EE4\n<n> <command>             -- \u5C06\u547D\u4EE4\u91CD\u590D\u6267\u884C n \u6B21\nrepeat                    -- \u663E\u793A\u662F\u5426\u542F\u7528\u4E86 GDB \u6837\u5F0F\u7684\u7A7A\u547D\u4EE4\u91CD\u590D\nrepeat <on|off>           -- \u542F\u7528/\u7981\u7528 GDB \u6837\u5F0F\u7684\u91CD\u590D\n# <command>               -- \u653E\u5F03 (\u65E0\u64CD\u4F5C)\nhelp (\u6216 ?)     
           -- \u5217\u51FA\u547D\u4EE4\ndbgtrace [flag]           -- \u4E0E dbgtrace \u547D\u4EE4\u884C\u9009\u9879\u76F8\u540C\nversion                   -- \u8F93\u51FA\u7248\u672C\u4FE1\u606F\nexit (\u6216 quit)            -- \u9000\u51FA\u8C03\u8BD5\u5668\n\n<class id>: \u5E26\u6709\u7A0B\u5E8F\u5305\u9650\u5B9A\u7B26\u7684\u5B8C\u6574\u7C7B\u540D\n<class pattern>: \u5E26\u6709\u524D\u5BFC\u6216\u5C3E\u968F\u901A\u914D\u7B26 ('*') \u7684\u7C7B\u540D\n<thread id>: 'threads' \u547D\u4EE4\u4E2D\u62A5\u544A\u7684\u7EBF\u7A0B\u7F16\u53F7\n<expr>: Java(TM) \u7F16\u7A0B\u8BED\u8A00\u8868\u8FBE\u5F0F\u3002\n\u652F\u6301\u5927\u591A\u6570\u5E38\u89C1\u8BED\u6CD5\u3002\n\n\u53EF\u4EE5\u5C06\u542F\u52A8\u547D\u4EE4\u7F6E\u4E8E \"jdb.ini\" \u6216 \".jdbrc\" \u4E2D\n\u4F4D\u4E8E user.home \u6216 user.dir \u4E2D"},

Same comment here as mentioned in TTYResources_ja.java.

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

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

From naoto at openjdk.java.net  Thu Mar 10 19:54:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Mar 2022 19:54:44 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <oMFrgMwp9G7NK7ODUrjTKrPIFUgFnperV1nrSzNBU_A=.4014965c-a571-40a9-8ed2-40559c24fadb@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

No need for these lines in each localized files, as English bundle contains them.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

Same here with `de` bundle.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

and here.

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

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

From weijun at openjdk.java.net  Fri Mar 11 15:32:52 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 11 Mar 2022 15:32:52 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <OJXsIql3eK0cuKV5iLH_tmXrzKQkov7dukuN5CU5FQ4=.fb66f4aa-ff5d-45b9-a6fb-7fcb9c29f5bc@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

The security related changes look fine, except for the year 2021.

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

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

From achung at openjdk.java.net  Mon Mar 14 16:41:48 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Mar 2022 16:41:48 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
 <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com>
Message-ID: <aFQYlAxHrt1xgVqg6IzAILy_arxPtISUJjV4XTInMIc=.98676675-43ef-44ef-bc29-935fb586e100@github.com>

On Thu, 10 Mar 2022 18:56:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   moved CurrencyNames changes to jdk.localedata
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 305:
> 
>> 303:         {"Thread not suspended", "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"},
>> 304:         {"thread group number description name", "{0,number,integer}. {1} {2}"},
>> 305:         {"Threadgroup name not specified.", "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"},
> 
> I'm not sure what happened here. This resource was just removed yesterday as part of #7687. It had been around for a long time before that (probably from the beginning of this file), so I'm not sure what triggered getting it re-added.

The translation was started before the updates to this file. This update can be done in the next msg drop.

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

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

From kizune at openjdk.java.net  Mon Mar 14 17:41:55 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 14 Mar 2022 17:41:55 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <czftHGbEDrHytjmuT25dBWmgpN3gaiEPLmzDFtod0pA=.0c2274f6-25af-43fa-817f-0e41ede1c530@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

Marked as reviewed by kizune (Reviewer).

Clientlibs related stuff looks correct.

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

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

From achung at openjdk.java.net  Mon Mar 14 20:39:46 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Mar 2022 20:39:46 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <EX20WV-YgdYDcf8bAQVowI8_bLWbhpIVbE6VcPJuoAQ=.1bb0d805-0b7c-4e02-8a95-5c7d86b31c70@github.com>

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed repeated lines from ROOT bundle in CurrencyNames

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/4735722d..d5c9b884

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

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

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

From naoto at openjdk.java.net  Mon Mar 14 21:58:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 14 Mar 2022 21:58:45 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <EX20WV-YgdYDcf8bAQVowI8_bLWbhpIVbE6VcPJuoAQ=.1bb0d805-0b7c-4e02-8a95-5c7d86b31c70@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <EX20WV-YgdYDcf8bAQVowI8_bLWbhpIVbE6VcPJuoAQ=.1bb0d805-0b7c-4e02-8a95-5c7d86b31c70@github.com>
Message-ID: <AePZQwkLsjSCRROANYizCTzIfiMBaWBOgZaVcnJtm5k=.132459fa-34c1-487f-b2c0-ce1d9e9e5f60@github.com>

On Mon, 14 Mar 2022 20:39:46 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed repeated lines from ROOT bundle in CurrencyNames

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct_ja.properties line 1:

> 1: #

The change to this file (moving ct.properties to ct_ja.properties) does look suspicious. Looks like this is not a translation file, but some kind of a configuration for `javac`. If so, it should not be translated (and translation configuration in the closed repository should exclude this file)

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

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

From kevinw at openjdk.java.net  Tue Mar 15 20:29:56 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 15 Mar 2022 20:29:56 GMT
Subject: jmx-dev RFR: 8283092: JMX subclass permission check redundant with
 strong encapsulation
Message-ID: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>

Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass".  This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules.

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

Commit messages:
 - 8283092: JMX subclass permission check redundant with strong encapsulation

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

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

From dfuchs at openjdk.java.net  Wed Mar 16 15:18:51 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 16 Mar 2022 15:18:51 GMT
Subject: jmx-dev RFR: 8283092: JMX subclass permission check redundant
 with strong encapsulation
In-Reply-To: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
References: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
Message-ID: <WbNaKx_nJCUcaBah33FroE4yB3eGc9lQGl1S12nNNMQ=.af8f1dd9-3c5f-4bbd-8790-c5aad94569ff@github.com>

On Tue, 15 Mar 2022 20:22:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass".  This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules.

Marked as reviewed by dfuchs (Reviewer).

src/java.management/share/classes/sun/management/spi/PlatformMBeanProvider.java line 233:

> 231:         }
> 232:         return null;
> 233:     }

I have verified in module-info.java that sun.management.spi is only conditionally exported so I agree that the explicit permission check can now be removed.

src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java line 35:

> 33: 
> 34:     /**
> 35:      * Instantiates a new AgentProvider.

This class should probably be removed altogether. I see that you logged [JDK-8283254](https://bugs.openjdk.java.net/browse/JDK-8283254) so this is fine.

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

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

From achung at openjdk.java.net  Wed Mar 16 18:31:55 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 16 Mar 2022 18:31:55 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <SJQ29Ut1Mvo1_wXVRH6czoCYrkVhBoLSsVr0-wC9H34=.78a2083f-774e-4f4a-97f7-b998a2042c49@github.com>

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed incorrect translation of compiler configuration file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/d5c9b884..715a6ad7

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

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

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

From kevinw at openjdk.java.net  Wed Mar 16 21:31:45 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 16 Mar 2022 21:31:45 GMT
Subject: jmx-dev RFR: 8283092: JMX subclass permission check redundant
 with strong encapsulation
In-Reply-To: <WbNaKx_nJCUcaBah33FroE4yB3eGc9lQGl1S12nNNMQ=.af8f1dd9-3c5f-4bbd-8790-c5aad94569ff@github.com>
References: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
 <WbNaKx_nJCUcaBah33FroE4yB3eGc9lQGl1S12nNNMQ=.af8f1dd9-3c5f-4bbd-8790-c5aad94569ff@github.com>
Message-ID: <XlJjvMDsZaG1i5yp1af8c239OpgiFSvt2yHTWpfseuA=.d374670d-c949-48e7-bc70-fd752f21328e@github.com>

On Wed, 16 Mar 2022 15:14:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass".  This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules.
>
> src/java.management/share/classes/sun/management/spi/PlatformMBeanProvider.java line 233:
> 
>> 231:         }
>> 232:         return null;
>> 233:     }
> 
> I have verified in module-info.java that sun.management.spi is only conditionally exported so I agree that the explicit permission check can now be removed.

thanks

> src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java line 35:
> 
>> 33: 
>> 34:     /**
>> 35:      * Instantiates a new AgentProvider.
> 
> This class should probably be removed altogether. I see that you logged [JDK-8283254](https://bugs.openjdk.java.net/browse/JDK-8283254) so this is fine.

Thanks Daniel - yes will get rid of this class soon, I'll keep these two actions in separate changes. 8-)

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

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

From naoto at openjdk.java.net  Wed Mar 16 21:40:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 16 Mar 2022 21:40:44 GMT
Subject: jmx-dev RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <SJQ29Ut1Mvo1_wXVRH6czoCYrkVhBoLSsVr0-wC9H34=.78a2083f-774e-4f4a-97f7-b998a2042c49@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <SJQ29Ut1Mvo1_wXVRH6czoCYrkVhBoLSsVr0-wC9H34=.78a2083f-774e-4f4a-97f7-b998a2042c49@github.com>
Message-ID: <e38JXXFphxIsB3GPU8tMLtEBR2d6nJ52y-1yWWYbA1I=.66a0c141-db54-4f02-8e75-28d9e562c002@github.com>

On Wed, 16 Mar 2022 18:31:55 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed incorrect translation of compiler configuration file

LGTM. Thanks for the change.

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

Marked as reviewed by naoto (Reviewer).

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

From mullan at openjdk.java.net  Thu Mar 17 14:13:30 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 17 Mar 2022 14:13:30 GMT
Subject: jmx-dev RFR: 8283092: JMX subclass permission check redundant
 with strong encapsulation
In-Reply-To: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
References: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
Message-ID: <agQ7intPN_g1NHG1l_OtbhtIBR2KVwK8NdhvOu9zBtw=.2bc69c41-4759-4b4c-9512-a3ae516c5773@github.com>

On Tue, 15 Mar 2022 20:22:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass".  This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules.

I think you also need to update this test such that it checks that the module access restrictions prevent subclassing instead of the permission check: test/jdk/sun/management/PlatformMBeanProviderConstructorCheck.java

Also, it looks like this permission was never publicly documented and was only used internally, so it probably doesn't need a CSR, but I don't know for sure.

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

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

From kevinw at openjdk.java.net  Fri Mar 18 14:45:35 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 18 Mar 2022 14:45:35 GMT
Subject: jmx-dev RFR: 8283092: JMX subclass permission check redundant
 with strong encapsulation
In-Reply-To: <agQ7intPN_g1NHG1l_OtbhtIBR2KVwK8NdhvOu9zBtw=.2bc69c41-4759-4b4c-9512-a3ae516c5773@github.com>
References: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
 <agQ7intPN_g1NHG1l_OtbhtIBR2KVwK8NdhvOu9zBtw=.2bc69c41-4759-4b4c-9512-a3ae516c5773@github.com>
Message-ID: <IbHIDFR1tXrmBeK_VB_aJ4kLJuFoGUNg2rYHmG2_ofo=.a3b68a3d-0837-4062-90db-a22f96b4faa4@github.com>

On Thu, 17 Mar 2022 13:55:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> test/jdk/sun/management/PlatformMBeanProviderConstructorCheck.java

Thank for noticing that Sean - had run various tests but missed this.  I have an update, will add it here soon.

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

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

From kevinw at openjdk.java.net  Fri Mar 18 17:49:05 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 18 Mar 2022 17:49:05 GMT
Subject: jmx-dev RFR: 8283092: JMX subclass permission check redundant
 with strong encapsulation [v2]
In-Reply-To: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
References: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
Message-ID: <kfz4jUOtYC_KqjRM5rhpEELXS2ZgDmI1YtiJb9UpZ4s=.a7650a4e-3b96-4937-8ac2-232480d07ef0@github.com>

> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass".  This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Test update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7827/files
  - new: https://git.openjdk.java.net/jdk/pull/7827/files/a6d05f73..98f1577d

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

  Stats: 71 lines in 1 file changed: 28 ins; 11 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7827.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7827/head:pull/7827

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

From kevinw at openjdk.java.net  Fri Mar 18 17:49:06 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 18 Mar 2022 17:49:06 GMT
Subject: jmx-dev RFR: 8283092: JMX subclass permission check redundant
 with strong encapsulation
In-Reply-To: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
References: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
Message-ID: <oR2UBx0UktQvwIlOO1h_71ZgJWyCZ5TzvvXBEWLUo54=.2b4da014-4e4c-435d-ae86-89cf92f35965@github.com>

On Tue, 15 Mar 2022 20:22:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass".  This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules.

Added test update.  Checks that with permissive module options we can extend sun.management.spi.PlatformMBeanProvider, and that without them we cannot.

Output of the new test is like this:

----------System.out:(11/1279)----------
---PlatformMBeanProviderConstructorCheck:
---PlatformMBeanProviderConstructorCheck: invoke MyProvider with expectedFail = false
---PlatformMBeanProviderConstructorCheck PASSED (1) (expectedFail = false)
---PlatformMBeanProviderConstructorCheck: re-invoke without --add-modules or --add-exports
Command line: [/tank/kwalls/repos/personal/jdk/open/test/../../build/linux-x86_64-server-release/images/jdk/bin/java -cp /tank/kwalls/repos/personal/jdk/open/test/JTwork/classes/sun/management/PlatformMBeanProviderConstructorCheck.d:/tank/kwalls/repos/personal/jdk/open/test/jdk/sun/management:/tank/kwalls/repos/personal/jdk/open/test/JTwork/classes/test/lib:/tank/kwalls/repos/personal/jdk/open/test/lib:/opt/jtreg6.1/lib/javatest.jar:/opt/jtreg6.1/lib/jtreg.jar PlatformMBeanProviderConstructorCheck --nomoduleargs ]
[2022-03-18T17:19:34.798024163Z] Gathering output for process 10627
[2022-03-18T17:19:34.902532753Z] Waiting for completion for process 10627
[2022-03-18T17:19:34.902807078Z] Waiting for completion finished for process 10627
Output and diagnostic info for process 10627 was saved into 'pid-10627-output.log'
[2022-03-18T17:19:34.908368606Z] Waiting for completion for process 10627
[2022-03-18T17:19:34.908503964Z] Waiting for completion finished for process 10627
----------System.err:(9/647)----------
 stdout: [---PlatformMBeanProviderConstructorCheck:
---PlatformMBeanProviderConstructorCheck: invoke MyProvider with expectedFail = true
---PlatformMBeanProviderConstructorCheck got exception: java.lang.IllegalAccessError: superclass access check failed: class PlatformMBeanProviderConstructorCheck$MyProvider (in unnamed module @0x4795bbf5) cannot access class sun.management.spi.PlatformMBeanProvider (in module java.management) because module java.management does not export sun.management.spi to unnamed module @0x4795bbf5
---PlatformMBeanProviderConstructorCheck PASSED (2) (expectedFail = true)
];
 stderr: []
 exitValue = 0

STATUS:Passed.

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

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

From mchung at openjdk.java.net  Mon Mar 21 18:46:27 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 21 Mar 2022 18:46:27 GMT
Subject: jmx-dev RFR: 8283092: JMX subclass permission check redundant
 with strong encapsulation [v2]
In-Reply-To: <kfz4jUOtYC_KqjRM5rhpEELXS2ZgDmI1YtiJb9UpZ4s=.a7650a4e-3b96-4937-8ac2-232480d07ef0@github.com>
References: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
 <kfz4jUOtYC_KqjRM5rhpEELXS2ZgDmI1YtiJb9UpZ4s=.a7650a4e-3b96-4937-8ac2-232480d07ef0@github.com>
Message-ID: <oDWy3hhslg4eIAqM6KIiRR34ZBsRmNUWoK0gjxypQvA=.bb8089b7-97d9-4390-ac8a-502d88f7ba17@github.com>

On Fri, 18 Mar 2022 17:49:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass".  This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

src/java.management/share/classes/sun/management/spi/PlatformMBeanProvider.java line 210:

> 208:     }
> 209: 
> 210:     private PlatformMBeanProvider(Void unused) {

This `PlatformMBeanProvider(Void)` constructor is no longer needed.   Same for `AgentProvider(Void)` constructor.

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

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

From kevinw at openjdk.java.net  Mon Mar 21 20:19:03 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 21 Mar 2022 20:19:03 GMT
Subject: jmx-dev RFR: 8283092: JMX subclass permission check redundant
 with strong encapsulation [v3]
In-Reply-To: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
References: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
Message-ID: <REMxfD88ZjQwt0v8FJJpLBHj4todi22Bu2xqQ-fMwLI=.9e82e92f-7754-44c9-a2db-de92a816c5ba@github.com>

> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass".  This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  remove redundant constructors

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7827/files
  - new: https://git.openjdk.java.net/jdk/pull/7827/files/98f1577d..913958e9

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

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

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

From kevinw at openjdk.java.net  Mon Mar 21 20:25:32 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 21 Mar 2022 20:25:32 GMT
Subject: jmx-dev RFR: 8283092: JMX subclass permission check redundant
 with strong encapsulation [v2]
In-Reply-To: <oDWy3hhslg4eIAqM6KIiRR34ZBsRmNUWoK0gjxypQvA=.bb8089b7-97d9-4390-ac8a-502d88f7ba17@github.com>
References: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
 <kfz4jUOtYC_KqjRM5rhpEELXS2ZgDmI1YtiJb9UpZ4s=.a7650a4e-3b96-4937-8ac2-232480d07ef0@github.com>
 <oDWy3hhslg4eIAqM6KIiRR34ZBsRmNUWoK0gjxypQvA=.bb8089b7-97d9-4390-ac8a-502d88f7ba17@github.com>
Message-ID: <W1TTyxAt4bBVBAxTSckk2jN8UwV7-Xsfp5c61uxEKeY=.a66e091b-24d5-42fb-bfcb-844ae965ca93@github.com>

On Mon, 21 Mar 2022 18:40:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test update
>
> src/java.management/share/classes/sun/management/spi/PlatformMBeanProvider.java line 210:
> 
>> 208:     }
>> 209: 
>> 210:     private PlatformMBeanProvider(Void unused) {
> 
> This `PlatformMBeanProvider(Void)` constructor is no longer needed.   Same for `AgentProvider(Void)` constructor.

Thanks, yes they can go...  Rebuilt and tested ok after the new commit.

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

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

From mchung at openjdk.java.net  Mon Mar 21 20:38:32 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 21 Mar 2022 20:38:32 GMT
Subject: jmx-dev RFR: 8283092: JMX subclass permission check redundant
 with strong encapsulation [v3]
In-Reply-To: <REMxfD88ZjQwt0v8FJJpLBHj4todi22Bu2xqQ-fMwLI=.9e82e92f-7754-44c9-a2db-de92a816c5ba@github.com>
References: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
 <REMxfD88ZjQwt0v8FJJpLBHj4todi22Bu2xqQ-fMwLI=.9e82e92f-7754-44c9-a2db-de92a816c5ba@github.com>
Message-ID: <WAm24YmtbDysUgdoR9DfoVeju_arkXVEWreE7EJXGt8=.cbd32626-0082-440d-a5a3-f14bee92223f@github.com>

On Mon, 21 Mar 2022 20:19:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass".  This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant constructors

Marked as reviewed by mchung (Reviewer).

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

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

From kevinw at openjdk.java.net  Tue Mar 22 07:58:38 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 22 Mar 2022 07:58:38 GMT
Subject: jmx-dev RFR: 8283092: JMX subclass permission check redundant
 with strong encapsulation [v3]
In-Reply-To: <REMxfD88ZjQwt0v8FJJpLBHj4todi22Bu2xqQ-fMwLI=.9e82e92f-7754-44c9-a2db-de92a816c5ba@github.com>
References: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
 <REMxfD88ZjQwt0v8FJJpLBHj4todi22Bu2xqQ-fMwLI=.9e82e92f-7754-44c9-a2db-de92a816c5ba@github.com>
Message-ID: <XX6ib7-aNmLudJwlkVB86i_KIdCLnXPJd0urQp0NMfA=.0ff4f684-2417-45fe-ae4d-73c18dda5586@github.com>

On Mon, 21 Mar 2022 20:19:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass".  This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant constructors

Thanks all for the comments and reviews!

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

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

From kevinw at openjdk.java.net  Tue Mar 22 07:58:38 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 22 Mar 2022 07:58:38 GMT
Subject: jmx-dev Integrated: 8283092: JMX subclass permission check
 redundant with strong encapsulation
In-Reply-To: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
References: <KdB4n2_UqVxMANHJ64-OYzDtrK8M2B4Jj1rE0tk5v7I=.30585dbc-e2b1-4eb9-bd2c-0bc01685ba01@github.com>
Message-ID: <MdaisLyQdddQ0VKlOQUvWLDpBP37H-D-IEGb3nF2zd4=.45b75681-8235-422a-a3fc-2d5e0a784600@github.com>

On Tue, 15 Mar 2022 20:22:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass".  This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules.

This pull request has now been integrated.

Changeset: 37fc77ef
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/37fc77ef60dd97c4acc468ecfeb6753132974720
Stats:     108 lines in 4 files changed: 28 ins; 45 del; 35 mod

8283092: JMX subclass permission check redundant with strong encapsulation

Reviewed-by: dfuchs, mchung

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

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

From kevinw at openjdk.java.net  Tue Mar 22 21:26:02 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 22 Mar 2022 21:26:02 GMT
Subject: jmx-dev RFR: 8283254: Remove redundant class
 jdk/internal/agent/spi/AgentProvider
Message-ID: <EZoKw03O9MFkCS-QUCVycb5JJHIxuBrIojc2oqOXgYg=.64b45b42-fe33-488b-b17e-903940faa827@github.com>

There are no uses of jdk/internal/agent/spi/AgentProvider, since the SNMP agent was removed ( 8071367 ): this class should be removed.  It is not a public interface.

Remove src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java
Remove import from src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java
Remove uses from src/jdk.management.agent/share/classes/module-info.java

Testing with the test/jdk/sun/management tests looks good.

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

Commit messages:
 - 8283254: Remove redundant class jdk/internal/agent/spi/AgentProvider

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

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

From mchung at openjdk.java.net  Tue Mar 22 21:32:31 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 22 Mar 2022 21:32:31 GMT
Subject: jmx-dev RFR: 8283254: Remove redundant class
 jdk/internal/agent/spi/AgentProvider
In-Reply-To: <EZoKw03O9MFkCS-QUCVycb5JJHIxuBrIojc2oqOXgYg=.64b45b42-fe33-488b-b17e-903940faa827@github.com>
References: <EZoKw03O9MFkCS-QUCVycb5JJHIxuBrIojc2oqOXgYg=.64b45b42-fe33-488b-b17e-903940faa827@github.com>
Message-ID: <kYg5MKzrtPeVhUbo54w_4FIH-4CqULtXj3_YJsW3Mgg=.802d2ad8-0557-4824-84e7-b4334d43a741@github.com>

On Tue, 22 Mar 2022 21:19:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> There are no uses of jdk/internal/agent/spi/AgentProvider, since the SNMP agent was removed ( 8071367 ): this class should be removed.  It is not a public interface.
> 
> Remove src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java
> Remove import from src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java
> Remove uses from src/jdk.management.agent/share/classes/module-info.java
> 
> Testing with the test/jdk/sun/management tests looks good.

Marked as reviewed by mchung (Reviewer).

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

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

From redestad at openjdk.java.net  Tue Mar 22 21:48:29 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 22 Mar 2022 21:48:29 GMT
Subject: jmx-dev RFR: 8283254: Remove redundant class
 jdk/internal/agent/spi/AgentProvider
In-Reply-To: <EZoKw03O9MFkCS-QUCVycb5JJHIxuBrIojc2oqOXgYg=.64b45b42-fe33-488b-b17e-903940faa827@github.com>
References: <EZoKw03O9MFkCS-QUCVycb5JJHIxuBrIojc2oqOXgYg=.64b45b42-fe33-488b-b17e-903940faa827@github.com>
Message-ID: <du6nxm-2rS2iKVirAh9e8xXnyMtX_znWYzQmEpzrlmQ=.839675ad-2ab1-4f5c-8018-ad4ebf96a317@github.com>

On Tue, 22 Mar 2022 21:19:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> There are no uses of jdk/internal/agent/spi/AgentProvider, since the SNMP agent was removed ( 8071367 ): this class should be removed.  It is not a public interface.
> 
> Remove src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java
> Remove import from src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java
> Remove uses from src/jdk.management.agent/share/classes/module-info.java
> 
> Testing with the test/jdk/sun/management tests looks good.

Marked as reviewed by redestad (Reviewer).

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

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

From dfuchs at openjdk.java.net  Wed Mar 23 11:01:33 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 23 Mar 2022 11:01:33 GMT
Subject: jmx-dev RFR: 8283254: Remove redundant class
 jdk/internal/agent/spi/AgentProvider
In-Reply-To: <EZoKw03O9MFkCS-QUCVycb5JJHIxuBrIojc2oqOXgYg=.64b45b42-fe33-488b-b17e-903940faa827@github.com>
References: <EZoKw03O9MFkCS-QUCVycb5JJHIxuBrIojc2oqOXgYg=.64b45b42-fe33-488b-b17e-903940faa827@github.com>
Message-ID: <7VYi-JEA_6IYMKtNQPoSMExA-ppEHSb3b_GA56TxlDU=.7cf868e8-913b-4ad4-9e6f-77c559eecc63@github.com>

On Tue, 22 Mar 2022 21:19:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> There are no uses of jdk/internal/agent/spi/AgentProvider, since the SNMP agent was removed ( 8071367 ): this class should be removed.  It is not a public interface.
> 
> Remove src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java
> Remove import from src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java
> Remove uses from src/jdk.management.agent/share/classes/module-info.java
> 
> Testing with the test/jdk/sun/management tests looks good.

Thanks for taking care of that Kevin!

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

Marked as reviewed by dfuchs (Reviewer).

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

From kevinw at openjdk.java.net  Wed Mar 23 11:07:36 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 23 Mar 2022 11:07:36 GMT
Subject: jmx-dev RFR: 8283254: Remove redundant class
 jdk/internal/agent/spi/AgentProvider
In-Reply-To: <EZoKw03O9MFkCS-QUCVycb5JJHIxuBrIojc2oqOXgYg=.64b45b42-fe33-488b-b17e-903940faa827@github.com>
References: <EZoKw03O9MFkCS-QUCVycb5JJHIxuBrIojc2oqOXgYg=.64b45b42-fe33-488b-b17e-903940faa827@github.com>
Message-ID: <46DdD6pf3ER-pvATr8b36pHJCVUCaQzXph3O7P3cif8=.cdd3ca56-c338-4a49-b6f8-390e650f2db6@github.com>

On Tue, 22 Mar 2022 21:19:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> There are no uses of jdk/internal/agent/spi/AgentProvider, since the SNMP agent was removed ( 8071367 ): this class should be removed.  It is not a public interface.
> 
> Remove src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java
> Remove import from src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java
> Remove uses from src/jdk.management.agent/share/classes/module-info.java
> 
> Testing with the test/jdk/sun/management tests looks good.

Thanks for the reviews!

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

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

From kevinw at openjdk.java.net  Wed Mar 23 11:07:36 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 23 Mar 2022 11:07:36 GMT
Subject: jmx-dev Integrated: 8283254: Remove redundant class
 jdk/internal/agent/spi/AgentProvider
In-Reply-To: <EZoKw03O9MFkCS-QUCVycb5JJHIxuBrIojc2oqOXgYg=.64b45b42-fe33-488b-b17e-903940faa827@github.com>
References: <EZoKw03O9MFkCS-QUCVycb5JJHIxuBrIojc2oqOXgYg=.64b45b42-fe33-488b-b17e-903940faa827@github.com>
Message-ID: <mGlMhjBUZVEOYnEjIXMFFexIxJNZiyLcd_zD2I4nfzQ=.f5d85d7e-1996-4273-a846-be96a5380ab1@github.com>

On Tue, 22 Mar 2022 21:19:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> There are no uses of jdk/internal/agent/spi/AgentProvider, since the SNMP agent was removed ( 8071367 ): this class should be removed.  It is not a public interface.
> 
> Remove src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java
> Remove import from src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java
> Remove uses from src/jdk.management.agent/share/classes/module-info.java
> 
> Testing with the test/jdk/sun/management tests looks good.

This pull request has now been integrated.

Changeset: 61d7d868
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/61d7d868db030d878f4a1c4467075e8d4e116a6e
Stats:     80 lines in 3 files changed: 0 ins; 79 del; 1 mod

8283254: Remove redundant class jdk/internal/agent/spi/AgentProvider

Reviewed-by: mchung, redestad, dfuchs

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

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

From naoto at openjdk.java.net  Thu Mar 24 22:11:30 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 24 Mar 2022 22:11:30 GMT
Subject: jmx-dev RFR: 8282819: Deprecate Locale class constructors
Message-ID: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>

Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

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

Commit messages:
 - 8282819: Deprecate Locale class constructors

Changes: https://git.openjdk.java.net/jdk/pull/7947/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282819
  Stats: 904 lines in 196 files changed: 74 ins; 22 del; 808 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7947.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947

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

From smarks at openjdk.java.net  Fri Mar 25 00:25:47 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 25 Mar 2022 00:25:47 GMT
Subject: jmx-dev RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <RSdSQRML_fxp83kPgyjhwRAbLU9aQ7gmcwt485ai5MU=.e2fcbdd7-d325-4ac2-ade5-2a2bfa1658ee@github.com>

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

Specs looks good, with minor modifications. I'm not so sure about replacement of the constructors with string concatenation with ternary operators; see my other comment.

src/java.base/share/classes/java/util/Locale.java line 252:

> 250:  * <p>The {@code Locale} class provides a number of convenient constants
> 251:  * that you can use to obtain {@code Locale} objects for commonly used
> 252:  * locales. For example, the following obtains a {@code Locale} object

I'd replace this part (and the example below) with something like,

    For example, {@code Locale.US} is the {@code Locale} object for the United States.

src/java.base/share/classes/java/util/Locale.java line 2511:

> 2509:      * constructors, the {@code Builder} checks if a value configured by a
> 2510:      * setter satisfies the syntax requirements defined by the {@code Locale}
> 2511:      * class.  A {@code Locale} object obtained by a {@code Builder} is

...obtained from a Builder...

src/java.base/share/classes/java/util/Locale.java line 2526:

> 2524:      *
> 2525:      * <p>The following example shows how to obtain a {@code Locale} object
> 2526:      * with the {@code Builder}.

...shows how to obtain a Locale object using a Builder.

src/java.base/share/classes/java/util/Locale.java line 2660:

> 2658:          *
> 2659:          * <p>The country value in the {@code Locale} obtained by the
> 2660:          * {@code Builder} is always normalized to upper case.

...obtained from a Builder...

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 375:

> 373:                         (locale.getLanguage().isEmpty() ? "und" : locale.getLanguage()) +
> 374:                         (locale.getCountry().isEmpty() ? "" : "-" + locale.getCountry()) +
> 375:                         (locale.getVariant().isEmpty() ? "" : "-x-lvariant-" + locale.getVariant()));

It seems like this snippet (and ones very similar to it) are repeated several times throughout the JDK code as replacements for the two- and three-arg constructors. This seems like a fair increase in complexity, and the use of "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third party code that uses the Locale constructors replace them with this snippet? Is there something better that we can provide?

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

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

From naoto at openjdk.java.net  Fri Mar 25 01:59:51 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Mar 2022 01:59:51 GMT
Subject: jmx-dev RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <RSdSQRML_fxp83kPgyjhwRAbLU9aQ7gmcwt485ai5MU=.e2fcbdd7-d325-4ac2-ade5-2a2bfa1658ee@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <RSdSQRML_fxp83kPgyjhwRAbLU9aQ7gmcwt485ai5MU=.e2fcbdd7-d325-4ac2-ade5-2a2bfa1658ee@github.com>
Message-ID: <OBsFbX0ds7pjRk7RgpbdV4Zn8KOlnZlxty5xXmq8tPs=.55c6d83e-91d9-4c7d-9157-cab06c6f2f0a@github.com>

On Fri, 25 Mar 2022 00:18:54 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.
>
> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 375:
> 
>> 373:                         (locale.getLanguage().isEmpty() ? "und" : locale.getLanguage()) +
>> 374:                         (locale.getCountry().isEmpty() ? "" : "-" + locale.getCountry()) +
>> 375:                         (locale.getVariant().isEmpty() ? "" : "-x-lvariant-" + locale.getVariant()));
> 
> It seems like this snippet (and ones very similar to it) are repeated several times throughout the JDK code as replacements for the two- and three-arg constructors. This seems like a fair increase in complexity, and the use of "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third party code that uses the Locale constructors replace them with this snippet? Is there something better that we can provide?

True. One solution could be to expose `Locale.getInstance()`, which is currently a package-private static method, for this purpose. Though that means promoting `ill-formed` locale objects which defy some part of the deprecation cause.

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

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

From rriggs at openjdk.java.net  Fri Mar 25 15:40:46 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 25 Mar 2022 15:40:46 GMT
Subject: jmx-dev RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <tyOR0vEQfJzdx8ZwYHY45srRuXftQXscF48fPmAXqRs=.fd7f148b-cef1-41d9-8f7c-59c8bfcda8e5@github.com>

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

src/java.base/share/classes/java/util/Locale.java line 245:

> 243:  * <h4>Factory Method</h4>
> 244:  *
> 245:  * <p>The method {@link #forLanguageTag} obtains a {@code Locale}

The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like the best name for the factory.
Yes, it already exists and does what's required but you might get better uptake with a more natural name.

Some alternatives:
 - `Locale.of("en_US")` - short and conventional
 - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories
 - `Locale.forLanguage("en_US")` - natural but less conventional

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

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

From rriggs at openjdk.java.net  Fri Mar 25 16:21:52 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 25 Mar 2022 16:21:52 GMT
Subject: jmx-dev RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <rvpu-eVSZUdEqfnckoWr-J9r6wzDOxNjzSbyW5aFOjE=.8654bef5-9b34-4618-92f7-b9a1bf0c13fa@github.com>

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

Given the large number of cleanups, I would have suggested to keep them separate from the change to re-focus the API on factories.

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

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

From naoto at openjdk.java.net  Fri Mar 25 16:21:52 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Mar 2022 16:21:52 GMT
Subject: jmx-dev RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <tyOR0vEQfJzdx8ZwYHY45srRuXftQXscF48fPmAXqRs=.fd7f148b-cef1-41d9-8f7c-59c8bfcda8e5@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <tyOR0vEQfJzdx8ZwYHY45srRuXftQXscF48fPmAXqRs=.fd7f148b-cef1-41d9-8f7c-59c8bfcda8e5@github.com>
Message-ID: <WWaUZ9i-O6PCG638nKOBsZabzM2ssK5gzG_SDVattvE=.d63a8f82-17f8-4ed2-bed6-ba717c04b545@github.com>

On Fri, 25 Mar 2022 15:37:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.
>
> src/java.base/share/classes/java/util/Locale.java line 245:
> 
>> 243:  * <h4>Factory Method</h4>
>> 244:  *
>> 245:  * <p>The method {@link #forLanguageTag} obtains a {@code Locale}
> 
> The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like the best name for the factory.
> Yes, it already exists and does what's required but you might get better uptake with a more natural name.
> 
> Some alternatives:
>  - `Locale.of("en_US")` - short and conventional
>  - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories
>  - `Locale.forLanguage("en_US")` - natural but less conventional

I was thinking of a *new* factory method, along the line with Stuart's suggestion, something like this:

Locale.of(String... elements)

where elements can either `(lang)`, `(lang, ctry)`, `(lang, ctry, vrnt)`, or `(lang, ctry, vrnt, scpt)`. Either element can be an empty string, but cannot be null. These elements are *not* language tags, but conventional arguments to constructors, so it is compatible (and works as a stop-gap) to the old constructors. This way third parties will not have to deal with the boilerplate code mentioned above on migration.

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

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

From achung at openjdk.java.net  Mon Mar 28 18:35:54 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 28 Mar 2022 18:35:54 GMT
Subject: jmx-dev Integrated: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <Gltjkc_Ybexl1S5THR_ItVyUAyld7nfA_h8fTuf8qqQ=.875739c6-22bf-4338-8e20-3e6e1b090140@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

This pull request has now been integrated.

Changeset: c0aecd15
Author:    Alisen Chung <achung at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0aecd15ae8d7abf37901f785fccaff2317c3b23
Stats:     11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod

8280400: JDK 19 L10n resource files update - msgdrop 10

Reviewed-by: naoto, kizune

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

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

From achung at openjdk.java.net  Mon Mar 28 21:30:15 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 28 Mar 2022 21:30:15 GMT
Subject: jmx-dev RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update -
 msgdrop 10
Message-ID: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>

This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

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

Commit messages:
 - Revert "8280400: JDK 19 L10n resource files update - msgdrop 10"

Changes: https://git.openjdk.java.net/jdk/pull/8005/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8005&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283806
  Stats: 11316 lines in 139 files changed: 1252 ins; 9124 del; 940 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8005.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8005/head:pull/8005

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

From kcr at openjdk.java.net  Mon Mar 28 21:30:16 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 28 Mar 2022 21:30:16 GMT
Subject: jmx-dev RFR: 8283806: [BACKOUT] JDK 19 L10n resource files
 update - msgdrop 10
In-Reply-To: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
References: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
Message-ID: <FaqSreLXyYzhr0FYhkqcq8UW9Dn8RNNX0C7kb7-RGkA=.ba08bc41-383f-4e23-8103-7f0ef391df19@github.com>

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

I confirm that this is an exact backout of [JDK-8280400](https://bugs.openjdk.java.net/browse/JDK-8280400).

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

Marked as reviewed by kcr (Author).

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

From naoto at openjdk.java.net  Mon Mar 28 22:44:36 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Mar 2022 22:44:36 GMT
Subject: jmx-dev RFR: 8283806: [BACKOUT] JDK 19 L10n resource files
 update - msgdrop 10
In-Reply-To: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
References: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
Message-ID: <jtwpNmcgdU1P5vo-z1GqeBzGlkydOcOsamki-j7cdAA=.d2087435-7f1a-4a78-b8c5-91d4577745e5@github.com>

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

LGTM

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

Marked as reviewed by naoto (Reviewer).

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

From achung at openjdk.java.net  Mon Mar 28 23:40:44 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 28 Mar 2022 23:40:44 GMT
Subject: jmx-dev Integrated: 8283806: [BACKOUT] JDK 19 L10n resource files
 update - msgdrop 10
In-Reply-To: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
References: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
Message-ID: <zrorEpgQ5H2ZmwvH02RY-vMNitbxb4vcyk7W_pXhThw=.dd16b716-2dc8-42e6-b70e-7b58196a88de@github.com>

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

This pull request has now been integrated.

Changeset: 634800a5
Author:    Alisen Chung <achung at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/634800a536e7f9d148a4caa2663a60a2c5fc4929
Stats:     11316 lines in 139 files changed: 1252 ins; 9124 del; 940 mod

8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10

Reviewed-by: kcr, naoto

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

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

From achung at openjdk.java.net  Wed Mar 30 00:54:29 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 30 Mar 2022 00:54:29 GMT
Subject: jmx-dev RFR: 8283805: [REDO] JDK 19 L10n resource files update -
 msgdrop 10
Message-ID: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>

redo of 8280400

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

Commit messages:
 - 8280400: JDK 19 L10n resource files update - msgdrop 10

Changes: https://git.openjdk.java.net/jdk/pull/8026/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8026&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283805
  Stats: 11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8026/head:pull/8026

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

From duke at openjdk.java.net  Wed Mar 30 01:52:57 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 30 Mar 2022 01:52:57 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode
Message-ID: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>

```        
               long hostTicks = getHostTotalCpuTicks0();
                int totalCPUs = getHostOnlineCpuCount0();
                int containerCPUs = getAvailableProcessors();
                // scale the total host load to the actual container cpus
                hostTicks = hostTicks * containerCPUs / totalCPUs;

hostTicks=175476155560000000
totalCPUs=96
containerCPUs=90

Calculate the overflow

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

Commit messages:
 - 8283903: GetContainerCpuLoad does not return the correct result in share mode

Changes: https://git.openjdk.java.net/jdk/pull/8028/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8028&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283903
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8028.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8028/head:pull/8028

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

From jiefu at openjdk.java.net  Wed Mar 30 02:04:37 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 30 Mar 2022 02:04:37 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode
In-Reply-To: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
Message-ID: <HHAYLQ9cbRVt6_4w930pXY7fjsb9k4B5HDflnm4c48E=.7d423e98-2791-4fb8-b3c9-6b9fe286313b@github.com>

On Wed, 30 Mar 2022 01:46:20 GMT, xpbob <duke at openjdk.java.net> wrote:

> ```        
>                long hostTicks = getHostTotalCpuTicks0();
>                 int totalCPUs = getHostOnlineCpuCount0();
>                 int containerCPUs = getAvailableProcessors();
>                 // scale the total host load to the actual container cpus
>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
> 
> hostTicks=175476155560000000
> totalCPUs=96
> containerCPUs=90
> 
> Calculate the overflow

It would be better to describe how to reproduce the bug.

Is it possible to add a jtreg test for this case?
Please also update the copyright year.

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

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

From duke at openjdk.java.net  Wed Mar 30 02:08:16 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 30 Mar 2022 02:08:16 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v2]
In-Reply-To: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
Message-ID: <2yMUjxFu7TKo8D9XocPiqkIhYEu6qYFxZhhHJm04IUc=.722d6ebb-7b48-420e-a401-cc339ae4f126@github.com>

> ```        
>                long hostTicks = getHostTotalCpuTicks0();
>                 int totalCPUs = getHostOnlineCpuCount0();
>                 int containerCPUs = getAvailableProcessors();
>                 // scale the total host load to the actual container cpus
>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
> 
> hostTicks=175476155560000000
> totalCPUs=96
> containerCPUs=90
> 
> Calculate the overflow

xpbob has updated the pull request incrementally with one additional commit since the last revision:

  update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8028/files
  - new: https://git.openjdk.java.net/jdk/pull/8028/files/e88a00f7..e59d894d

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

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

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

From duke at openjdk.java.net  Wed Mar 30 02:32:43 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 30 Mar 2022 02:32:43 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode
In-Reply-To: <HHAYLQ9cbRVt6_4w930pXY7fjsb9k4B5HDflnm4c48E=.7d423e98-2791-4fb8-b3c9-6b9fe286313b@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <HHAYLQ9cbRVt6_4w930pXY7fjsb9k4B5HDflnm4c48E=.7d423e98-2791-4fb8-b3c9-6b9fe286313b@github.com>
Message-ID: <WQ9AS95JFR_PV2se1heNtfhIp0bwxtpdBe8KqpGnRb8=.642a016b-3769-41e6-b6aa-064c5278a8a1@github.com>

On Wed, 30 Mar 2022 02:00:59 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> It would be better to describe how to reproduce the bug.
> 
> Is it possible to add a jtreg test for this case? Please also update the copyright year.

Thanks.
The reappearance depends on the environment. In share mode, the process runs for a long time and the number of physical machine cores is large, making it easier to reappear.
The data I listed above is runtime data obtained through redefine bytecode

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

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

From jiefu at openjdk.java.net  Wed Mar 30 02:40:38 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 30 Mar 2022 02:40:38 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode
In-Reply-To: <WQ9AS95JFR_PV2se1heNtfhIp0bwxtpdBe8KqpGnRb8=.642a016b-3769-41e6-b6aa-064c5278a8a1@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <HHAYLQ9cbRVt6_4w930pXY7fjsb9k4B5HDflnm4c48E=.7d423e98-2791-4fb8-b3c9-6b9fe286313b@github.com>
 <WQ9AS95JFR_PV2se1heNtfhIp0bwxtpdBe8KqpGnRb8=.642a016b-3769-41e6-b6aa-064c5278a8a1@github.com>
Message-ID: <5kr3nhfYI_WPXHI-f8UwPw8dxJCLiA1STQEUsJM1ocw=.c486c8c3-48b3-4a44-8b27-61b5820fcca9@github.com>

On Wed, 30 Mar 2022 02:29:47 GMT, xpbob <duke at openjdk.java.net> wrote:

> In share mode, the process runs for a long time and the number of physical machine cores is large, making it easier to reappear.

So if we run long enough, the `getHostTotalCpuTicks0()` may return overflowed `hostTicks`, right?

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

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

From duke at openjdk.java.net  Wed Mar 30 02:47:44 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 30 Mar 2022 02:47:44 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode
In-Reply-To: <5kr3nhfYI_WPXHI-f8UwPw8dxJCLiA1STQEUsJM1ocw=.c486c8c3-48b3-4a44-8b27-61b5820fcca9@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <HHAYLQ9cbRVt6_4w930pXY7fjsb9k4B5HDflnm4c48E=.7d423e98-2791-4fb8-b3c9-6b9fe286313b@github.com>
 <WQ9AS95JFR_PV2se1heNtfhIp0bwxtpdBe8KqpGnRb8=.642a016b-3769-41e6-b6aa-064c5278a8a1@github.com>
 <5kr3nhfYI_WPXHI-f8UwPw8dxJCLiA1STQEUsJM1ocw=.c486c8c3-48b3-4a44-8b27-61b5820fcca9@github.com>
Message-ID: <CNEzg9q_xg4huBcQ0VCxaS9ZVUYo9D1UfzsUjqFLkdk=.0a2a41c4-8c47-4a9d-bebb-781f7097e08d@github.com>

On Wed, 30 Mar 2022 02:37:31 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > In share mode, the process runs for a long time and the number of physical machine cores is large, making it easier to reappear.
> 
> So if we run long enough, the `getHostTotalCpuTicks0()` may return overflowed `hostTicks`, right?

GetHostTotalCpuTicks0 is correct
(GetHostTotalCpuTicks0() * containerCPUs)  will overflowed

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

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

From jiefu at openjdk.java.net  Wed Mar 30 03:20:36 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 30 Mar 2022 03:20:36 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v2]
In-Reply-To: <2yMUjxFu7TKo8D9XocPiqkIhYEu6qYFxZhhHJm04IUc=.722d6ebb-7b48-420e-a401-cc339ae4f126@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <2yMUjxFu7TKo8D9XocPiqkIhYEu6qYFxZhhHJm04IUc=.722d6ebb-7b48-420e-a401-cc339ae4f126@github.com>
Message-ID: <TltgoFnXS9yk2Mk7Ur1QkEeeS3ZXQLeqR-oPLMbR3CQ=.79b796d3-9149-4471-b04b-7000d63fd65f@github.com>

On Wed, 30 Mar 2022 02:08:16 GMT, xpbob <duke at openjdk.java.net> wrote:

>> ```        
>>                long hostTicks = getHostTotalCpuTicks0();
>>                 int totalCPUs = getHostOnlineCpuCount0();
>>                 int containerCPUs = getAvailableProcessors();
>>                 // scale the total host load to the actual container cpus
>>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
>> 
>> hostTicks=175476155560000000
>> totalCPUs=96
>> containerCPUs=90
>> 
>> Calculate the overflow
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

Marked as reviewed by jiefu (Reviewer).

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

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

From jiefu at openjdk.java.net  Wed Mar 30 03:20:36 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 30 Mar 2022 03:20:36 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode
In-Reply-To: <CNEzg9q_xg4huBcQ0VCxaS9ZVUYo9D1UfzsUjqFLkdk=.0a2a41c4-8c47-4a9d-bebb-781f7097e08d@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <HHAYLQ9cbRVt6_4w930pXY7fjsb9k4B5HDflnm4c48E=.7d423e98-2791-4fb8-b3c9-6b9fe286313b@github.com>
 <WQ9AS95JFR_PV2se1heNtfhIp0bwxtpdBe8KqpGnRb8=.642a016b-3769-41e6-b6aa-064c5278a8a1@github.com>
 <5kr3nhfYI_WPXHI-f8UwPw8dxJCLiA1STQEUsJM1ocw=.c486c8c3-48b3-4a44-8b27-61b5820fcca9@github.com>
 <CNEzg9q_xg4huBcQ0VCxaS9ZVUYo9D1UfzsUjqFLkdk=.0a2a41c4-8c47-4a9d-bebb-781f7097e08d@github.com>
Message-ID: <ECFMA5NaTPB0TBityCbTbRbsuwLY5CSaYHbL1kwPjdE=.bf2bb463-9cc3-4aa3-9e49-e5c78e01477c@github.com>

On Wed, 30 Mar 2022 02:44:52 GMT, xpbob <duke at openjdk.java.net> wrote:

> GetHostTotalCpuTicks0 is correct
> (GetHostTotalCpuTicks0() * containerCPUs) will overflowed

Okay.
It makes sense for this case.

Maybe, there is no way to prevent the overflow of `hostTicks ` returned by `getHostTotalCpuTicks0()`.
So the change looks good to me.
Thanks.

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

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

From dholmes at openjdk.java.net  Wed Mar 30 04:43:36 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 30 Mar 2022 04:43:36 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v2]
In-Reply-To: <2yMUjxFu7TKo8D9XocPiqkIhYEu6qYFxZhhHJm04IUc=.722d6ebb-7b48-420e-a401-cc339ae4f126@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <2yMUjxFu7TKo8D9XocPiqkIhYEu6qYFxZhhHJm04IUc=.722d6ebb-7b48-420e-a401-cc339ae4f126@github.com>
Message-ID: <XlubM1nwy5UvN9HlJNYMlTXdazi9z3FhXQeVKaoTNpY=.40ff5113-68c1-4d41-8bb7-1a262635d5f5@github.com>

On Wed, 30 Mar 2022 02:08:16 GMT, xpbob <duke at openjdk.java.net> wrote:

>> ```        
>>                long hostTicks = getHostTotalCpuTicks0();
>>                 int totalCPUs = getHostOnlineCpuCount0();
>>                 int containerCPUs = getAvailableProcessors();
>>                 // scale the total host load to the actual container cpus
>>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
>> 
>> hostTicks=175476155560000000
>> totalCPUs=96
>> containerCPUs=90
>> 
>> Calculate the overflow
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

175476155560000000 host ticks at 1ns/tick => 5.5 years!

This is a theoretical overflow - right?

David

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

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

From dholmes at openjdk.java.net  Wed Mar 30 04:58:36 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 30 Mar 2022 04:58:36 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v2]
In-Reply-To: <2yMUjxFu7TKo8D9XocPiqkIhYEu6qYFxZhhHJm04IUc=.722d6ebb-7b48-420e-a401-cc339ae4f126@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <2yMUjxFu7TKo8D9XocPiqkIhYEu6qYFxZhhHJm04IUc=.722d6ebb-7b48-420e-a401-cc339ae4f126@github.com>
Message-ID: <oAxZgeaj508SlF1X4dqBmLXxJ6iX54YOb7kcgbyckDI=.c2873ce3-326f-4c24-a008-94c929aa062e@github.com>

On Wed, 30 Mar 2022 02:08:16 GMT, xpbob <duke at openjdk.java.net> wrote:

>> ```        
>>                long hostTicks = getHostTotalCpuTicks0();
>>                 int totalCPUs = getHostOnlineCpuCount0();
>>                 int containerCPUs = getAvailableProcessors();
>>                 // scale the total host load to the actual container cpus
>>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
>> 
>> hostTicks=175476155560000000
>> totalCPUs=96
>> containerCPUs=90
>> 
>> Calculate the overflow
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 96:

> 94:                 int containerCPUs = getAvailableProcessors();
> 95:                 // scale the total host load to the actual container cpus
> 96:                 hostTicks = hostTicks / totalCPUs * containerCPUs;

It might be better to convert to a floating-point calculation before converting back to a whole number:

`hostTicks = (long) (hostTicks * (1.0 * containerCPUs / totalCPUs));`

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

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

From duke at openjdk.java.net  Wed Mar 30 06:20:19 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 30 Mar 2022 06:20:19 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v3]
In-Reply-To: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
Message-ID: <PLg5XykYH9Klr6Gsl_oldxe80eX42qMyA8SjVhygTgs=.6d3c92d1-0e70-4ab7-ad83-2922954ac8b0@github.com>

> ```        
>                long hostTicks = getHostTotalCpuTicks0();
>                 int totalCPUs = getHostOnlineCpuCount0();
>                 int containerCPUs = getAvailableProcessors();
>                 // scale the total host load to the actual container cpus
>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
> 
> hostTicks=175476155560000000
> totalCPUs=96
> containerCPUs=90
> 
> Calculate the overflow

xpbob has updated the pull request incrementally with one additional commit since the last revision:

  Change the expression

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8028/files
  - new: https://git.openjdk.java.net/jdk/pull/8028/files/e59d894d..a1fda8a4

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

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

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

From duke at openjdk.java.net  Wed Mar 30 06:38:39 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 30 Mar 2022 06:38:39 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v2]
In-Reply-To: <XlubM1nwy5UvN9HlJNYMlTXdazi9z3FhXQeVKaoTNpY=.40ff5113-68c1-4d41-8bb7-1a262635d5f5@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <2yMUjxFu7TKo8D9XocPiqkIhYEu6qYFxZhhHJm04IUc=.722d6ebb-7b48-420e-a401-cc339ae4f126@github.com>
 <XlubM1nwy5UvN9HlJNYMlTXdazi9z3FhXQeVKaoTNpY=.40ff5113-68c1-4d41-8bb7-1a262635d5f5@github.com>
Message-ID: <lAwMlvfgE1SsTsPBjoBwSvjtt-YkgvZ0eSBurpuypdI=.5131de1a-7523-477a-952a-a8b728ceab07@github.com>

On Wed, 30 Mar 2022 04:40:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright year
>
> 175476155560000000 host ticks at 1ns/tick => 5.5 years!
> 
> This is a theoretical overflow - right?
> 
> David

@dholmes-ora 
Thanks to review.
This code expression is more accurate

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

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

From sgehwolf at openjdk.java.net  Wed Mar 30 09:08:40 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 30 Mar 2022 09:08:40 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v3]
In-Reply-To: <PLg5XykYH9Klr6Gsl_oldxe80eX42qMyA8SjVhygTgs=.6d3c92d1-0e70-4ab7-ad83-2922954ac8b0@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <PLg5XykYH9Klr6Gsl_oldxe80eX42qMyA8SjVhygTgs=.6d3c92d1-0e70-4ab7-ad83-2922954ac8b0@github.com>
Message-ID: <fevbrBAKkJvk1yP4NqbgAnYsSwdfkMxV55BpU-a8P34=.b161d37d-a0b9-4321-8d5a-695f92ef130b@github.com>

On Wed, 30 Mar 2022 06:20:19 GMT, xpbob <duke at openjdk.java.net> wrote:

>> ```        
>>                long hostTicks = getHostTotalCpuTicks0();
>>                 int totalCPUs = getHostOnlineCpuCount0();
>>                 int containerCPUs = getAvailableProcessors();
>>                 // scale the total host load to the actual container cpus
>>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
>> 
>> hostTicks=175476155560000000
>> totalCPUs=96
>> containerCPUs=90
>> 
>> Calculate the overflow
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the expression

src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 96:

> 94:                 int containerCPUs = getAvailableProcessors();
> 95:                 // scale the total host load to the actual container cpus
> 96:                 hostTicks = (long) (hostTicks * (1.0 * containerCPUs / totalCPUs));

The intent is to ensure floating point arithmetic on the second expression, right? A clearer way to express this may be the following. This avoids the `1.0` constant:


hostTicks = (long) (hostTicks * ((double) containerCPUs)/ totalCPUs)

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

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

From kevinw at openjdk.java.net  Wed Mar 30 09:23:40 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 30 Mar 2022 09:23:40 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v3]
In-Reply-To: <PLg5XykYH9Klr6Gsl_oldxe80eX42qMyA8SjVhygTgs=.6d3c92d1-0e70-4ab7-ad83-2922954ac8b0@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <PLg5XykYH9Klr6Gsl_oldxe80eX42qMyA8SjVhygTgs=.6d3c92d1-0e70-4ab7-ad83-2922954ac8b0@github.com>
Message-ID: <Ky5bF9qrwNY4kbNEXaibUsPj6gNxyTrHvFGfZYJqaZQ=.f934797e-1707-4cb7-be6a-9b53957756b6@github.com>

On Wed, 30 Mar 2022 06:20:19 GMT, xpbob <duke at openjdk.java.net> wrote:

>> ```        
>>                long hostTicks = getHostTotalCpuTicks0();
>>                 int totalCPUs = getHostOnlineCpuCount0();
>>                 int containerCPUs = getAvailableProcessors();
>>                 // scale the total host load to the actual container cpus
>>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
>> 
>> hostTicks=175476155560000000
>> totalCPUs=96
>> containerCPUs=90
>> 
>> Calculate the overflow
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the expression

Hi,
Could the bug description be updated to state what the problem is, and under what circumstances is there a problem?

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

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

From sgehwolf at openjdk.java.net  Wed Mar 30 09:23:40 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 30 Mar 2022 09:23:40 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v3]
In-Reply-To: <Ky5bF9qrwNY4kbNEXaibUsPj6gNxyTrHvFGfZYJqaZQ=.f934797e-1707-4cb7-be6a-9b53957756b6@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <PLg5XykYH9Klr6Gsl_oldxe80eX42qMyA8SjVhygTgs=.6d3c92d1-0e70-4ab7-ad83-2922954ac8b0@github.com>
 <Ky5bF9qrwNY4kbNEXaibUsPj6gNxyTrHvFGfZYJqaZQ=.f934797e-1707-4cb7-be6a-9b53957756b6@github.com>
Message-ID: <nBizyi7Et_RcrMFjP-LlW069Mh4U3fp0FzI3yHnhEz0=.4dd541fa-5ec1-467f-9269-9bdfcad9bb78@github.com>

On Wed, 30 Mar 2022 09:17:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Hi, Could the bug description be updated to state what the problem is, and under what circumstances is there a problem?

+1

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

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

From duke at openjdk.java.net  Wed Mar 30 09:52:45 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 30 Mar 2022 09:52:45 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v3]
In-Reply-To: <Ky5bF9qrwNY4kbNEXaibUsPj6gNxyTrHvFGfZYJqaZQ=.f934797e-1707-4cb7-be6a-9b53957756b6@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <PLg5XykYH9Klr6Gsl_oldxe80eX42qMyA8SjVhygTgs=.6d3c92d1-0e70-4ab7-ad83-2922954ac8b0@github.com>
 <Ky5bF9qrwNY4kbNEXaibUsPj6gNxyTrHvFGfZYJqaZQ=.f934797e-1707-4cb7-be6a-9b53957756b6@github.com>
Message-ID: <_PRmHMae2S0C85lpS9DJG72zun3vn13NTx_waJIyB4M=.a53b8874-97ae-4d0c-a856-33ec1eb96920@github.com>

On Wed, 30 Mar 2022 09:17:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change the expression
>
> Hi,
> Could the bug description be updated to state what the problem is, and under what circumstances is there a problem?

@kevinjwalls @jerboaa 
Thanks to review.
I updated bug descriptions, runtime data,  and reproduction methods

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

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

From duke at openjdk.java.net  Wed Mar 30 09:52:46 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 30 Mar 2022 09:52:46 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v3]
In-Reply-To: <fevbrBAKkJvk1yP4NqbgAnYsSwdfkMxV55BpU-a8P34=.b161d37d-a0b9-4321-8d5a-695f92ef130b@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <PLg5XykYH9Klr6Gsl_oldxe80eX42qMyA8SjVhygTgs=.6d3c92d1-0e70-4ab7-ad83-2922954ac8b0@github.com>
 <fevbrBAKkJvk1yP4NqbgAnYsSwdfkMxV55BpU-a8P34=.b161d37d-a0b9-4321-8d5a-695f92ef130b@github.com>
Message-ID: <Ue5kau5snF8XpLh6SD7hLowfBgPgUGPryobKBQEB4Ws=.506ca04b-5ceb-4e4d-8497-86261bae025b@github.com>

On Wed, 30 Mar 2022 09:04:25 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The intent is to ensure floating point arithmetic on the second expression, right? A clearer way to express this may be the following. This avoids the `1.0` constant:
> 
> ```
> hostTicks = (long) (hostTicks * ((double) containerCPUs)/ totalCPUs)
> ```

1.0 used to convert the data type to floating point and compute the division first

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

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

From sgehwolf at openjdk.java.net  Wed Mar 30 10:16:38 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 30 Mar 2022 10:16:38 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v3]
In-Reply-To: <Ue5kau5snF8XpLh6SD7hLowfBgPgUGPryobKBQEB4Ws=.506ca04b-5ceb-4e4d-8497-86261bae025b@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <PLg5XykYH9Klr6Gsl_oldxe80eX42qMyA8SjVhygTgs=.6d3c92d1-0e70-4ab7-ad83-2922954ac8b0@github.com>
 <fevbrBAKkJvk1yP4NqbgAnYsSwdfkMxV55BpU-a8P34=.b161d37d-a0b9-4321-8d5a-695f92ef130b@github.com>
 <Ue5kau5snF8XpLh6SD7hLowfBgPgUGPryobKBQEB4Ws=.506ca04b-5ceb-4e4d-8497-86261bae025b@github.com>
Message-ID: <F03TzuTqJcfpUFX0OjbuafDKK1KE0FCCTnfkap7Vxlk=.81d2fd5a-123b-4357-86c6-aad7df590e89@github.com>

On Wed, 30 Mar 2022 09:49:47 GMT, xpbob <duke at openjdk.java.net> wrote:

>> src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 96:
>> 
>>> 94:                 int containerCPUs = getAvailableProcessors();
>>> 95:                 // scale the total host load to the actual container cpus
>>> 96:                 hostTicks = (long) (hostTicks * (1.0 * containerCPUs / totalCPUs));
>> 
>> The intent is to ensure floating point arithmetic on the second expression, right? A clearer way to express this may be the following. This avoids the `1.0` constant:
>> 
>> 
>> hostTicks = (long) (hostTicks * ((double) containerCPUs)/ totalCPUs)
>
>> The intent is to ensure floating point arithmetic on the second expression, right? A clearer way to express this may be the following. This avoids the `1.0` constant:
>> 
>> ```
>> hostTicks = (long) (hostTicks * ((double) containerCPUs)/ totalCPUs)
>> ```
> 
> 1.0 used to convert the data type to floating point and compute the division first

Right. It seems a strange way to achieve this. Maybe consider this instead?

double scaleFactor = ((double)containerCPUs)/totalCPUs;
hostTicks = (long)(hostTicks * scaleFactor);

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

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

From duke at openjdk.java.net  Wed Mar 30 11:02:18 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 30 Mar 2022 11:02:18 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v4]
In-Reply-To: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
Message-ID: <nTf6ajM4CRPQE35Xmq9NTLDBfUMcaOjpkbr6uKSjavs=.3db58a89-e4bc-420e-a322-bec269536500@github.com>

> ```        
>                long hostTicks = getHostTotalCpuTicks0();
>                 int totalCPUs = getHostOnlineCpuCount0();
>                 int containerCPUs = getAvailableProcessors();
>                 // scale the total host load to the actual container cpus
>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
> 
> hostTicks=175476155560000000
> totalCPUs=96
> containerCPUs=90
> 
> Calculate the overflow

xpbob has updated the pull request incrementally with one additional commit since the last revision:

  Change the expression

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8028/files
  - new: https://git.openjdk.java.net/jdk/pull/8028/files/a1fda8a4..96184502

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

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

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

From duke at openjdk.java.net  Wed Mar 30 11:02:19 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 30 Mar 2022 11:02:19 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v3]
In-Reply-To: <nBizyi7Et_RcrMFjP-LlW069Mh4U3fp0FzI3yHnhEz0=.4dd541fa-5ec1-467f-9269-9bdfcad9bb78@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <PLg5XykYH9Klr6Gsl_oldxe80eX42qMyA8SjVhygTgs=.6d3c92d1-0e70-4ab7-ad83-2922954ac8b0@github.com>
 <Ky5bF9qrwNY4kbNEXaibUsPj6gNxyTrHvFGfZYJqaZQ=.f934797e-1707-4cb7-be6a-9b53957756b6@github.com>
 <nBizyi7Et_RcrMFjP-LlW069Mh4U3fp0FzI3yHnhEz0=.4dd541fa-5ec1-467f-9269-9bdfcad9bb78@github.com>
Message-ID: <dj31mCGdE_uxajud1ouUTtJAK-zAYzJpCZKejuUV4e8=.8e2702df-4f6e-4382-bfe1-eb9ce1909f87@github.com>

On Wed, 30 Mar 2022 09:20:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Hi,
>> Could the bug description be updated to state what the problem is, and under what circumstances is there a problem?
>
>> Hi, Could the bug description be updated to state what the problem is, and under what circumstances is there a problem?
> 
> +1

@jerboaa 
Thanks
It is more accurate to explicitly convert data types

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

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

From kcr at openjdk.java.net  Wed Mar 30 11:35:38 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 30 Mar 2022 11:35:38 GMT
Subject: jmx-dev RFR: 8283805: [REDO] JDK 19 L10n resource files update
 - msgdrop 10
In-Reply-To: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
References: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
Message-ID: <EnIpfAYY92S_YJGTVXtEYAlGCdqtzUcbzEmSV1_Zduo=.eb6608f2-1158-474a-80bb-118baf99af89@github.com>

On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung <achung at openjdk.org> wrote:

> redo of 8280400

Since this is identical to the original fix, I would expect the same Tier2 test failure as reported in [JDK-8283804](https://bugs.openjdk.java.net/browse/JDK-8283804).

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

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

From sgehwolf at openjdk.java.net  Wed Mar 30 11:55:37 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 30 Mar 2022 11:55:37 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v4]
In-Reply-To: <nTf6ajM4CRPQE35Xmq9NTLDBfUMcaOjpkbr6uKSjavs=.3db58a89-e4bc-420e-a322-bec269536500@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <nTf6ajM4CRPQE35Xmq9NTLDBfUMcaOjpkbr6uKSjavs=.3db58a89-e4bc-420e-a322-bec269536500@github.com>
Message-ID: <gSTELrFpZd6xF83BarvUlosGcWHbMxn2wrpLnexIme4=.ae75a27f-0d55-42f5-9dc8-b0393dfe53ff@github.com>

On Wed, 30 Mar 2022 11:02:18 GMT, xpbob <duke at openjdk.java.net> wrote:

>> ```        
>>                long hostTicks = getHostTotalCpuTicks0();
>>                 int totalCPUs = getHostOnlineCpuCount0();
>>                 int containerCPUs = getAvailableProcessors();
>>                 // scale the total host load to the actual container cpus
>>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
>> 
>> hostTicks=175476155560000000
>> totalCPUs=96
>> containerCPUs=90
>> 
>> Calculate the overflow
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the expression

Thanks. This seems easier to read and shows the intent more clearly.

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

Marked as reviewed by sgehwolf (Reviewer).

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

From kevinw at openjdk.java.net  Wed Mar 30 12:22:45 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 30 Mar 2022 12:22:45 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v4]
In-Reply-To: <nTf6ajM4CRPQE35Xmq9NTLDBfUMcaOjpkbr6uKSjavs=.3db58a89-e4bc-420e-a322-bec269536500@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <nTf6ajM4CRPQE35Xmq9NTLDBfUMcaOjpkbr6uKSjavs=.3db58a89-e4bc-420e-a322-bec269536500@github.com>
Message-ID: <ePCwgpSS6C_cB70kJu-5Hu4-6jIH0HHUN55FAj46J4A=.e4bf94ae-e0a0-4d03-beab-d13b6a5bc52d@github.com>

On Wed, 30 Mar 2022 11:02:18 GMT, xpbob <duke at openjdk.java.net> wrote:

>> ```        
>>                long hostTicks = getHostTotalCpuTicks0();
>>                 int totalCPUs = getHostOnlineCpuCount0();
>>                 int containerCPUs = getAvailableProcessors();
>>                 // scale the total host load to the actual container cpus
>>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
>> 
>> hostTicks=175476155560000000
>> totalCPUs=96
>> containerCPUs=90
>> 
>> Calculate the overflow
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the expression

Marked as reviewed by kevinw (Committer).

OK thanks for the description update, and I think the updated code is better also.

I guess the app has not been running with the fix long enough to test it fully yet?  But if it's looking good so far and reporting good information, and any other tests are unaffected, then looks good.

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

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

From dholmes at openjdk.java.net  Wed Mar 30 13:37:46 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 30 Mar 2022 13:37:46 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode [v4]
In-Reply-To: <nTf6ajM4CRPQE35Xmq9NTLDBfUMcaOjpkbr6uKSjavs=.3db58a89-e4bc-420e-a322-bec269536500@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <nTf6ajM4CRPQE35Xmq9NTLDBfUMcaOjpkbr6uKSjavs=.3db58a89-e4bc-420e-a322-bec269536500@github.com>
Message-ID: <Ah7eeS8mrxR-ieFyE5VUL4e-2Zx_icLwsc0qaG25ZPU=.94e675db-0c21-4108-a1a8-c0fdc0254433@github.com>

On Wed, 30 Mar 2022 11:02:18 GMT, xpbob <duke at openjdk.java.net> wrote:

>> ```        
>>                long hostTicks = getHostTotalCpuTicks0();
>>                 int totalCPUs = getHostOnlineCpuCount0();
>>                 int containerCPUs = getAvailableProcessors();
>>                 // scale the total host load to the actual container cpus
>>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
>> 
>> hostTicks=175476155560000000
>> totalCPUs=96
>> containerCPUs=90
>> 
>> Calculate the overflow
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the expression

That works too. :)

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

Marked as reviewed by dholmes (Reviewer).

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

From duke at openjdk.java.net  Wed Mar 30 15:11:44 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 30 Mar 2022 15:11:44 GMT
Subject: jmx-dev RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode
In-Reply-To: <ECFMA5NaTPB0TBityCbTbRbsuwLY5CSaYHbL1kwPjdE=.bf2bb463-9cc3-4aa3-9e49-e5c78e01477c@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
 <HHAYLQ9cbRVt6_4w930pXY7fjsb9k4B5HDflnm4c48E=.7d423e98-2791-4fb8-b3c9-6b9fe286313b@github.com>
 <WQ9AS95JFR_PV2se1heNtfhIp0bwxtpdBe8KqpGnRb8=.642a016b-3769-41e6-b6aa-064c5278a8a1@github.com>
 <5kr3nhfYI_WPXHI-f8UwPw8dxJCLiA1STQEUsJM1ocw=.c486c8c3-48b3-4a44-8b27-61b5820fcca9@github.com>
 <CNEzg9q_xg4huBcQ0VCxaS9ZVUYo9D1UfzsUjqFLkdk=.0a2a41c4-8c47-4a9d-bebb-781f7097e08d@github.com>
 <ECFMA5NaTPB0TBityCbTbRbsuwLY5CSaYHbL1kwPjdE=.bf2bb463-9cc3-4aa3-9e49-e5c78e01477c@github.com>
Message-ID: <a_PiiT606dUUSfcrJtHp808-xIrAPqlU-nrBFh75c4A=.29af2d77-2762-4960-ae14-9ee9fd7ec93c@github.com>

On Wed, 30 Mar 2022 03:17:23 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> > In share mode, the process runs for a long time and the number of physical machine cores is large, making it easier to reappear.
>>> 
>>> So if we run long enough, the `getHostTotalCpuTicks0()` may return overflowed `hostTicks`, right?
>> 
>> GetHostTotalCpuTicks0 is correct
>> (GetHostTotalCpuTicks0() * containerCPUs)  will overflowed
>
>> GetHostTotalCpuTicks0 is correct
>> (GetHostTotalCpuTicks0() * containerCPUs) will overflowed
> 
> Okay.
> It makes sense for this case.
> 
> Maybe, there is no way to prevent the overflow of `hostTicks ` returned by `getHostTotalCpuTicks0()`.
> So the change looks good to me.
> Thanks.

Thanks for the reviews @DamonFool @dholmes-ora @jerboaa  @kevinjwalls

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

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

From naoto at openjdk.java.net  Wed Mar 30 15:48:38 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 30 Mar 2022 15:48:38 GMT
Subject: jmx-dev RFR: 8283805: [REDO] JDK 19 L10n resource files update
 - msgdrop 10
In-Reply-To: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
References: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
Message-ID: <a41NNQJWMB7s3ZKC9Oc0wOR6djcVyJwClVqybrBHmto=.7cabbe09-19b7-414f-8843-c2490eab98ea@github.com>

On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung <achung at openjdk.org> wrote:

> redo of 8280400

I believe `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties` and `test/jdk/sun/text/resources/LocaleData` have to be adjusted according to the l10n changes.

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

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

From duke at openjdk.java.net  Wed Mar 30 17:10:45 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 30 Mar 2022 17:10:45 GMT
Subject: jmx-dev Integrated: 8283903: GetContainerCpuLoad does not return
 the correct result in share mode
In-Reply-To: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
References: <nry5dXH1Ms0g3ZAf4HuAZTUJQvDB_zHIrfhqYYdnAek=.eee4bc22-8787-4ce4-9206-bb136fe0a312@github.com>
Message-ID: <d-EkhLYs7CORZlKaDrdiWcqBFijfyPmyRuEDE3qAzDo=.7ed165d3-fccf-460c-950c-c782bf9a895a@github.com>

On Wed, 30 Mar 2022 01:46:20 GMT, xpbob <duke at openjdk.java.net> wrote:

> ```        
>                long hostTicks = getHostTotalCpuTicks0();
>                 int totalCPUs = getHostOnlineCpuCount0();
>                 int containerCPUs = getAvailableProcessors();
>                 // scale the total host load to the actual container cpus
>                 hostTicks = hostTicks * containerCPUs / totalCPUs;
> 
> hostTicks=175476155560000000
> totalCPUs=96
> containerCPUs=90
> 
> Calculate the overflow

This pull request has now been integrated.

Changeset: a625bfdb
Author:    bobpengxie <bobpengxie at tencent.com>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a625bfdba45d49bc717bcc9be4112db93b50f50a
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8283903: GetContainerCpuLoad does not return the correct result in share mode

Reviewed-by: jiefu, sgehwolf, kevinw, dholmes

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

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