From tschatzl at openjdk.org  Mon Jan  2 14:21:58 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 2 Jan 2023 14:21:58 GMT
Subject: jmx-dev [jdk20] RFR: 8293824:
 gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue:
 expected true, was false"
In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
Message-ID: <yh2BaduQswhcrupfR0oBzQxelQzkpwSkdIVNRBMWqus=.a15ab5f2-1855-4c7e-8719-39611e1ccd02@github.com>

On Thu, 22 Dec 2022 02:04:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to WhiteBox and some tests involving G1 concurrent GCs.
> 
> Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
> concurrent GC.  Many of them follow it with a loop waiting for a concurrent
> cycle to not be in progress.  A few also preceed that call with a similar
> loop, since that call does nothing and returns false if a concurrent cycle is
> already in progress.  Those tests typically want to ensure there was a
> concurrent cycle that was started after some setup.
> 
> The failing test calls that function, asserting that it returned true, e.g. a
> new concurrent cycle was started.
> 
> There are various problems with this, due to races with concurrent cycles
> started automatically, and due to possibly aborted (by full GCs) concurrent cycles,
> making some of these tests unreliable in some configurations.
> 
> For example, the test failure associated with this bug intermittently arises
> when running with `-Xcomp`, triggering a concurrent cycle before the explicit
> request by the test, causing the explicit request to fail (because there is
> already one in progress), failing the assert.  Waiting for there not to be an
> in-progress cycle before the explicit request just narrows the race window.
> 
> We have a different mechanism in WhiteBox for controlling concurrent cycles,
> the concurrent GC breakpoint mechanism.  By adding a counter specifically for
> such cycles, we can use GC breakpoints to ensure only the concurrent cycles
> the test wants are occurring, and can verify they completed successfully.
> 
> So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
> breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
> avoid racing request problems and to detect aborted cycles.  Since it is no
> longer used, WhiteBox.g1StartConcMarkCycle() is removed.  The test that began
> this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer
> serves any purpose, having been purely a test of that removed function.
> 
> Testing:
> mach5 tier1-7 - running the changed tests on a variety of platforms with a
> variety of configurations.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/71

From kbarrett at openjdk.org  Wed Jan  4 03:27:19 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 4 Jan 2023 03:27:19 GMT
Subject: jmx-dev [jdk20] RFR: 8293824:
 gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue:
 expected true, was false" [v2]
In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
Message-ID: <2wRK9LZ0L4QdgzNhCM2bya3emb4zU9OTwvt5VnyzO0E=.0b22adcb-c49b-4a46-bf8a-82975ea1d514@github.com>

> Please review this change to WhiteBox and some tests involving G1 concurrent GCs.
> 
> Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
> concurrent GC.  Many of them follow it with a loop waiting for a concurrent
> cycle to not be in progress.  A few also preceed that call with a similar
> loop, since that call does nothing and returns false if a concurrent cycle is
> already in progress.  Those tests typically want to ensure there was a
> concurrent cycle that was started after some setup.
> 
> The failing test calls that function, asserting that it returned true, e.g. a
> new concurrent cycle was started.
> 
> There are various problems with this, due to races with concurrent cycles
> started automatically, and due to possibly aborted (by full GCs) concurrent cycles,
> making some of these tests unreliable in some configurations.
> 
> For example, the test failure associated with this bug intermittently arises
> when running with `-Xcomp`, triggering a concurrent cycle before the explicit
> request by the test, causing the explicit request to fail (because there is
> already one in progress), failing the assert.  Waiting for there not to be an
> in-progress cycle before the explicit request just narrows the race window.
> 
> We have a different mechanism in WhiteBox for controlling concurrent cycles,
> the concurrent GC breakpoint mechanism.  By adding a counter specifically for
> such cycles, we can use GC breakpoints to ensure only the concurrent cycles
> the test wants are occurring, and can verify they completed successfully.
> 
> So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
> breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
> avoid racing request problems and to detect aborted cycles.  Since it is no
> longer used, WhiteBox.g1StartConcMarkCycle() is removed.  The test that began
> this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer
> serves any purpose, having been purely a test of that removed function.
> 
> Testing:
> mach5 tier1-7 - running the changed tests on a variety of platforms with a
> variety of configurations.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into test-concmark20
 - use gc breakpoints to perform conc gc

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/71/files
  - new: https://git.openjdk.org/jdk20/pull/71/files/39abc3dc..3b837273

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=71&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=71&range=00-01

  Stats: 786 lines in 35 files changed: 563 ins; 95 del; 128 mod
  Patch: https://git.openjdk.org/jdk20/pull/71.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/71/head:pull/71

PR: https://git.openjdk.org/jdk20/pull/71

From kbarrett at openjdk.org  Wed Jan  4 03:27:20 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 4 Jan 2023 03:27:20 GMT
Subject: jmx-dev [jdk20] RFR: 8293824:
 gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue:
 expected true, was false" [v2]
In-Reply-To: <KDWDqPiHkgakhFDbNdeWz5erUt1A2CBCXvk2SfwpkMw=.70bed1bf-5922-404f-8159-ee31cf1ed2bf@github.com>
References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
 <KDWDqPiHkgakhFDbNdeWz5erUt1A2CBCXvk2SfwpkMw=.70bed1bf-5922-404f-8159-ee31cf1ed2bf@github.com>
Message-ID: <ewHWLarptGnibDEJTirjYVjDhwXrryihc_rkYqqthm4=.a75a2dca-9492-48d2-ad3e-c182ccd2530c@github.com>

On Thu, 22 Dec 2022 16:11:46 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into test-concmark20
>>  - use gc breakpoints to perform conc gc
>
> Lgtm!

Thanks for reviews @walulyai and @tschatzl .

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

PR: https://git.openjdk.org/jdk20/pull/71

From kbarrett at openjdk.org  Wed Jan  4 03:31:57 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 4 Jan 2023 03:31:57 GMT
Subject: jmx-dev [jdk20] Integrated: 8293824:
 gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue:
 expected true, was false"
In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
Message-ID: <JP7DknMo4cvi0uHYqU_AKWuC_ouQKrYzHuilNma12w8=.53ade68c-0c5d-485f-856b-80298124e7ed@github.com>

On Thu, 22 Dec 2022 02:04:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to WhiteBox and some tests involving G1 concurrent GCs.
> 
> Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
> concurrent GC.  Many of them follow it with a loop waiting for a concurrent
> cycle to not be in progress.  A few also preceed that call with a similar
> loop, since that call does nothing and returns false if a concurrent cycle is
> already in progress.  Those tests typically want to ensure there was a
> concurrent cycle that was started after some setup.
> 
> The failing test calls that function, asserting that it returned true, e.g. a
> new concurrent cycle was started.
> 
> There are various problems with this, due to races with concurrent cycles
> started automatically, and due to possibly aborted (by full GCs) concurrent cycles,
> making some of these tests unreliable in some configurations.
> 
> For example, the test failure associated with this bug intermittently arises
> when running with `-Xcomp`, triggering a concurrent cycle before the explicit
> request by the test, causing the explicit request to fail (because there is
> already one in progress), failing the assert.  Waiting for there not to be an
> in-progress cycle before the explicit request just narrows the race window.
> 
> We have a different mechanism in WhiteBox for controlling concurrent cycles,
> the concurrent GC breakpoint mechanism.  By adding a counter specifically for
> such cycles, we can use GC breakpoints to ensure only the concurrent cycles
> the test wants are occurring, and can verify they completed successfully.
> 
> So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
> breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
> avoid racing request problems and to detect aborted cycles.  Since it is no
> longer used, WhiteBox.g1StartConcMarkCycle() is removed.  The test that began
> this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer
> serves any purpose, having been purely a test of that removed function.
> 
> Testing:
> mach5 tier1-7 - running the changed tests on a variety of platforms with a
> variety of configurations.

This pull request has now been integrated.

Changeset: b743519b
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/b743519ba911a254669fa8a96e6006c14e3f5ad1
Stats:     288 lines in 24 files changed: 98 ins; 131 del; 59 mod

8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false"

Reviewed-by: iwalulya, tschatzl

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

PR: https://git.openjdk.org/jdk20/pull/71

From jwilhelm at openjdk.org  Wed Jan  4 14:34:19 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 4 Jan 2023 14:34:19 GMT
Subject: jmx-dev RFR: Merge jdk20
Message-ID: <zDvWYKrrzE24L5hYEI-x2F3F8HzwFFX8jhk9K7-uQgY=.35dbb7d4-fb82-4fa8-bf34-4de6a5b2bda4@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8299476: PPC64 Zero build fails after JDK-8286302
 - 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false"
 - 8299483: ProblemList java/text/Format/NumberFormat/CurrencyFormat.java
 - 8298324: Unable to run shell test with make
 - 8299235: broken link referencing missing id

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11845&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11845&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11845/files
  Stats: 299 lines in 28 files changed: 101 ins; 131 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/11845.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11845/head:pull/11845

PR: https://git.openjdk.org/jdk/pull/11845

From jwilhelm at openjdk.org  Wed Jan  4 16:06:57 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 4 Jan 2023 16:06:57 GMT
Subject: jmx-dev Integrated: Merge jdk20
In-Reply-To: <zDvWYKrrzE24L5hYEI-x2F3F8HzwFFX8jhk9K7-uQgY=.35dbb7d4-fb82-4fa8-bf34-4de6a5b2bda4@github.com>
References: <zDvWYKrrzE24L5hYEI-x2F3F8HzwFFX8jhk9K7-uQgY=.35dbb7d4-fb82-4fa8-bf34-4de6a5b2bda4@github.com>
Message-ID: <Y9iOsvwOKa2PrIXFCB5jl5Sa5fBfVzSNRFNvEdGXuoE=.71580b8a-7e64-4ca9-828a-bdffc14b90cd@github.com>

On Wed, 4 Jan 2023 14:25:12 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: df1caf90
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df1caf90818558b897a6b8ab80757f2a03398c55
Stats:     299 lines in 28 files changed: 101 ins; 131 del; 67 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/11845

From duke at openjdk.org  Fri Jan  6 02:45:18 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 6 Jan 2023 02:45:18 GMT
Subject: jmx-dev RFR: 8015831: Add lint check for calling overridable
 methods from a constructor
Message-ID: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>

This PR adds a new lint warning category `this-escape`.

It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.

A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
* Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
* Some constructor `B()` of `B` invokes `A()` as its superclass constructor
* During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly

In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.

Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.

>From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.

For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.

More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.

Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.

Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.

**Patch Navigation Guide**

* Non-trivial compiler changes:
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`

* Javadoc additions of `@implNote`:

    * `src/java.base/share/classes/java/io/PipedReader.java`
    * `src/java.base/share/classes/java/io/PipedWriter.java`
    * `src/java.base/share/classes/java/lang/Throwable.java`
    * `src/java.base/share/classes/java/util/ArrayDeque.java`
    * `src/java.base/share/classes/java/util/EnumMap.java`
    * `src/java.base/share/classes/java/util/HashSet.java`
    * `src/java.base/share/classes/java/util/Hashtable.java`
    * `src/java.base/share/classes/java/util/LinkedList.java`
    * `src/java.base/share/classes/java/util/TreeMap.java`
    * `src/java.base/share/classes/java/util/TreeSet.java`

* New unit tests
    * `test/langtools/tools/javac/warnings/ThisEscape/*.java`

* **Everything else** is just adding `@SuppressWarnings("this-escape")`

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

Commit messages:
 - Remove trailing whitespace.
 - Some documentation tweaks.
 - Treat method references like the equivalent lambda.
 - Fix bug where initializers could generate duplicate warnings.
 - Javadoc fix.
 - Add ThisEscape.html doc note and link the new @implNote's to it.
 - Add more @SuppressWarnings("this-escape") annotations.
 - Add more @SuppressWarnings("this-escape") annotations.
 - Add more @SuppressWarnings("this-escape") annotations.
 - Add more @SuppressWarnings("this-escape") annotations.
 - ... and 38 more: https://git.openjdk.org/jdk/compare/c6588d5b...9c162283

Changes: https://git.openjdk.org/jdk/pull/11874/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8015831
  Stats: 4326 lines in 1285 files changed: 4259 ins; 3 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874

From dholmes at openjdk.org  Fri Jan  6 04:51:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 6 Jan 2023 04:51:00 GMT
Subject: jmx-dev RFR: 8015831: Add lint check for calling overridable
 methods from a constructor
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>

On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Hi Archie,

The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere?

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

PR: https://git.openjdk.org/jdk/pull/11874

From alanb at openjdk.org  Fri Jan  6 07:53:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jan 2023 07:53:54 GMT
Subject: jmx-dev RFR: 8015831: Add lint check for calling overridable
 methods from a constructor
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <Hnu2IeLr21reuXeHYgIlKiNCwQ9zJLeg9dykcL_Y8KM=.67209ee1-a778-4bae-a7a8-d61e860f7b23@github.com>

On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

This looks like a very useful lint warning to have but this PR is unwieldy. If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially.

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

PR: https://git.openjdk.org/jdk/pull/11874

From kevinw at openjdk.org  Fri Jan  6 13:19:22 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 6 Jan 2023 13:19:22 GMT
Subject: jmx-dev RFR: 8299112: HashedPasswordFileTest.java and
 ExceptionTest.java fails with java.lang.NullPointerException
Message-ID: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>

Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
We must only call close if this is not null.

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

Commit messages:
 - 8299112: HashedPasswordFileTest.java and ExceptionTest.java fails with java.lang.NullPointerException

Changes: https://git.openjdk.org/jdk/pull/11881/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11881&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299112
  Stats: 18 lines in 2 files changed: 9 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11881.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11881/head:pull/11881

PR: https://git.openjdk.org/jdk/pull/11881

From duke at openjdk.org  Fri Jan  6 14:51:54 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 6 Jan 2023 14:51:54 GMT
Subject: jmx-dev RFR: 8015831: Add lint check for calling overridable
 methods from a constructor
In-Reply-To: <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
Message-ID: <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>

On Fri, 6 Jan 2023 04:48:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere?

Hi @dholmes-ora,

The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc.

Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds.

Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. 

> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details.

Hi @AlanBateman,

As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well.

> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially.

Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?

If this is generally agreed as a better route then let me know and I'll update the patch.

Thanks for both of your comments.

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

PR: https://git.openjdk.org/jdk/pull/11874

From alanb at openjdk.org  Fri Jan  6 15:41:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jan 2023 15:41:16 GMT
Subject: jmx-dev RFR: 8015831: Add lint check for calling overridable
 methods from a constructor
In-Reply-To: <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
Message-ID: <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>

On Fri, 6 Jan 2023 14:49:16 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
> 
> If this is generally agreed as a better route then let me know and I'll update the patch.

Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Fri Jan  6 15:57:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Jan 2023 15:57:50 GMT
Subject: jmx-dev RFR: 8015831: Add lint check for calling overridable
 methods from a constructor
In-Reply-To: <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
 <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
Message-ID: <D_mLssKO7VlglPgP2sf3S1seKgyuJazeTrpnURCpxQk=.7e318df2-ef54-484c-9cb2-bea1100fe949@github.com>

On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere?
>> 
>> Hi @dholmes-ora,
>> 
>> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc.
>> 
>> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds.
>> 
>> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. 
>> 
>>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details.
>> 
>> Hi @AlanBateman,
>> 
>> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well.
>> 
>>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially.
>> 
>> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
>> 
>> If this is generally agreed as a better route then let me know and I'll update the patch.
>> 
>> Thanks for both of your comments.
>
>> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
>> 
>> If this is generally agreed as a better route then let me know and I'll update the patch.
> 
> Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.

I agree with @AlanBateman. When we introduced similar warnings in the past, we have enabled support in javac (with some test) in a separate PR, and then followed up with small dedicated PR for each of the various areas (enabling new warnings one by one).

See this great umbrella JBS issue (created by @asotona) which has details on all the issues that were filed when we added an extra Lint warning for lossy conversions:

https://bugs.openjdk.org/browse/JDK-8286374

They all refer to this:

https://bugs.openjdk.org/browse/JDK-8244681

Which was submitted as a separate javac-only PR:
https://github.com/openjdk/jdk/pull/8599

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

PR: https://git.openjdk.org/jdk/pull/11874

From sspitsyn at openjdk.org  Fri Jan  6 17:48:52 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 6 Jan 2023 17:48:52 GMT
Subject: jmx-dev RFR: 8299739: HashedPasswordFileTest.java and
 ExceptionTest.java can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <4am0cKTtgvOUXiVcrcVpeRZ0lw0yDhbMBua7AejtBmA=.7edac3f6-56b5-4dc1-b1e0-eeebb9eefa79@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11881

From cjplummer at openjdk.org  Fri Jan  6 19:14:50 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 6 Jan 2023 19:14:50 GMT
Subject: jmx-dev RFR: 8299739: HashedPasswordFileTest.java and
 ExceptionTest.java can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <0-cc5qcwvvB385rZYtIXAdzWPLApYZqxGgI1r9P2KVU=.abc27141-122e-4fcb-a893-3f7f2cee122d@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

I looks like ExceptionTest.java does log the exception before hitting the NPE. Were you not seeing it in the log?

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

PR: https://git.openjdk.org/jdk/pull/11881

From duke at openjdk.org  Fri Jan  6 23:13:09 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 6 Jan 2023 23:13:09 GMT
Subject: jmx-dev RFR: 8015831: Add lint check for calling overridable
 methods from a constructor [v2]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <QUOGIQWxLc_RT0xtonZXdnCxSUR7Gkw3vj4MSp8wiW8=.23bbeb90-21fe-435a-a4e3-d631ebab9ad6@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year for newly added files to 2023.
 - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/9c162283..f667cd56

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00-01

  Stats: 1935 lines in 1303 files changed: 60 ins; 1770 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Fri Jan  6 23:13:09 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 6 Jan 2023 23:13:09 GMT
Subject: jmx-dev RFR: 8015831: Add lint check for calling overridable
 methods from a constructor
In-Reply-To: <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
 <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
Message-ID: <D_16yzU3GKCNp3muk32Ykwpy9od0qdOohTmBO8Gt_Es=.c914efeb-2b98-44ef-891a-7480fb094315@github.com>

On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere?
>> 
>> Hi @dholmes-ora,
>> 
>> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc.
>> 
>> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds.
>> 
>> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. 
>> 
>>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details.
>> 
>> Hi @AlanBateman,
>> 
>> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well.
>> 
>>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially.
>> 
>> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
>> 
>> If this is generally agreed as a better route then let me know and I'll update the patch.
>> 
>> Thanks for both of your comments.
>
>> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
>> 
>> If this is generally agreed as a better route then let me know and I'll update the patch.
> 
> Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.

Hi @AlanBateman,

OK that sounds like a plan. I've pushed a new commit to the `ThisEscape` branch that removes all the`@SuppressWarnings` annotations and replaces them with adjustments to build flags.

I've moved the `@SuppressWarnings` annotations onto a new branch `ThisEscapeAnnotations`. This is just for future reference in case somebody wants to add them back someday and doesn't want to start from scratch.

>  I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.

Hmm. Hasn't that horse already left the barn? You kind of implied that when you said:

> I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor.

In other words, it doesn't sound like changing the behavior of these constructors is viable option at this point. And if that's the case, we might as well document and warn about the current behavior.

Of course I'd love to be wrong... in which case, we can fix these constructors.

Or, the third option - just do nothing yet. That would mean removing the warnings, which is fine.

But then the `ThisEscape.html` document is orphaned. What should we do with it? I can remove it, just leave it there, or put it somewhere else (where?).

It seems like having some documentation of the meaning of "this escape" would be helpful, because it's a subtle concept and there are multiple ways to define "escape".

Thanks.

@mcimadamore thanks for the bugs suggestion, I'll put that on the to-do list.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Sat Jan  7 16:24:56 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 7 Jan 2023 16:24:56 GMT
Subject: jmx-dev RFR: 8015831: Add lint check for calling overridable
 methods from a constructor [v2]
In-Reply-To: <QUOGIQWxLc_RT0xtonZXdnCxSUR7Gkw3vj4MSp8wiW8=.23bbeb90-21fe-435a-a4e3-d631ebab9ad6@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <QUOGIQWxLc_RT0xtonZXdnCxSUR7Gkw3vj4MSp8wiW8=.23bbeb90-21fe-435a-a4e3-d631ebab9ad6@github.com>
Message-ID: <xWYztLE9Mx-jVzvGesQ0jF5PXrQYZE_aDpOvZ6EW5K8=.70ef0e5d-3fcc-4428-bbc4-d2847fd57e69@github.com>

On Fri, 6 Jan 2023 23:13:09 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year for newly added files to 2023.
>  - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations.

src/java.base/share/classes/java/lang/AssertionError.java line 75:

> 73:      */
> 74:     @SuppressWarnings("this-escape")
> 75:     public AssertionError(Object detailMessage) {

The?Javadoc of?this?constructor should?probably?mention that?it?calls `initCause(?)` when?`detailMessage` is?a?`Throwable`.

src/java.base/share/classes/java/lang/BootstrapMethodError.java line 77:

> 75:      * Constructs a {@code BootstrapMethodError} with the specified
> 76:      * cause.
> 77:      *

Suggestion:

     *
     * @implNote This constructor invokes {@link #initCause initCause()}; see
     * <a href="{@docRoot}/java.base/java/lang/doc-files/ThisEscape.html">This Escape</a>.
     *

src/java.base/share/classes/java/lang/ExceptionInInitializerError.java line 54:

> 52:      * throwable object.
> 53:      * A detail message is a String that describes this particular exception.
> 54:      */

Suggestion:

     *
     * @implNote This constructor invokes {@link #initCause initCause()}; see
     * <a href="{@docRoot}/java.base/java/lang/doc-files/ThisEscape.html">This Escape</a>.
     */

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

PR: https://git.openjdk.org/jdk/pull/11874

From kevinw at openjdk.org  Wed Jan 11 09:50:08 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 11 Jan 2023 09:50:08 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed
Message-ID: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>

The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
javax.management.Attribute and AttributeList classes are also needed, and Query related classes.

There are a number of Query-relate classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.

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

Commit messages:
 - trailing whitespace in comment
 - change flag for testing operations vs. other classes
 - whitespace
 - 8299891: JMX ObjectInputFilter additional classes needed

Changes: https://git.openjdk.org/jdk20/pull/97/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=97&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299891
  Stats: 101 lines in 2 files changed: 92 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk20/pull/97.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/97/head:pull/97

PR: https://git.openjdk.org/jdk20/pull/97

From dfuchs at openjdk.org  Wed Jan 11 12:22:23 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Jan 2023 12:22:23 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed
In-Reply-To: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
Message-ID: <lGs05eLWSB6cvCovkp84faQllos20yPkHiLYzQiG6Ns=.634b1eb2-05cf-47c0-9130-f99ed2a44f19@github.com>

On Wed, 11 Jan 2023 09:40:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
> 
> There are a number of Query-relate classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.

I believe it would be good to add a test method that registers for notifications using a notification filter. Especially attribute change notification, possibly MBean registration too.

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

PR: https://git.openjdk.org/jdk20/pull/97

From xuelei at openjdk.org  Wed Jan 11 21:03:12 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 11 Jan 2023 21:03:12 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf in
 Xcode 14
Message-ID: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>

The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.

This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly.

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

Commit messages:
 - typo correction
 - 8299635: More test issues for deprecated sprintf in Xcode 14

Changes: https://git.openjdk.org/jdk/pull/11935/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299635
  Stats: 43 lines in 26 files changed: 4 ins; 0 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/11935.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935

PR: https://git.openjdk.org/jdk/pull/11935

From mikael at openjdk.org  Wed Jan 11 21:19:12 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 11 Jan 2023 21:19:12 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14
In-Reply-To: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
Message-ID: <qCC4cki5JEt3jiQmtZyEGIAW8hLB-OPpn3GES2IwAlc=.c1a6062d-b503-4b5b-8e2d-b8e086cb5bb1@github.com>

On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
> 
> This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly.

This PR does not address all the remaining sprintf:s in hotspot, and with it now explicitly forbidden the build will fail:


src/hotspot/os/linux/attachListener_linux.cpp: In member function 'virtual void LinuxAttachOperation::complete(jint, bufferedStream*)':
src/hotspot/os/linux/attachListener_linux.cpp:414:10: error: call to 'sprintf' declared with attribute warning: use os::snprintf [-Werror=attribute-warning]
  414 |   sprintf(msg, "%d\n", result);
      |   ~~~~~~~^~~~~~~~~~~~~~~~~~~~~


I count ~30 sprintf:s that need updating.

I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files?

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Wed Jan 11 21:32:14 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 11 Jan 2023 21:32:14 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14
In-Reply-To: <qCC4cki5JEt3jiQmtZyEGIAW8hLB-OPpn3GES2IwAlc=.c1a6062d-b503-4b5b-8e2d-b8e086cb5bb1@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <qCC4cki5JEt3jiQmtZyEGIAW8hLB-OPpn3GES2IwAlc=.c1a6062d-b503-4b5b-8e2d-b8e086cb5bb1@github.com>
Message-ID: <nxm9RxFD1m-yYZUbqWOeA_8HZuy-6lFBa1MJWHWy8NM=.9c049582-ca06-4392-b473-ab584232e92d@github.com>

On Wed, 11 Jan 2023 21:16:51 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> This PR does not address all the remaining sprintf:s in hotspot, and with it now explicitly forbidden the build will fail:
> 

This is a question to me as well.  I noticed there are still some use of sprintf, but the building passed on MacOS and Linux.  I was wondering if the following update really work (if the '...' parameter works for the forbidden?), or something else matters.


FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf");


> I count ~30 sprintf:s that need updating.
> 
> I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files?

I'm new to hotspot.  Do you know how could I enable C2?  Thanks!

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Thu Jan 12 07:28:13 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 12 Jan 2023 07:28:13 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14
In-Reply-To: <nxm9RxFD1m-yYZUbqWOeA_8HZuy-6lFBa1MJWHWy8NM=.9c049582-ca06-4392-b473-ab584232e92d@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <qCC4cki5JEt3jiQmtZyEGIAW8hLB-OPpn3GES2IwAlc=.c1a6062d-b503-4b5b-8e2d-b8e086cb5bb1@github.com>
 <nxm9RxFD1m-yYZUbqWOeA_8HZuy-6lFBa1MJWHWy8NM=.9c049582-ca06-4392-b473-ab584232e92d@github.com>
Message-ID: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com>

On Wed, 11 Jan 2023 21:29:01 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files?
> 
> I'm new to hotspot. Do you know how could I enable C2? Thanks!

Never mind, I got it from configuration help message (use --with-jvm-features=compiler2).

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

PR: https://git.openjdk.org/jdk/pull/11935

From sspitsyn at openjdk.org  Fri Jan 13 04:02:58 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 13 Jan 2023 04:02:58 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14
In-Reply-To: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
Message-ID: <yNFzRfssO_X3cmoMRnshCc49pR8UVrKrT3mt-vWxYkQ=.801188b6-0813-48a7-9fba-fc1b8088a90f@github.com>

On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
> 
> This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly.

This looks good.
Thank you for fixing it.
Serguei

There are more uses of sprintf in some serviceability folders:


src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c:  sprintf(fname, "/proc/%d/status", pid);
src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c:  sprintf(fname, "/proc/%d/maps", ph->pid);
src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c:  s = filename + sprintf (filename, "%s/.build-id/", debug_file_directory);
src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c:      s += sprintf (s, "%02x", *data++);
src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c:    s += sprintf (s, "%02x", *data++);
src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp:        sprintf(errmsg, "%s (hr: 0x%08X)", str, hr); \


src/jdk.management/share/native/libmanagement_ext/management_ext.c:    sprintf(errmsg, "errno: %d error: %s\n", errno, msg);
src/java.management/share/native/libmanagement/VMManagementImpl.c:    sprintf(buf, "%d.%d", major, minor);
src/java.management/share/native/libmanagement/management.c:    sprintf(errmsg, "errno: %d error: %s\n", errno, msg);


src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c:        sprintf(msg, "handshake failed - received >%s< - expected >%s<", b, hello);
src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c:        sprintf(buf, "%d", portNum);
src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c:                sprintf(ebuf, "ERROR: Peer not allowed to connect: %s\n",
src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c:        sprintf(buf, "winsock error %d", error);
src/jdk.jdwp.agent/windows/native/libjdwp/linker_md.c:        sprintf(holder, "%s.dll", fname);

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11935

From sspitsyn at openjdk.org  Fri Jan 13 08:06:13 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 13 Jan 2023 08:06:13 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14
In-Reply-To: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <qCC4cki5JEt3jiQmtZyEGIAW8hLB-OPpn3GES2IwAlc=.c1a6062d-b503-4b5b-8e2d-b8e086cb5bb1@github.com>
 <nxm9RxFD1m-yYZUbqWOeA_8HZuy-6lFBa1MJWHWy8NM=.9c049582-ca06-4392-b473-ab584232e92d@github.com>
 <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com>
Message-ID: <hiycglKv4vh95Js3CfEFhkHHzSSH5gIQv0Ptw9cgExA=.fbfc613d-4f6c-43d4-b9d1-50bec80c83a3@github.com>

On Thu, 12 Jan 2023 07:25:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> This PR does not address all the remaining sprintf:s in hotspot, and with it now explicitly forbidden the build will fail:
>>> 
>> 
>> This is a question to me as well.  I noticed there are still some use of sprintf, but the building passed on MacOS and Linux.  I was wondering if the following update really work (if the '...' parameter works for the forbidden?), or something else matters.
>> 
>> 
>> FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf");
>> 
>> 
>>> I count ~30 sprintf:s that need updating.
>>> 
>>> I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files?
>> 
>> I'm new to hotspot.  Do you know how could I enable C2?  Thanks!
>
>> > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files?
>> 
>> I'm new to hotspot. Do you know how could I enable C2? Thanks!
> 
> Never mind, I got it from configuration help message (use --with-jvm-features=compiler2).

@XueleiFan Could you, please, do not integrate until more cases with the same problem are fixed?

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

PR: https://git.openjdk.org/jdk/pull/11935

From sspitsyn at openjdk.org  Fri Jan 13 08:18:17 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 13 Jan 2023 08:18:17 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14
In-Reply-To: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
Message-ID: <tJQJ9VsCWsxM6i1rSst07EiF6x9InXyMRYm9emAL2Vg=.6a9da9b5-d05e-43be-9cef-edba8e0a5ee5@github.com>

On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
> 
> This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly.

More cases with the same issue were found.

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

Changes requested by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Fri Jan 13 08:45:16 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 13 Jan 2023 08:45:16 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14
In-Reply-To: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <qCC4cki5JEt3jiQmtZyEGIAW8hLB-OPpn3GES2IwAlc=.c1a6062d-b503-4b5b-8e2d-b8e086cb5bb1@github.com>
 <nxm9RxFD1m-yYZUbqWOeA_8HZuy-6lFBa1MJWHWy8NM=.9c049582-ca06-4392-b473-ab584232e92d@github.com>
 <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com>
Message-ID: <831CK10pKtyMvjCIInY9jDxfXiLD68orvfLXhm6koRs=.d1b87cbc-0969-4d1a-a3c5-48c00a60a754@github.com>

On Thu, 12 Jan 2023 07:25:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> This PR does not address all the remaining sprintf:s in hotspot, and with it now explicitly forbidden the build will fail:
>>> 
>> 
>> This is a question to me as well.  I noticed there are still some use of sprintf, but the building passed on MacOS and Linux.  I was wondering if the following update really work (if the '...' parameter works for the forbidden?), or something else matters.
>> 
>> 
>> FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf");
>> 
>> 
>>> I count ~30 sprintf:s that need updating.
>>> 
>>> I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files?
>> 
>> I'm new to hotspot.  Do you know how could I enable C2?  Thanks!
>
>> > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files?
>> 
>> I'm new to hotspot. Do you know how could I enable C2? Thanks!
> 
> Never mind, I got it from configuration help message (use --with-jvm-features=compiler2).

> @XueleiFan Could you, please, do not integrate until more cases with the same problem are fixed?

Sure. That's on my plan.  I am trying to figure out how to get these files included in the building.  My build passed on MacOS and Linux, even with C2 enabled.

The update on test may be different from src update.  I may divide the fix into two PRs, if I figure out how to build the missing uses of sprintf:s.

Thank for for the feedback.  I appreciated it.

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Fri Jan 13 23:27:36 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 13 Jan 2023 23:27:36 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14 [v2]
In-Reply-To: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
Message-ID: <9QM0jWWZ-iupPlS3I9Ym-VDl6egK0jHXGezReju0vCs=.b8396d23-68b6-4ea6-8ee3-4ab0fca39963@github.com>

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
> 
> This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  more in src/hotspot

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11935/files
  - new: https://git.openjdk.org/jdk/pull/11935/files/1f7706f9..62a6be82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=00-01

  Stats: 59 lines in 12 files changed: 2 ins; 2 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/11935.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935

PR: https://git.openjdk.org/jdk/pull/11935

From mikael at openjdk.org  Sat Jan 14 00:44:11 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Sat, 14 Jan 2023 00:44:11 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14 [v2]
In-Reply-To: <9QM0jWWZ-iupPlS3I9Ym-VDl6egK0jHXGezReju0vCs=.b8396d23-68b6-4ea6-8ee3-4ab0fca39963@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <9QM0jWWZ-iupPlS3I9Ym-VDl6egK0jHXGezReju0vCs=.b8396d23-68b6-4ea6-8ee3-4ab0fca39963@github.com>
Message-ID: <z6iFuEVwRiXogodPGQiDg9WaIKOg91ijQ97MtboA11s=.c12c516e-056f-47f8-8cee-3670896d517b@github.com>

On Fri, 13 Jan 2023 23:27:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
>> 
>> This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more in src/hotspot

Thank you for making these additional changes! I'm still seeing some issue building on linux-x64, for example:


src/hotspot/share/opto/regalloc.hpp:130:17: note: candidate: 'virtual char* PhaseRegAlloc::dump_register(const Node*, char*, size_t) const'
  130 |   virtual char *dump_register( const Node *n, char *buf, size_t buf_size) const = 0;
      |                 ^~~~~~~~~~~~~

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Sat Jan 14 03:37:26 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 14 Jan 2023 03:37:26 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14 [v3]
In-Reply-To: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
Message-ID: <uczBiHcSoX7f6LEW10qgdkqeiEnPp7Q6RLpzEtzp1nM=.3023a43c-1899-4d34-b665-62c7473b3576@github.com>

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
> 
> This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  missed update for debug mode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11935/files
  - new: https://git.openjdk.org/jdk/pull/11935/files/62a6be82..98c7d3dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=01-02

  Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/11935.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Sat Jan 14 06:36:33 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 14 Jan 2023 06:36:33 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14 [v4]
In-Reply-To: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
Message-ID: <s5xMm_FPjmlCse9h2i7_u5iYhD6Eu6PwxZ5UZ2jCUY4=.4820ffe3-da5f-4af1-84d5-82288b6d14c5@github.com>

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
> 
> This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  correction for ppc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11935/files
  - new: https://git.openjdk.org/jdk/pull/11935/files/98c7d3dd..076f8b54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Sat Jan 14 18:52:09 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 14 Jan 2023 18:52:09 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14
In-Reply-To: <yNFzRfssO_X3cmoMRnshCc49pR8UVrKrT3mt-vWxYkQ=.801188b6-0813-48a7-9fba-fc1b8088a90f@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <yNFzRfssO_X3cmoMRnshCc49pR8UVrKrT3mt-vWxYkQ=.801188b6-0813-48a7-9fba-fc1b8088a90f@github.com>
Message-ID: <2uKA4WjPxwJ_rBTfaHM6d60QEplxWxMDLlL8falWyD4=.889cee2f-9ec0-48b0-a34a-37080ae7e038@github.com>

On Fri, 13 Jan 2023 01:56:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> There are more uses of sprintf in some serviceability folders:

Yes.  There are at least 57 src files that use sprintf function, as far as I can see.  This PR is pretty big now.  I would like to clean them up in an other PR so that it is easier to review.

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Sat Jan 14 19:01:52 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 14 Jan 2023 19:01:52 GMT
Subject: jmx-dev RFR: 8299635: More test issues for deprecated sprintf
 in Xcode 14 [v5]
In-Reply-To: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
Message-ID: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
> 
> This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly.

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge
 - correction for ppc
 - missed update for debug mode
 - more in src/hotspot
 - typo correction
 - 8299635: More test issues for deprecated sprintf in Xcode 14

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11935/files
  - new: https://git.openjdk.org/jdk/pull/11935/files/076f8b54..143887e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=03-04

  Stats: 8279 lines in 310 files changed: 5031 ins; 1837 del; 1411 mod
  Patch: https://git.openjdk.org/jdk/pull/11935.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935

PR: https://git.openjdk.org/jdk/pull/11935

From ihse at openjdk.org  Mon Jan 16 16:50:06 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Jan 2023 16:50:06 GMT
Subject: jmx-dev RFR: 8298047: Remove all non-significant trailing
 whitespace from properties files [v2]
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into properties-eol-clean-safe
 - 8298047: Remove all non-significant trailing whitespace from properties files

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

Changes: https://git.openjdk.org/jdk/pull/11491/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11491&range=01
  Stats: 693 lines in 264 files changed: 0 ins; 0 del; 693 mod
  Patch: https://git.openjdk.org/jdk/pull/11491.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11491/head:pull/11491

PR: https://git.openjdk.org/jdk/pull/11491

From ihse at openjdk.org  Mon Jan 16 16:52:12 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Jan 2023 16:52:12 GMT
Subject: jmx-dev RFR: 8298047: Remove all non-significant trailing
 whitespace from properties files
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <_jLR_ky5hw9zllvt1MZyi3KWmGOefoRazd7sjzoUivo=.e0bc2d7a-05ad-4417-bc34-369c67c3bf5a@github.com>

On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

I know this is boring stuff, but please can I get some more reviews on this? Sergey has reviewed the client parts. It's just removing trailing whitespaces. You should be able to just quickly scroll through this and confirm that this is indeed the case. If someone can take pity on me and just quickly check the non-client parts, I'd be very grateful.

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

PR: https://git.openjdk.org/jdk/pull/11491

From rriggs at openjdk.org  Mon Jan 16 17:25:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 16 Jan 2023 17:25:12 GMT
Subject: jmx-dev RFR: 8298047: Remove all non-significant trailing
 whitespace from properties files [v2]
In-Reply-To: <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
Message-ID: <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>

On Mon, 16 Jan 2023 16:50:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
>> 
>> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
>> 
>> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
>> 
>> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
>> 
>> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into properties-eol-clean-safe
>  - 8298047: Remove all non-significant trailing whitespace from properties files

The non-client parts look fine.

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11491

From ihse at openjdk.org  Mon Jan 16 18:57:21 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Jan 2023 18:57:21 GMT
Subject: jmx-dev RFR: 8298047: Remove all non-significant trailing
 whitespace from properties files [v2]
In-Reply-To: <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>
Message-ID: <aifLgLpgJS_gMzyzRP6INOO4R7bE50ruKJ6R5pQS-lk=.66345dcc-48ae-43d9-b205-8d2f8f1e7ebf@github.com>

On Mon, 16 Jan 2023 17:22:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into properties-eol-clean-safe
>>  - 8298047: Remove all non-significant trailing whitespace from properties files
>
> The non-client parts look fine.

@RogerRiggs Thanks!

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

PR: https://git.openjdk.org/jdk/pull/11491

From ihse at openjdk.org  Mon Jan 16 18:57:22 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Jan 2023 18:57:22 GMT
Subject: jmx-dev Integrated: 8298047: Remove all non-significant trailing
 whitespace from properties files
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <fTgnorzgmXthXmq26skxN42TKuvrV5cVOtaxjIVUu84=.75d2e856-d8c4-4630-8fb8-a35112a68b05@github.com>

On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

This pull request has now been integrated.

Changeset: 4073b685
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4073b68565f9d5283be96ee6b75bab686f076bea
Stats:     693 lines in 264 files changed: 0 ins; 0 del; 693 mod

8298047: Remove all non-significant trailing whitespace from properties files

Reviewed-by: serb, rriggs

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

PR: https://git.openjdk.org/jdk/pull/11491

From dholmes at openjdk.org  Tue Jan 17 01:31:14 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jan 2023 01:31:14 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v5]
In-Reply-To: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>
Message-ID: <Caf4EAveLQ0yxrFR-EHThfggS5Au_IFOPLEpm7qHrNA=.3e4752c3-8b1d-4fc9-b337-a5880665f9b1@github.com>

On Sat, 14 Jan 2023 19:01:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
>> 
>> This patch is trying to find the use of sprintf in hotspot iml and test cases.
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge
>  - correction for ppc
>  - missed update for debug mode
>  - more in src/hotspot
>  - typo correction
>  - 8299635: More test issues for deprecated sprintf in Xcode 14

src/hotspot/os/windows/os_windows.cpp line 387:

> 385:     os::snprintf_checked(buf, sizeof(buf), "%s%s;%s%s%s",
> 386:             Arguments::get_java_home(), EXT_DIR,
> 387:             path, PACKAGE_DIR, EXT_DIR);

When the call is split across multiple lines like this, the subsequent lines should align with the first parameter i.e. align under `buf`.

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

PR: https://git.openjdk.org/jdk/pull/11935

From dholmes at openjdk.org  Tue Jan 17 01:39:14 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jan 2023 01:39:14 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v5]
In-Reply-To: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>
Message-ID: <qjZtvnQuEo5s0BjfRwOA1Yb-1oxXTFlcC-WEXi3wajI=.d0eaee14-33ed-404e-8e9e-d5d54c513f8c@github.com>

On Sat, 14 Jan 2023 19:01:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
>> 
>> This patch is trying to find the use of sprintf in hotspot iml and test cases.
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge
>  - correction for ppc
>  - missed update for debug mode
>  - more in src/hotspot
>  - typo correction
>  - 8299635: More test issues for deprecated sprintf in Xcode 14

I would suggest constraining this PR to src/hotspot and test/hotspot and deal with the JDK serviceability files in a different PR (and there may be other JDK files impacted too).

src/hotspot/share/utilities/globalDefinitions.hpp line 191:

> 189: FORBID_C_FUNCTION(char* strerror(int), "use os::strerror");
> 190: FORBID_C_FUNCTION(char* strtok(char*, const char*), "use strtok_r");
> 191: FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf");

I have to wonder whether this actually works too. Perhaps @kbarrett can comment?

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

PR: https://git.openjdk.org/jdk/pull/11935

From vsitnikov at openjdk.org  Tue Jan 17 11:47:26 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Tue, 17 Jan 2023 11:47:26 GMT
Subject: jmx-dev RFR: 8298047: Remove all non-significant trailing
 whitespace from properties files [v2]
In-Reply-To: <aifLgLpgJS_gMzyzRP6INOO4R7bE50ruKJ6R5pQS-lk=.66345dcc-48ae-43d9-b205-8d2f8f1e7ebf@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>
 <aifLgLpgJS_gMzyzRP6INOO4R7bE50ruKJ6R5pQS-lk=.66345dcc-48ae-43d9-b205-8d2f8f1e7ebf@github.com>
Message-ID: <JxuulcLUmSJ-XI3ENSzO2Nji3I5Z-irlTUt3AITca0c=.d6978830-c241-4d1a-be0d-1515935c38e2@github.com>

On Mon, 16 Jan 2023 18:52:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The non-client parts look fine.
>
> @RogerRiggs Thanks!

@magicus , have you considered adding `.editorconfig` file (see https://editorconfig.org/ ) so it configures developers' editors to trim the whitespace?

Of course, `.editorconfig` does not enforce the policy, however, it would make it easier for those who use editors that support `.editorconfig`. For instance, IntelliJ editors support it by default.

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

PR: https://git.openjdk.org/jdk/pull/11491

From ihse at openjdk.org  Tue Jan 17 12:17:25 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 17 Jan 2023 12:17:25 GMT
Subject: jmx-dev RFR: 8298047: Remove all non-significant trailing
 whitespace from properties files [v2]
In-Reply-To: <JxuulcLUmSJ-XI3ENSzO2Nji3I5Z-irlTUt3AITca0c=.d6978830-c241-4d1a-be0d-1515935c38e2@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>
 <aifLgLpgJS_gMzyzRP6INOO4R7bE50ruKJ6R5pQS-lk=.66345dcc-48ae-43d9-b205-8d2f8f1e7ebf@github.com>
 <JxuulcLUmSJ-XI3ENSzO2Nji3I5Z-irlTUt3AITca0c=.d6978830-c241-4d1a-be0d-1515935c38e2@github.com>
Message-ID: <lKrVS5Y1fnd5UqKpq4potUFK_E7nBX4lAeqVoLY1OrM=.0db54199-ac6f-4b3a-bf25-f6df1db5bfef@github.com>

On Tue, 17 Jan 2023 11:44:32 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> @RogerRiggs Thanks!
>
> @magicus , have you considered adding `.editorconfig` file (see https://editorconfig.org/ ) so it configures developers' editors to trim the whitespace?
> 
> Of course, `.editorconfig` does not enforce the policy, however, it would make it easier for those who use editors that support `.editorconfig`. For instance, IntelliJ editors support it by default.

@vlsi That is an interesting suggestion. My experience with `.editorconfig` is that it is a bit so-so about getting it to actually describe the coding practices of a project, but it can probably be used for a thing like stripping trailing whitespace.

I suggest we continue that discussion in ide-support-dev at openjdk.org, to figure out exactly what can be added to an `.editorconfig file`, how it interacts with jcheck rules and test how different IDEs behave.

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

PR: https://git.openjdk.org/jdk/pull/11491

From cjplummer at openjdk.org  Tue Jan 17 20:53:23 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 17 Jan 2023 20:53:23 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v5]
In-Reply-To: <Caf4EAveLQ0yxrFR-EHThfggS5Au_IFOPLEpm7qHrNA=.3e4752c3-8b1d-4fc9-b337-a5880665f9b1@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>
 <Caf4EAveLQ0yxrFR-EHThfggS5Au_IFOPLEpm7qHrNA=.3e4752c3-8b1d-4fc9-b337-a5880665f9b1@github.com>
Message-ID: <Sdq1TUb6Bxgkuf0IfxmqZJ5bPTdbKGb6qE8F8ktsZgU=.39a3c5f3-1a43-4792-b76e-e240cd82e22b@github.com>

On Tue, 17 Jan 2023 01:28:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge
>>  - correction for ppc
>>  - missed update for debug mode
>>  - more in src/hotspot
>>  - typo correction
>>  - 8299635: More test issues for deprecated sprintf in Xcode 14
>
> src/hotspot/os/windows/os_windows.cpp line 387:
> 
>> 385:     os::snprintf_checked(buf, sizeof(buf), "%s%s;%s%s%s",
>> 386:             Arguments::get_java_home(), EXT_DIR,
>> 387:             path, PACKAGE_DIR, EXT_DIR);
> 
> When the call is split across multiple lines like this, the subsequent lines should align with the first parameter i.e. align under `buf`.

I think the other acceptable approach is to put the first argument on the 2nd line, and then indent all the argument lines by 8. That works well if the first argument would otherwise start too far to the right. For the above, I think either approach would look ok.

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

PR: https://git.openjdk.org/jdk/pull/11935

From kevinw at openjdk.org  Wed Jan 18 17:56:43 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 18 Jan 2023 17:56:43 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v2]
In-Reply-To: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
Message-ID: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>

> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
> 
> There are a number of Query-relate classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - filter properties update: more classes logged as ALLOWED during wider testing
 - Add a Notification test

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/97/files
  - new: https://git.openjdk.org/jdk20/pull/97/files/96cc5120..ab81891d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=97&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=97&range=00-01

  Stats: 51 lines in 2 files changed: 48 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/97.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/97/head:pull/97

PR: https://git.openjdk.org/jdk20/pull/97

From dfuchs at openjdk.org  Wed Jan 18 18:00:24 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 18 Jan 2023 18:00:24 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v2]
In-Reply-To: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>
Message-ID: <4qEii_mc0E2BmzUeVjIjU8vNyr0LkYF9JaFerx8XpL0=.3c7f16b3-4d9d-4c62-a0b5-f4f70d32364c@github.com>

On Wed, 18 Jan 2023 17:56:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
>> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
>> 
>> There are a number of Query-relate classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - filter properties update: more classes logged as ALLOWED during wider testing
>  - Add a Notification test

Thanks for adding the new testcases, especially WRT to notifications.
Your filter might be a little wider than strictly required but it looks like a good first step, and is obviously better than no filter. I am approving on the condition that all JMX (and JCK?) tests are stable passing.
Please obtain approval from a maintainer of this area before pushing.

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/97

From xuelei at openjdk.org  Wed Jan 18 19:34:46 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 18 Jan 2023 19:34:46 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v5]
In-Reply-To: <Sdq1TUb6Bxgkuf0IfxmqZJ5bPTdbKGb6qE8F8ktsZgU=.39a3c5f3-1a43-4792-b76e-e240cd82e22b@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>
 <Caf4EAveLQ0yxrFR-EHThfggS5Au_IFOPLEpm7qHrNA=.3e4752c3-8b1d-4fc9-b337-a5880665f9b1@github.com>
 <Sdq1TUb6Bxgkuf0IfxmqZJ5bPTdbKGb6qE8F8ktsZgU=.39a3c5f3-1a43-4792-b76e-e240cd82e22b@github.com>
Message-ID: <ca9UDhIQlqj0B8kT4R_WFIRU7-abRamLUiEVcKG7GGY=.bd731b2b-6b53-4ed9-938b-c914d21c8c13@github.com>

On Tue, 17 Jan 2023 20:50:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 387:
>> 
>>> 385:     os::snprintf_checked(buf, sizeof(buf), "%s%s;%s%s%s",
>>> 386:             Arguments::get_java_home(), EXT_DIR,
>>> 387:             path, PACKAGE_DIR, EXT_DIR);
>> 
>> When the call is split across multiple lines like this, the subsequent lines should align with the first parameter i.e. align under `buf`.
>
> I think the other acceptable approach is to put the first argument on the 2nd line, and then indent all the argument lines by 8. That works well if the first argument would otherwise start too far to the right. For the above, I think either approach would look ok.

I can see both styles are used in this file.  The current code here uses 8 whitespaces indent, I would like to keep it.

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Wed Jan 18 19:34:55 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 18 Jan 2023 19:34:55 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v5]
In-Reply-To: <qjZtvnQuEo5s0BjfRwOA1Yb-1oxXTFlcC-WEXi3wajI=.d0eaee14-33ed-404e-8e9e-d5d54c513f8c@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>
 <qjZtvnQuEo5s0BjfRwOA1Yb-1oxXTFlcC-WEXi3wajI=.d0eaee14-33ed-404e-8e9e-d5d54c513f8c@github.com>
Message-ID: <1ClKpQgCeS1zWMqBwXYSR3Y0LzX_l2-uOHoy_lFDQuQ=.9fb3d52b-0421-4945-860b-e149e5c07a8c@github.com>

On Tue, 17 Jan 2023 01:34:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge
>>  - correction for ppc
>>  - missed update for debug mode
>>  - more in src/hotspot
>>  - typo correction
>>  - 8299635: More test issues for deprecated sprintf in Xcode 14
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 191:
> 
>> 189: FORBID_C_FUNCTION(char* strerror(int), "use os::strerror");
>> 190: FORBID_C_FUNCTION(char* strtok(char*, const char*), "use strtok_r");
>> 191: FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf");
> 
> I have to wonder whether this actually works too. Perhaps @kbarrett can comment?

I am not confident with it.  Maybe it is better to remove this change and consider it later.

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Wed Jan 18 19:41:11 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 18 Jan 2023 19:41:11 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v6]
In-Reply-To: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
Message-ID: <fkzrOICGOczt2OF1cPz1p7dc_sIJUmBFPxUYkIQJjhg=.9679c781-ec88-4a21-a089-18f049460f93@github.com>

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
> 
> This patch is trying to find the use of sprintf in hotspot iml and test cases.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  Remove FORBID_C_FUNCTION update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11935/files
  - new: https://git.openjdk.org/jdk/pull/11935/files/143887e9..99d5c611

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Wed Jan 18 19:41:12 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 18 Jan 2023 19:41:12 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v5]
In-Reply-To: <qjZtvnQuEo5s0BjfRwOA1Yb-1oxXTFlcC-WEXi3wajI=.d0eaee14-33ed-404e-8e9e-d5d54c513f8c@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>
 <qjZtvnQuEo5s0BjfRwOA1Yb-1oxXTFlcC-WEXi3wajI=.d0eaee14-33ed-404e-8e9e-d5d54c513f8c@github.com>
Message-ID: <HxUuwEfCuA1h414v_35afvuDCLcK4sGaMUOrNe1r0g0=.382a1419-c9a8-475d-88be-53db14db1e3c@github.com>

On Tue, 17 Jan 2023 01:36:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I would suggest constraining this PR to src/hotspot and test/hotspot and deal with the JDK serviceability files in a different PR (and there may be other JDK files impacted too).

I agreed.  This PR is mainly focus on the hotspot, except two test files for jdk management.  The test clean up is done with this PR, but there are still a lot (57+) use in other src component.   One or more PR will be filed for the remaining clean up.

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

PR: https://git.openjdk.org/jdk/pull/11935

From cjplummer at openjdk.org  Wed Jan 18 19:48:18 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 18 Jan 2023 19:48:18 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v5]
In-Reply-To: <ca9UDhIQlqj0B8kT4R_WFIRU7-abRamLUiEVcKG7GGY=.bd731b2b-6b53-4ed9-938b-c914d21c8c13@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>
 <Caf4EAveLQ0yxrFR-EHThfggS5Au_IFOPLEpm7qHrNA=.3e4752c3-8b1d-4fc9-b337-a5880665f9b1@github.com>
 <Sdq1TUb6Bxgkuf0IfxmqZJ5bPTdbKGb6qE8F8ktsZgU=.39a3c5f3-1a43-4792-b76e-e240cd82e22b@github.com>
 <ca9UDhIQlqj0B8kT4R_WFIRU7-abRamLUiEVcKG7GGY=.bd731b2b-6b53-4ed9-938b-c914d21c8c13@github.com>
Message-ID: <5RjH-SG_Tv8lcUfEwfnAx1LzLThe3Kl__Vv_O6W5sz4=.f9128d51-3bcf-4adb-9097-32c312d045ce@github.com>

On Wed, 18 Jan 2023 19:28:42 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> I think the other acceptable approach is to put the first argument on the 2nd line, and then indent all the argument lines by 8. That works well if the first argument would otherwise start too far to the right. For the above, I think either approach would look ok.
>
> I can see both styles are used in this file.  The current code here uses 8 whitespaces indent, I would like to keep it.

I scanned the first 1000 lines and saw many cases of multi-line argument passing, and they all indent as David suggested. I'm not saying there are non in the file that indent has you have, but it seems if there are cases, they are the exception.

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Wed Jan 18 20:07:35 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 18 Jan 2023 20:07:35 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v5]
In-Reply-To: <5RjH-SG_Tv8lcUfEwfnAx1LzLThe3Kl__Vv_O6W5sz4=.f9128d51-3bcf-4adb-9097-32c312d045ce@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>
 <Caf4EAveLQ0yxrFR-EHThfggS5Au_IFOPLEpm7qHrNA=.3e4752c3-8b1d-4fc9-b337-a5880665f9b1@github.com>
 <Sdq1TUb6Bxgkuf0IfxmqZJ5bPTdbKGb6qE8F8ktsZgU=.39a3c5f3-1a43-4792-b76e-e240cd82e22b@github.com>
 <ca9UDhIQlqj0B8kT4R_WFIRU7-abRamLUiEVcKG7GGY=.bd731b2b-6b53-4ed9-938b-c914d21c8c13@github.com>
 <5RjH-SG_Tv8lcUfEwfnAx1LzLThe3Kl__Vv_O6W5sz4=.f9128d51-3bcf-4adb-9097-32c312d045ce@github.com>
Message-ID: <29kkAIFV45-0r65aIMq0TnkQcfNE8q8tlvswoTmzv7k=.b35606a8-bb9e-4ba1-a419-a5f1c2dcbc62@github.com>

On Wed, 18 Jan 2023 19:45:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I can see both styles are used in this file.  The current code here uses 8 whitespaces indent, I would like to keep it.
>
> I scanned the first 1000 lines and saw many cases of multi-line argument passing, and they all indent as David suggested. I'm not saying there are non in the file that indent has you have, but it seems if there are cases, they are the exception.

OK.  I have no strong preference.  Updated to align with the 1st parameter.

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Wed Jan 18 20:07:31 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 18 Jan 2023 20:07:31 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v7]
In-Reply-To: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
Message-ID: <JJzHQR0xf8o9UCCBByZTpANsAkYOz0EpZCcrIS3sa-Q=.e1556149-24ad-4098-b68a-c99ec641be0e@github.com>

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
> 
> This patch is trying to find the use of sprintf in hotspot iml and test cases.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  align splited lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11935/files
  - new: https://git.openjdk.org/jdk/pull/11935/files/99d5c611..62589ae5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/11935

From dholmes at openjdk.org  Thu Jan 19 07:34:31 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Jan 2023 07:34:31 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v6]
In-Reply-To: <fkzrOICGOczt2OF1cPz1p7dc_sIJUmBFPxUYkIQJjhg=.9679c781-ec88-4a21-a089-18f049460f93@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <fkzrOICGOczt2OF1cPz1p7dc_sIJUmBFPxUYkIQJjhg=.9679c781-ec88-4a21-a089-18f049460f93@github.com>
Message-ID: <83nPGVU0MkRtftZHs_NJN_5ZOzPb6lrWUyzTdZCkRNw=.e122aa01-d981-4d9e-bb23-65aa9670ebf1@github.com>

On Wed, 18 Jan 2023 19:41:11 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
>> 
>> This patch is trying to find the use of sprintf in hotspot iml and test cases.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove FORBID_C_FUNCTION update

src/hotspot/share/utilities/globalDefinitions.hpp line 191:

> 189: FORBID_C_FUNCTION(char* strerror(int), "use os::strerror");
> 190: FORBID_C_FUNCTION(char* strtok(char*, const char*), "use strtok_r");
> 191: FORBID_C_FUNCTION(int vsprintf(char*, const char*, va_list), "use os::vsnprintf");

At some point we would want this and as this should be the last PR to touch hotspot code in this area then this seems like the right PR to have it in. We just need to check that it is actually working as expected.

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

PR: https://git.openjdk.org/jdk/pull/11935

From dholmes at openjdk.org  Thu Jan 19 07:37:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Jan 2023 07:37:28 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v5]
In-Reply-To: <HxUuwEfCuA1h414v_35afvuDCLcK4sGaMUOrNe1r0g0=.382a1419-c9a8-475d-88be-53db14db1e3c@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>
 <qjZtvnQuEo5s0BjfRwOA1Yb-1oxXTFlcC-WEXi3wajI=.d0eaee14-33ed-404e-8e9e-d5d54c513f8c@github.com>
 <HxUuwEfCuA1h414v_35afvuDCLcK4sGaMUOrNe1r0g0=.382a1419-c9a8-475d-88be-53db14db1e3c@github.com>
Message-ID: <kkxDw1SZZnLkvHcpMMTTqMkv8XreqZcEED587hgqxyk=.2b9f41f6-1f0f-4205-aacd-7d46541edfae@github.com>

On Wed, 18 Jan 2023 19:35:08 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>  This PR is mainly focus on the hotspot, except two test files for jdk management.

I would suggest leaving those two management files for the serviceability PR.

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Thu Jan 19 18:54:08 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 19 Jan 2023 18:54:08 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v8]
In-Reply-To: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
Message-ID: <y7XcGDQUZNee6ZHBM9yIVxMyGgm696OCEmOrY7DhogQ=.ebbdfb20-7f9c-4052-af62-3f6569b63903@github.com>

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
> 
> This patch is trying to find the use of sprintf in hotspot iml and test cases.

Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision:

 - remove serviceability update and add back forbid of sprintf
 - remove serviceability update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11935/files
  - new: https://git.openjdk.org/jdk/pull/11935/files/62589ae5..ec0bb486

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=06-07

  Stats: 9 lines in 3 files changed: 1 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11935.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935

PR: https://git.openjdk.org/jdk/pull/11935

From mikael at openjdk.org  Thu Jan 19 21:10:11 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 19 Jan 2023 21:10:11 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v8]
In-Reply-To: <y7XcGDQUZNee6ZHBM9yIVxMyGgm696OCEmOrY7DhogQ=.ebbdfb20-7f9c-4052-af62-3f6569b63903@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <y7XcGDQUZNee6ZHBM9yIVxMyGgm696OCEmOrY7DhogQ=.ebbdfb20-7f9c-4052-af62-3f6569b63903@github.com>
Message-ID: <husg5Dk9wBAJkzssaiPF9kvSBY50OS7ZTX-lpChscoU=.9e7154e7-1a35-405d-8c31-78303e397d82@github.com>

On Thu, 19 Jan 2023 18:54:08 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
>> 
>> This patch is trying to find the use of sprintf in hotspot iml and test cases.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove serviceability update and add back forbid of sprintf
>  - remove serviceability update

I was (still) puzzled by the remaining sprintf:s in the JDK and the fact that the build completed successfully even if not all of them had been address/updated, so I investigated it a bit and came to the conclusion that the Xcode/clang warning (which we turn into an error with `-Werror`) only seems to be generated for C++ files, not for C files.

For many reasons we may still want to fix the remaining occurrences as well, but for the immediate case of the new Xcode version it seems to be sufficient to fix the C++ files.

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

PR: https://git.openjdk.org/jdk/pull/11935

From dholmes at openjdk.org  Fri Jan 20 04:42:32 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 20 Jan 2023 04:42:32 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v8]
In-Reply-To: <y7XcGDQUZNee6ZHBM9yIVxMyGgm696OCEmOrY7DhogQ=.ebbdfb20-7f9c-4052-af62-3f6569b63903@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <y7XcGDQUZNee6ZHBM9yIVxMyGgm696OCEmOrY7DhogQ=.ebbdfb20-7f9c-4052-af62-3f6569b63903@github.com>
Message-ID: <owip38H68JQrhEFFFrHJOiLj2afqtQXf_5kbC54wpAA=.c7b61495-0328-4280-8466-03e8a4bca81b@github.com>

On Thu, 19 Jan 2023 18:54:08 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
>> 
>> This patch is trying to find the use of sprintf in hotspot iml and test cases.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove serviceability update and add back forbid of sprintf
>  - remove serviceability update

Nothing further from me. I think this is okay as-is now. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11935

From dholmes at openjdk.org  Fri Jan 20 04:42:34 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 20 Jan 2023 04:42:34 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v5]
In-Reply-To: <1ClKpQgCeS1zWMqBwXYSR3Y0LzX_l2-uOHoy_lFDQuQ=.9fb3d52b-0421-4945-860b-e149e5c07a8c@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com>
 <qjZtvnQuEo5s0BjfRwOA1Yb-1oxXTFlcC-WEXi3wajI=.d0eaee14-33ed-404e-8e9e-d5d54c513f8c@github.com>
 <1ClKpQgCeS1zWMqBwXYSR3Y0LzX_l2-uOHoy_lFDQuQ=.9fb3d52b-0421-4945-860b-e149e5c07a8c@github.com>
Message-ID: <J84hlsjQUqnLGbfMyqvN_mXqNt_7L_yj4l0LbZ0Oyhc=.f195d58f-9cdc-41d6-a696-1b774041780c@github.com>

On Wed, 18 Jan 2023 19:30:42 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions.hpp line 191:
>> 
>>> 189: FORBID_C_FUNCTION(char* strerror(int), "use os::strerror");
>>> 190: FORBID_C_FUNCTION(char* strtok(char*, const char*), "use strtok_r");
>>> 191: FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf");
>> 
>> I have to wonder whether this actually works too. Perhaps @kbarrett can comment?
>
> I am not confident with it.  Maybe it is better to remove this change and consider it later.

For the record I tested this standalone and it works fine in a C++ program.

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Fri Jan 20 18:22:34 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 20 Jan 2023 18:22:34 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14
In-Reply-To: <hiycglKv4vh95Js3CfEFhkHHzSSH5gIQv0Ptw9cgExA=.fbfc613d-4f6c-43d4-b9d1-50bec80c83a3@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <qCC4cki5JEt3jiQmtZyEGIAW8hLB-OPpn3GES2IwAlc=.c1a6062d-b503-4b5b-8e2d-b8e086cb5bb1@github.com>
 <nxm9RxFD1m-yYZUbqWOeA_8HZuy-6lFBa1MJWHWy8NM=.9c049582-ca06-4392-b473-ab584232e92d@github.com>
 <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com>
 <hiycglKv4vh95Js3CfEFhkHHzSSH5gIQv0Ptw9cgExA=.fbfc613d-4f6c-43d4-b9d1-50bec80c83a3@github.com>
Message-ID: <L-0a9fdiJLqw22Gu-INX6yX1PmTDoMYoU4ydQV2GrJY=.92925919-96f4-46be-b3c7-5c920050ff23@github.com>

On Fri, 13 Jan 2023 08:00:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files?
>>> 
>>> I'm new to hotspot. Do you know how could I enable C2? Thanks!
>> 
>> Never mind, I got it from configuration help message (use --with-jvm-features=compiler2).
>
> @XueleiFan Could you, please, do not integrate until more cases with the same problem are fixed?

@sspitsyn I'm going to integrate the changeset.  Did you have further comment or need more time?

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Fri Jan 20 18:22:36 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 20 Jan 2023 18:22:36 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v8]
In-Reply-To: <owip38H68JQrhEFFFrHJOiLj2afqtQXf_5kbC54wpAA=.c7b61495-0328-4280-8466-03e8a4bca81b@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <y7XcGDQUZNee6ZHBM9yIVxMyGgm696OCEmOrY7DhogQ=.ebbdfb20-7f9c-4052-af62-3f6569b63903@github.com>
 <owip38H68JQrhEFFFrHJOiLj2afqtQXf_5kbC54wpAA=.c7b61495-0328-4280-8466-03e8a4bca81b@github.com>
Message-ID: <YcffxejUoLJ-kzK_gG59Fz-hbJlrioLYf6RKpo0c5Z8=.9559db53-b980-4787-922f-fffc642cdf50@github.com>

On Fri, 20 Jan 2023 04:39:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Nothing further from me. I think this is okay as-is now. Thanks.

@dholmes-ora Thank you for the review!

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

PR: https://git.openjdk.org/jdk/pull/11935

From dholmes at openjdk.org  Sun Jan 22 22:18:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 22 Jan 2023 22:18:06 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v8]
In-Reply-To: <YcffxejUoLJ-kzK_gG59Fz-hbJlrioLYf6RKpo0c5Z8=.9559db53-b980-4787-922f-fffc642cdf50@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <y7XcGDQUZNee6ZHBM9yIVxMyGgm696OCEmOrY7DhogQ=.ebbdfb20-7f9c-4052-af62-3f6569b63903@github.com>
 <owip38H68JQrhEFFFrHJOiLj2afqtQXf_5kbC54wpAA=.c7b61495-0328-4280-8466-03e8a4bca81b@github.com>
 <YcffxejUoLJ-kzK_gG59Fz-hbJlrioLYf6RKpo0c5Z8=.9559db53-b980-4787-922f-fffc642cdf50@github.com>
Message-ID: <-dUevC7v-TgLD27ARVcoKTVMbxjBN5WAYxRjFqoNwxE=.0ebafba6-465d-48c9-b823-402c70a28d95@github.com>

On Fri, 20 Jan 2023 18:20:10 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Nothing further from me. I think this is okay as-is now. Thanks.
>
>> Nothing further from me. I think this is okay as-is now. Thanks.
> 
> @dholmes-ora Thank you for the review!

@XueleiFan  You need two reviews before integrating a Hotspot change - thanks.

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Tue Jan 24 15:33:07 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 24 Jan 2023 15:33:07 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v8]
In-Reply-To: <YcffxejUoLJ-kzK_gG59Fz-hbJlrioLYf6RKpo0c5Z8=.9559db53-b980-4787-922f-fffc642cdf50@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <y7XcGDQUZNee6ZHBM9yIVxMyGgm696OCEmOrY7DhogQ=.ebbdfb20-7f9c-4052-af62-3f6569b63903@github.com>
 <owip38H68JQrhEFFFrHJOiLj2afqtQXf_5kbC54wpAA=.c7b61495-0328-4280-8466-03e8a4bca81b@github.com>
 <YcffxejUoLJ-kzK_gG59Fz-hbJlrioLYf6RKpo0c5Z8=.9559db53-b980-4787-922f-fffc642cdf50@github.com>
Message-ID: <SjEhfEbac5rzL1Mv5QyYioCLyoeNji8Sh2Krm-6l4UA=.304c4aae-4fbb-4a69-ab15-9014f9a7789d@github.com>

On Fri, 20 Jan 2023 18:20:10 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Nothing further from me. I think this is okay as-is now. Thanks.
>
>> Nothing further from me. I think this is okay as-is now. Thanks.
> 
> @dholmes-ora Thank you for the review!

> @XueleiFan You need two reviews before integrating a Hotspot change - thanks.

May I get one more reviewer for this PR?  Thanks!

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

PR: https://git.openjdk.org/jdk/pull/11935

From dnguyen at openjdk.org  Tue Jan 24 20:57:43 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 20:57:43 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update
Message-ID: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>

Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
All tests passed

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

Commit messages:
 - Remove currency symbol entries
 - Remove whitespace using tool
 - Remove double quotes generated by translation tool
 - Revert translation's removal of <is considered> text
 - Update files for localization

Changes: https://git.openjdk.org/jdk20/pull/116/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300719
  Stats: 1030 lines in 81 files changed: 218 ins; 115 del; 697 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 21:08:11 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 21:08:11 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <4tI9y6FpAFrOiS4N4joygZHAHvPm-Ka2D9_3F8pyD6o=.fbb62ba6-4658-46b5-96f8-307ab3b41f81@github.com>

On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

@prrace @wangweij @naotoj @JoeWang-Java @plummercj @alexeysemenyukoracle
Could you review the changes from this localization drop?

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

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 21:48:11 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 21:48:11 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <SltPNoJFof9JSmmSGamoTHPgVj-sZYWE0-_ijvVAHq4=.904ae847-154e-4fbc-bb8f-3792d5767b3e@github.com>

On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

@magicus @LanceAndersen @jonathan-gibbons @pavelrappo @dougxc @lahodaj
Could you review the changes from this localization drop for the areas you're familiar with?

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

PR: https://git.openjdk.org/jdk20/pull/116

From cjplummer at openjdk.org  Tue Jan 24 22:05:10 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 24 Jan 2023 22:05:10 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <B6mEwU9m4V_eHQKkH5EHYR4ofs8G7wh5Zzpt7K6-M7I=.a2729d77-4f00-4871-a4a1-2904ce852c74@github.com>

On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

jdk.console and jdk.management.agent changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 22:12:26 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:12:26 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v2]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

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

  Change German help of jar command

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/4ced04fb..a2528015

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From naoto at openjdk.org  Tue Jan 24 22:24:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Jan 2023 22:24:15 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v2]
In-Reply-To: <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
Message-ID: <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>

On Tue, 24 Jan 2023 22:12:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change German help of jar command

Changes requested by naoto (Reviewer).

src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174:

> 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U)
> 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5
> 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean:

This looks like a prefix, so instead of removing the space, it should be replaced with `\u0020` like other locations.
Also, it seems that other l10n files (de, ja) do not seem to have spaces in the first place.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 38:

> 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm
> 37: resource.wxl-file=WiX-Lokalisierungsdatei
> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Shouldn't this be `de`?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 38:

> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 37: resource.wxl-file=WiX\u30ED\u30FC\u30AB\u30EA\u30BC\u30FC\u30B7\u30E7\u30F3\u30FB\u30D5\u30A1\u30A4\u30EB
> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Shouldn't this be `ja`?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 38:

> 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C
> 37: resource.wxl-file=WiX \u672C\u5730\u5316\u6587\u4EF6
> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Shouldn't this be `zh_CN`?

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

> 61: # written authorization of the copyright holder.
> 62: 
> 63: CNY=\uffe5

Do not remove this.

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

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 22:24:16 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:24:16 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v2]
In-Reply-To: <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
Message-ID: <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>

On Tue, 24 Jan 2023 22:05:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change German help of jar command
>
> src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174:
> 
>> 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U)
>> 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5
>> 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean:
> 
> This looks like a prefix, so instead of removing the space, it should be replaced with `\u0020` like other locations.
> Also, it seems that other l10n files (de, ja) do not seem to have spaces in the first place.

OK, I can make the manual edit for this

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 38:
> 
>> 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C
>> 37: resource.wxl-file=WiX \u672C\u5730\u5316\u6587\u4EF6
>> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Shouldn't this be `zh_CN`?

The translation tool seems to use the English source file's file name here, so it's replaced. I will handle these 3 occurrences now. I thought I handled all occurrences of this, but these 3 slipped in

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

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 22:33:24 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:33:24 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v3]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

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

  Change localization codes. Add CNY back

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/a2528015..40291c61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=01-02

  Stats: 4 lines in 4 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 22:33:28 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:33:28 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v2]
In-Reply-To: <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
Message-ID: <aSepuyRGkRCKZRV73viMQmYFsLPiygi9ty1PrPJAfOA=.847916eb-487b-4d07-9959-df8e9e178ac9@github.com>

On Tue, 24 Jan 2023 22:12:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change German help of jar command
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 38:
> 
>> 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm
>> 37: resource.wxl-file=WiX-Lokalisierungsdatei
>> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Shouldn't this be `de`?

Changed back similar to with zh_CN

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 38:
> 
>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>> 37: resource.wxl-file=WiX\u30ED\u30FC\u30AB\u30EA\u30BC\u30FC\u30B7\u30E7\u30F3\u30FB\u30D5\u30A1\u30A4\u30EB
>> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Shouldn't this be `ja`?

Changed back similar to with zh_CN

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

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 22:33:29 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:33:29 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v3]
In-Reply-To: <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
Message-ID: <uWum8tAJrTs5hLSFFUV1E67SZFZsqqAsHpCELrLIMaM=.d90513b3-c6af-43a5-bb37-2024bcfc3f70@github.com>

On Tue, 24 Jan 2023 22:14:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change localization codes. Add CNY back
>
> src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63:
> 
>> 61: # written authorization of the copyright holder.
>> 62: 
>> 63: CNY=\uffe5
> 
> Do not remove this.

Added back. Thanks for catching this!

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

PR: https://git.openjdk.org/jdk20/pull/116

From prr at openjdk.org  Tue Jan 24 22:44:13 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Jan 2023 22:44:13 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v2]
In-Reply-To: <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
Message-ID: <gQ5g-MSzzcsErcy0NLkwj4OOYoilBeIRyRHnNlZzfFM=.05615d12-452b-4bab-89cf-9ed5ffb91510@github.com>

On Tue, 24 Jan 2023 22:12:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change German help of jar command

Removing the trailing white space seems OK in the desktop resources.
I checked the base (English) version of the files and none of them have trailing white space so it seems unlikely it is significant.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From jlu at openjdk.org  Tue Jan 24 22:44:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 24 Jan 2023 22:44:14 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v3]
In-Reply-To: <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
 <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>
Message-ID: <asI2PH6xlHtgVW2Mj-E4puV5nna6IRYlNLeu2qIisXQ=.527599ac-16ce-41f1-bb92-263bb85b79f6@github.com>

On Tue, 24 Jan 2023 22:20:22 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174:
>> 
>>> 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U)
>>> 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5
>>> 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean:
>> 
>> This looks like a prefix, so instead of removing the space, it should be replaced with `\u0020` like other locations.
>> Also, it seems that other l10n files (de, ja) do not seem to have spaces in the first place.
>
> OK, I can make the manual edit for this

This change was made because it was compared to the original messages.properties. In that file, the respective line is given as `MANAGE_HOTSPOT_MBEANS_IN_COLON_=Manage Hotspot MBeans in:` with no trailing space. That's why in this file, to ensure consistency, the trailing space was stripped.

I think either this space should be removed, or all 4 (en, ja, de, zh) should have the `\u0020` appended. I agree that since it is a prefix it would make sense for a space to be there, but there is no guarantee that what comes after, or even the code that loads the .properties file does not already handles that necessary space.

Should the space remain removed like in the English source file and the other l10n files, or do you think all 4 should be changed to add `\u0020`?

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

PR: https://git.openjdk.org/jdk20/pull/116

From joehw at openjdk.org  Tue Jan 24 22:59:07 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 24 Jan 2023 22:59:07 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v3]
In-Reply-To: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
Message-ID: <8IAAljdZ35sxC22s2SeFdCTX5xmx83YUFr8dwOYtXzA=.028e67c7-0969-4204-b843-0c0f2d79574f@github.com>

On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change localization codes. Add CNY back

Marked as reviewed by joehw (Reviewer).

java.xml changes look good to me. Thanks.

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

PR: https://git.openjdk.org/jdk20/pull/116

From naoto at openjdk.org  Tue Jan 24 22:59:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Jan 2023 22:59:08 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v3]
In-Reply-To: <asI2PH6xlHtgVW2Mj-E4puV5nna6IRYlNLeu2qIisXQ=.527599ac-16ce-41f1-bb92-263bb85b79f6@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
 <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>
 <asI2PH6xlHtgVW2Mj-E4puV5nna6IRYlNLeu2qIisXQ=.527599ac-16ce-41f1-bb92-263bb85b79f6@github.com>
Message-ID: <CsAAVzIKnnz5XUpUrnwieoCon_IUB2AloJD3f088IQ0=.cafe7f9a-af56-4ed0-a57a-10ac66ba0958@github.com>

On Tue, 24 Jan 2023 22:40:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> OK, I can make the manual edit for this
>
> This change was made because it was compared to the original messages.properties. In that file, the respective line is given as `MANAGE_HOTSPOT_MBEANS_IN_COLON_=Manage Hotspot MBeans in:` with no trailing space. That's why in this file, to ensure consistency, the trailing space was stripped.
> 
> I think either this space should be removed, or all 4 (en, ja, de, zh) should have the `\u0020` appended. I agree that since it is a prefix it would make sense for a space to be there, but there is no guarantee that what comes after, or even the code that loads the .properties file does not already handles that necessary space.
> 
> Should the space remain removed like in the English source file and the other l10n files, or do you think all 4 should be changed to add `\u0020`?

Confirmed that the message is for a label (`sun.tools.jconsole.LabeledComponent`), followed by a Component, so no space seems needed in each file. Sorry for the false alarm.

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

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 22:59:08 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:59:08 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v3]
In-Reply-To: <CsAAVzIKnnz5XUpUrnwieoCon_IUB2AloJD3f088IQ0=.cafe7f9a-af56-4ed0-a57a-10ac66ba0958@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
 <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>
 <asI2PH6xlHtgVW2Mj-E4puV5nna6IRYlNLeu2qIisXQ=.527599ac-16ce-41f1-bb92-263bb85b79f6@github.com>
 <CsAAVzIKnnz5XUpUrnwieoCon_IUB2AloJD3f088IQ0=.cafe7f9a-af56-4ed0-a57a-10ac66ba0958@github.com>
Message-ID: <l0IK6fz7xp_c34lMdRgzs570ED6G2oXQ-CZwZ9pU1XU=.7b1893fe-06c8-4a9c-acf1-00ec66245dc2@github.com>

On Tue, 24 Jan 2023 22:49:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change was made because it was compared to the original messages.properties. In that file, the respective line is given as `MANAGE_HOTSPOT_MBEANS_IN_COLON_=Manage Hotspot MBeans in:` with no trailing space. That's why in this file, to ensure consistency, the trailing space was stripped.
>> 
>> I think either this space should be removed, or all 4 (en, ja, de, zh) should have the `\u0020` appended. I agree that since it is a prefix it would make sense for a space to be there, but there is no guarantee that what comes after, or even the code that loads the .properties file does not already handles that necessary space.
>> 
>> Should the space remain removed like in the English source file and the other l10n files, or do you think all 4 should be changed to add `\u0020`?
>
> Confirmed that the message is for a label (`sun.tools.jconsole.LabeledComponent`), followed by a Component, so no space seems needed in each file. Sorry for the false alarm.

Ok I left this change out of my most recent update just in case. I addressed all the other comments I believe. Thanks!

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

PR: https://git.openjdk.org/jdk20/pull/116

From asemenyuk at openjdk.org  Tue Jan 24 22:59:12 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 24 Jan 2023 22:59:12 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v3]
In-Reply-To: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
Message-ID: <SYT5AGvWO_Miz8XToU091Kyt7GKfYd167UmiGFLjy6Q=.963f58d4-d913-4ab4-abd3-8bb9c10ae16a@github.com>

On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change localization codes. Add CNY back

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="de-de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">

Please revert the value of the `Culture` attribute.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="ja-jp" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="932">

Please revert the value of the `Culture` attribute.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="zh-CN" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="936">

Please revert the value of the `Culture` attribute.

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

PR: https://git.openjdk.org/jdk20/pull/116

From jlu at openjdk.org  Tue Jan 24 23:06:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 24 Jan 2023 23:06:14 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v3]
In-Reply-To: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
Message-ID: <NHJe4Mt27DnzPaNGgGPmBegrpITlHxclp91qKggg9Xg=.899a3122-736b-48d9-a564-f629ad1e3096@github.com>

On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change localization codes. Add CNY back

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_ja.properties line 62:

> 60: dedup-legal-notices.usage=\  --dedup-legal-notices [error-if-not-same-content]\n                            \u3059\u3079\u3066\u306E\u6CD5\u5F8B\u4E0A\u306E\u6CE8\u610F\u70B9\u306E\u91CD\u8907\u3092\u9664\u5916\u3057\u307E\u3059\u3002\n                            error-if-not-same-content\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u3001\n                            \u540C\u3058\u30D5\u30A1\u30A4\u30EB\u540D\u306E2\u3064\u306E\u30D5\u30A1\u30A4\u30EB\u304C\u7570\u306A\u3063\u3066\u3044\u308B\u3068\n                            \u30A8\u30E9\u30FC\u306B\u306A\u308A\u307E\u3059\u3002
> 61: 
> 62: exclude-files.argument=\u9664\u5916\u3059\u308B\u30D5\u30A1\u30A4\u30EB\u306E<pattern-list> 

It seems like the translation process added a space here, but it does not appear in the original. This should be removed.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 194:

> 192: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
> 193: 
> 194: main.plugin.category=\u7C7B\u522B 

Same as above.

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

PR: https://git.openjdk.org/jdk20/pull/116

From asemenyuk at openjdk.org  Tue Jan 24 23:19:12 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 24 Jan 2023 23:19:12 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v3]
In-Reply-To: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
Message-ID: <53tinlttCmtNrOBaz7F54bKSeftrurnsr9OVoQzzjC8=.191b9195-e775-4b4b-8811-d34789cec36e@github.com>

On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change localization codes. Add CNY back

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="zh-CN" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="936">

Please revert the value of the Culture attribute.

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

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 23:38:23 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:38:23 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v4]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <T2H6mU3enuaNrLKae6YLvpA313QW2F1gfnXOzKhYP20=.d188ea58-f00e-4782-a508-ba25ed9f8819@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

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

  Remove trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/40291c61..fc32c37f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 23:56:23 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:56:23 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

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

  Revert culture attribute

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/fc32c37f..616b2502

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=03-04

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 23:59:13 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:59:13 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v3]
In-Reply-To: <NHJe4Mt27DnzPaNGgGPmBegrpITlHxclp91qKggg9Xg=.899a3122-736b-48d9-a564-f629ad1e3096@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
 <NHJe4Mt27DnzPaNGgGPmBegrpITlHxclp91qKggg9Xg=.899a3122-736b-48d9-a564-f629ad1e3096@github.com>
Message-ID: <tro5Qie7pi8hcU2dfXbz7Ew2P5_UBRDcEhohq7MBBmc=.ccef1231-0bb4-457d-8f3c-78878c6e98bb@github.com>

On Tue, 24 Jan 2023 23:02:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change localization codes. Add CNY back
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_ja.properties line 62:
> 
>> 60: dedup-legal-notices.usage=\  --dedup-legal-notices [error-if-not-same-content]\n                            \u3059\u3079\u3066\u306E\u6CD5\u5F8B\u4E0A\u306E\u6CE8\u610F\u70B9\u306E\u91CD\u8907\u3092\u9664\u5916\u3057\u307E\u3059\u3002\n                            error-if-not-same-content\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u3001\n                            \u540C\u3058\u30D5\u30A1\u30A4\u30EB\u540D\u306E2\u3064\u306E\u30D5\u30A1\u30A4\u30EB\u304C\u7570\u306A\u3063\u3066\u3044\u308B\u3068\n                            \u30A8\u30E9\u30FC\u306B\u306A\u308A\u307E\u3059\u3002
>> 61: 
>> 62: exclude-files.argument=\u9664\u5916\u3059\u308B\u30D5\u30A1\u30A4\u30EB\u306E<pattern-list> 
> 
> It seems like the translation process added a space here, but it does not appear in the original. This should be removed.

Removed both instances of the extra trailing whitespace.

> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 194:
> 
>> 192: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>> 193: 
>> 194: main.plugin.category=\u7C7B\u522B 
> 
> Same as above.

Addressed as above

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

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 23:59:17 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:59:17 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v2]
In-Reply-To: <SYT5AGvWO_Miz8XToU091Kyt7GKfYd167UmiGFLjy6Q=.963f58d4-d913-4ab4-abd3-8bb9c10ae16a@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
 <SYT5AGvWO_Miz8XToU091Kyt7GKfYd167UmiGFLjy6Q=.963f58d4-d913-4ab4-abd3-8bb9c10ae16a@github.com>
Message-ID: <wT1oblMLJ8pV6MGHIXybIcNIp71p6Gm4AT0VQgbfTzA=.06b8ac34-8d10-4e71-a596-b64f856c6b27@github.com>

On Tue, 24 Jan 2023 22:55:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change German help of jar command
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">
> 
> Please revert the value of the `Culture` attribute.

I resolved this for the German, Japanese, and Chinese files in the latest commit.

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="ja" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="932">
> 
> Please revert the value of the `Culture` attribute.

Resolved in recent commit

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

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 23:59:19 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:59:19 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v3]
In-Reply-To: <53tinlttCmtNrOBaz7F54bKSeftrurnsr9OVoQzzjC8=.191b9195-e775-4b4b-8811-d34789cec36e@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
 <53tinlttCmtNrOBaz7F54bKSeftrurnsr9OVoQzzjC8=.191b9195-e775-4b4b-8811-d34789cec36e@github.com>
Message-ID: <oM9Wt1fwilca-26aYPtGk-oarvJai1SJ6UgYbfw2Yao=.c0ab676d-eeb8-4c8b-9219-20bd58c4b32c@github.com>

On Tue, 24 Jan 2023 23:16:02 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change localization codes. Add CNY back
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="zh-CN" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="936">
> 
> Please revert the value of the Culture attribute.

Resolved in recent commit

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

PR: https://git.openjdk.org/jdk20/pull/116

From asemenyuk at openjdk.org  Wed Jan 25 00:12:09 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 25 Jan 2023 00:12:09 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <HxDebTNqUdnnPbK_vZ7sFzNng3LygKgZCCajLqQYoKY=.08357b3d-91d8-4871-9c14-f73053d8a7af@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

jpackage changes look good

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

Marked as reviewed by asemenyuk (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From jlu at openjdk.org  Wed Jan 25 01:11:15 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jan 2023 01:11:15 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <zEwbMCW5Eq8q0rv8_F8m2iddDj6z-QdBCfiT8w93Di0=.b0991198-41b8-4204-aafe-32bedd2974f7@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

Marked as reviewed by jlu (Author).

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

PR: https://git.openjdk.org/jdk20/pull/116

From mikael at openjdk.org  Wed Jan 25 02:08:05 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 25 Jan 2023 02:08:05 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v8]
In-Reply-To: <y7XcGDQUZNee6ZHBM9yIVxMyGgm696OCEmOrY7DhogQ=.ebbdfb20-7f9c-4052-af62-3f6569b63903@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <y7XcGDQUZNee6ZHBM9yIVxMyGgm696OCEmOrY7DhogQ=.ebbdfb20-7f9c-4052-af62-3f6569b63903@github.com>
Message-ID: <Rxd6_9vJ7QGucBh22iNbnSLCJ3o7dti_2Xlkb8cCdPI=.04f8805a-7ddd-4745-8c43-5bb02f5b227d@github.com>

On Thu, 19 Jan 2023 18:54:08 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
>> 
>> This patch is trying to find the use of sprintf in hotspot iml and test cases.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove serviceability update and add back forbid of sprintf
>  - remove serviceability update

Looks good, thank you for doing this!

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

Marked as reviewed by mikael (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11935

From duke at openjdk.org  Wed Jan 25 08:20:13 2023
From: duke at openjdk.org (danielpeintner)
Date: Wed, 25 Jan 2023 08:20:13 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v2]
In-Reply-To: <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
Message-ID: <TsM2mpquBl2wvitATox3_QNHuSrQLhZN0MFsaaINyHg=.41bef814-3f17-402b-be0d-a1797114bbee@github.com>

On Tue, 24 Jan 2023 22:12:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change German help of jar command

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 111:

> 109: main.help.opt.main.update=\  -u, --update               Ein vorhandenes JAR-Archiv aktualisieren
> 110: main.help.opt.main.extract=\  -x, --extract              Benannte (oder alle) Dateien aus dem Archiv extrahieren
> 111: main.help.opt.main.describe-module=\  -d, --describe-module      Gibt den Moduldeskriptor oder automatischen Modulnamen aus

Just because I stumbled over this commit. I think the line should be translated as follows:

`Gibt die Modulbeschreibung oder den automatischen Modulnamen aus`

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

PR: https://git.openjdk.org/jdk20/pull/116

From lancea at openjdk.org  Wed Jan 25 13:45:21 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 25 Jan 2023 13:45:21 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <DhnLBlhufb7h62qL0BwYg-_kg8ttfCWuViNBhrYhAcs=.88b29cf5-12bd-4cac-9d43-b0b123d0c1b4@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/116

From ihse at openjdk.org  Wed Jan 25 13:56:21 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 25 Jan 2023 13:56:21 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <-Mjbn1ko2InJOzXLccieEzU8h4bypdm9vTzHdmtA-JQ=.2e1f4d59-e30e-434a-8e62-25777adb3a07@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

I skimmed through this, basically looking for trailing white space changes only, and it generally looks okay.

Note that some of these trailing whitespace fixes has been independently address in mainline. Forward-porting this might involve some (virtual) conflicts.

It is also impossible to see in the Github interface if you are introducing *new* trailing white spaces in the added texts. I hope you are not, and that you have verified this.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From xuelei at openjdk.org  Wed Jan 25 15:43:16 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 25 Jan 2023 15:43:16 GMT
Subject: jmx-dev RFR: 8299635: Hotspot update for deprecated sprintf in
 Xcode 14 [v8]
In-Reply-To: <Rxd6_9vJ7QGucBh22iNbnSLCJ3o7dti_2Xlkb8cCdPI=.04f8805a-7ddd-4745-8c43-5bb02f5b227d@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
 <y7XcGDQUZNee6ZHBM9yIVxMyGgm696OCEmOrY7DhogQ=.ebbdfb20-7f9c-4052-af62-3f6569b63903@github.com>
 <Rxd6_9vJ7QGucBh22iNbnSLCJ3o7dti_2Xlkb8cCdPI=.04f8805a-7ddd-4745-8c43-5bb02f5b227d@github.com>
Message-ID: <TtgHGP0U3coRPYF3ywxjbyCUx6i89h0TXUJ3eGlMizA=.a3b98459-87fb-4f67-95d8-698f7746ca9e@github.com>

On Wed, 25 Jan 2023 02:05:31 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Looks good, thank you for doing this!

@vidmik Thank you!

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

PR: https://git.openjdk.org/jdk/pull/11935

From xuelei at openjdk.org  Wed Jan 25 15:47:52 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 25 Jan 2023 15:47:52 GMT
Subject: jmx-dev Integrated: 8299635: Hotspot update for deprecated sprintf
 in Xcode 14
In-Reply-To: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
References: <TZVcVoG8vhsTUMwwwi2eQhEte_8nuu6yKOtasEpMkHU=.f5af727d-a978-4072-8d5e-57616c1ec560@github.com>
Message-ID: <d2GAa381LJfWGOYnwK_9HCUWoTnph4Uvnb_An_i52xY=.21e044ed-d385-4caf-aa71-9f12e1f33eb5@github.com>

On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing.
> 
> This patch is trying to find the use of sprintf in hotspot iml and test cases.

This pull request has now been integrated.

Changeset: e80b5ea4
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e80b5ea448c715519d14e238321ceb5ec40b37f4
Stats:     109 lines in 40 files changed: 4 ins; 2 del; 103 mod

8299635: Hotspot update for deprecated sprintf in Xcode 14

Reviewed-by: dholmes, mikael

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

PR: https://git.openjdk.org/jdk/pull/11935

From naoto at openjdk.org  Wed Jan 25 16:55:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jan 2023 16:55:04 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <cAC0d_Qt7wDZq7kMDzQPm2QO8NrgIF5XMMvxq4Bhcc4=.131687a3-5000-4bee-af43-05d577b19748@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From weijun at openjdk.org  Wed Jan 25 17:36:38 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Jan 2023 17:36:38 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <_THK1t7SrTRqoW0o0gfgmCo1Ea1WfgdfeB7jNJDKUKk=.05512373-8cb2-41d3-a71f-589075240bb7@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties line 32:

> 30: err.bad.constant.pool=\u8BFB\u53D6{0}\u7684\u5E38\u91CF\u6C60\u65F6\u51FA\u9519: {1}
> 31: err.class.not.found=\u627E\u4E0D\u5230\u7C7B: {0}
> 32: err.crash=\u51FA\u73B0\u4E25\u91CD\u7684\u5185\u90E8\u9519\u8BEF\uFF1A{0}\n\u8BF7\u586B\u5199 Bug \u62A5\u544A\uFF0C\u5E76\u5305\u62EC\u4EE5\u4E0B\u4FE1\u606F\uFF1A\n{1}

While personally I like to see Chinese-style punctuation marks (Ex: `?`) used in Chinese contexts instead of their English-style ones (Ex: `:`), it's only updated on this single line and all the others are still using the English-style.

There should be a general rule on which style we should use throughout all display messages.

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

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Wed Jan 25 17:47:19 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 17:47:19 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v6]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <X62CFfqZcV_yEfImnVmu3ZoHI5P2xChVA-ky8AgsYBA=.07cc648b-7d60-4188-89d9-c6254d2ce023@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

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

  Revert translated punctuation

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/616b2502..4222df9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Wed Jan 25 17:51:20 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 17:51:20 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v7]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

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

  Revert one more punctuation

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/4222df9a..9a5b45a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From weijun at openjdk.org  Wed Jan 25 17:52:21 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Jan 2023 17:52:21 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 113:

> 111: doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 @inheritDoc
> 112: doclet.inheritDocNoDoc=\u88AB\u8986\u76D6\u7684\u65B9\u6CD5\u4E0D\u8BB0\u5F55\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B {0}
> 113: doclet.throwsInheritDocUnsupported=\u4E0D\u662F\u7531\u65B9\u6CD5\u58F0\u660E\u7684 exception-type \u7C7B\u578B\u53C2\u6570\u4E0D\u652F\u6301 @inheritDoc\uFF1B\u76F4\u63A5\u8BB0\u5F55\u6B64\u7C7B\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B

Should `exception-type` be translated?

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

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Wed Jan 25 18:03:54 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 18:03:54 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
Message-ID: <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>

On Wed, 25 Jan 2023 17:49:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert culture attribute
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 113:
> 
>> 111: doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 @inheritDoc
>> 112: doclet.inheritDocNoDoc=\u88AB\u8986\u76D6\u7684\u65B9\u6CD5\u4E0D\u8BB0\u5F55\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B {0}
>> 113: doclet.throwsInheritDocUnsupported=\u4E0D\u662F\u7531\u65B9\u6CD5\u58F0\u660E\u7684 exception-type \u7C7B\u578B\u53C2\u6570\u4E0D\u652F\u6301 @inheritDoc\uFF1B\u76F4\u63A5\u8BB0\u5F55\u6B64\u7C7B\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B
> 
> Should `exception-type` be translated?

The translation tool didn't seem to translate this. Either because it couldn't or because it somehow missed it. I'm not sure which, but I'm open to replacing this with a translation suggestion you have. Or I can leave it as is.

> src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties line 32:
> 
>> 30: err.bad.constant.pool=\u8BFB\u53D6{0}\u7684\u5E38\u91CF\u6C60\u65F6\u51FA\u9519: {1}
>> 31: err.class.not.found=\u627E\u4E0D\u5230\u7C7B: {0}
>> 32: err.crash=\u51FA\u73B0\u4E25\u91CD\u7684\u5185\u90E8\u9519\u8BEF\uFF1A{0}\n\u8BF7\u586B\u5199 Bug \u62A5\u544A\uFF0C\u5E76\u5305\u62EC\u4EE5\u4E0B\u4FE1\u606F\uFF1A\n{1}
> 
> While personally I like to see Chinese-style punctuation marks (Ex: `?`) used in Chinese contexts instead of their English-style ones (Ex: `:`), it's only updated on this single line and all the others are still using the English-style.
> 
> There should be a general rule on which style we should use throughout all display messages.

Updated the punctuation (colons and comma) to be more consistent throughout the file.

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

PR: https://git.openjdk.org/jdk20/pull/116

From weijun at openjdk.org  Wed Jan 25 18:03:55 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Jan 2023 18:03:55 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
 <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
Message-ID: <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>

On Wed, 25 Jan 2023 17:56:15 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 113:
>> 
>>> 111: doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 @inheritDoc
>>> 112: doclet.inheritDocNoDoc=\u88AB\u8986\u76D6\u7684\u65B9\u6CD5\u4E0D\u8BB0\u5F55\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B {0}
>>> 113: doclet.throwsInheritDocUnsupported=\u4E0D\u662F\u7531\u65B9\u6CD5\u58F0\u660E\u7684 exception-type \u7C7B\u578B\u53C2\u6570\u4E0D\u652F\u6301 @inheritDoc\uFF1B\u76F4\u63A5\u8BB0\u5F55\u6B64\u7C7B\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B
>> 
>> Should `exception-type` be translated?
>
> The translation tool didn't seem to translate this. Either because it couldn't or because it somehow missed it. I'm not sure which, but I'm open to replacing this with a translation suggestion you have. Or I can leave it as is.

I'm not sure either. You can ask a javadoc expert whether this is a proper noun or just plain English. I noticed it's also not translated in the Japanese version but the German version has translated it.

>> src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties line 32:
>> 
>>> 30: err.bad.constant.pool=\u8BFB\u53D6{0}\u7684\u5E38\u91CF\u6C60\u65F6\u51FA\u9519: {1}
>>> 31: err.class.not.found=\u627E\u4E0D\u5230\u7C7B: {0}
>>> 32: err.crash=\u51FA\u73B0\u4E25\u91CD\u7684\u5185\u90E8\u9519\u8BEF\uFF1A{0}\n\u8BF7\u586B\u5199 Bug \u62A5\u544A\uFF0C\u5E76\u5305\u62EC\u4EE5\u4E0B\u4FE1\u606F\uFF1A\n{1}
>> 
>> While personally I like to see Chinese-style punctuation marks (Ex: `?`) used in Chinese contexts instead of their English-style ones (Ex: `:`), it's only updated on this single line and all the others are still using the English-style.
>> 
>> There should be a general rule on which style we should use throughout all display messages.
>
> Updated the punctuation (colons and comma) to be more consistent throughout the file.

Looks good now.

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

PR: https://git.openjdk.org/jdk20/pull/116

From jjg at openjdk.org  Wed Jan 25 18:24:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 25 Jan 2023 18:24:55 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v7]
In-Reply-To: <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>
Message-ID: <J-ty6TMfR4ldx_S-L65JWYllWC1ZHnF_ongCEJBxtxI=.aca2e3d7-6b87-4bd0-ab84-ca75ee3ce007@github.com>

On Wed, 25 Jan 2023 17:51:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert one more punctuation

I don't see anything absurdly wrong in the jdk.compiler files.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From weijun at openjdk.org  Wed Jan 25 18:58:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Jan 2023 18:58:57 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v7]
In-Reply-To: <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>
Message-ID: <v7uEXriAXWk-hzpE3-k1fiiPitnlhkkN1gkTMXFQ9Yg=.951f83bf-79b3-4270-981f-140e84b68fb9@github.com>

On Wed, 25 Jan 2023 17:51:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert one more punctuation

zh_cn translations look fine. Thanks.

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From prappo at openjdk.org  Wed Jan 25 20:06:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 25 Jan 2023 20:06:53 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
 <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
 <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>
Message-ID: <HmtuZgI4Gn2cXWC_wVOVAjPD0DdjSnOa4OENGo9ofsU=.aa00f17c-703d-494d-9594-9f6f084be286@github.com>

On Wed, 25 Jan 2023 18:00:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The translation tool didn't seem to translate this. Either because it couldn't or because it somehow missed it. I'm not sure which, but I'm open to replacing this with a translation suggestion you have. Or I can leave it as is.
>
> I'm not sure either. You can ask a javadoc expert whether this is a proper noun or just plain English. I noticed it's also not translated in the Japanese version but the German version has translated it.

It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows:

    doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \
    that are not declared by a method; document such exception types directly

JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type.

@jonathan-gibbons thoughts?

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

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Wed Jan 25 22:02:45 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 22:02:45 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v8]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <AB1V6yMmmoy0zYaY-mNjq4QPc8MTvQO4t8BCsUs0EFA=.40f66568-b479-45c6-8126-1e0d8b375bf9@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

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

  Update German translation

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/9a5b45a2..35829a25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Wed Jan 25 22:19:34 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 22:19:34 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v2]
In-Reply-To: <TsM2mpquBl2wvitATox3_QNHuSrQLhZN0MFsaaINyHg=.41bef814-3f17-402b-be0d-a1797114bbee@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <TsM2mpquBl2wvitATox3_QNHuSrQLhZN0MFsaaINyHg=.41bef814-3f17-402b-be0d-a1797114bbee@github.com>
Message-ID: <XTYcX2V5gNfgnD4UmjFcya6DL2xEA1xmZha3_37alEU=.ab625ad0-c40c-48e1-b759-337ca44d2b98@github.com>

On Wed, 25 Jan 2023 08:17:26 GMT, danielpeintner <duke at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change German help of jar command
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 111:
> 
>> 109: main.help.opt.main.update=\  -u, --update               Ein vorhandenes JAR-Archiv aktualisieren
>> 110: main.help.opt.main.extract=\  -x, --extract              Benannte (oder alle) Dateien aus dem Archiv extrahieren
>> 111: main.help.opt.main.describe-module=\  -d, --describe-module      Gibt den Moduldeskriptor oder automatischen Modulnamen aus
> 
> Just because I stumbled over this commit. I think the line should be translated as follows:
> 
> `Gibt die Modulbeschreibung oder den automatischen Modulnamen aus`

Resolved

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

PR: https://git.openjdk.org/jdk20/pull/116

From jjg at openjdk.org  Wed Jan 25 22:41:34 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 25 Jan 2023 22:41:34 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <HmtuZgI4Gn2cXWC_wVOVAjPD0DdjSnOa4OENGo9ofsU=.aa00f17c-703d-494d-9594-9f6f084be286@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
 <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
 <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>
 <HmtuZgI4Gn2cXWC_wVOVAjPD0DdjSnOa4OENGo9ofsU=.aa00f17c-703d-494d-9594-9f6f084be286@github.com>
Message-ID: <SguhDj7riiU8cDGLybLwdwjSQbHGgLUsDhGBVeHk5L4=.df78d310-21cb-422c-b588-6e3b0a060709@github.com>

On Wed, 25 Jan 2023 20:03:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I'm not sure either. You can ask a javadoc expert whether this is a proper noun or just plain English. I noticed it's also not translated in the Japanese version but the German version has translated it.
>
> It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows:
> 
>     doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \
>     that are not declared by a method; document such exception types directly
> 
> JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type.
> 
> @jonathan-gibbons thoughts?

While the text is technically correct, it may not be as clear as it could be to all folk that will read this message for whom English is not their primary language.

I would suggest translating the phrase as if it were something like

@inheritDoc is not supported for type parameters that are exception types and not declared by a method


and secondarily, changing the English resource to something like that as well.

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

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Wed Jan 25 22:56:59 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 22:56:59 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v9]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <VeAjGWpLXL0FNT25iwGS5NsmzRe4Navl_LNepqMKSNg=.23960b10-c6cb-4893-93f8-cbc2f8a8297c@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

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

  Replace exception-type

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/35829a25..53a86ef2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Wed Jan 25 22:56:59 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 22:56:59 GMT
Subject: jmx-dev [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files
 update [v5]
In-Reply-To: <SguhDj7riiU8cDGLybLwdwjSQbHGgLUsDhGBVeHk5L4=.df78d310-21cb-422c-b588-6e3b0a060709@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
 <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
 <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>
 <HmtuZgI4Gn2cXWC_wVOVAjPD0DdjSnOa4OENGo9ofsU=.aa00f17c-703d-494d-9594-9f6f084be286@github.com>
 <SguhDj7riiU8cDGLybLwdwjSQbHGgLUsDhGBVeHk5L4=.df78d310-21cb-422c-b588-6e3b0a060709@github.com>
Message-ID: <qWC3dfg9l9N5Om85X97AxhnYgQJCQEYtxknwqG0MeY0=.417d15ec-c2d8-424e-97dc-867c4f753e9a@github.com>

On Wed, 25 Jan 2023 22:38:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows:
>> 
>>     doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \
>>     that are not declared by a method; document such exception types directly
>> 
>> JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type.
>> 
>> @jonathan-gibbons thoughts?
>
> While the text is technically correct, it may not be as clear as it could be to all folk that will read this message for whom English is not their primary language.
> 
> I would suggest translating the phrase as if it were something like
> 
> @inheritDoc is not supported for type parameters that are exception types and not declared by a method
> 
> 
> and secondarily, changing the English resource to something like that as well.

Updated this line with `exception-type` translated. Hopefully this will be addressed in future drops with changes to the translation tool after some bug fixes.

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

PR: https://git.openjdk.org/jdk20/pull/116

From xuelei at openjdk.org  Thu Jan 26 10:14:08 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 26 Jan 2023 10:14:08 GMT
Subject: jmx-dev RFR: 8301132: Test update for deprecated sprintf in Xcode 14
Message-ID: <SDWm-fIzoTgNK1roDZ8HrwIaoIX32ggYmYIwEYncldw=.933b77b0-208c-4d78-9d0d-98c65dd6a44c@github.com>

The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812)/[JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635), but the test was not fully covered yet. This would be the last effort to fix the issue in test.

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

Commit messages:
 - 8301132: Test update for deprecated sprintf in Xcode 14

Changes: https://git.openjdk.org/jdk/pull/12211/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12211&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301132
  Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12211.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12211/head:pull/12211

PR: https://git.openjdk.org/jdk/pull/12211

From mikael at openjdk.org  Thu Jan 26 18:11:18 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 26 Jan 2023 18:11:18 GMT
Subject: jmx-dev RFR: 8301132: Test update for deprecated sprintf in
 Xcode 14
In-Reply-To: <SDWm-fIzoTgNK1roDZ8HrwIaoIX32ggYmYIwEYncldw=.933b77b0-208c-4d78-9d0d-98c65dd6a44c@github.com>
References: <SDWm-fIzoTgNK1roDZ8HrwIaoIX32ggYmYIwEYncldw=.933b77b0-208c-4d78-9d0d-98c65dd6a44c@github.com>
Message-ID: <SYcRxM3aj454ZSW_Vrn2Nw2D7KzAutN1Par0A57jpDM=.36e7162c-95d9-4fb1-b5c4-1ad73e7d410d@github.com>

On Thu, 26 Jan 2023 06:38:00 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812)/[JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635), but the test was not fully covered yet. This would be the last effort to fix the issue in test.

test/jdk/sun/management/windows/exerevokeall.c line 102:

> 100: 
> 101:     // S-SID_REVISION
> 102:     snprintf(name, sizeof(name), "S-%lu-", SID_REVISION );

Name is a `char *` so sizeof will return the size of the pointer, not the length of the allocate data.

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

PR: https://git.openjdk.org/jdk/pull/12211

From dnguyen at openjdk.org  Thu Jan 26 22:36:39 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 26 Jan 2023 22:36:39 GMT
Subject: jmx-dev [jdk20] Integrated: 8300719: JDK 20 RDP2 L10n resource
 files update
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <z7OxU1K7tY5joYmEwBKhNW6uZjOx05mtjEF7bRlLNIg=.d95c6b89-3c0d-4400-8def-cd5b3d59c3e7@github.com>

On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

This pull request has now been integrated.

Changeset: a67b1e77
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/a67b1e77d33339f5db36c6d15bac0423a31eb5ee
Stats:     1023 lines in 82 files changed: 218 ins; 114 del; 691 mod

8300719: JDK 20 RDP2 L10n resource files update

Reviewed-by: cjplummer, naoto, prr, joehw, asemenyuk, jlu, lancea, ihse, jjg, weijun

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

PR: https://git.openjdk.org/jdk20/pull/116

From xuelei at openjdk.org  Fri Jan 27 05:27:41 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 27 Jan 2023 05:27:41 GMT
Subject: jmx-dev RFR: 8301132: Test update for deprecated sprintf in
 Xcode 14 [v2]
In-Reply-To: <SDWm-fIzoTgNK1roDZ8HrwIaoIX32ggYmYIwEYncldw=.933b77b0-208c-4d78-9d0d-98c65dd6a44c@github.com>
References: <SDWm-fIzoTgNK1roDZ8HrwIaoIX32ggYmYIwEYncldw=.933b77b0-208c-4d78-9d0d-98c65dd6a44c@github.com>
Message-ID: <RtLrgFU2U8D6fyEKnX20r4Sh2ji8FmS3jWSyVty-N0Q=.7160f86a-9996-4972-a239-fe7927a00083@github.com>

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812)/[JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635), but the test was not fully covered yet. This would be the last effort to fix the issue in test.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  incorrect use of sizeof

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12211/files
  - new: https://git.openjdk.org/jdk/pull/12211/files/3030620a..c9b3d889

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12211&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12211&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12211.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12211/head:pull/12211

PR: https://git.openjdk.org/jdk/pull/12211

From xuelei at openjdk.org  Fri Jan 27 05:27:42 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 27 Jan 2023 05:27:42 GMT
Subject: jmx-dev RFR: 8301132: Test update for deprecated sprintf in
 Xcode 14 [v2]
In-Reply-To: <SYcRxM3aj454ZSW_Vrn2Nw2D7KzAutN1Par0A57jpDM=.36e7162c-95d9-4fb1-b5c4-1ad73e7d410d@github.com>
References: <SDWm-fIzoTgNK1roDZ8HrwIaoIX32ggYmYIwEYncldw=.933b77b0-208c-4d78-9d0d-98c65dd6a44c@github.com>
 <SYcRxM3aj454ZSW_Vrn2Nw2D7KzAutN1Par0A57jpDM=.36e7162c-95d9-4fb1-b5c4-1ad73e7d410d@github.com>
Message-ID: <zSNzvH5cCRzbKQ8gP7GHl3lQ3VnXSN9VkI6MlqNbLUs=.bc6b4f68-741d-4230-a534-9cc9e7637961@github.com>

On Thu, 26 Jan 2023 18:07:42 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   incorrect use of sizeof
>
> test/jdk/sun/management/windows/exerevokeall.c line 102:
> 
>> 100: 
>> 101:     // S-SID_REVISION
>> 102:     snprintf(name, sizeof(name), "S-%lu-", SID_REVISION );
> 
> Name is a `char *` so sizeof will return the size of the pointer, not the length of the allocate data.

Ooooops.  Thank you for the catch!

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

PR: https://git.openjdk.org/jdk/pull/12211

From mikael at openjdk.org  Fri Jan 27 18:13:18 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 27 Jan 2023 18:13:18 GMT
Subject: jmx-dev RFR: 8301132: Test update for deprecated sprintf in
 Xcode 14 [v2]
In-Reply-To: <RtLrgFU2U8D6fyEKnX20r4Sh2ji8FmS3jWSyVty-N0Q=.7160f86a-9996-4972-a239-fe7927a00083@github.com>
References: <SDWm-fIzoTgNK1roDZ8HrwIaoIX32ggYmYIwEYncldw=.933b77b0-208c-4d78-9d0d-98c65dd6a44c@github.com>
 <RtLrgFU2U8D6fyEKnX20r4Sh2ji8FmS3jWSyVty-N0Q=.7160f86a-9996-4972-a239-fe7927a00083@github.com>
Message-ID: <MIM6SLXuxBg0JgQCnoMgtoe5lUsCaFdYTifHHDUPEn8=.cb54db04-643f-419d-9563-f70a3e3c0431@github.com>

On Fri, 27 Jan 2023 05:27:41 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812)/[JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635), but the test was not fully covered yet. This would be the last effort to fix the issue in test.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorrect use of sizeof

Marked as reviewed by mikael (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12211

From xuelei at openjdk.org  Fri Jan 27 19:04:26 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 27 Jan 2023 19:04:26 GMT
Subject: jmx-dev Integrated: 8301132: Test update for deprecated sprintf in
 Xcode 14
In-Reply-To: <SDWm-fIzoTgNK1roDZ8HrwIaoIX32ggYmYIwEYncldw=.933b77b0-208c-4d78-9d0d-98c65dd6a44c@github.com>
References: <SDWm-fIzoTgNK1roDZ8HrwIaoIX32ggYmYIwEYncldw=.933b77b0-208c-4d78-9d0d-98c65dd6a44c@github.com>
Message-ID: <4S8I0v4s9Sui7kdmAyQBxtDSRO445IvsCX6aAl6BwmY=.b04b6ba0-a1e2-4525-bb76-5af8d7daa8c2@github.com>

On Thu, 26 Jan 2023 06:38:00 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812)/[JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635), but the test was not fully covered yet. This would be the last effort to fix the issue in test.

This pull request has now been integrated.

Changeset: 9c4bc2c3
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c4bc2c3954b97821a2bf371cab61edbc3d81d36
Stats:     8 lines in 2 files changed: 2 ins; 0 del; 6 mod

8301132: Test update for deprecated sprintf in Xcode 14

Reviewed-by: mikael

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

PR: https://git.openjdk.org/jdk/pull/12211

From xuelei at openjdk.org  Fri Jan 27 21:02:59 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 27 Jan 2023 21:02:59 GMT
Subject: jmx-dev RFR: 8301279: update for deprecated sprintf for management
 components
Message-ID: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>

The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in management components.

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

Commit messages:
 - 8301279: update for deprecated sprintf for management components

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

PR: https://git.openjdk.org/jdk/pull/12266

From jwilhelm at openjdk.org  Fri Jan 27 21:08:40 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 27 Jan 2023 21:08:40 GMT
Subject: jmx-dev RFR: Merge jdk20
Message-ID: <7o8i6xuRhpJrSJJg2EUyu-JPcawJAytTWS3yHX3PZd0=.0157940a-bbb2-4dc0-a645-5cde446d5052@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8301206: Fix issue with LocaleData after JDK-8300719
 - 8300953: ClassDesc::ofInternalName missing @since tag
 - 8300719: JDK 20 RDP2 L10n resource files update

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=12267&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=12267&range=00.1

Changes: https://git.openjdk.org/jdk/pull/12267/files
  Stats: 1078 lines in 85 files changed: 220 ins; 114 del; 744 mod
  Patch: https://git.openjdk.org/jdk/pull/12267.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12267/head:pull/12267

PR: https://git.openjdk.org/jdk/pull/12267

From jwilhelm at openjdk.org  Fri Jan 27 22:49:26 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 27 Jan 2023 22:49:26 GMT
Subject: jmx-dev Integrated: Merge jdk20
In-Reply-To: <7o8i6xuRhpJrSJJg2EUyu-JPcawJAytTWS3yHX3PZd0=.0157940a-bbb2-4dc0-a645-5cde446d5052@github.com>
References: <7o8i6xuRhpJrSJJg2EUyu-JPcawJAytTWS3yHX3PZd0=.0157940a-bbb2-4dc0-a645-5cde446d5052@github.com>
Message-ID: <JVZE_mPEwJ2rcS4QD7ftXAXrVcbj_TksRnNb7Nmdi-U=.44286872-ced9-458a-b59d-879b09876ecf@github.com>

On Fri, 27 Jan 2023 21:00:03 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 5c59de52
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c59de52a31da937663ad2cef055213489b0516e
Stats:     1078 lines in 85 files changed: 220 ins; 114 del; 744 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/12267

From duke at openjdk.org  Sat Jan 28 00:37:32 2023
From: duke at openjdk.org (duke)
Date: Sat, 28 Jan 2023 00:37:32 GMT
Subject: jmx-dev Withdrawn: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code
In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
Message-ID: <PUFiY72l_M4ZHSzDy23S8ztgo8TTZ5RG5tR2DgublNk=.dd494fd5-a5fe-49f5-96cd-0c59639b56c7@github.com>

On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/11490

From rriggs at openjdk.org  Sat Jan 28 15:13:25 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 28 Jan 2023 15:13:25 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code
In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
Message-ID: <I3VmMiKMmaI6SkvwpTtYzQN2zYYxptXCfPGlkMBB7bM=.0f76b9a0-ab89-4d1b-a059-5c11ded1029c@github.com>

On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.

It appears that the suggested changes could be include to resume this issue.

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

PR: https://git.openjdk.org/jdk/pull/11490

From kevinw at openjdk.org  Mon Jan 30 09:15:23 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 30 Jan 2023 09:15:23 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code
In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
Message-ID: <W4jLFf_JGCO3k2WuKctMLX4yJqSzPGG3LXigsupDP6Y=.c05174cd-bb71-475e-a446-a6cef6045b02@github.com>

On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.

The suggestions from Chris look good, i.e. the trailing \u0020 were unintentional.

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

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.org/jdk/pull/11490

From kevinw at openjdk.org  Mon Jan 30 10:26:18 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 30 Jan 2023 10:26:18 GMT
Subject: jmx-dev RFR: 8301279: update for deprecated sprintf for
 management components
In-Reply-To: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
References: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
Message-ID: <rqv13CwvPP0T9L2Wbh8-6GqGIVbKN6-fR9RGgx_yYN0=.18890c10-bec4-4c78-b382-5be564be0e00@github.com>

On Fri, 27 Jan 2023 20:32:35 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in management components.

Looks good to me (sizeof a local char buffer is the number of chars...).

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

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.org/jdk/pull/12266

From kevinw at openjdk.org  Mon Jan 30 11:50:24 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 30 Jan 2023 11:50:24 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v2]
In-Reply-To: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>
Message-ID: <WXbEEN7ci05lNWJt4j_NM4zk16cciNQZI1ZiB2oxVj4=.c05b22b1-3daf-4535-bc9c-1499c26ffbd1@github.com>

On Wed, 18 Jan 2023 17:56:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
>> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
>> 
>> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - filter properties update: more classes logged as ALLOWED during wider testing
>  - Add a Notification test

Thanks Daniel.  Yes, one problem is that tests were passing with the more restrictive filter.  With the test update here, at least we have a failure with the too-restrictive filter and a pass with this change.
JCK: api/javax_management/ also looks good.

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

PR: https://git.openjdk.org/jdk20/pull/97

From xuelei at openjdk.org  Mon Jan 30 15:12:17 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 30 Jan 2023 15:12:17 GMT
Subject: jmx-dev RFR: 8301279: update for deprecated sprintf for
 management components
In-Reply-To: <rqv13CwvPP0T9L2Wbh8-6GqGIVbKN6-fR9RGgx_yYN0=.18890c10-bec4-4c78-b382-5be564be0e00@github.com>
References: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
 <rqv13CwvPP0T9L2Wbh8-6GqGIVbKN6-fR9RGgx_yYN0=.18890c10-bec4-4c78-b382-5be564be0e00@github.com>
Message-ID: <xgRQSAvQBhucShT7Gu4jcNYVKpQXdrnMPqM900rk1a4=.6dbea05c-b5de-4ca0-8df8-3b8053185e59@github.com>

On Mon, 30 Jan 2023 10:23:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in management components.
>
> Looks good to me (sizeof a local char buffer is the number of chars...).

@kevinjwalls Thank you for the code review.

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

PR: https://git.openjdk.org/jdk/pull/12266

From cjplummer at openjdk.org  Mon Jan 30 19:24:27 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 30 Jan 2023 19:24:27 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v2]
In-Reply-To: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>
Message-ID: <xEmQ1n-w8_sQXkbkBa9b8HDUhYh18Sajfi9-zM6RGIc=.0b3c6d01-597d-449f-bd37-f851a70cba06@github.com>

On Wed, 18 Jan 2023 17:56:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
>> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
>> 
>> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - filter properties update: more classes logged as ALLOWED during wider testing
>  - Add a Notification test

src/jdk.management.agent/share/conf/management.properties line 323:

> 321: java.rmi.dgc.*;\
> 322: java.rmi.server.*;\
> 323: javax.security.auth.Subject;!*

What does the ! at the end indicate?

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

PR: https://git.openjdk.org/jdk20/pull/97

From kevinw at openjdk.org  Mon Jan 30 20:14:10 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 30 Jan 2023 20:14:10 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v2]
In-Reply-To: <xEmQ1n-w8_sQXkbkBa9b8HDUhYh18Sajfi9-zM6RGIc=.0b3c6d01-597d-449f-bd37-f851a70cba06@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>
 <xEmQ1n-w8_sQXkbkBa9b8HDUhYh18Sajfi9-zM6RGIc=.0b3c6d01-597d-449f-bd37-f851a70cba06@github.com>
Message-ID: <U5kT49IJYIcj7DuLdr2Rd4ETQkEZMtlJR5K4hf520Xs=.129781be-e916-4381-9e6b-dd5cff216eaa@github.com>

On Mon, 30 Jan 2023 19:21:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - filter properties update: more classes logged as ALLOWED during wider testing
>>  - Add a Notification test
>
> src/jdk.management.agent/share/conf/management.properties line 323:
> 
>> 321: java.rmi.dgc.*;\
>> 322: java.rmi.server.*;\
>> 323: javax.security.auth.Subject;!*
> 
> What does the ! at the end indicate?

It's "not everything else".

https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html

"If a class name doesn?t match any filter, then it is allowed. If you want to allow only certain class names, then your filter must reject everything that doesn?t match. To reject all class names other than those specified, include !* as the last pattern in a class filter."

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

PR: https://git.openjdk.org/jdk20/pull/97

From sspitsyn at openjdk.org  Mon Jan 30 20:29:06 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 30 Jan 2023 20:29:06 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v2]
In-Reply-To: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>
Message-ID: <T-LoshuYTwu3x4wIjT6qydLb3q6pXIiGdZyoFGrdOd4=.5d8c1c85-e2d9-452d-b1a6-8aff6dd66aac@github.com>

On Wed, 18 Jan 2023 17:56:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
>> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
>> 
>> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - filter properties update: more classes logged as ALLOWED during wider testing
>  - Add a Notification test

This fix looks okay to me.
One nit was inlined.
Thanks,
Serguei

test/jdk/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java line 150:

> 148:             String description = "An attribute of this MBean has changed";
> 149:             MBeanNotificationInfo info = new MBeanNotificationInfo(types, name, description);
> 150:             return new MBeanNotificationInfo[] {info};

Nit: It can be useful to print that this method was invoked the same as in other methods.

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/97

From cjplummer at openjdk.org  Mon Jan 30 21:24:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 30 Jan 2023 21:24:04 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v2]
In-Reply-To: <U5kT49IJYIcj7DuLdr2Rd4ETQkEZMtlJR5K4hf520Xs=.129781be-e916-4381-9e6b-dd5cff216eaa@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>
 <xEmQ1n-w8_sQXkbkBa9b8HDUhYh18Sajfi9-zM6RGIc=.0b3c6d01-597d-449f-bd37-f851a70cba06@github.com>
 <U5kT49IJYIcj7DuLdr2Rd4ETQkEZMtlJR5K4hf520Xs=.129781be-e916-4381-9e6b-dd5cff216eaa@github.com>
Message-ID: <RXjZb8PGcj5lp6vc-YVi_JghSmFpo2dt7frYU2H9F20=.c0e6b55e-5ac3-42c9-a6f0-35d3d68eaeb5@github.com>

On Mon, 30 Jan 2023 20:11:06 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/jdk.management.agent/share/conf/management.properties line 323:
>> 
>>> 321: java.rmi.dgc.*;\
>>> 322: java.rmi.server.*;\
>>> 323: javax.security.auth.Subject;!*
>> 
>> What does the ! at the end indicate?
>
> It's "not everything else".
> 
> https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html
> 
> "If a class name doesn?t match any filter, then it is allowed. If you want to allow only certain class names, then your filter must reject everything that doesn?t match. To reject all class names other than those specified, include !* as the last pattern in a class filter."

Ok. It would be good to clarify that in the comment above this filter. Also, maybe put it on a new line. Otherwise at first glance it appears to have a relationship to the class immediately before it.

Does this mean that this filter list would serve no purpose if the !* was omitted? I'm just curious as to why the !* is needed rather than it just being default behavior that a class has to match a filter in the list.

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

PR: https://git.openjdk.org/jdk20/pull/97

From kevinw at openjdk.org  Tue Jan 31 14:29:38 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 31 Jan 2023 14:29:38 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v3]
In-Reply-To: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
Message-ID: <PFSKFfXoQq5HBrGAcoZWHtQ5iM915Opp-pQoWkTNoeA=.85a93461-9cc8-46c7-bcd4-0119b16a91bc@github.com>

> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
> 
> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.

Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:

 - Test additional print, and comment edit
 - properties comment and formatting
 - Print in getNotificationInfo

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/97/files
  - new: https://git.openjdk.org/jdk20/pull/97/files/ab81891d..2932611e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=97&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=97&range=01-02

  Stats: 11 lines in 2 files changed: 5 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk20/pull/97.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/97/head:pull/97

PR: https://git.openjdk.org/jdk20/pull/97

From kevinw at openjdk.org  Tue Jan 31 14:29:38 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 31 Jan 2023 14:29:38 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v2]
In-Reply-To: <RXjZb8PGcj5lp6vc-YVi_JghSmFpo2dt7frYU2H9F20=.c0e6b55e-5ac3-42c9-a6f0-35d3d68eaeb5@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>
 <xEmQ1n-w8_sQXkbkBa9b8HDUhYh18Sajfi9-zM6RGIc=.0b3c6d01-597d-449f-bd37-f851a70cba06@github.com>
 <U5kT49IJYIcj7DuLdr2Rd4ETQkEZMtlJR5K4hf520Xs=.129781be-e916-4381-9e6b-dd5cff216eaa@github.com>
 <RXjZb8PGcj5lp6vc-YVi_JghSmFpo2dt7frYU2H9F20=.c0e6b55e-5ac3-42c9-a6f0-35d3d68eaeb5@github.com>
Message-ID: <6YsEK10XRSugXAykEEAOp5BXEGw0MU3qwAFRyHxX2cU=.4ced9485-9f1f-4894-99dc-ef60d1c2f4a2@github.com>

On Mon, 30 Jan 2023 21:20:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> It's "not everything else".
>> 
>> https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html
>> 
>> "If a class name doesn?t match any filter, then it is allowed. If you want to allow only certain class names, then your filter must reject everything that doesn?t match. To reject all class names other than those specified, include !* as the last pattern in a class filter."
>
> Ok. It would be good to clarify that in the comment above this filter. Also, maybe put it on a new line. Otherwise at first glance it appears to have a relationship to the class immediately before it.
> 
> Does this mean that this filter list would serve no purpose if the !* was omitted? I'm just curious as to why the !* is needed rather than it just being default behavior that a class has to match a filter in the list.

If a class is not matched, it is "undecided", mentioned at the end of the long comment.  That is not a rejection, which that existing long comment does not state.  For an actual rejection, we need the ! to match, so patterns generally end in !*

It's the same or very similar comment as in conf/security/java.security

I added a note about the !* at the end to clarify, as it is new to use the filter in this area, and yes put it on a new line.

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

PR: https://git.openjdk.org/jdk20/pull/97

From kevinw at openjdk.org  Tue Jan 31 14:29:43 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 31 Jan 2023 14:29:43 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v2]
In-Reply-To: <T-LoshuYTwu3x4wIjT6qydLb3q6pXIiGdZyoFGrdOd4=.5d8c1c85-e2d9-452d-b1a6-8aff6dd66aac@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com>
 <T-LoshuYTwu3x4wIjT6qydLb3q6pXIiGdZyoFGrdOd4=.5d8c1c85-e2d9-452d-b1a6-8aff6dd66aac@github.com>
Message-ID: <9wK0cy50AFGG-GaePRXoriVqdcn27bfQTOO7k1WDow4=.eb063ea1-525c-4c12-923e-c078557b8960@github.com>

On Mon, 30 Jan 2023 20:24:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - filter properties update: more classes logged as ALLOWED during wider testing
>>  - Add a Notification test
>
> test/jdk/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java line 150:
> 
>> 148:             String description = "An attribute of this MBean has changed";
>> 149:             MBeanNotificationInfo info = new MBeanNotificationInfo(types, name, description);
>> 150:             return new MBeanNotificationInfo[] {info};
> 
> Nit: It can be useful to print that this method was invoked the same as in other methods.

got it

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

PR: https://git.openjdk.org/jdk20/pull/97

From kevinw at openjdk.org  Tue Jan 31 17:08:03 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 31 Jan 2023 17:08:03 GMT
Subject: jmx-dev RFR: 8298966: Deprecate JMX Subject Delegation and the
 method JMXConnector.getMBeanServerConnection(Subject) for removal.
Message-ID: <Zc_hSl-2em1bEEdIspD0w9Bnjiu-TKsR1_lBiMRm3iA=.49806323-b36a-4910-ae02-da02e3879a5b@github.com>

Deprecate the Java Management Extension (JMX) Subject Delegation feature for removal in a future release.

Given no known usage, there is no replacement feature for JMX Subject Delegation.

CSR is https://bugs.openjdk.org/browse/JDK-8298967

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

Commit messages:
 - 8298966: Deprecate JMX Subject Delegation and the method JMXConnector.getMBeanServerConnection(Subject) for removal.

Changes: https://git.openjdk.org/jdk/pull/11880/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11880&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298966
  Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11880.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11880/head:pull/11880

PR: https://git.openjdk.org/jdk/pull/11880

From cjplummer at openjdk.org  Tue Jan 31 20:13:09 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 31 Jan 2023 20:13:09 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v3]
In-Reply-To: <PFSKFfXoQq5HBrGAcoZWHtQ5iM915Opp-pQoWkTNoeA=.85a93461-9cc8-46c7-bcd4-0119b16a91bc@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <PFSKFfXoQq5HBrGAcoZWHtQ5iM915Opp-pQoWkTNoeA=.85a93461-9cc8-46c7-bcd4-0119b16a91bc@github.com>
Message-ID: <R5XQ1dS7fCUBZrR-vH_ti4qxQYyoBr7OskuvahtfSuY=.ada83b1c-949c-487d-bf12-6a760a06a98b@github.com>

On Tue, 31 Jan 2023 14:29:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
>> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
>> 
>> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.
>
> Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Test additional print, and comment edit
>  - properties comment and formatting
>  - Print in getNotificationInfo

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/97