From alanb at openjdk.org  Thu Feb  1 06:56:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Feb 2024 06:56:02 GMT
Subject: jmx-dev RFR: 8324845: management.properties text "interface
 name" is misleading [v2]
In-Reply-To: <tQVu8b_7H1uge7tw1CsxMVCTVY8pY2-b3nkmtOWp8R0=.6b2cc8ed-5c93-4561-adf9-ee18ccc5e2e4@github.com>
References: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
 <tQVu8b_7H1uge7tw1CsxMVCTVY8pY2-b3nkmtOWp8R0=.6b2cc8ed-5c93-4561-adf9-ee18ccc5e2e4@github.com>
Message-ID: <HOS596p92xSauTWJT2RDtcqWKL8z6me9lE9WgvsUJk0=.a025014a-e38f-4c32-be80-6cb125894c70@github.com>

On Wed, 31 Jan 2024 21:29:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.  It should just say it needs to be a host name or address.
>> 
>> This change only affects comment text in a properties file.
>> 
>> (We don't currently mention this property in other docs, e.g. in the M&M guide.)
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   text update

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17615#pullrequestreview-1855667712

From kevinw at openjdk.org  Thu Feb  1 09:21:07 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 1 Feb 2024 09:21:07 GMT
Subject: jmx-dev RFR: 8324845: management.properties text "interface
 name" is misleading [v2]
In-Reply-To: <tQVu8b_7H1uge7tw1CsxMVCTVY8pY2-b3nkmtOWp8R0=.6b2cc8ed-5c93-4561-adf9-ee18ccc5e2e4@github.com>
References: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
 <tQVu8b_7H1uge7tw1CsxMVCTVY8pY2-b3nkmtOWp8R0=.6b2cc8ed-5c93-4561-adf9-ee18ccc5e2e4@github.com>
Message-ID: <Ou_P8Qpe9iInOvbTRfL25rhlgB--DK37P2NzuLY8yOM=.fc14d9d3-427b-4ca7-a630-32b818371ca6@github.com>

On Wed, 31 Jan 2024 21:29:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.  It should just say it needs to be a host name or address.
>> 
>> This change only affects comment text in a properties file.
>> 
>> (We don't currently mention this property in other docs, e.g. in the M&M guide.)
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   text update

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17615#issuecomment-1920859573

From kevinw at openjdk.org  Thu Feb  1 09:21:08 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 1 Feb 2024 09:21:08 GMT
Subject: jmx-dev Integrated: 8324845: management.properties text "interface
 name" is misleading
In-Reply-To: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
References: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
Message-ID: <NS6Iw3H4_ebSRL4pT2fsuk7sRxKamkdZYOFdk2CiFHM=.d998c108-4ece-4c9d-87cd-3ce61d7fbac7@github.com>

On Mon, 29 Jan 2024 14:45:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.  It should just say it needs to be a host name or address.
> 
> This change only affects comment text in a properties file.
> 
> (We don't currently mention this property in other docs, e.g. in the M&M guide.)

This pull request has now been integrated.

Changeset: d9331bfd
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9331bfd49461c08e165e8f202cbbf88cc0ecec1
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8324845: management.properties text "interface name" is misleading

Reviewed-by: mchung, alanb

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

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

From dnsimon at openjdk.org  Thu Feb  1 18:29:10 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 1 Feb 2024 18:29:10 GMT
Subject: jmx-dev RFR: 8325137:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp
 with out of expected range
Message-ID: <lFs7EoCOc2RPNPWBbApCGwGWAQU52AHhmaJo4kYmUbo=.6c7f7207-284f-4462-94aa-42b8da2fcf55@github.com>

The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads.

The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded.

It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present.

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

Commit messages:
 - disable ThreadCpuTimeArray with xcomp

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

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

From dholmes at openjdk.org  Fri Feb  2 03:04:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 2 Feb 2024 03:04:02 GMT
Subject: jmx-dev RFR: 8325137:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp
 with out of expected range
In-Reply-To: <lFs7EoCOc2RPNPWBbApCGwGWAQU52AHhmaJo4kYmUbo=.6c7f7207-284f-4462-94aa-42b8da2fcf55@github.com>
References: <lFs7EoCOc2RPNPWBbApCGwGWAQU52AHhmaJo4kYmUbo=.6c7f7207-284f-4462-94aa-42b8da2fcf55@github.com>
Message-ID: <NANuPg6m6lP6V68olvcIA4RW0BycKXanS5NIQoR6jI8=.066201dc-8be8-4fb4-87fb-d0b92f5bdac2@github.com>

On Thu, 1 Feb 2024 18:25:33 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads.
> 
> The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded.
> 
> It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present.

Excluding Xcomp mode seems the most practical/expedient solution.

Please update the 2023 copyright year to 2024.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17675#pullrequestreview-1858173944

From dnsimon at openjdk.org  Fri Feb  2 07:38:24 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 2 Feb 2024 07:38:24 GMT
Subject: jmx-dev RFR: 8325137:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp
 with out of expected range [v2]
In-Reply-To: <lFs7EoCOc2RPNPWBbApCGwGWAQU52AHhmaJo4kYmUbo=.6c7f7207-284f-4462-94aa-42b8da2fcf55@github.com>
References: <lFs7EoCOc2RPNPWBbApCGwGWAQU52AHhmaJo4kYmUbo=.6c7f7207-284f-4462-94aa-42b8da2fcf55@github.com>
Message-ID: <SMl8A-X-tqcZgY48ked5NgEthE5Ok9jKWF1RcdT-Rf8=.f68bb751-56eb-4790-8992-268e523b800c@github.com>

> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads.
> 
> The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded.
> 
> It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present.

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

  fix date in header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17675/files
  - new: https://git.openjdk.org/jdk/pull/17675/files/4ff2f7cd..a3bc2653

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

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

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

From sspitsyn at openjdk.org  Fri Feb  2 10:30:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 2 Feb 2024 10:30:01 GMT
Subject: jmx-dev RFR: 8325137:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp
 with out of expected range [v2]
In-Reply-To: <SMl8A-X-tqcZgY48ked5NgEthE5Ok9jKWF1RcdT-Rf8=.f68bb751-56eb-4790-8992-268e523b800c@github.com>
References: <lFs7EoCOc2RPNPWBbApCGwGWAQU52AHhmaJo4kYmUbo=.6c7f7207-284f-4462-94aa-42b8da2fcf55@github.com>
 <SMl8A-X-tqcZgY48ked5NgEthE5Ok9jKWF1RcdT-Rf8=.f68bb751-56eb-4790-8992-268e523b800c@github.com>
Message-ID: <DBwMYT4twO_JYP_YBFnvz6lQTGJK4pXBEEijFAIbU5M=.c6892baf-c360-49f7-82a3-25da5fa0d46c@github.com>

On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads.
>> 
>> The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded.
>> 
>> It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix date in header

Looks good. Thank you for fixing!

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17675#pullrequestreview-1858895296

From dnsimon at openjdk.org  Fri Feb  2 10:47:05 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 2 Feb 2024 10:47:05 GMT
Subject: jmx-dev RFR: 8325137:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp
 with out of expected range [v2]
In-Reply-To: <SMl8A-X-tqcZgY48ked5NgEthE5Ok9jKWF1RcdT-Rf8=.f68bb751-56eb-4790-8992-268e523b800c@github.com>
References: <lFs7EoCOc2RPNPWBbApCGwGWAQU52AHhmaJo4kYmUbo=.6c7f7207-284f-4462-94aa-42b8da2fcf55@github.com>
 <SMl8A-X-tqcZgY48ked5NgEthE5Ok9jKWF1RcdT-Rf8=.f68bb751-56eb-4790-8992-268e523b800c@github.com>
Message-ID: <XRLLcxSZmp3q64iHbAPCp3FjDu1HV_ImktJkIkMart0=.ed35f704-f43e-4185-8d3b-0a04e126c622@github.com>

On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads.
>> 
>> The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded.
>> 
>> It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix date in header

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/17675#issuecomment-1923543404

From dnsimon at openjdk.org  Fri Feb  2 10:47:05 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 2 Feb 2024 10:47:05 GMT
Subject: jmx-dev Integrated: 8325137:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp
 with out of expected range
In-Reply-To: <lFs7EoCOc2RPNPWBbApCGwGWAQU52AHhmaJo4kYmUbo=.6c7f7207-284f-4462-94aa-42b8da2fcf55@github.com>
References: <lFs7EoCOc2RPNPWBbApCGwGWAQU52AHhmaJo4kYmUbo=.6c7f7207-284f-4462-94aa-42b8da2fcf55@github.com>
Message-ID: <jSsGGMn7TYBNr-_9EMr92bBgKCt_8oe7vb67xQoKrAk=.f71bd77e-e289-4826-a90b-1c5cd8c12dc3@github.com>

On Thu, 1 Feb 2024 18:25:33 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads.
> 
> The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded.
> 
> It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present.

This pull request has now been integrated.

Changeset: 91d8dac9
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91d8dac9cff5689abcf2fc8950b15d284f933afd
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range

Reviewed-by: dholmes, sspitsyn

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

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

From kevinw at openjdk.org  Fri Feb  2 10:51:07 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 2 Feb 2024 10:51:07 GMT
Subject: jmx-dev RFR: 8325137:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp
 with out of expected range [v2]
In-Reply-To: <SMl8A-X-tqcZgY48ked5NgEthE5Ok9jKWF1RcdT-Rf8=.f68bb751-56eb-4790-8992-268e523b800c@github.com>
References: <lFs7EoCOc2RPNPWBbApCGwGWAQU52AHhmaJo4kYmUbo=.6c7f7207-284f-4462-94aa-42b8da2fcf55@github.com>
 <SMl8A-X-tqcZgY48ked5NgEthE5Ok9jKWF1RcdT-Rf8=.f68bb751-56eb-4790-8992-268e523b800c@github.com>
Message-ID: <ZRNh3mqx_MbSvh3kNPhe_v1pXGQQZN0mn6bjYAyVAng=.b093245d-9424-40bd-a7d7-286e89a0a0e7@github.com>

On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads.
>> 
>> The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded.
>> 
>> It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix date in header

It doesn't seem that critical to test this with -Xcomp
But just checking: the threads are meant to be waiting, after we call waitUntilThreadBlocked(), so do they wake up and do some deopt or compilation work for some reason?  Or maybe they are not done the initial -Xcomp compile and waitUntilThreadBlocked() is mistakenly thinking they are now idle...

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

PR Comment: https://git.openjdk.org/jdk/pull/17675#issuecomment-1923550642

From dnsimon at openjdk.org  Fri Feb  2 11:08:07 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 2 Feb 2024 11:08:07 GMT
Subject: jmx-dev RFR: 8325137:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp
 with out of expected range [v2]
In-Reply-To: <ZRNh3mqx_MbSvh3kNPhe_v1pXGQQZN0mn6bjYAyVAng=.b093245d-9424-40bd-a7d7-286e89a0a0e7@github.com>
References: <lFs7EoCOc2RPNPWBbApCGwGWAQU52AHhmaJo4kYmUbo=.6c7f7207-284f-4462-94aa-42b8da2fcf55@github.com>
 <SMl8A-X-tqcZgY48ked5NgEthE5Ok9jKWF1RcdT-Rf8=.f68bb751-56eb-4790-8992-268e523b800c@github.com>
 <ZRNh3mqx_MbSvh3kNPhe_v1pXGQQZN0mn6bjYAyVAng=.b093245d-9424-40bd-a7d7-286e89a0a0e7@github.com>
Message-ID: <PXaX5OorKMAEhNixtXPcG9xkedO2GhQnEVol_ddGbJ4=.b5d80584-ff8c-49bd-987e-db7e22369333@github.com>

On Fri, 2 Feb 2024 10:48:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Or maybe they are not done the initial -Xcomp compile and waitUntilThreadBlocked() is mistakenly thinking they are now idle...

Yes, I believe this is the case.

It's not really clear to me what the test is testing. As far as I can see, if the 2 timings are meant to be taken when the worker threads are idle, I would have thought the expected delta should be 0.

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

PR Comment: https://git.openjdk.org/jdk/pull/17675#issuecomment-1923578655

From kevinw at openjdk.org  Fri Feb  2 11:31:06 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 2 Feb 2024 11:31:06 GMT
Subject: jmx-dev RFR: 8325137:
 com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp
 with out of expected range [v2]
In-Reply-To: <SMl8A-X-tqcZgY48ked5NgEthE5Ok9jKWF1RcdT-Rf8=.f68bb751-56eb-4790-8992-268e523b800c@github.com>
References: <lFs7EoCOc2RPNPWBbApCGwGWAQU52AHhmaJo4kYmUbo=.6c7f7207-284f-4462-94aa-42b8da2fcf55@github.com>
 <SMl8A-X-tqcZgY48ked5NgEthE5Ok9jKWF1RcdT-Rf8=.f68bb751-56eb-4790-8992-268e523b800c@github.com>
Message-ID: <9Z7N57uRRLZArmFKsHzJ6sg-Jab9d4hyKVLAJCT7d04=.5b1df68d-d2a8-4982-a20a-ca48198ef150@github.com>

On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads.
>> 
>> The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded.
>> 
>> It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix date in header

Yes, if you're idle, you should not have used any cpu time, that's what I think it's testing, and the 100 ms slack (DELTA) to account for slack in the accounting.
If compilation makes a thread state Thread.State.WAITING then it would fool the check in waitUntilThreadBlocked().  Next time it causes trouble that check could be revisited... 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/17675#issuecomment-1923615761

From ihse at openjdk.org  Mon Feb  5 16:27:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 16:27:05 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code
In-Reply-To: <oaxm_OORIw0EW3-tPcLgM4CfWB_vhcDEK9g8wKvAoUw=.933bd885-a0e3-4449-9690-f7afa9ede8f4@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
 <oaxm_OORIw0EW3-tPcLgM4CfWB_vhcDEK9g8wKvAoUw=.933bd885-a0e3-4449-9690-f7afa9ede8f4@github.com>
Message-ID: <ud2HGr7QFDTqj8UuqvdLpQg3qsuwAicwEelernW0DXk=.bf5a378c-2079-42f7-aec4-d165101bdbed@github.com>

On Tue, 28 Mar 2023 17:36:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> What was the reason for not moving forward with this PR?

Me going on medical leave most of 2023... :-/

I intend to get this done now.

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

PR Comment: https://git.openjdk.org/jdk/pull/11490#issuecomment-1927376112

From ihse at openjdk.org  Mon Feb  5 16:45:38 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 16:45:38 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code [v2]
In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
Message-ID: <BSfRSeTXkJL4y7yec4WkK2FGCt5C9wchcRuBg_KyBFk=.ebeb8a48-e79d-4840-ae96-11aff571aa77@github.com>

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Delete trailing \u0020 as per plummercj's suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11490/files
  - new: https://git.openjdk.org/jdk/pull/11490/files/1b418216..60fda42b

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

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

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

From ihse at openjdk.org  Mon Feb  5 16:57:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 16:57:01 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code [v3]
In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
Message-ID: <xXOJjxCCi4-f_mF0sR5DhdPQ5NL5S0fuxQifhH9CXDw=.44c2869c-1a73-4b8f-a84f-1235d349894f@github.com>

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.

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

 - Merge branch 'master' into properties-eol-serviceability
 - Delete trailing \u0020 as per plummercj's suggestions
 - 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code

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

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

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

From ihse at openjdk.org  Mon Feb  5 16:57:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 16:57:01 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code [v3]
In-Reply-To: <xXOJjxCCi4-f_mF0sR5DhdPQ5NL5S0fuxQifhH9CXDw=.44c2869c-1a73-4b8f-a84f-1235d349894f@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
 <xXOJjxCCi4-f_mF0sR5DhdPQ5NL5S0fuxQifhH9CXDw=.44c2869c-1a73-4b8f-a84f-1235d349894f@github.com>
Message-ID: <f8htstpPBSRSkfji-Dfsizdx939lSNmUq7UFiAvcez8=.a8a4efe6-bfd4-478f-b1ed-955975b04ab1@github.com>

On Mon, 5 Feb 2024 16:53:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
>> 
>> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
>> 
>> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
>> 
>> Doing so has a dual benefit:
>> 
>> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
>> 
>> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
>> 
>> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into properties-eol-serviceability
>  - Delete trailing \u0020 as per plummercj's suggestions
>  - 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code

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

> 25: 
> 26: agent.err.error			   = ??
> 27: agent.err.exception                = ????? ????? ??????. 

I decided to remove the period here...

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

> 36: 
> 37: agent.err.agentclass.notfound      = ?? ???? ???? ?? ? ????.
> 38: agent.err.agentclass.failed        = ?? ???? ???? ??????. 

... but keep it here, as it aligned with the surrounding error messages.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11490#discussion_r1478576012
PR Review Comment: https://git.openjdk.org/jdk/pull/11490#discussion_r1478576479

From ihse at openjdk.org  Mon Feb  5 16:58:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 16:58:56 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code
In-Reply-To: <oaxm_OORIw0EW3-tPcLgM4CfWB_vhcDEK9g8wKvAoUw=.933bd885-a0e3-4449-9690-f7afa9ede8f4@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
 <oaxm_OORIw0EW3-tPcLgM4CfWB_vhcDEK9g8wKvAoUw=.933bd885-a0e3-4449-9690-f7afa9ede8f4@github.com>
Message-ID: <vG4uyzqIc8VOAKAAEfa3mgK2B1HsOhOI07n7yWjZ3uM=.32935210-908e-4f3e-a849-cb9a00d25702@github.com>

On Tue, 28 Mar 2023 17:36:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
>> 
>> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
>> 
>> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
>> 
>> Doing so has a dual benefit:
>> 
>> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
>> 
>> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
>> 
>> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.
>
> What was the reason for not moving forward with this PR?

Several of the original problems has been resolved since this PR was opened, but some remain. I believe this is now ready for integration, but I'd like to get a re-review from @plummercj.

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

PR Comment: https://git.openjdk.org/jdk/pull/11490#issuecomment-1927469254

From ihse at openjdk.org  Tue Feb  6 00:03:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 00:03:31 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code [v4]
In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
Message-ID: <9ezdxqyo0C-oR0r8bleXRJKI55qduwl9z3Lj2si_lpw=.46ae3241-62b3-489e-9342-ab10810e20d0@github.com>

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Restore period

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11490/files
  - new: https://git.openjdk.org/jdk/pull/11490/files/0c91a370..5acd13a4

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

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

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

From cjplummer at openjdk.org  Tue Feb  6 00:03:45 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Feb 2024 00:03:45 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code [v4]
In-Reply-To: <f8htstpPBSRSkfji-Dfsizdx939lSNmUq7UFiAvcez8=.a8a4efe6-bfd4-478f-b1ed-955975b04ab1@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
 <xXOJjxCCi4-f_mF0sR5DhdPQ5NL5S0fuxQifhH9CXDw=.44c2869c-1a73-4b8f-a84f-1235d349894f@github.com>
 <f8htstpPBSRSkfji-Dfsizdx939lSNmUq7UFiAvcez8=.a8a4efe6-bfd4-478f-b1ed-955975b04ab1@github.com>
Message-ID: <OCg9HBgHgQpN-DntCrLaNgG56KHPuVvcDWHXan3zC5k=.80146f91-c035-4db2-afe8-0dff7abd7835@github.com>

On Mon, 5 Feb 2024 16:53:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore period
>
> src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 27:
> 
>> 25: 
>> 26: agent.err.error			   = ??
>> 27: agent.err.exception                = ????? ????? ??????. 
> 
> I decided to remove the period here...

I think it should probably stay, but this is really guess work. Would be nice to have a locale expert weigh in on this one. The reason I think it should stay is because it is a period at the end of a sentence vs a single word. Looking at some of the English entries sheds some light one this fact:


agent.err.error			   = Error
agent.err.exception                = Exception thrown by the agent 
agent.err.warning		   = Warning

agent.err.configfile.notfound      = Config file not found
agent.err.configfile.failed        = Failed in reading the config file
agent.err.configfile.closed.failed = Failed in closing the config file
agent.err.configfile.access.denied = Access to the config file is denied


Within this group, the error and warning entries are the only ones without a period (in the Korean version) and the only ones that are a single word instead of a sentence. However, I'm not sure why any of them have the period in the first place since the English version does not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11490#discussion_r1478829597

From cjplummer at openjdk.org  Tue Feb  6 00:03:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Feb 2024 00:03:36 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code [v4]
In-Reply-To: <9ezdxqyo0C-oR0r8bleXRJKI55qduwl9z3Lj2si_lpw=.46ae3241-62b3-489e-9342-ab10810e20d0@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
 <9ezdxqyo0C-oR0r8bleXRJKI55qduwl9z3Lj2si_lpw=.46ae3241-62b3-489e-9342-ab10810e20d0@github.com>
Message-ID: <Ddqj7ReNlbdMTfWBC5bnzs3eylah8f3lh93PRRbpwQE=.f99b8e9d-5129-4af2-9e64-acc1713d4c53@github.com>

On Mon, 5 Feb 2024 21:51:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
>> 
>> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
>> 
>> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
>> 
>> Doing so has a dual benefit:
>> 
>> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
>> 
>> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
>> 
>> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore period

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/11490#pullrequestreview-1863870608

From ihse at openjdk.org  Tue Feb  6 00:03:47 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 00:03:47 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code [v4]
In-Reply-To: <OCg9HBgHgQpN-DntCrLaNgG56KHPuVvcDWHXan3zC5k=.80146f91-c035-4db2-afe8-0dff7abd7835@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
 <xXOJjxCCi4-f_mF0sR5DhdPQ5NL5S0fuxQifhH9CXDw=.44c2869c-1a73-4b8f-a84f-1235d349894f@github.com>
 <f8htstpPBSRSkfji-Dfsizdx939lSNmUq7UFiAvcez8=.a8a4efe6-bfd4-478f-b1ed-955975b04ab1@github.com>
 <OCg9HBgHgQpN-DntCrLaNgG56KHPuVvcDWHXan3zC5k=.80146f91-c035-4db2-afe8-0dff7abd7835@github.com>
Message-ID: <E5I8xj8n5StEChlYdlvKs3fgb18zLezYF80-b89Fw1Q=.769dba7d-7eb8-47a0-92a8-2108142992cc@github.com>

On Mon, 5 Feb 2024 19:48:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 27:
>> 
>>> 25: 
>>> 26: agent.err.error			   = ??
>>> 27: agent.err.exception                = ????? ????? ??????. 
>> 
>> I decided to remove the period here...
>
> I think it should probably stay, but this is really guess work. Would be nice to have a locale expert weigh in on this one. The reason I think it should stay is because it is a period at the end of a sentence vs a single word. Looking at some of the English entries sheds some light one this fact:
> 
> 
> agent.err.error			   = Error
> agent.err.exception                = Exception thrown by the agent 
> agent.err.warning		   = Warning
> 
> agent.err.configfile.notfound      = Config file not found
> agent.err.configfile.failed        = Failed in reading the config file
> agent.err.configfile.closed.failed = Failed in closing the config file
> agent.err.configfile.access.denied = Access to the config file is denied
> 
> 
> Within this group, the error and warning entries are the only ones without a period (in the Korean version) and the only ones that are a single word instead of a sentence. However, I'm not sure why any of them have the period in the first place since the English version does not.

Ok, restored it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11490#discussion_r1478934863

From ihse at openjdk.org  Tue Feb  6 08:11:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 08:11:01 GMT
Subject: jmx-dev Integrated: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code
In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
Message-ID: <VV-eYIG7bq-IRBw2sU36s4kzWcRyfg3xjmcfbpd5UUI=.84231ff5-5e7a-45f3-ad2f-c174646246ef@github.com>

On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.

This pull request has now been integrated.

Changeset: b02599d2
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b02599d22e0f424a08045b32b94549c272fe35a7
Stats:     19 lines in 11 files changed: 0 ins; 0 del; 19 mod

8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code

Reviewed-by: cjplummer, kevinw

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

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

From lmesnik at openjdk.org  Thu Feb  8 05:43:05 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 Feb 2024 05:43:05 GMT
Subject: jmx-dev RFR: 8316460: 4 javax/management tests ignore VM flags
Message-ID: <uFB7WlA3qq3wDy1q5IAqbN3S0hZeYf_r_VNYqmq10xo=.dd65a6c5-b1af-40c9-865f-86c09e5a6368@github.com>

The tests 
javax/management/ImplementationVersion/ImplVersionTest.java
javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java
javax/management/remote/mandatory/version/ImplVersionTest.java
javax/management/security/HashedPasswordFileTest.java
were updated to use
ProcessTools.createTestJavaProcessBuilder(...)

Tested by running tests with different jvm flags and tier1.

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

Commit messages:
 - 8316460: 4 javax/management tests ignore VM flags

Changes: https://git.openjdk.org/jdk/pull/17764/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17764&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316460
  Stats: 132 lines in 5 files changed: 12 ins; 59 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/17764.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17764/head:pull/17764

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

From kevinw at openjdk.org  Thu Feb  8 10:39:53 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 Feb 2024 10:39:53 GMT
Subject: jmx-dev RFR: 8316460: 4 javax/management tests ignore VM flags
In-Reply-To: <uFB7WlA3qq3wDy1q5IAqbN3S0hZeYf_r_VNYqmq10xo=.dd65a6c5-b1af-40c9-865f-86c09e5a6368@github.com>
References: <uFB7WlA3qq3wDy1q5IAqbN3S0hZeYf_r_VNYqmq10xo=.dd65a6c5-b1af-40c9-865f-86c09e5a6368@github.com>
Message-ID: <H9GleJybMCUwgO4O-Lb7BxU15SCGo2i-L_wflgR1pgQ=.f9852002-4c0c-4fc4-a0fd-13ce3912700c@github.com>

On Thu, 8 Feb 2024 05:38:32 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The tests 
> javax/management/ImplementationVersion/ImplVersionTest.java
> javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java
> javax/management/remote/mandatory/version/ImplVersionTest.java
> javax/management/security/HashedPasswordFileTest.java
> were updated to use
> ProcessTools.createTestJavaProcessBuilder(...)
> 
> Tested by running tests with different jvm flags and tier1.

Looks good.  
I think you're saying this creates no obvious new failures. 8-)

Is there a bug on why we are problemlisting those two ImplVersion tests?
They are SecurityManager related, and I see your failures with an access denied problem, but I see them passing also, and some different failures in the history.
I'm not sure these tests have a great value, but we want to track the problemlisting I think.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17764#pullrequestreview-1869795183

From lmesnik at openjdk.org  Thu Feb  8 16:00:07 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 Feb 2024 16:00:07 GMT
Subject: jmx-dev RFR: 8316460: 4 javax/management tests ignore VM flags
In-Reply-To: <H9GleJybMCUwgO4O-Lb7BxU15SCGo2i-L_wflgR1pgQ=.f9852002-4c0c-4fc4-a0fd-13ce3912700c@github.com>
References: <uFB7WlA3qq3wDy1q5IAqbN3S0hZeYf_r_VNYqmq10xo=.dd65a6c5-b1af-40c9-865f-86c09e5a6368@github.com>
 <H9GleJybMCUwgO4O-Lb7BxU15SCGo2i-L_wflgR1pgQ=.f9852002-4c0c-4fc4-a0fd-13ce3912700c@github.com>
Message-ID: <TvBSLy4KhAXlwieyDySY8YKcLmdapQOJ-eya6wNNd10=.6219f3f0-143e-42e9-9cc2-5ed3ffa27a8f@github.com>

On Thu, 8 Feb 2024 10:36:52 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Is there a bug on why we are problemlisting those two ImplVersion tests?

They are permanently excluded from execution with the virtual thread test factory. The virtual threads are not compatible with the secutiry manager. It is not going to be fixed and bug is not needed here.

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

PR Comment: https://git.openjdk.org/jdk/pull/17764#issuecomment-1934429400

From ihse at openjdk.org  Fri Feb  9 13:41:39 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Feb 2024 13:41:39 GMT
Subject: jmx-dev RFR: 8325558: Add jcheck whitespace checking for properties
 files
Message-ID: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>

This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 

With Skara jcheck, it is possible to increase the coverage of the whitespace checks.

However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

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

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

Changes: https://git.openjdk.org/jdk/pull/17789/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17789&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325558
  Stats: 761 lines in 95 files changed: 0 ins; 5 del; 756 mod
  Patch: https://git.openjdk.org/jdk/pull/17789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17789/head:pull/17789

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

From ihse at openjdk.org  Fri Feb  9 13:41:39 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Feb 2024 13:41:39 GMT
Subject: jmx-dev RFR: 8325558: Add jcheck whitespace checking for
 properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <vjpYKJQJffU8Erjfn6uucPoPpWriBq1VQhvkztNZ5yg=.834ae963-240f-4bbf-8110-2278d7e17cec@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

I'll add some specific comments/reasoning to individual files, where I think a remark might be needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1935947566

From ihse at openjdk.org  Fri Feb  9 13:55:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Feb 2024 13:55:09 GMT
Subject: jmx-dev RFR: 8325558: Add jcheck whitespace checking for
 properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

src/java.base/unix/classes/sun/net/www/content-types.properties line 1:

> 1: #sun.net.www MIME content-types table

I have converted all leading tabs to 8 spaces.

src/java.base/windows/classes/sun/net/www/content-types.properties line 1:

> 1: #sun.net.www MIME content-types table

I have converted all leading tabs to 8 spaces.

src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties line 11:

> 9: ImageUtil0=The supplied Raster does not represent a binary data set.
> 10: ImageUtil1=The provided sample model is null.
> 11: ImageUtil2=The provided image cannot be encoded using: 

While it seems like this could have been significant, the code that uses it looks like this:

 throw new IIOException(I18N.getString("ImageUtil2")+" "+
                                   writer.getClass().getName());

so it will end up with a double space right now.

src/java.scripting/share/classes/com/sun/tools/script/shell/messages.properties line 1:

> 1: #

I have converted all leading tabs to 8 spaces.

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 

This sounded like it could potentially be followed by a name, but this is not the case.

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

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

This sounded like it could potentially be followed by a string, but this is not the case.

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

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties line 24:

> 22: 
> 23:         BadMessageKey = The error message corresponding to the message key can not be found.
> 24:         FormatFailed = An internal error occurred while formatting the following message:\n  

At first glance, it might look like something should follow the `:`, but note that there is a `\n` so if anything this will only make the next line improperly indented.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties line 20:

> 18: # Messages for message reporting
> 19: BadMessageKey = The error message corresponding to the message key can not be found.
> 20: FormatFailed = An internal error occurred while formatting the following message:\n

At first glance, it might look like something should follow the :, but note that there is a \n so if anything this will only make the next line improperly indented.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 27:

> 25: 
> 26:         BadMessageKey = The error message corresponding to the message key can not be found.
> 27:         FormatFailed = An internal error occurred while formatting the following message:\n

Same here with `:\n`...

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties line 24:

> 22: # Messages for message reporting
> 23: BadMessageKey = The error message corresponding to the message key can not be found.
> 24: FormatFailed = An internal error occurred while formatting the following message:\n

Same here with `:\n`...

src/jdk.compiler/share/classes/sun/tools/serialver/resources/serialver.properties line 1:

> 1: #

I have converted all leading tabs to 8 spaces.

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

> 47:         'u' flag requires manifest, 'e' flag or input files to be specified!
> 48: error.bad.eflag=\
> 49: 	'e' flag and manifest with the 'Main-Class' attribute cannot be specified \n\

Here were two lines that used tab instead of space; I converted them to 8 spaces.

test/jaxp/javax/xml/jaxp/unittest/common/config/files/catalog2.properties line 4:

> 2: #       XML Library (java.xml) Configuration File
> 3: #
> 4: # This file is in java.util.Properties format and typically located in the conf 

These spaces at the end of comment lines has crept in since I cleaned all such out in [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047). It's a good example of why we need the jcheck verification to keep this from regressing once more.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties line 12:

> 10: 
> 11: TableDemo.noDataStatusLabel=No data loaded
> 12: TableDemo.loadingStatusLabel=Loading data:\u0020

According to https://github.com/openjdk/jdk/pull/11488/files#r1038605801 the latter two are actually needed as spaces, and the first might be; so keeping it as well seems to be the safe choice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484326435
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484326568
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484327614
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484327859
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484329632
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484329770
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484330650
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484332081
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484332649
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484334629
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484334259
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484335061
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484335669
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484337306
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484338418
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484339114
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484341847
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484345466

From dfuchs at openjdk.org  Fri Feb  9 14:10:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Feb 2024 14:10:57 GMT
Subject: jmx-dev RFR: 8325558: Add jcheck whitespace checking for
 properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <MAPhOTYtvVaNcWCFKbDS-_1DUpWDjk7QPxjKCqRkcMU=.6138cf57-eec3-47fd-9932-3ab1d538e789@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

changes to sun/net content-types.properties look OK

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

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1935996382

From erikj at openjdk.org  Fri Feb  9 14:56:57 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Feb 2024 14:56:57 GMT
Subject: jmx-dev RFR: 8325558: Add jcheck whitespace checking for
 properties files
In-Reply-To: <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
 <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>
Message-ID: <nhpBrqfBtPnWkJykz1_einfiy1GazMV7NLU1-ukdtiw=.c2e3123b-9bc5-418e-9785-62a078ab9466@github.com>

On Fri, 9 Feb 2024 13:42:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.
>
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties line 24:
> 
>> 22: 
>> 23:         BadMessageKey = The error message corresponding to the message key can not be found.
>> 24:         FormatFailed = An internal error occurred while formatting the following message:\n  
> 
> At first glance, it might look like something should follow the `:`, but note that there is a `\n` so if anything this will only make the next line improperly indented.

That could have been intentional though. Not sure if it was a good idea, but indenting something is a way of making something stand out as a quote. But looking at every use site, there is an extra space added anyway, so this seems fine. If we wanted to preserve the exact same behavior, all use sites should be updated to add 3 spaces.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484416962

From naoto at openjdk.org  Fri Feb  9 18:12:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Feb 2024 18:12:06 GMT
Subject: jmx-dev RFR: 8325558: Add jcheck whitespace checking for
 properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <rB3HxteVgSXBiQnLDLdYgc2jXTL2fFPg5zdCQwxHt1g=.37699c1c-1dad-4451-b364-38d1b2170957@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

Skimmed through the changes and all look good to me. Good to have `jcheck` detect those unneeded trailing spaces.

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

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1872951198

From lmesnik at openjdk.org  Fri Feb  9 18:43:08 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 Feb 2024 18:43:08 GMT
Subject: jmx-dev Integrated: 8316460: 4 javax/management tests ignore VM
 flags
In-Reply-To: <uFB7WlA3qq3wDy1q5IAqbN3S0hZeYf_r_VNYqmq10xo=.dd65a6c5-b1af-40c9-865f-86c09e5a6368@github.com>
References: <uFB7WlA3qq3wDy1q5IAqbN3S0hZeYf_r_VNYqmq10xo=.dd65a6c5-b1af-40c9-865f-86c09e5a6368@github.com>
Message-ID: <IiuVt8bOWlWvlEY6TYgIquezLRK9U55v80AL2U11iNI=.5493e2d3-bc20-4e2e-b1dc-9c5792df6255@github.com>

On Thu, 8 Feb 2024 05:38:32 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The tests 
> javax/management/ImplementationVersion/ImplVersionTest.java
> javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java
> javax/management/remote/mandatory/version/ImplVersionTest.java
> javax/management/security/HashedPasswordFileTest.java
> were updated to use
> ProcessTools.createTestJavaProcessBuilder(...)
> 
> Tested by running tests with different jvm flags and tier1.

This pull request has now been integrated.

Changeset: d39b7bab
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d39b7bab27af5ba24ff0925037b8e5fb99680dc0
Stats:     132 lines in 5 files changed: 12 ins; 59 del; 61 mod

8316460: 4 javax/management tests ignore VM flags

Reviewed-by: kevinw

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

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

From ihse at openjdk.org  Mon Feb 12 08:11:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 08:11:03 GMT
Subject: jmx-dev RFR: 8325558: Add jcheck whitespace checking for
 properties files
In-Reply-To: <rB3HxteVgSXBiQnLDLdYgc2jXTL2fFPg5zdCQwxHt1g=.37699c1c-1dad-4451-b364-38d1b2170957@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
 <rB3HxteVgSXBiQnLDLdYgc2jXTL2fFPg5zdCQwxHt1g=.37699c1c-1dad-4451-b364-38d1b2170957@github.com>
Message-ID: <8BLLuuu7gTj4P8bDZ40PWRJDT7668CSSqMiywzlPrIs=.1f188e66-2327-43e3-b30e-16798937eefe@github.com>

On Fri, 9 Feb 2024 18:09:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.
>
> Skimmed through the changes and all look good to me. Good to have `jcheck` detect those unneeded trailing spaces.

@naotoj Thanks! Would you care to also submit a review?

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

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1938204446

From naoto at openjdk.org  Mon Feb 12 17:37:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Feb 2024 17:37:56 GMT
Subject: jmx-dev RFR: 8325558: Add jcheck whitespace checking for
 properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <NscNVRE66ok6SSHmMGQaeVZSxYEnWS_WzhLMve54xbU=.5ecae045-37aa-45aa-86c3-926bfb04599e@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

> @naotoj Thanks! Would you care to also submit a review?

My bad. I thought I approved this PR.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1875811619

From dfuchs at openjdk.org  Mon Feb 12 17:42:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Feb 2024 17:42:06 GMT
Subject: jmx-dev RFR: 8325558: Add jcheck whitespace checking for
 properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <aP9GcIjHZudg8GUlGYhOK4kUlFo5m6aWU4_adCeIIU8=.8634bdeb-198c-4827-b90f-bdee1a94e0f4@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

Approving the sun.net changes.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1875818676

From joehw at openjdk.org  Mon Feb 12 20:25:59 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 12 Feb 2024 20:25:59 GMT
Subject: jmx-dev RFR: 8325558: Add jcheck whitespace checking for
 properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <o8ZfKM3dvC-eD-ryNHYogkK94Ha8ArlUiw1qb9Bw51U=.bc0a293b-0dff-43d9-98d0-a798b2ba2dc7@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

java.xml changes look fine to me.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1876181019

From joehw at openjdk.org  Mon Feb 12 20:26:00 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 12 Feb 2024 20:26:00 GMT
Subject: jmx-dev RFR: 8325558: Add jcheck whitespace checking for
 properties files
In-Reply-To: <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
 <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>
Message-ID: <xLIVBeMz0nzp8xjs9ukxIJ1CAe4Aflvz0mtCgDL3RU4=.61371bf6-7719-4bc5-9537-df645d3fa640@github.com>

On Fri, 9 Feb 2024 13:46:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.
>
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties line 24:
> 
>> 22: # Messages for message reporting
>> 23: BadMessageKey = The error message corresponding to the message key can not be found.
>> 24: FormatFailed = An internal error occurred while formatting the following message:\n
> 
> Same here with `:\n`...

It's done with the code (that is, a key is appended with the code). In fact, the whole Xerces stack was implemented this way. I'd leave it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1486731927

From ihse at openjdk.org  Tue Feb 13 10:03:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Feb 2024 10:03:08 GMT
Subject: jmx-dev Integrated: 8325558: Add jcheck whitespace checking for
 properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <1_5f_JhU7k2LuEKn7w-rn3FkkBpaBDiz3o_uBy-uKiw=.7ed5bef7-6484-435f-8d87-12dadc4d9e9d@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

This pull request has now been integrated.

Changeset: c266800a
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c266800a3a7dd44416b0b4df3bdd78410241d74b
Stats:     761 lines in 95 files changed: 0 ins; 5 del; 756 mod

8325558: Add jcheck whitespace checking for properties files

Reviewed-by: naoto, dfuchs, joehw

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

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

From ihse at openjdk.org  Thu Feb 15 12:29:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 12:29:23 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass jcheck
Message-ID: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>

Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).

I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

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

Commit messages:
 - 8325950: Make sure all files in the JDK pass jcheck

Changes: https://git.openjdk.org/jdk/pull/17871/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17871&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325950
  Stats: 113 lines in 38 files changed: 0 ins; 10 del; 103 mod
  Patch: https://git.openjdk.org/jdk/pull/17871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17871/head:pull/17871

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

From ihse at openjdk.org  Thu Feb 15 12:29:24 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 12:29:24 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

Some general remarks: The problems in .m4 files where not properly detected and fixed when I added .m4 to the list of checked files. The properties files were recently checked by me, so these suprrised me. It turned out I had misunderstood the jcheck criteria: I thought only leading tabs were disallowed, but it is actually tabs anywhere in the file that are banned.

In general, I have replaced tab characters with spaces aligning to tab stops at 8 characters distance. 

I'll leave some remarks for individual files.

src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties line 10:

> 8: java.naming.factory.object=com.sun.jndi.ldap.obj.AttrsToCorba:com.sun.jndi.ldap.obj.MarshalledToObject
> 9: 
> 10: # RemoteToAttrs: Turn RMI/JRMP and RMI/IIOP object into javaMarshalledObject or

I adjusted this tab stop (with one space) so it aligned properly with the line above; I think that was the intention.

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdkinternals.properties line 41:

> 39: jdk.internal.ref.Cleaner=Use java.lang.ref.PhantomReference @since 1.2 or java.lang.ref.Cleaner @since 9
> 40: sun.awt.CausedFocusEvent=Use java.awt.event.FocusEvent::getCause @since 9
> 41: sun.font.FontUtilities=See java.awt.Font.textRequiresLayout	@since 9

This tab just looked out of place, so I replaced it with a space. (Rhyming not intentional...)

test/hotspot/jtreg/containers/docker/JfrReporter.java line 52:

> 50:             }
> 51:         }
> 52:     }

I'm not sure how a Java file ever got into the code base with trailing spaces, but a guess is that there have been a bug in jcheck that did not properly check for trailing whitespace at the end of the file, or something like that.

test/jdk/java/util/Currency/currency.properties line 18:

> 16: SB=EUR,111,2, 2099-01-01T00:00:00
> 17: US=euR,978,2,2001-01-01T00:00:00
> 18: ZZ	=	ZZZ	,	999	,	3

This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.

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

PR Comment: https://git.openjdk.org/jdk/pull/17871#issuecomment-1945992837
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490931378
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490931979
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490933432
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490934063

From erikj at openjdk.org  Thu Feb 15 14:05:12 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 15 Feb 2024 14:05:12 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
Message-ID: <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>

On Thu, 15 Feb 2024 12:26:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> test/jdk/java/util/Currency/currency.properties line 18:
> 
>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>> 17: US=euR,978,2,2001-01-01T00:00:00
>> 18: ZZ	=	ZZZ	,	999	,	3
> 
> This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.

This looks weird indeed. Luckily it's just test code. Did you run the test after this change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491056108

From ihse at openjdk.org  Thu Feb 15 15:50:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 15:50:57 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
Message-ID: <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>

On Thu, 15 Feb 2024 14:01:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> test/jdk/java/util/Currency/currency.properties line 18:
>> 
>>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>>> 17: US=euR,978,2,2001-01-01T00:00:00
>>> 18: ZZ	=	ZZZ	,	999	,	3
>> 
>> This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.
>
> This looks weird indeed. Luckily it's just test code. Did you run the test after this change?

All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491227492

From naoto at openjdk.org  Thu Feb 15 17:12:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Feb 2024 17:12:55 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
Message-ID: <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>

On Thu, 15 Feb 2024 15:48:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This looks weird indeed. Luckily it's just test code. Did you run the test after this change?
>
> All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.

Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491352359

From angorya at openjdk.org  Thu Feb 15 17:31:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 Feb 2024 17:31:56 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
 <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
Message-ID: <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>

On Thu, 15 Feb 2024 17:09:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.
>
> Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)

`\u000b` is VT   (vertical tab)  
`\u0009` or `\t` perhaps?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491375928

From naoto at openjdk.org  Thu Feb 15 17:55:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Feb 2024 17:55:58 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
 <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
 <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>
Message-ID: <RtDj7nYzLQTAHvuthfA12JIjqYTM7LkXy92QXXib4jY=.62dbc402-ade5-48be-9e7a-1ca1091899d4@github.com>

On Thu, 15 Feb 2024 17:28:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)
>
> `\u000b` is VT   (vertical tab)  
> `\u0009` or `\t` perhaps?

Right. `\t` is better to avoid such a mistake.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491403426

From prr at openjdk.org  Thu Feb 15 22:40:56 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Feb 2024 22:40:56 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <lmqQHpQrlQkG9kFB3GhPa0530wpWgAWXrVjKeKLrezM=.8050c3cd-2143-439e-ad8d-c3b27e82e59a@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

desktop changes look fine to me.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1884009342

From wetmore at openjdk.org  Fri Feb 16 01:44:57 2024
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 Feb 2024 01:44:57 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <AG07BfABTTmZaZhAd9jHgMMgcaGRtP_31MVSJg8LUYo=.e9355b50-d5d1-4551-a161-15712bf6b1e8@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

security properties looks ok.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1884183930

From ihse at openjdk.org  Fri Feb 16 12:43:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:43:25 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass
 jcheck [v2]
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Replace spaces with \t in test properties file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17871/files
  - new: https://git.openjdk.org/jdk/pull/17871/files/3faa912e..e1c9c0f0

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

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

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

From ihse at openjdk.org  Fri Feb 16 12:43:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:43:25 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass
 jcheck [v2]
In-Reply-To: <RtDj7nYzLQTAHvuthfA12JIjqYTM7LkXy92QXXib4jY=.62dbc402-ade5-48be-9e7a-1ca1091899d4@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
 <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
 <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>
 <RtDj7nYzLQTAHvuthfA12JIjqYTM7LkXy92QXXib4jY=.62dbc402-ade5-48be-9e7a-1ca1091899d4@github.com>
Message-ID: <gQYN5tDVDEdGZVHhgOHMz2IvGZn4iam8xh4Xx3jKPFk=.55c92a6d-68dd-4838-a2f8-840b4a66e4c2@github.com>

On Thu, 15 Feb 2024 17:53:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `\u000b` is VT   (vertical tab)  
>> `\u0009` or `\t` perhaps?
>
> Right. `\t` is better to avoid such a mistake.

Ok, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1492403403

From erikj at openjdk.org  Fri Feb 16 13:39:56 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 16 Feb 2024 13:39:56 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass
 jcheck [v2]
In-Reply-To: <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
Message-ID: <EG72V-Kg8FWuzTzqCGrfpb3fX_WIq4oybS3sljVlPGY=.400d3c9f-a361-4515-8c6f-6a465b89adc0@github.com>

On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace spaces with \t in test properties file

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1885177994

From naoto at openjdk.org  Fri Feb 16 16:55:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Feb 2024 16:55:57 GMT
Subject: jmx-dev RFR: 8325950: Make sure all files in the JDK pass
 jcheck [v2]
In-Reply-To: <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
Message-ID: <fV_QpLFoKMrAxR1VvhztN6ha6WJBO8iNcPzNbP-fgAo=.25e82e1c-ed8d-4b7f-9f76-a9ed2a08e62d@github.com>

On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace spaces with \t in test properties file

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1885586969

From ihse at openjdk.org  Mon Feb 19 16:16:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 16:16:00 GMT
Subject: jmx-dev Integrated: 8325950: Make sure all files in the JDK pass
 jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <8lQWgT0JhzAP5uuraMs8UjJXJcyTacHziySbnLN9XaQ=.16d4233d-1815-4cf8-8761-368fe425a131@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

This pull request has now been integrated.

Changeset: 5c5a282f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c5a282f91dd28b306673ca2bcc30dec451e7a7d
Stats:     113 lines in 38 files changed: 0 ins; 10 del; 103 mod

8325950: Make sure all files in the JDK pass jcheck

Reviewed-by: prr, wetmore, erikj, naoto

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

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