From weijun at openjdk.org  Sat Oct  1 15:02:04 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 1 Oct 2022 15:02:04 GMT
Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net =>
 openjdk.org [v4]
In-Reply-To: <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
 <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
 <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
Message-ID: <azol0p7osOA4BoEFm_2HZT1U9GmKrrF4_vMq3o35hVE=.7e936b3f-a0fa-41e8-bf82-66f977688fd8@github.com>

On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?
>
> This is correct.
> AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../"

Thanks @prrace. And yes, git link is better.

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

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

From dfuchs at openjdk.org  Mon Oct  3 11:39:39 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Oct 2022 11:39:39 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter
In-Reply-To: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
Message-ID: <XN1FtrauubZa2UGCD1xmuQXL9Ymez7t4xKKoy8PIc0Q=.76ff2e39-07c0-4e9d-8e64-6df8a6d16307@github.com>

On Fri, 30 Sep 2022 11:00:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
> 
> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
> 
> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.

You will also need to CSR (and release notes). An application that registers its own MBeans in the platform MBeanServer, where such MBeans are not OpenMBeans will be affected by this change, and will need to add whatever types it uses (which might include different flavors of `MBeanInfo` subtypes) in order to be able to access its MBeans through the default agent.

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

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

From darcy at openjdk.org  Mon Oct  3 17:20:53 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:20:53 GMT
Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net =>
 openjdk.org [v4]
In-Reply-To: <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
 <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
Message-ID: <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>

On Fri, 30 Sep 2022 20:25:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?

Filed a few follow-up bugs:

JDK-8294724: Update openjdk.java.net => openjdk.org in tests (umbrella)
JDK-8294725: Update openjdk.java.net => openjdk.org in java command man page

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

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

From darcy at openjdk.org  Mon Oct  3 17:25:30 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:25:30 GMT
Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net =>
 openjdk.org [v6]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <_UYUckHSBcJizYd7JBVbr6evdOrHu9h2MopGUlzrLR8=.b5c6d747-800b-462b-a19a-73a0f5096e3e@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

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

  Update doc directory files.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/fbaf3d4c..6bf7bf61

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

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

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

From darcy at openjdk.org  Mon Oct  3 17:29:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:29:45 GMT
Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net =>
 openjdk.org [v7]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

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

  Update make directory.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/6bf7bf61..224ed7a0

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

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

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

From darcy at openjdk.org  Mon Oct  3 17:38:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:38:14 GMT
Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net =>
 openjdk.org [v4]
In-Reply-To: <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
 <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
 <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>
Message-ID: <w8oqOHIlJyGizESmriPdGYTsVqpLZya2cPRL-2FjHWE=.8730e026-5e1c-4b3f-9543-a8f3eb4a8c3c@github.com>

On Mon, 3 Oct 2022 17:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?
> 
> Filed a few follow-up bugs:
> 
> JDK-8294724: Update openjdk.java.net => openjdk.org in tests (umbrella) JDK-8294725: Update openjdk.java.net => openjdk.org in java command man page

And also filed

JDK-8294728: Update openjdk.java.net => openjdk.org in hotspot unit test docs

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

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

From prr at openjdk.org  Mon Oct  3 20:08:19 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Oct 2022 20:08:19 GMT
Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net =>
 openjdk.org [v7]
In-Reply-To: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
Message-ID: <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>

On Mon, 3 Oct 2022 17:29:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make directory.

src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 36:

> 34:  * https://git.openjdk.org/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> 35:  *
> 36:  * Also note that the API is used in the jaccessinspector and jaccesswalker tools.

The problem with this is, is that anyone who gets JDK 20 (or 21 the LTS) will be forever more then pointed at the OpenJDK "tip" and if we made an incompatible ABI change, that would be a problem.
At this point I'd prefer that this be updated to point to JDK 17, as in
https://github.com/openjdk/jdk17/blob/master/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp
So it is a defined, known, compatible version.

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

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

From darcy at openjdk.org  Mon Oct  3 20:37:11 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 20:37:11 GMT
Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net =>
 openjdk.org [v8]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy 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 11 additional commits since the last revision:

 - Update accessibility URLs.
 - Merge branch 'master' into JDK-8294618
 - Update make directory.
 - Update doc directory files.
 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - Revert unintended update to binary file.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/7a8d31f3...4055f1a6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/224ed7a0..4055f1a6

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

  Stats: 5510 lines in 75 files changed: 3554 ins; 1669 del; 287 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

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

From darcy at openjdk.org  Mon Oct  3 20:37:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 20:37:14 GMT
Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net =>
 openjdk.org [v7]
In-Reply-To: <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
 <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>
Message-ID: <hGRiPhKIV8XCNGN7oJ010i5zPMJJlaYU7XzaP-c0vjM=.dee8d1ca-3312-4540-9f43-879aeffe7431@github.com>

On Mon, 3 Oct 2022 20:04:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update make directory.
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 36:
> 
>> 34:  * https://git.openjdk.org/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
>> 35:  *
>> 36:  * Also note that the API is used in the jaccessinspector and jaccesswalker tools.
> 
> The problem with this is, is that anyone who gets JDK 20 (or 21 the LTS) will be forever more then pointed at the OpenJDK "tip" and if we made an incompatible ABI change, that would be a problem.
> At this point I'd prefer that this be updated to point to JDK 17, as in
> https://github.com/openjdk/jdk17/blob/master/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp
> So it is a defined, known, compatible version.

Updated to refer to JDK 17 specifically.

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

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

From cjplummer at openjdk.org  Tue Oct  4 18:23:32 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 4 Oct 2022 18:23:32 GMT
Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
 <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>
Message-ID: <CR61AGqmsFAARRtaenUEX9DJvp3BC5TknkAuUGNXr8w=.ba3ebdbf-056c-46b7-8762-3e6aff4f1edd@github.com>

On Wed, 28 Sep 2022 15:32:11 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> The title was edited by someone other than me, as you can see from the PR history.

The PR title needs to match the CR synopsis, so update the CR first, and then update the PR.

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

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

From prr at openjdk.org  Tue Oct  4 18:42:44 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 18:42:44 GMT
Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net =>
 openjdk.org [v8]
In-Reply-To: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
Message-ID: <sHOtl2OQ9-SEwkAbYNVq8gBaJMrW-my-5CBX2s1avkI=.8c95a200-f440-4e98-907f-2060e620c5b6@github.com>

On Mon, 3 Oct 2022 20:37:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy 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 11 additional commits since the last revision:
> 
>  - Update accessibility URLs.
>  - Merge branch 'master' into JDK-8294618
>  - Update make directory.
>  - Update doc directory files.
>  - Update hg URLs to git.
>  - Merge branch 'master' into JDK-8294618
>  - http -> https
>  - Undo manpage update.
>  - Update copyright.
>  - Revert unintended update to binary file.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/571e4932...4055f1a6

Marked as reviewed by prr (Reviewer).

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

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

From ihse at openjdk.org  Wed Oct  5 07:43:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Oct 2022 07:43:19 GMT
Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net =>
 openjdk.org [v8]
In-Reply-To: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
Message-ID: <VwPBSkgS79Le2mS0S-MK5Zsm49GZ3eIHj-M-yyHovZg=.219c7fcd-da16-4b54-b50f-6b203107fde2@github.com>

On Mon, 3 Oct 2022 20:37:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy 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 11 additional commits since the last revision:
> 
>  - Update accessibility URLs.
>  - Merge branch 'master' into JDK-8294618
>  - Update make directory.
>  - Update doc directory files.
>  - Update hg URLs to git.
>  - Merge branch 'master' into JDK-8294618
>  - http -> https
>  - Undo manpage update.
>  - Update copyright.
>  - Revert unintended update to binary file.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/72d7bf5d...4055f1a6

Marked as reviewed by ihse (Reviewer).

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

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

From aivanov at openjdk.org  Wed Oct  5 13:27:29 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 13:27:29 GMT
Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <PnxcaX4A0UPATWCWR6qBg7AHmu1d6spEkRYu5mpKFME=.e81f7c64-59d7-48a9-b74a-254af1cc1a18@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Changes requested by aivanov (Reviewer).

src/hotspot/share/opto/memnode.cpp line 2365:

> 2363:   if (x != this)  return x;
> 2364: 
> 2365:   // Take apart the address into an oop and offset.

?and _an_ offset??

src/java.xml/share/classes/org/w3c/dom/Document.java line 293:

> 291:      * <code>systemId</code>, and <code>notationName</code> attributes are
> 292:      * copied. If a <code>deep</code> import is requested, the descendants
> 293:      * of the source <code>Entity</code> are recursively imported and

This class may come from a 3rd party library. Anyone from `java.xml` can confirm it?

test/hotspot/jtreg/vmTestbase/nsk/share/locks/DeadlockMaker.java line 31:

> 29: /*
> 30:  * Class used to create deadlocked threads. It is possible create 2 or more deadlocked thread, also
> 31:  * is possible to specify resource of which type should lock each deadlocked thread

Suggestion:

 * it is possible to specify resource of which type should lock each deadlocked thread

It doesn't sound right without _?it?_.

test/jdk/com/sun/jdi/connect/spi/GeneratedConnectors.java line 28:

> 26:  * @summary Unit test for "Pluggable Connectors and Transports" feature.
> 27:  *
> 28:  * When a transport service is deployed the virtual machine

Suggestion:

 * When a transport service is deployed, the virtual machine

Let's add a comma for clarity.

test/jdk/java/security/testlibrary/SimpleOCSPServer.java line 445:

> 443: 
> 444:     /**
> 445:      * Check the status database for revocation information on one or more

Suggestion:

     * Check the status database for revocation information of one or more

test/jdk/sun/jvmstat/testlibrary/utils.sh line 181:

> 179:         if [ $? -eq 0 ]
> 180:         then
> 181:             # it's still lingering, now it is hard

Suggestion:

            # it's still lingering, now hit it hard

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

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

From aivanov at openjdk.org  Wed Oct  5 14:17:13 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 14:17:13 GMT
Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <VFoXow0glQ610il1bDU1a3KC6dP3S7cxr63T2tRJRZE=.46f798ba-af7c-4aea-9ca8-ce706658b5cc@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

I agree with everyone who said the PR should be broken to smaller pieces so that it touches code / tests in one or two packages, modules. It would be easier to review, you would need to get an approval from reviewers in a one or two specific areas. At this time, this PR touches files in 11 areas according the number of labels which correspond to a specific mailing list where discussions for the area are held.

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

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

From darcy at openjdk.org  Wed Oct  5 16:39:32 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Oct 2022 16:39:32 GMT
Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net =>
 openjdk.org [v9]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <T3sWlUnikg_EsuKqJ5PFiXj8IDAbk0fYG-WR3iLLvTw=.19912185-605f-4201-8022-0ffb7e00342d@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy 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 12 additional commits since the last revision:

 - Merge branch 'master' into JDK-8294618
 - Update accessibility URLs.
 - Merge branch 'master' into JDK-8294618
 - Update make directory.
 - Update doc directory files.
 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/8aa24fec...eba2bd4b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/4055f1a6..eba2bd4b

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

  Stats: 1452 lines in 87 files changed: 912 ins; 312 del; 228 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

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

From darcy at openjdk.org  Wed Oct  5 16:52:27 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Oct 2022 16:52:27 GMT
Subject: jmx-dev Integrated: JDK-8294618: Update openjdk.java.net =>
 openjdk.org
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <vtc6z3XjCCr9yLV3usCQemL0opkJB2S_3H8IZGWwD_A=.7c03befe-b74b-48e0-ad2d-3594d6ebc1b5@github.com>

On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

This pull request has now been integrated.

Changeset: 536c9a51
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/536c9a512ea90d97a1ae5310453410d55db98bdd
Stats:     128 lines in 45 files changed: 0 ins; 0 del; 128 mod

8294618: Update openjdk.java.net => openjdk.org

Reviewed-by: mikael, iris, joehw, prr, ihse

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

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

From alanb at openjdk.org  Fri Oct  7 12:53:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Oct 2022 12:53:30 GMT
Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

src/java.se/share/data/jdwp/jdwp.spec line 101:

> 99:         "<a href=../../api/java.base/java/lang/Thread.html#platform-threads>platform thread</a> "
> 100:         "in the target VM. This includes platform threads created with the Thread "
> 101:         "API and all native threads attached to the target VM with JNI code."

The spec for the JDWP AllThreads command was significantly reworded in Java 19 so this is where this typo crept in. We have JDK-8294672 tracking it to fix for Java 20, maybe you should take it?

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

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

From dfuchs at openjdk.org  Tue Oct 11 17:52:18 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Oct 2022 17:52:18 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter
In-Reply-To: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
Message-ID: <KH3EHBG4u8aFiadaU_Z3UAFMJ65NF6yrJCbgoqjFdpY=.54077899-99f2-4161-b99a-30a71c25eff5@github.com>

On Fri, 30 Sep 2022 11:00:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
> 
> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
> 
> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.

src/jdk.management.agent/share/conf/management.properties line 306:

> 304: #   Otherwise, the status is UNDECIDED.
> 305: com.sun.management.jmxremote.serial.filter.pattern=java.lang.*;java.math.BigInteger;java.math.BigDecimal;java.util.*;javax.management.openmbean.*;javax.management.ObjectName;java.rmi.MarshalledObject;javax.security.auth.Subject;!*
> 306: 

Should the pattern also include the name of the module that define these type?
Also this set doesn't seem to include javax.management.MBeanInfo and all the types it might contain. This leads me to think that regular MBeans which are not MXBeans or OpenMBeans, like the `DiagnosticCommandMBean` or the `MBeanServerDelegateMBean` might become inaccessible from remote after this change.

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

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

From jpai at openjdk.org  Mon Oct 17 14:03:50 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Oct 2022 14:03:50 GMT
Subject: jmx-dev RFR: 8030616:
 sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently
 with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <kV_rKhrYtDEsLIFsCJ8fJqyLWt-nbjt-MlimSSn8ujY=.58e94369-7166-4bc8-a2f6-84b3d4fd92b4@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

Please keep open. Waiting for reviews on this one.

Mark and me ran some experiments related to this issue and we did conclude that this change will help the issue at hand. @msheppar, please correct me if that's not an accurate summary.

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

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

From kevinw at openjdk.org  Wed Oct 19 16:14:16 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 19 Oct 2022 16:14:16 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v2]
In-Reply-To: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
Message-ID: <QpxsG4wtsYa5a2PbjTIso-9xTGoG1R7mkMRYAC_Fbh8=.7e36f798-9412-4a4f-bb63-7b0c118df48f@github.com>

> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
> 
> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
> 
> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.

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

  Update test to check default filter in place.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10507/files
  - new: https://git.openjdk.org/jdk/pull/10507/files/7d171854..78e5c897

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

  Stats: 25 lines in 1 file changed: 16 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10507.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10507/head:pull/10507

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

From kevinw at openjdk.org  Wed Oct 19 16:14:16 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 19 Oct 2022 16:14:16 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter
In-Reply-To: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
Message-ID: <KBnNgC5NrIwBp4HJ81w844Y0-nT1Cc6qeaawq6dYe2A=.0409268f-cac7-4cdb-8f95-b88aa37af744@github.com>

On Fri, 30 Sep 2022 11:00:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
> 
> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
> 
> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.

Test update...  We have:
test/jdk/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java
...which already tests the filter feature.
It tests a JMX Connection and an operation with a parameter of type "MyTestObject", which can  work or fail depending on which filter is in place.
I am updating that test to make sure there is a failure when using the default filter.

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

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

From dfuchs at openjdk.org  Wed Oct 19 16:39:02 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 19 Oct 2022 16:39:02 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v2]
In-Reply-To: <QpxsG4wtsYa5a2PbjTIso-9xTGoG1R7mkMRYAC_Fbh8=.7e36f798-9412-4a4f-bb63-7b0c118df48f@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <QpxsG4wtsYa5a2PbjTIso-9xTGoG1R7mkMRYAC_Fbh8=.7e36f798-9412-4a4f-bb63-7b0c118df48f@github.com>
Message-ID: <jikmlLnuv9GpNLSVrKhL3uPztL-embZ_P8lLUZ5kKVE=.18cd93f4-e754-4457-b668-6cb40ad3b6b7@github.com>

On Wed, 19 Oct 2022 16:14:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
>> 
>> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
>> 
>> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test to check default filter in place.

Trivially you should probably add `8283093` in the list of bugs that the test helps verify.
Also I see the test is using `Utils.getFreePort()` which is a recipe for intermittent failures (not something you should change here, unless adding the new test case increases  their occurrence, but something to remember for later).

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

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

From kevinw at openjdk.org  Wed Oct 19 17:54:02 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 19 Oct 2022 17:54:02 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
Message-ID: <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>

> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
> 
> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
> 
> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.

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

  Additional test with command-line filter setting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10507/files
  - new: https://git.openjdk.org/jdk/pull/10507/files/78e5c897..e6940778

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

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

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

From kevinw at openjdk.org  Wed Oct 19 17:54:04 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 19 Oct 2022 17:54:04 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v2]
In-Reply-To: <jikmlLnuv9GpNLSVrKhL3uPztL-embZ_P8lLUZ5kKVE=.18cd93f4-e754-4457-b668-6cb40ad3b6b7@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <QpxsG4wtsYa5a2PbjTIso-9xTGoG1R7mkMRYAC_Fbh8=.7e36f798-9412-4a4f-bb63-7b0c118df48f@github.com>
 <jikmlLnuv9GpNLSVrKhL3uPztL-embZ_P8lLUZ5kKVE=.18cd93f4-e754-4457-b668-6cb40ad3b6b7@github.com>
Message-ID: <coxyj6IYQ2cKRkhLyeSz9hqCjkSSVjUJF2Czc1taYL0=.a8f9b38c-4c49-4993-8724-f40d4d9c7b52@github.com>

On Wed, 19 Oct 2022 16:36:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Trivially you should probably add `8283093` in the list of bugs that the test helps verify. Also I see the test is using `Utils.getFreePort()` which is a recipe for intermittent failures (not something you should change here, unless adding the new test case increases their occurrence, but something to remember for later).

Yes, added.  Yes the port clashes are problematic, this one seems to run well at the moment!

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

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

From kevinw at openjdk.org  Wed Oct 19 17:55:40 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 19 Oct 2022 17:55:40 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v2]
In-Reply-To: <QpxsG4wtsYa5a2PbjTIso-9xTGoG1R7mkMRYAC_Fbh8=.7e36f798-9412-4a4f-bb63-7b0c118df48f@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <QpxsG4wtsYa5a2PbjTIso-9xTGoG1R7mkMRYAC_Fbh8=.7e36f798-9412-4a4f-bb63-7b0c118df48f@github.com>
Message-ID: <Ww7IGty4_7V8l--A7RYziirMQg-vPJq1PHhIhhf1_0E=.cb7d6363-235d-4ddc-8632-44e23fcf0170@github.com>

On Wed, 19 Oct 2022 16:14:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
>> 
>> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
>> 
>> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test to check default filter in place.

Updated with additional test: specify a filter on the command-line with -D.  
Setting -Dcom.sun.management.jmxremote.serial.filter.pattern= is the alternative workaround to setting -Dcom.sun.management.config.file if a problematic app/mbean is discovered.

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

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

From sspitsyn at openjdk.org  Thu Oct 20 00:33:57 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Oct 2022 00:33:57 GMT
Subject: jmx-dev RFR: 8030616:
 sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently
 with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <BvE4r9TdgOEe8r7urVd4j0IvzhukESe4E1zdu7daCcA=.db72b11a-4658-4e3d-b0cb-32cde0e983b8@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

This looks okay to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From jpai at openjdk.org  Thu Oct 20 10:01:19 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Oct 2022 10:01:19 GMT
Subject: jmx-dev RFR: 8030616:
 sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently
 with cannot find a free port [v2]
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

Jaikiran Pai 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 three additional commits since the last revision:

 - Merge latest from master branch
 - remove unintentionally committed file
 - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10322/files
  - new: https://git.openjdk.org/jdk/pull/10322/files/ddfb8c95..01267c65

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

  Stats: 66155 lines in 2020 files changed: 37805 ins; 19685 del; 8665 mod
  Patch: https://git.openjdk.org/jdk/pull/10322.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10322/head:pull/10322

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

From jpai at openjdk.org  Thu Oct 20 10:01:20 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Oct 2022 10:01:20 GMT
Subject: jmx-dev RFR: 8030616:
 sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently
 with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <u_HgyeNwDcLAoB2YG-VY9NX1dMnHThl3iSH9OcwNaK8=.220c5237-a512-4f4f-9c82-50a97ba9fa25@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

Hello Serguei,

Thank you for your review. I was about to integrate this when I just noticed that I had unintentionally included a new empty file in this commit. 

I've now updated this PR to remove that stray file (and no other changes). Could you please review the current state of this PR once more?

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

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

From ihse at openjdk.org  Thu Oct 20 12:06:27 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 12:06:27 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for properties
 files
Message-ID: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>

Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).

The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

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

Commit messages:
 - 8295729: Add jcheck whitespace checking for properties files

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

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

From sspitsyn at openjdk.org  Thu Oct 20 14:34:19 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Oct 2022 14:34:19 GMT
Subject: jmx-dev RFR: 8030616:
 sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently
 with cannot find a free port [v2]
In-Reply-To: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
 <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
Message-ID: <EGTFUUFqShqr3vjtYisj2s0-fA1y5nrwC5QYj3gMPyM=.194e98d2-0c98-4899-a7e8-e02f36646315@github.com>

On Thu, 20 Oct 2022 10:01:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
>> 
>> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
>> 
>> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
>> 
>> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
>> 
>> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
>> 
>> Multiple test runs after this change hasn't yet run into the failure.
>
> Jaikiran Pai 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 three additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - remove unintentionally committed file
>  - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Marked as reviewed by sspitsyn (Reviewer).

Two reviews are required in the Serviceability area.
So, please, wait for one more.

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

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

From jpai at openjdk.org  Thu Oct 20 14:47:53 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Oct 2022 14:47:53 GMT
Subject: jmx-dev RFR: 8030616:
 sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently
 with cannot find a free port [v2]
In-Reply-To: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
 <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
Message-ID: <-jTKvVALRloZ4SS6xWVZYOtfN6IDo4dVDRNhH4OnY_0=.2b6327a2-c5af-491b-9963-65fb9128d22b@github.com>

On Thu, 20 Oct 2022 10:01:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
>> 
>> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
>> 
>> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
>> 
>> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
>> 
>> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
>> 
>> Multiple test runs after this change hasn't yet run into the failure.
>
> Jaikiran Pai 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 three additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - remove unintentionally committed file
>  - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Thank you again Serguei for the review.

> Two reviews are required in the Serviceability area.
So, please, wait for one more.

I wasn't aware of that. Will certainly wait. I have triggered some tests in our internal CI system too to make sure the latest runs too are clean.

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

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

From msheppar at openjdk.org  Thu Oct 20 16:16:53 2022
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 20 Oct 2022 16:16:53 GMT
Subject: jmx-dev RFR: 8030616:
 sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently
 with cannot find a free port [v2]
In-Reply-To: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
 <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
Message-ID: <eqttcOVozBKxZWZwhgARUS_nMXI3U-dc-vG7RSzKb9A=.d2dac29b-87cd-49e2-9be7-8e792113dcde@github.com>

On Thu, 20 Oct 2022 10:01:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
>> 
>> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
>> 
>> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
>> 
>> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
>> 
>> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
>> 
>> Multiple test runs after this change hasn't yet run into the failure.
>
> Jaikiran Pai 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 three additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - remove unintentionally committed file
>  - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

yes, I think we found the change will be benefial

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

Marked as reviewed by msheppar (Reviewer).

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

From erikj at openjdk.org  Thu Oct 20 18:26:46 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:26:46 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <NObZDn88VUQ8fHaLhcrqe0wkth0EfVAwjWA7K4eAY2k=.0c70399e-f307-4ca4-a637-e2f1ebedf960@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Nice job!

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

Marked as reviewed by erikj (Reviewer).

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

From naoto at openjdk.org  Thu Oct 20 18:33:47 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 18:33:47 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <0VhVC2dpGOdpE3OL1278r0iCVXO1Jd_83Q4kszfikjY=.fecfe4ed-9a48-4fe4-827a-7ab1bc2defa2@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

LGTM. Haven't looked at all the l10n files.

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

Marked as reviewed by naoto (Reviewer).

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

From angorya at openjdk.org  Thu Oct 20 18:40:47 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:40:47 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

I would vote against this change.  Per java properties spec
https://github.com/openjdk/jdk/pull/10792


White space following the property value is not ignored, and is treated as part of the property value.


This change might break localization or messages where trailing whitespace is important (example: "Label: ")

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

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

From ihse at openjdk.org  Thu Oct 20 18:48:17 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 18:48:17 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> I would vote against this change.  Per java properties spec
> https://github.com/openjdk/jdk/pull/10792
> 
> 
> White space following the property value is not ignored, and is treated as part of the property value.
> 
> 
> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
> 
> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
> 
> 
> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;

@andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

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

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

From erikj at openjdk.org  Thu Oct 20 18:53:49 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:53:49 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <qf8daMUSgSlaXN3bROLfbFbpzrDJh5wSJdnTYQdol64=.df762075-9646-4aab-ab95-ead96e45936a@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Given that trailing whitespace may be part of a property value, then I take back my review.

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

Changes requested by erikj (Reviewer).

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

From cjplummer at openjdk.org  Thu Oct 20 18:53:50 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Oct 2022 18:53:50 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <uNs096Y7_C0U9CTifzO1PL71uAgKv0RwAxTfOuL5LGw=.e8e725f6-3fac-4b54-b406-111628923ae8@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> `White space following the property value is not ignored, and is treated as part of the property value.`

Although I didn't know this was in the spec, I suspected it might be the case. When looking at the jdk.management.agent changes, it looked like the extra space was actually a typo and was copied into all the localized versions (and not actually localized for unicode locales). In this case removing the white space is the right thing to do. It is in fact fixing an actual bug.

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

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

From angorya at openjdk.org  Thu Oct 20 18:53:51 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:53:51 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
 <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
Message-ID: <HJm4YG5tr3dJ4SeXPS58BEpkBqzUEk7QwX6Cmf5x8JA=.7076b0a9-6fe2-4e0a-99f9-d3ca8a828a5a@github.com>

On Thu, 20 Oct 2022 18:46:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I would vote against this change.  Per java properties spec
>> https://github.com/openjdk/jdk/pull/10792
>> 
>> 
>> White space following the property value is not ignored, and is treated as part of the property value.
>> 
>> 
>> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
>> 
>> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
>> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
>> 
>> 
>> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;
>
> @andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

@magicus  : 
no, this is how Properties were working from day one.


package goryachev.research;

import java.io.IOException;
import java.io.StringReader;
import java.util.Properties;

public class TestProperties {
    public static void main(String[] args) throws IOException {
        String text = "key= value ";
        Properties p = new Properties();
        p.load(new StringReader(text));
        System.out.println("value=["  +p.getProperty("key") + "]");
    }
}


outputs:

value=[value ]

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

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

From ihse at openjdk.org  Thu Oct 20 19:07:52 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 19:07:52 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <vN85_fh3ocln38nEOKYh1GBwW5xzb3nIo_jYOQYqiLY=.6e65e099-3d3c-40fe-8cfa-1acf25fdd0a7@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Okay. That definitely rules out adding .properties to the whitespace jcheck verification.

However, I think that instead opens up a ton of more individual problems, since I think most (if perhaps not all) of these trailing whitespaces are incidental, and thus might be bugs. Perhaps no-one really noticed a double whitespace where it were not supposed to be, etc, especially not if it was just for a translated language.

I'm thinking I should redirect this PR to skip the jcheck requirement, and revert all changes to property values, but keep the part of the patch that removes trailing spaces in `#` comment lines. That seems to account for a majority of the changes.

For the remaining properties files with trailing spaces in the actual values, I'll make a sanity check if it seems correct or not, and if it looks fishy, I'll open bugs on the respective component teams to verify that their property values are indeed correct.

Does that sound reasonable?

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

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

From naoto at openjdk.org  Thu Oct 20 19:29:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:29:51 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <iu-qPLbaWYYTSq2jVgsGXDGt8Weqq2RVuoaHyuI0YRg=.f4131b5a-9685-4246-bbac-85b776fee6e3@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Retracting my approval too. Thanks for the catch, Andy!
That sounds reasonable > Magnus

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

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

From naoto at openjdk.org  Thu Oct 20 19:40:55 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:40:55 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <eJ0YaIIkCYOV7stEG2AEVx05evyYix9H9Zp2eAlJsjA=.2e14e322-75f6-4651-bb96-c24cf2f10391@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

(retracting approval)

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

Changes requested by naoto (Reviewer).

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

From ihse at openjdk.org  Fri Oct 21 08:17:46 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:17:46 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v2]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove check for .properties from jcheck
 - Restore trailing whitespace for property values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/e33c0765..c91fdaa1

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

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

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

From jpai at openjdk.org  Fri Oct 21 08:29:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Oct 2022 08:29:51 GMT
Subject: jmx-dev RFR: 8030616:
 sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently
 with cannot find a free port [v2]
In-Reply-To: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
 <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
Message-ID: <7zx8mBlRbPNKN4gNtAtiD3Ha1P5iaw4j4VeUsy0LfPA=.ed01337f-83bf-496a-803e-ff79aef67b4e@github.com>

On Thu, 20 Oct 2022 10:01:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
>> 
>> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
>> 
>> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
>> 
>> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
>> 
>> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
>> 
>> Multiple test runs after this change hasn't yet run into the failure.
>
> Jaikiran Pai 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 three additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - remove unintentionally committed file
>  - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Thank you Mark for the review.

The CI tests for this came back fine.

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

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

From ihse at openjdk.org  Fri Oct 21 08:31:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:31:59 GMT
Subject: jmx-dev RFR: 8295729: Remove trailing whitespace from non-value
 lines in properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <1mu65mMxl2Nf-mwa4iZczOBqJbPdutKpL6dE_3vMWcg=.c03430ed-70df-40fa-994e-700080b7b8fa@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Ok, I repurposed this PR to deal only with trailing space on non-value lines (comments and empty lines). This should be trivial, and will reduce the trailing spaces to only the value lines.

I believe most, but perhaps not all, trailing spaces in the value lines are actually bugs, but that will need further scrutiny by the owners of the properties files. Expect follow up bugs on this.

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

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

From jpai at openjdk.org  Fri Oct 21 08:32:01 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Oct 2022 08:32:01 GMT
Subject: jmx-dev Integrated: 8030616:
 sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently
 with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <_IC9ikiTepKTv7KU3fGXyC6i8hh3GKUJAg9xCVjgzfc=.6184ddb6-7bd2-4059-a7cc-1d9028d7a86d@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

This pull request has now been integrated.

Changeset: 8b010e01
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b010e014c44ffb728b7a8343d3298466f5252fa
Stats:     7 lines in 2 files changed: 5 ins; 0 del; 2 mod

8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Reviewed-by: sspitsyn, msheppar

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

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

From dfuchs at openjdk.org  Fri Oct 21 09:48:06 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Oct 2022 09:48:06 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
Message-ID: <0WuglNS-VfPbyjPLvw-EuSUhQEUBavHyqnHAVn1qs90=.8e9fffb3-9bf8-42a0-af92-64b4b7514dbd@github.com>

On Wed, 19 Oct 2022 17:54:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
>> 
>> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
>> 
>> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional test with command-line filter setting.

Looks good

test/jdk/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java line 297:

> 295:             // Use default filter, should fail with: java.io.InvalidClassException: filter status: REJECTED
> 296:             testDefaultAgent(null /* no properties file */);
> 297:             throw new RuntimeException("---" + DefaultAgentFilterTest.class.getName() + " - No exception reported");

Not that it matters much but traditionally we would throw AssertionError in such cases...

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

Marked as reviewed by dfuchs (Reviewer).

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

From dfuchs at openjdk.org  Fri Oct 21 09:51:47 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Oct 2022 09:51:47 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
Message-ID: <OcFc7jMwA5mu3y4R4oR4wPNzJNgFsD9ryW_FFokCyJ4=.364c0fa8-85f3-46c6-afe4-ace670eccdad@github.com>

On Wed, 19 Oct 2022 17:54:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
>> 
>> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
>> 
>> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional test with command-line filter setting.

Please get approval from a serviceability reviewer before integrating.

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

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

From kevinw at openjdk.org  Fri Oct 21 10:02:27 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Oct 2022 10:02:27 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
Message-ID: <n5en3-1UqpGOZZR3o1iq_cpGyP6I58w78mlmaUWRAZo=.b1de96a7-0bb7-4e54-af20-8dc794d6ded2@github.com>

On Wed, 19 Oct 2022 17:54:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
>> 
>> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
>> 
>> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional test with command-line filter setting.

Thanks Daniel!

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

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

From kevinw at openjdk.org  Fri Oct 21 10:02:29 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Oct 2022 10:02:29 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <KH3EHBG4u8aFiadaU_Z3UAFMJ65NF6yrJCbgoqjFdpY=.54077899-99f2-4161-b99a-30a71c25eff5@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <KH3EHBG4u8aFiadaU_Z3UAFMJ65NF6yrJCbgoqjFdpY=.54077899-99f2-4161-b99a-30a71c25eff5@github.com>
Message-ID: <gIl4ZvxYVmK4NPpIAl-SPaz9mjLJC2YW-i9V8qEhX2I=.2eccb9a1-456c-4207-b60e-83e5a55e82c4@github.com>

On Tue, 11 Oct 2022 17:48:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Additional test with command-line filter setting.
>
> src/jdk.management.agent/share/conf/management.properties line 306:
> 
>> 304: #   Otherwise, the status is UNDECIDED.
>> 305: com.sun.management.jmxremote.serial.filter.pattern=java.lang.*;java.math.BigInteger;java.math.BigDecimal;java.util.*;javax.management.openmbean.*;javax.management.ObjectName;java.rmi.MarshalledObject;javax.security.auth.Subject;!*
>> 306: 
> 
> Should the pattern also include the name of the module that define these type?

Thinking that won't matter for packages like java.lang but we could mention somewhere (e.g. release note) that a package can be specified (it's documented in the ObjectInputFilter api docs I think).

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

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

From dfuchs at openjdk.org  Fri Oct 21 10:25:54 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Oct 2022 10:25:54 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <gIl4ZvxYVmK4NPpIAl-SPaz9mjLJC2YW-i9V8qEhX2I=.2eccb9a1-456c-4207-b60e-83e5a55e82c4@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <KH3EHBG4u8aFiadaU_Z3UAFMJ65NF6yrJCbgoqjFdpY=.54077899-99f2-4161-b99a-30a71c25eff5@github.com>
 <gIl4ZvxYVmK4NPpIAl-SPaz9mjLJC2YW-i9V8qEhX2I=.2eccb9a1-456c-4207-b60e-83e5a55e82c4@github.com>
Message-ID: <blj2w0MxS7yrJFz2dnx2DprdUPpVQoRpT8JOBoxQzNY=.04d51fda-6ce9-4c29-9df3-df8372c05cdd@github.com>

On Fri, 21 Oct 2022 09:59:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/jdk.management.agent/share/conf/management.properties line 306:
>> 
>>> 304: #   Otherwise, the status is UNDECIDED.
>>> 305: com.sun.management.jmxremote.serial.filter.pattern=java.lang.*;java.math.BigInteger;java.math.BigDecimal;java.util.*;javax.management.openmbean.*;javax.management.ObjectName;java.rmi.MarshalledObject;javax.security.auth.Subject;!*
>>> 306: 
>> 
>> Should the pattern also include the name of the module that define these type?
>
> Thinking that won't matter for packages like java.lang but we could mention somewhere (e.g. release note) that a package can be specified (it's documented in the ObjectInputFilter api docs I think).

Yes. It would matter for any package not in the java space that has a pattern allowing recursive match, like e.g. `<package-prefix>.**` ; In that case specifying the module would be important.

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

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

From erikj at openjdk.org  Fri Oct 21 12:59:48 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 21 Oct 2022 12:59:48 GMT
Subject: jmx-dev RFR: 8295729: Remove trailing whitespace from non-value
 lines in properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <AoFGXlCHPgwZa3u0Kwp6W-h5k-I_Malb2gWa3tSxSbw=.500a110c-0c73-4205-9a2e-e281bfb3a730@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by erikj (Reviewer).

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

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

From naoto at openjdk.org  Fri Oct 21 16:09:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 16:09:28 GMT
Subject: jmx-dev RFR: 8295729: Remove trailing whitespace from non-value
 lines in properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

One possible solution to this is to replace those dangling white spaces with explicit Unicode escapes, i.e. "\u0009" and "\u0020".  This way jcheck can safely be enabled to detect future unwanted trailing spaces, and possibly existing ones can be visually recognizable by the engineers to correct them.

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

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

From angorya at openjdk.org  Fri Oct 21 16:09:29 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Oct 2022 16:09:29 GMT
Subject: jmx-dev RFR: 8295729: Remove trailing whitespace from non-value
 lines in properties files [v2]
In-Reply-To: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
Message-ID: <khuIARsEyKMyIfUxBD69kijyjnwDFCzAra51YwctMyY=.71b00eb7-1312-4db9-a6a5-ff85f7635132@github.com>

On Fri, 21 Oct 2022 16:04:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> replace those dangling white spaces with explicit Unicode escapes

this is a *very good* idea.

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

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

From bhuang at openjdk.org  Fri Oct 21 21:52:48 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Fri, 21 Oct 2022 21:52:48 GMT
Subject: jmx-dev RFR: JDK-8295756 Improve NonLocalRegistry Manual Test
 Process
Message-ID: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>

The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. 

Tests include: 
java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java 
java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java 
javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java

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

Commit messages:
 - Updated TEST.groups
 - JDK-8295756 Improve NonLocalRegistry Manual Test Process

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

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

From prr at openjdk.org  Mon Oct 24 03:55:56 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:55:56 GMT
Subject: jmx-dev RFR: 8295729: Remove trailing whitespace from non-value
 lines in properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <6Nga-zBIoxnexiDJp-uJqSHjkki2U2n6y5WW9chvPz0=.f389c36c-e6bd-4b32-81a2-0304f23ba6a2@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by prr (Reviewer).

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

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

From ihse at openjdk.org  Mon Oct 24 19:21:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:21:07 GMT
Subject: jmx-dev RFR: 8295729: Remove trailing whitespace from non-value
 lines in properties files [v3]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "Remove check for .properties from jcheck"
   
   This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
 - Change trailing space and tab in values to unicode encoding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/c91fdaa1..f4f94341

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

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

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

From angorya at openjdk.org  Mon Oct 24 19:22:38 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:22:38 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

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

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

From ihse at openjdk.org  Mon Oct 24 19:25:38 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:25:38 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <yZpwsDUeKIrGQT3tvyGfGHFjIOuQTOBfRyvV7b-uArA=.077497ab-51b8-4346-b67d-9838e3419964@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I agree, that was an excellent idea Naoto! In my last commit, I have converted all trailing spaces/tabs in value lines into explicit unicode characters. Since that means we have no trailing spaces (from a jcheck perspective), I could also restore the jcheck that was the original driver behind this bug. (And also restore the bug/PR title to show the original intent.)

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

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

From ihse at openjdk.org  Mon Oct 24 19:31:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:31:26 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v2]
In-Reply-To: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
Message-ID: <HmB2uBGv-fQnz3Kn7yEA0yIR4akDfM4tmso3sgA4-aQ=.d84de722-5d04-4aad-8ba3-572eea3cacc1@github.com>

On Mon, 24 Oct 2022 19:20:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove check for .properties from jcheck
>>  - Restore trailing whitespace for property values
>
> 368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

@andy-goryachev-oracle They are all automatically processed. There are two kinds of changes: Non-value lines have their trailing whitespace removed. You can verify that part of the PR by looking here: https://github.com/openjdk/jdk/pull/10792/files/c91fdaa19dc06351598bd1c0614e1af3bfa08ae2

This was the state of the PR as of three days ago. The most numerous number of changed files are here, but you can just scroll through the change and verify quickly that it is trivial.

The second change is the one suggested by Naoti; I have replaced all trailing tabs (there were just one) with `\u0009` and all trailing spaces with `\u0020`. That part was just pushed by me now. You can see that part separately here: https://github.com/openjdk/jdk/pull/10792/commits/a509b90f1b7f833924493fbd28b3cbb1a85c1f21

This affects far fewer files. And once again, it was mechanically generated. You can once again just scroll through and verify that all changes are due to the trailing whitespace being converted to unicode sequences.

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

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

From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Started looking at whether certain trailing spaces can be (and/or should be) removed, but it quickly became apparent that we should just keep these properties as is (with the unicode escapes), rather than risk regression.

src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:

> 185: ### Button Demo ###
> 186: 
> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020

trailing whitespace looks unnecessary (accessible description?)

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Fehler beim Umbenennen von Datei oder Ordner
> 66: FileChooser.renameError.textAndMnemonic={0} kann nicht umbenannt werden
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0} kann nicht umbenannt werden: Es ist bereits eine Datei mit dem angegebenen Namen vorhanden. Geben Sie einen anderen Dateinamen an.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Error al cambiar el nombre del archivo o carpeta
> 66: FileChooser.renameError.textAndMnemonic=No se puede cambiar el nombre de {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=No se puede cambiar el nombre de {0}: ya existe un archivo con el nombre especificado. Especifique otro nombre de archivo.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Erreur lors du changement de nom du fichier ou du dossier
> 66: FileChooser.renameError.textAndMnemonic=Impossible de renommer {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossible de renommer {0} : il existe d\u00E9j\u00E0 un fichier portant le nom indiqu\u00E9. Indiquez-en un autre.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Errore durante la ridenominazione del file o della cartella
> 66: FileChooser.renameError.textAndMnemonic=Impossibile rinominare {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossibile rinominare {0}: esiste gi\u00E0 un file con il nome specificato. Specificare un altro nome.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=\u30D5\u30A1\u30A4\u30EB\u307E\u305F\u306F\u30D5\u30A9\u30EB\u30C0\u306E\u540D\u524D\u5909\u66F4\u30A8\u30E9\u30FC
> 66: FileChooser.renameError.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093: \u6307\u5B9A\u3057\u305F\u540D\u524D\u306E\u30D5\u30A1\u30A4\u30EB\u306F\u3059\u3067\u306B\u5B58\u5728\u3057\u307E\u3059\u3002\u5225\u306E\u30D5\u30A1\u30A4\u30EB\u540D\u3092\u6307\u5B9A\u3057\u3066\u304F\u3060\u3055\u3044\u3002\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Ett fel intr\u00E4ffade vid f\u00F6rs\u00F6k att \u00E4ndra namn p\u00E5 fil eller mapp
> 66: FileChooser.renameError.textAndMnemonic=Kan inte namn\u00E4ndra {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Kan inte namn\u00E4ndra {0}: En fil med angivet namn finns redan. Ange ett annat filnamn.\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat failed on value ( {0} ) in column {1}
> 43: cachedrowsetimpl.doublefail = getDouble failed on value ( {0} ) in column {1}
> 44: cachedrowsetimpl.dtypemismt = Data Type Mismatch\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 73:

> 71: cachedrowsetimpl.numrows = Number of rows is less than zero or less than fetch size
> 72: cachedrowsetimpl.startpos = Start position cannot be negative
> 73: cachedrowsetimpl.nextpage = Populate data before calling\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative : Invalid cursor operation\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 128:

> 126: crswriter.params1 = Value of params1 : {0}\u0020
> 127: crswriter.params2 = Value of params2 : {0}\u0020
> 128: crswriter.conflictsno =  conflicts while synchronizing\u0020

this is tricky.  if this value is a part of a sentence (i.e. something like "5 conflicts..."), the localization is likely to be wrong.  it's hard to tell without looking further into the code.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 43: cachedrowsetimpl.doublefail = getDouble bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 44: cachedrowsetimpl.dtypemismt = Keine Datentyp\u00FCbereinstimmung\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 73:

> 71: cachedrowsetimpl.numrows = Zeilenanzahl ist kleiner als null oder kleiner als Abrufgr\u00F6\u00DFe
> 72: cachedrowsetimpl.startpos = Startposition darf keinen Negativwert aufweisen
> 73: cachedrowsetimpl.nextpage = Daten m\u00FCssen vor dem Aufruf ausgef\u00FCllt werden\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative: Ung\u00FCltiger Cursorvorgang\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Indexwert liegt au\u00DFerhalb des Bereichs\u0020\u0020

prob. unnecessary

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

Marked as reviewed by angorya (no project role).

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

From ihse at openjdk.org  Mon Oct 24 19:45:01 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed. I did not think it was a good idea to hold this PR, waiting for component teams to do the whitespace check first, for two reasons:

1) Now the trailing whitespace will be obvious, and any intended whitespace will not be accidentally stripped by an editor, so it will be easier for engineers to fix any problems.

2) I know from experience that this kind of cleaning-up has a very low priority for many engineers. If this PR were dependent on all JDK groups going through their properties files, it would basically never be closed.

And finally: Here is a complete list of the files which has trailing "unicode whitespace" in values. I will try to figure out to which components these belongs and open corresponding bugs.


src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties
src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties
src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_TW.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_zh_CN.properties
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_de.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties
test/jdk/javax/net/ssl/Stapling/TEST.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/FileChooserDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/togglebutton/resources/ToggleButtonDemo.properties
test/jdk/tools/jmod/src/foo/jdk/test/foo/resources/foo.properties

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

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

From jjg at openjdk.org  Mon Oct 24 19:45:01 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

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

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

From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
Message-ID: <cuJYgquzi3I4fULUZZz_G_ZjmEd_wDsUPw2mzCceM_w=.ad366bc4-db7f-48ad-9d3f-a8d0ba9e1820@github.com>

On Mon, 24 Oct 2022 19:34:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed.

probably not needed - if nobody noticed anything until now we have no problem.  the solution to escape whitespace in values is the right solution, solves both the jcheck and WS visibility issues.

good job!

(and we can ignore my "prob. unnecessary" comments)

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

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

From angorya at openjdk.org  Mon Oct 24 19:45:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:02 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <cRpIep8vLpUKvRQH3e_vwTIqVChg5uSLhFH4sSCbmOQ=.9c8e6492-c665-4666-bba9-4947cd6059b1@github.com>

On Mon, 24 Oct 2022 19:23:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:
> 
>> 185: ### Button Demo ###
>> 186: 
>> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020
> 
> trailing whitespace looks unnecessary (accessible description?)

although this is in demo...

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

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

From naoto at openjdk.org  Mon Oct 24 20:02:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:02:54 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

The problem here is that all those (unnecessary) trailing spaces are appended by the external translators, who are not aware those spaces should not be at the end. I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

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

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

From angorya at openjdk.org  Mon Oct 24 20:12:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 20:12:02 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
Message-ID: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>

On Mon, 24 Oct 2022 19:58:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

Good idea! I wonder if this should be done as a unit test.  go through all the bundles and check leading/trailing whitespace.

in my experience, the translators also (unintentionally) change the quotes and other symbols, sometimes breaking the code.  I assume the JDK has been exhaustively tested and we have no such problems.

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

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

From naoto at openjdk.org  Mon Oct 24 20:16:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:16:56 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
 <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
Message-ID: <go6bwGp8ro_LeVwOJyBes4PXwMBEGNyPvq43vxGmmLU=.ed6bfa15-4664-41ab-87a9-51609382b9cf@github.com>

On Mon, 24 Oct 2022 20:08:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Good idea! I wonder if this should be done as a unit test. go through all the bundles and check leading/trailing whitespace.

Right. Definitely not a job for `jcheck`, but it should be considered somewhere in the l10n process.

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

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

From ihse at openjdk.org  Mon Oct 24 20:39:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:39:57 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
Message-ID: <HMdFi0RZ9_Jhobfq_DLpJY4wycMf6qXcIHo90U8sq80=.4a035bff-b633-400b-bbf4-c3e7111385f3@github.com>

On Mon, 24 Oct 2022 19:39:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

I respectfully disagree. I think changing a trailing " " into a "\u0020" is the opposite of hiding it; it is making it plainly visible. In fact, I believe most of these trailing spaces are the result of them not being visible enough (and the tooling not warning).

Secondly, there are a lot of definitely unintentional trailing spaces, in comments and blank lines. I'd say there is factor 10:1 more of these. Getting these out of the way allows developers to focus more clearly on the trailing whitespace that matters: those in the key-value pairs.

And as I said, I intend to file follow-up issues for all files where there is a trailing unicode-sequence whitespace, so it will definitely not be lost on the respective component teams that they have something they need to address.

> Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

That's probably a good idea, but I think we should leave that to each respective team. Just like Andy's and Naoto's suggestion of improving i18n tooling to detect issues like this earlier on. Good idea, but I'd like to see that implemented separated from this PR. This PR is already large. The only reason it makes sense is because all changes (except the one to jcheck) are automatically generated and trivial to verify correctness of. If we were to start adding individual, manual changes into this PR, it would be just a huge mess.

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

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

From cjplummer at openjdk.org  Tue Oct 25 03:16:49 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Oct 2022 03:16:49 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <qb_ryMLGem495x0rBbOxd4vVGYPmnRiOkynx6AmvZVE=.5c5d3ee8-8498-4d6d-bfec-04a075ab085c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Changes requested by cjplummer (Reviewer).

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties line 27:

> 25: 
> 26: agent.err.error			   = Error
> 27: agent.err.exception                = Exception thrown by the agent\u0020

I believe this space was just a typo and should be removed. Same for `agent.err.agentclass.failed` below and in all the other management property files.

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

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

From weijun at openjdk.org  Tue Oct 25 13:30:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:30:53 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <c28cQxkcVp8YCkAe0wDP4b7cUvb424JsH9ls5bR3m48=.31cad672-bef6-4d55-983d-2cb32a0cafea@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

test/jdk/javax/net/ssl/Stapling/TEST.properties line 5:

> 3:     java.base/sun.security.util \
> 4:     java.base/sun.security.validator \
> 5:     java.base/sun.security.x509\u0020

I'm quite sure this space can be safely removed.

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

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

From weijun at openjdk.org  Tue Oct 25 13:47:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:47:02 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I noticed another problem. In some English properties files (Ex: `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`), `\u0020` is already used today but it turns into a whitespace in the translated files. It looks like the translation tool (most likely written in Java) decoded it while reading the English file but was not able to encode it back in a translation. I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

I suggest we focus on the English files this time and file a bug to the translation tool.

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

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

From naoto at openjdk.org  Tue Oct 25 17:31:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Oct 2022 17:31:52 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
Message-ID: <CWhtHdVfwiBt9m16ZvVgfFbu-h9bRwVLYmwORiLTSVA=.210b4cf3-7f67-4f32-9983-b9fe54bd1571@github.com>

On Tue, 25 Oct 2022 13:43:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

Good catch, Max. Yes, that should be dealt with in the translation process.

> I suggest we focus on the English files this time and file a bug to the translation tool.

Agree.

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

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

From sspitsyn at openjdk.org  Tue Oct 25 18:02:48 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 25 Oct 2022 18:02:48 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
Message-ID: <CdkyKVHq-1hQW5BnfKTpx-__9nuV8neg2esgkhNPNEU=.487a4230-14ba-4667-a65b-9c950c56d8e5@github.com>

On Wed, 19 Oct 2022 17:54:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
>> 
>> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
>> 
>> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional test with command-line filter setting.

Does this need a Release Note?

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

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

From sspitsyn at openjdk.org  Tue Oct 25 18:21:19 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 25 Oct 2022 18:21:19 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
Message-ID: <3OzsfVdzy525COuGMtgxKHBVcH8ERKmQLAdSODApmGE=.ea8c5a17-5ec9-4ce6-8f37-d99d9b42e956@github.com>

On Wed, 19 Oct 2022 17:54:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
>> 
>> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
>> 
>> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional test with command-line filter setting.

This looks good to me in general.
But I've posted a couple of questions.
If an RN is needed then it is better to review it before integration.
Thanks,
Serguei

test/jdk/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java line 309:

> 307:         try {
> 308:             // Add custom filter on command-line.
> 309:             testDefaultAgent(null, "-Dcom.sun.management.jmxremote.serial.filter.pattern=\"java.lang.*;java.math.BigInteger;java.math.BigDecimal;java.util.*;javax.management.openmbean.*;javax.management.ObjectName;java.rmi.MarshalledObject;javax.security.auth.Subject;DefaultAgentFilterTest$MyTestObject;!*\"");

Long line. Can we use string concatenation to break it?

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

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

From kevinw at openjdk.org  Tue Oct 25 18:26:52 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Oct 2022 18:26:52 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
Message-ID: <1ID7N1OeAvo92VrGg-FJkPQadwUGjgLKQk9FZs8MnIA=.4da2e540-0674-4fc9-abcf-19ff06eb53fa@github.com>

On Wed, 19 Oct 2022 17:54:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
>> 
>> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
>> 
>> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional test with command-line filter setting.

> 

Yes definitely!  Most people should see no effect, but the release note would detail the property setting that has been set by default now, and how to set it/clear it in case you have specific needs that clash with the filter.

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

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

From sspitsyn at openjdk.org  Tue Oct 25 18:33:54 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 25 Oct 2022 18:33:54 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
Message-ID: <yhStCbUvYZTTzort8F8Q0GucwCkfOyt509QGsehUqic=.d8041501-2d3c-44f4-8783-87f8db791b6c@github.com>

On Wed, 19 Oct 2022 17:54:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
>> 
>> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
>> 
>> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional test with command-line filter setting.

Thank you for reply, Kevin.
Then it is better to create RN and review it before integration.
Also, I do not have expertise to assess the default `ObjectInputFilter` completeness and security implications.
How was this set of segments to be filtered by default identified?

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

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

From kevinw at openjdk.org  Tue Oct 25 20:13:47 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Oct 2022 20:13:47 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <yhStCbUvYZTTzort8F8Q0GucwCkfOyt509QGsehUqic=.d8041501-2d3c-44f4-8783-87f8db791b6c@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
 <yhStCbUvYZTTzort8F8Q0GucwCkfOyt509QGsehUqic=.d8041501-2d3c-44f4-8783-87f8db791b6c@github.com>
Message-ID: <kkNGhSvyF4ffVHK_Det2UcnMXILC9PdxxDujOW5AANM=.4eedda9a-e80d-4509-b6d7-fbdca159b810@github.com>

On Tue, 25 Oct 2022 18:31:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> How was this set of segments to be filtered by default identified?
I started with the set of classes given as an example in the Core Libraries guide, https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html in the "Filters for JMX" section.  
I queried the fields of every MBean in the JDK, plus running the tests in the JDK, and added the Subject class, as that caused a the only filter rejection I saw.

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

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

From sspitsyn at openjdk.org  Tue Oct 25 20:26:53 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 25 Oct 2022 20:26:53 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
Message-ID: <P7-2T0SHp1NUbNnVOx52EH7NehP83AqHqJiE_ezZO6k=.240e79fd-71f4-4024-9f39-f72107136c64@github.com>

On Wed, 19 Oct 2022 17:54:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
>> 
>> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
>> 
>> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional test with command-line filter setting.

Okay, thanks.

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

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

From kevinw at openjdk.org  Wed Oct 26 10:18:28 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Oct 2022 10:18:28 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v4]
In-Reply-To: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
Message-ID: <iQfMEXkRRiUtInXQWhE95AKlgfV0OpIw9VubYnXIK-M=.7a89b376-cc59-4d03-a8e8-1a3badd76e28@github.com>

> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
> 
> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
> 
> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.

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

  Split long line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10507/files
  - new: https://git.openjdk.org/jdk/pull/10507/files/e6940778..1dc7eef0

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

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

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

From kevinw at openjdk.org  Wed Oct 26 10:18:30 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Oct 2022 10:18:30 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v3]
In-Reply-To: <3OzsfVdzy525COuGMtgxKHBVcH8ERKmQLAdSODApmGE=.ea8c5a17-5ec9-4ce6-8f37-d99d9b42e956@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <BIdPcNXBOTkJCmiFxH6pfSJmDizqLRK2Pp9NgIQQe-g=.82dfac95-f218-4325-b67b-6e3bea8ed4a8@github.com>
 <3OzsfVdzy525COuGMtgxKHBVcH8ERKmQLAdSODApmGE=.ea8c5a17-5ec9-4ce6-8f37-d99d9b42e956@github.com>
Message-ID: <ytlzqQGXeLP671Cl6wsW-iR6grDPpsAGdF_7r7nX9n8=.9263583a-093c-47ad-82a2-6711b9d16587@github.com>

On Tue, 25 Oct 2022 18:16:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Additional test with command-line filter setting.
>
> test/jdk/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java line 309:
> 
>> 307:         try {
>> 308:             // Add custom filter on command-line.
>> 309:             testDefaultAgent(null, "-Dcom.sun.management.jmxremote.serial.filter.pattern=\"java.lang.*;java.math.BigInteger;java.math.BigDecimal;java.util.*;javax.management.openmbean.*;javax.management.ObjectName;java.rmi.MarshalledObject;javax.security.auth.Subject;DefaultAgentFilterTest$MyTestObject;!*\"");
> 
> Long line. Can we use string concatenation to break it?

Yes, done!

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

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

From sspitsyn at openjdk.org  Wed Oct 26 11:35:23 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Oct 2022 11:35:23 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v4]
In-Reply-To: <iQfMEXkRRiUtInXQWhE95AKlgfV0OpIw9VubYnXIK-M=.7a89b376-cc59-4d03-a8e8-1a3badd76e28@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <iQfMEXkRRiUtInXQWhE95AKlgfV0OpIw9VubYnXIK-M=.7a89b376-cc59-4d03-a8e8-1a3badd76e28@github.com>
Message-ID: <fPj9kp_Ob4RJ9E3j14-67Fj7lzgG8sCcS9wChCN0zBM=.3137391b-a704-4be3-8061-69e4a28f6d45@github.com>

On Wed, 26 Oct 2022 10:18:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
>> 
>> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
>> 
>> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Split long line

Thank you for the update and creating a RN sub-task.
Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From kevinw at openjdk.org  Thu Oct 27 08:18:24 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Oct 2022 08:18:24 GMT
Subject: jmx-dev RFR: 8283093: JMX connections should default to using
 an ObjectInputFilter [v4]
In-Reply-To: <iQfMEXkRRiUtInXQWhE95AKlgfV0OpIw9VubYnXIK-M=.7a89b376-cc59-4d03-a8e8-1a3badd76e28@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
 <iQfMEXkRRiUtInXQWhE95AKlgfV0OpIw9VubYnXIK-M=.7a89b376-cc59-4d03-a8e8-1a3badd76e28@github.com>
Message-ID: <v_Se0r60CFx9wjkQliT7tcNMExkmV45F_GzQI6Tre0E=.58aa0f70-084e-417b-9450-0a3ba1f2d18e@github.com>

On Wed, 26 Oct 2022 10:18:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
>> 
>> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
>> 
>> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Split long line

Thanks for the reviews, and the release note hints!

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

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

From kevinw at openjdk.org  Thu Oct 27 08:26:31 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Oct 2022 08:26:31 GMT
Subject: jmx-dev Integrated: 8283093: JMX connections should default to
 using an ObjectInputFilter
In-Reply-To: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com>
Message-ID: <XCvnwe8syDxgsWusgcODwAdKR5THAbZXZg_AbnYw8hY=.251d5755-da8d-48e7-af77-b3dd47b0c979@github.com>

On Fri, 30 Sep 2022 11:00:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Set the management.properties  "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized.
> 
> Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication.
> 
> The sun/management tests run OK with this change.  The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive.

This pull request has now been integrated.

Changeset: 628820f4
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/628820f47ef9c9ad3cc62e68db9c4dbc7e659154
Stats:     48 lines in 2 files changed: 36 ins; 1 del; 11 mod

8283093: JMX connections should default to using an ObjectInputFilter

Reviewed-by: dfuchs, sspitsyn

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

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

From bhuang at openjdk.org  Thu Oct 27 18:39:39 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 27 Oct 2022 18:39:39 GMT
Subject: jmx-dev RFR: JDK-8295756 Improve NonLocalRegistry Manual Test
 Process [v2]
In-Reply-To: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
References: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
Message-ID: <HU0lqGw2Ksf32DEpq68x3HpXtMtDhe9Y5IOq03Dr_e0=.fa5df9b8-13cc-46fd-b242-7ca2b1762a29@github.com>

> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. 
> 
> Tests include: 
> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java 
> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java 
> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java

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

  Updated test instruction messages.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10825/files
  - new: https://git.openjdk.org/jdk/pull/10825/files/a190fc71..a61d56e4

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

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

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

From alanb at openjdk.org  Thu Oct 27 19:02:25 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Oct 2022 19:02:25 GMT
Subject: jmx-dev RFR: JDK-8295756 Improve NonLocalRegistry Manual Test
 Process [v2]
In-Reply-To: <HU0lqGw2Ksf32DEpq68x3HpXtMtDhe9Y5IOq03Dr_e0=.fa5df9b8-13cc-46fd-b242-7ca2b1762a29@github.com>
References: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
 <HU0lqGw2Ksf32DEpq68x3HpXtMtDhe9Y5IOq03Dr_e0=.fa5df9b8-13cc-46fd-b242-7ca2b1762a29@github.com>
Message-ID: <tjrKnSX2X6O_JpaOsQZP5uGRdn4_y-ZykCg-jzByBZ0=.126290d3-6c45-4890-8ab3-8644903b75f5@github.com>

On Thu, 27 Oct 2022 18:39:39 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. 
>> 
>> Tests include: 
>> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java 
>> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java 
>> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test instruction messages.

test/jdk/TEST.groups line 204:

> 202:     java/rmi \
> 203:     -java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java \
> 204:     -java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java \

RunTests.gmk runs jtreg with -automatic so I don't think you need to exclude the manual tests from these test groups.

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

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

From bhuang at openjdk.org  Thu Oct 27 19:08:06 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 27 Oct 2022 19:08:06 GMT
Subject: jmx-dev RFR: JDK-8295756 Improve NonLocalRegistry Manual Test
 Process [v3]
In-Reply-To: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
References: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
Message-ID: <qWE-amaTygY7zpnTiw-Posy9H4JLslqXLGkb86rqg3o=.d95dd7d5-0022-4a93-bc22-85fc7861bcb6@github.com>

> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. 
> 
> Tests include: 
> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java 
> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java 
> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java

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

  Reverted exclusion of nonlocal registry tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10825/files
  - new: https://git.openjdk.org/jdk/pull/10825/files/a61d56e4..5ee556aa

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

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

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

From cjplummer at openjdk.org  Fri Oct 28 00:55:44 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Oct 2022 00:55:44 GMT
Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>
Message-ID: <DIScQIcbKFsercPkoaABYXSmJznKrSSnJwhL-kJDSDU=.5be8456a-ce87-4b56-83f9-b397e2785402@github.com>

On Fri, 7 Oct 2022 12:51:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Reinstate typos in Apache code that is copied into the JDK
>>  - Merge ../jdk-openjdk into typos-typos
>>  - Remove file that was removed upstream
>>  - Fix inconsistency in capitalization
>>  - Undo change in zlip
>>  - Fix typos
>
> src/java.se/share/data/jdwp/jdwp.spec line 101:
> 
>> 99:         "<a href=../../api/java.base/java/lang/Thread.html#platform-threads>platform thread</a> "
>> 100:         "in the target VM. This includes platform threads created with the Thread "
>> 101:         "API and all native threads attached to the target VM with JNI code."
> 
> The spec for the JDWP AllThreads command was significantly reworded in Java 19 so this is where this typo crept in. We have JDK-8294672 tracking it to fix for Java 20, maybe you should take it?

Since this PR has gone stale, I'll be fixing this typo in jdwp.spec via [JDK-8294672](https://bugs.openjdk.org/browse/JDK-8294672).

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

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

From aivanov at openjdk.org  Sat Oct 29 12:14:25 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 12:14:25 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <rzIw7fkMmSiQ4HJygtWh3SxVIIZg4QY0nvByxOYUyGs=.b878366e-a60f-410f-94ae-47b486f4e7b5@github.com>

On Mon, 24 Oct 2022 19:29:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:
> 
>> 132: 
>> 133: #SyncResolverImpl exceptions
>> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020
> 
> prob. unnecessary

This case is similar the one you mentioned below. If this value is used in a string template or concatenation, the trailing white-space could be necessary; however, one space is probably enough.

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

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

From aivanov at openjdk.org  Sat Oct 29 13:22:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 13:22:09 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <4Npxj4pEaiqkJ2UBTsYb3xTHYseNBoj_3yshwocOIxw=.c701af52-62db-40c2-b3a3-90e47c44ed76@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Trailing spaces in `LocaleNames_*` are only in two files:

- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties`
- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties`

It is very unlikely these spaces are part of a country or language name. The former file contains a few trailing spaces, the latter ? only one.

src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties line 238:

> 236: cpp=Kreolisch-Portugiesische Sprache
> 237: crh=Krimtatarisch
> 238: crp=Kreolische Sprache\u0020

I'm pretty sure locale names shouldn't contain trailing spaces.

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

Marked as reviewed by aivanov (Reviewer).

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