From prappo at openjdk.org  Tue Aug 20 09:10:56 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 20 Aug 2024 09:10:56 GMT
Subject: jmx-dev RFR: 8301991: Convert l10n properties resource bundles
 to UTF-8 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <MXhh7BptkSt56mS9c00G6g5ZxmSuhoMR0Lc9TVuQGp0=.34251420-7215-4987-917b-39151f50fad1@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

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

> 93: 
> 94: main.usage.summary=Uso: jar [OPTION...] [ [--release VERSION] [-C dir] files] ...
> 95: main.usage.summary.try=Tente `jar --ajuda' para obter mais informa??es.

I was looking for something unrelated in properties files, and found this. It is surprising to see an option name being localised; it must be a bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1722966688

From naoto at openjdk.org  Tue Aug 20 15:30:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Aug 2024 15:30:58 GMT
Subject: jmx-dev RFR: 8301991: Convert l10n properties resource bundles
 to UTF-8 native [v2]
In-Reply-To: <MXhh7BptkSt56mS9c00G6g5ZxmSuhoMR0Lc9TVuQGp0=.34251420-7215-4987-917b-39151f50fad1@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
 <MXhh7BptkSt56mS9c00G6g5ZxmSuhoMR0Lc9TVuQGp0=.34251420-7215-4987-917b-39151f50fad1@github.com>
Message-ID: <9wZvcGjRkpfRm02paHISi86ynU0aYrW9WoinmyIb-RM=.9795a780-b857-4de3-bca6-075305fbd9f7@github.com>

On Tue, 20 Aug 2024 09:07:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace InputStreamReader with BufferedReader
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_pt_BR.properties line 95:
> 
>> 93: 
>> 94: main.usage.summary=Uso: jar [OPTION...] [ [--release VERSION] [-C dir] files] ...
>> 95: main.usage.summary.try=Tente `jar --ajuda' para obter mais informa??es.
> 
> I was looking for something unrelated in properties files, and found this. It is surprising to see an option name being localised; it must be a bug.

Good catch, Pavel. It is indeed a bug. This type of overtranslation l10n bug happens all the time, and hard to catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1723520963

From jnordstrom at openjdk.org  Wed Aug 21 10:37:12 2024
From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Wed, 21 Aug 2024 10:37:12 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad
Message-ID: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>

Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.

Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.

This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.

double cpuLoad1 = getCpuLoad();
double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values

Worth noting is that this holds true even if getSystemCpuLoad() is called. 

double cpuLoad1 = getCpuLoad();
double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.

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

Commit messages:
 - 8335625: Update Javadoc for GetCpuLoad
 - 8335625: Update Javadoc for GetCpuLoad

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

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

From kevinw at openjdk.org  Wed Aug 21 10:48:04 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 21 Aug 2024 10:48:04 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad
In-Reply-To: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
Message-ID: <23IlqmUfAYAoQV3dfP-JafkqpfWUcmZPmCkOXyDvmmk=.4ce13add-c0cc-4909-80f2-f36017fc596e@github.com>

On Mon, 12 Aug 2024 12:33:04 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

> Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
> 
> Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.
> 
> This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.
> 
> double cpuLoad1 = getCpuLoad();
> double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values
> 
> Worth noting is that this holds true even if getSystemCpuLoad() is called. 
> 
> double cpuLoad1 = getCpuLoad();
> double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.

This is a helpful clarifying comment in the docs to avoid some confusion that's been seen with these methods.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20546#pullrequestreview-2250453882

From dholmes at openjdk.org  Wed Aug 21 11:30:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Aug 2024 11:30:04 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad
In-Reply-To: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
Message-ID: <vhbFRHJmbjH8Ivb0mE7Ec67NuNpQveDqYs4W5qJGF3o=.6b00b949-62de-43be-93d4-7d95d4e184d5@github.com>

On Mon, 12 Aug 2024 12:33:04 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

> Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
> 
> Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.
> 
> This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.
> 
> double cpuLoad1 = getCpuLoad();
> double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values
> 
> Worth noting is that this holds true even if getSystemCpuLoad() is called. 
> 
> double cpuLoad1 = getCpuLoad();
> double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.

src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java line 142:

> 140:      * negative value.
> 141:      *
> 142:      * <p> This method is not idempotent. The recent period of observation

I would not expect this method to be "idempotent" so it seems very odd to me to state this. Overall this sounds like you are now specifying an implementation limitation as the only way this can be done. Maybe this should be an `@ImplNote` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20546#discussion_r1724890551

From alanb at openjdk.org  Wed Aug 21 11:38:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Aug 2024 11:38:05 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad
In-Reply-To: <vhbFRHJmbjH8Ivb0mE7Ec67NuNpQveDqYs4W5qJGF3o=.6b00b949-62de-43be-93d4-7d95d4e184d5@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <vhbFRHJmbjH8Ivb0mE7Ec67NuNpQveDqYs4W5qJGF3o=.6b00b949-62de-43be-93d4-7d95d4e184d5@github.com>
Message-ID: <FL9PY8mtrHDlRp7-LevE4SXQtatvBK0YKkwscYluNmY=.7b9695e2-b638-4f33-b2de-644bc12d0e8d@github.com>

On Wed, 21 Aug 2024 11:27:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
>> 
>> Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.
>> 
>> This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values
>> 
>> Worth noting is that this holds true even if getSystemCpuLoad() is called. 
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.
>
> src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java line 142:
> 
>> 140:      * negative value.
>> 141:      *
>> 142:      * <p> This method is not idempotent. The recent period of observation
> 
> I would not expect this method to be "idempotent" so it seems very odd to me to state this. Overall this sounds like you are now specifying an implementation limitation as the only way this can be done. Maybe this should be an `@ImplNote` ?

You beat me to it. We specify some methods (close, dispose, ...) as idempotent. Specifying a getter as non-idempotent looks very strange here.

I can't tell if you are looking to specify implementation behavior (as David asks) or whether you want to provide advice for users of this API, in which case an apiNote may be the tag you need.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20546#discussion_r1724899378

From kevinw at openjdk.org  Wed Aug 21 12:28:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 21 Aug 2024 12:28:03 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad
In-Reply-To: <FL9PY8mtrHDlRp7-LevE4SXQtatvBK0YKkwscYluNmY=.7b9695e2-b638-4f33-b2de-644bc12d0e8d@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <vhbFRHJmbjH8Ivb0mE7Ec67NuNpQveDqYs4W5qJGF3o=.6b00b949-62de-43be-93d4-7d95d4e184d5@github.com>
 <FL9PY8mtrHDlRp7-LevE4SXQtatvBK0YKkwscYluNmY=.7b9695e2-b638-4f33-b2de-644bc12d0e8d@github.com>
Message-ID: <tQbJIdztiCRM9ZqnzD1R4mXFtjIxbh0sCRDMKo_tf8I=.53cd4873-1ecd-4f73-91f1-6e887e9c3948@github.com>

On Wed, 21 Aug 2024 11:35:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java line 142:
>> 
>>> 140:      * negative value.
>>> 141:      *
>>> 142:      * <p> This method is not idempotent. The recent period of observation
>> 
>> I would not expect this method to be "idempotent" so it seems very odd to me to state this. Overall this sounds like you are now specifying an implementation limitation as the only way this can be done. Maybe this should be an `@ImplNote` ?
>
> You beat me to it. We specify some methods (close, dispose, ...) as idempotent. Specifying a getter as non-idempotent looks very strange here.
> 
> I can't tell if you are looking to specify implementation behavior (as David asks) or whether you want to provide advice for users of this API, in which case an apiNote may be the tag you need.

Ok yes maybe "not idempotent" isn't a great term here.
Just removing that phrase, "This method is not idempotent.", this would still be a helpful update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20546#discussion_r1724962676

From jnordstrom at openjdk.org  Wed Aug 21 13:42:18 2024
From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Wed, 21 Aug 2024 13:42:18 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v2]
In-Reply-To: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
Message-ID: <SSs9mkjaXVdIQSUtkKTo82YD4WM0CO1czpZJ1xA81AU=.02f2fded-3f35-491e-8c9f-4db8ba3274b7@github.com>

> Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
> 
> Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.
> 
> This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.
> 
> double cpuLoad1 = getCpuLoad();
> double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values
> 
> Worth noting is that this holds true even if getSystemCpuLoad() is called. 
> 
> double cpuLoad1 = getCpuLoad();
> double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.

Joakim Nordstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Made it an apiNote

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20546/files
  - new: https://git.openjdk.org/jdk/pull/20546/files/88c10534..07b0faa6

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

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

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

From jnordstrom at openjdk.org  Wed Aug 21 13:52:02 2024
From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Wed, 21 Aug 2024 13:52:02 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v2]
In-Reply-To: <tQbJIdztiCRM9ZqnzD1R4mXFtjIxbh0sCRDMKo_tf8I=.53cd4873-1ecd-4f73-91f1-6e887e9c3948@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <vhbFRHJmbjH8Ivb0mE7Ec67NuNpQveDqYs4W5qJGF3o=.6b00b949-62de-43be-93d4-7d95d4e184d5@github.com>
 <FL9PY8mtrHDlRp7-LevE4SXQtatvBK0YKkwscYluNmY=.7b9695e2-b638-4f33-b2de-644bc12d0e8d@github.com>
 <tQbJIdztiCRM9ZqnzD1R4mXFtjIxbh0sCRDMKo_tf8I=.53cd4873-1ecd-4f73-91f1-6e887e9c3948@github.com>
Message-ID: <apG0ncjWHW-EAV8tQpWyNQTl9ALW5s_c-DllV9uMtDk=.f9d1fd55-de19-4e91-80d2-c553e8862eb6@github.com>

On Wed, 21 Aug 2024 12:25:48 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> You beat me to it. We specify some methods (close, dispose, ...) as idempotent. Specifying a getter as non-idempotent looks very strange here.
>> 
>> I can't tell if you are looking to specify implementation behavior (as David asks) or whether you want to provide advice for users of this API, in which case an apiNote may be the tag you need.
>
> Ok yes maybe "not idempotent" isn't a great term here.
> Just removing that phrase, "This method is not idempotent.", this would still be a helpful update.

I want to provide advice for how this API should be used.

The "recent period of time observed" is vague (Who's the observer? Who decides the "recent period"? The API user or the JVM?). In essence it is the time between two consecutive calls, but that is not very clear from the description -- this has been seen to cause confusion.

I hesitated to add "idempotent", but also I felt that it added something. Without it, the rest of the sentence is basically just the same words as in the first paragraph, so they can be easily missed. Also, the best practices I've seen is that "getters" should be idempotent, so stating this one isn't signals there's something to take note of here.

Adding `@apiNote` might be enough of signal. Have updated with the tag and removed "idempotent".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20546#discussion_r1725090806

From dfuchs at openjdk.org  Wed Aug 21 14:43:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 21 Aug 2024 14:43:06 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v2]
In-Reply-To: <SSs9mkjaXVdIQSUtkKTo82YD4WM0CO1czpZJ1xA81AU=.02f2fded-3f35-491e-8c9f-4db8ba3274b7@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <SSs9mkjaXVdIQSUtkKTo82YD4WM0CO1czpZJ1xA81AU=.02f2fded-3f35-491e-8c9f-4db8ba3274b7@github.com>
Message-ID: <yFqTBiIJLEjD_LCBcWOY7LN8nBBIN7iuiVJ1YAZn8Tg=.5580d3b4-c546-47b4-b3ba-178cbcd18d7c@github.com>

On Wed, 21 Aug 2024 13:42:18 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

>> Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
>> 
>> Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.
>> 
>> This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values
>> 
>> Worth noting is that this holds true even if getSystemCpuLoad() is called. 
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.
>
> Joakim Nordstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made it an apiNote

src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java line 145:

> 143:      * call made to this method, or {@link #getCpuLoad()}. For the very first
> 144:      * invocation of this method, the recent period of observation is undefined.
> 145:      *

I wonder if the text would read better as:

     * @apiNote The recent period of observation is typically the duration since the last


Since this is an MBean, many different callers could be calling this method, including other Monitor MBeans that may have been registered. Adding _typically_ will soften the assertion, give more leeway to implementations, and still be informative enough for readers to better understand the API?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20546#discussion_r1725176645

From dholmes at openjdk.org  Wed Aug 21 22:30:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Aug 2024 22:30:03 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v2]
In-Reply-To: <apG0ncjWHW-EAV8tQpWyNQTl9ALW5s_c-DllV9uMtDk=.f9d1fd55-de19-4e91-80d2-c553e8862eb6@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <vhbFRHJmbjH8Ivb0mE7Ec67NuNpQveDqYs4W5qJGF3o=.6b00b949-62de-43be-93d4-7d95d4e184d5@github.com>
 <FL9PY8mtrHDlRp7-LevE4SXQtatvBK0YKkwscYluNmY=.7b9695e2-b638-4f33-b2de-644bc12d0e8d@github.com>
 <tQbJIdztiCRM9ZqnzD1R4mXFtjIxbh0sCRDMKo_tf8I=.53cd4873-1ecd-4f73-91f1-6e887e9c3948@github.com>
 <apG0ncjWHW-EAV8tQpWyNQTl9ALW5s_c-DllV9uMtDk=.f9d1fd55-de19-4e91-80d2-c553e8862eb6@github.com>
Message-ID: <9TTLTFnxVYvmFdMT7AaZ7BEs84Gpskcbkn9bg7W2GRQ=.96fe7d4d-0ba4-47c0-8b97-b40a9f67385f@github.com>

On Wed, 21 Aug 2024 13:49:08 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

>> Ok yes maybe "not idempotent" isn't a great term here.
>> Just removing that phrase, "This method is not idempotent.", this would still be a helpful update.
>
> I want to provide advice for how this API should be used.
> 
> The "recent period of time observed" is vague (Who's the observer? Who decides the "recent period"? The API user or the JVM?). In essence it is the time between two consecutive calls, but that is not very clear from the description -- this has been seen to cause confusion.
> 
> I hesitated to add "idempotent", but also I felt that it added something. Without it, the rest of the sentence is basically just the same words as in the first paragraph, so they can be easily missed. Also, the best practices I've seen is that "getters" should be idempotent, so stating this one isn't signals there's something to take note of here.
> 
> Adding `@apiNote` might be enough of signal. Have updated with the tag and removed "idempotent".

> "Idempotence is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application. "

So the notion of idempotency on a getter method just doesn't make sense in general  and in this case in particular as you calculate a new result each time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20546#discussion_r1725887348

From jnordstrom at openjdk.org  Thu Aug 22 06:59:04 2024
From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Thu, 22 Aug 2024 06:59:04 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v2]
In-Reply-To: <9TTLTFnxVYvmFdMT7AaZ7BEs84Gpskcbkn9bg7W2GRQ=.96fe7d4d-0ba4-47c0-8b97-b40a9f67385f@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <vhbFRHJmbjH8Ivb0mE7Ec67NuNpQveDqYs4W5qJGF3o=.6b00b949-62de-43be-93d4-7d95d4e184d5@github.com>
 <FL9PY8mtrHDlRp7-LevE4SXQtatvBK0YKkwscYluNmY=.7b9695e2-b638-4f33-b2de-644bc12d0e8d@github.com>
 <tQbJIdztiCRM9ZqnzD1R4mXFtjIxbh0sCRDMKo_tf8I=.53cd4873-1ecd-4f73-91f1-6e887e9c3948@github.com>
 <apG0ncjWHW-EAV8tQpWyNQTl9ALW5s_c-DllV9uMtDk=.f9d1fd55-de19-4e91-80d2-c553e8862eb6@github.com>
 <9TTLTFnxVYvmFdMT7AaZ7BEs84Gpskcbkn9bg7W2GRQ=.96fe7d4d-0ba4-47c0-8b97-b40a9f67385f@github.com>
Message-ID: <DT28oFN6dq6Nf5QygLz72WmyxD1JE1TBm-kMRXJsMIQ=.c17e96b4-f083-4ec4-a08e-c70bb3049076@github.com>

On Wed, 21 Aug 2024 22:27:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I want to provide advice for how this API should be used.
>> 
>> The "recent period of time observed" is vague (Who's the observer? Who decides the "recent period"? The API user or the JVM?). In essence it is the time between two consecutive calls, but that is not very clear from the description -- this has been seen to cause confusion.
>> 
>> I hesitated to add "idempotent", but also I felt that it added something. Without it, the rest of the sentence is basically just the same words as in the first paragraph, so they can be easily missed. Also, the best practices I've seen is that "getters" should be idempotent, so stating this one isn't signals there's something to take note of here.
>> 
>> Adding `@apiNote` might be enough of signal. Have updated with the tag and removed "idempotent".
>
>> "Idempotence is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application. "
> 
> So the notion of idempotency on a getter method just doesn't make sense in general  and in this case in particular as you calculate a new result each time.

Right, I agree. The confusing thing here is that it isn't obvious by the name (nor the docs, until now hopefully) that it does calculate a new result each time it is called. 

What I think user's want, and mistakes this method for, is something of the commandline `top` equivalent. By not being able to define the period of observation, or even reliably tell what it is, I think many assumes it's something reasonable. To add to this, looking at the Windows implementation you have a minimum duration of 500 ticks, so you'll never see the outliers you see on Linux where you can get a duration of just 2 ticks, and get return values like 1.0, 0.5, or 0.0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20546#discussion_r1726458611

From alanb at openjdk.org  Thu Aug 22 07:48:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Aug 2024 07:48:03 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v2]
In-Reply-To: <SSs9mkjaXVdIQSUtkKTo82YD4WM0CO1czpZJ1xA81AU=.02f2fded-3f35-491e-8c9f-4db8ba3274b7@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <SSs9mkjaXVdIQSUtkKTo82YD4WM0CO1czpZJ1xA81AU=.02f2fded-3f35-491e-8c9f-4db8ba3274b7@github.com>
Message-ID: <54472N3LakKLbgIkXbzFO5QhvTqoJt8fDQPu_f_vUYc=.7f7feaa7-cf58-4c45-813c-3cb7092e40f2@github.com>

On Wed, 21 Aug 2024 13:42:18 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

>> Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
>> 
>> Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.
>> 
>> This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values
>> 
>> Worth noting is that this holds true even if getSystemCpuLoad() is called. 
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.
>
> Joakim Nordstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made it an apiNote

We can't say "since the last call made to this method" without some qualification. If the MXBean is used directly then it immediately begs the question as to whether it means the current thread, any thread, or even from any thread in any process.  If the MXBean is used indirectly (via the MBeanServer) then I don't know what it means.

If I read the bug report correctly then this is really about setting expectations as the data is obtained in a very implementation, and environment, specific way. I don't think you can say much more than that without adding an implNote with some hints on how it implementation in some environments.

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

PR Comment: https://git.openjdk.org/jdk/pull/20546#issuecomment-2304001884

From jnordstrom at openjdk.org  Fri Aug 23 08:49:38 2024
From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Fri, 23 Aug 2024 08:49:38 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v3]
In-Reply-To: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
Message-ID: <YJsL1RLJfEGmTJ1A-LgamE7fXKEP48z0rAh_VSDxmeQ=.e156963e-dd92-41aa-8125-220fa0efe639@github.com>

> Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
> 
> Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.
> 
> This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.
> 
> double cpuLoad1 = getCpuLoad();
> double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values
> 
> Worth noting is that this holds true even if getSystemCpuLoad() is called. 
> 
> double cpuLoad1 = getCpuLoad();
> double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.

Joakim Nordstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Added implNote and made some re-arrangements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20546/files
  - new: https://git.openjdk.org/jdk/pull/20546/files/07b0faa6..af69aa88

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

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

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

From jnordstrom at openjdk.org  Fri Aug 23 08:53:04 2024
From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Fri, 23 Aug 2024 08:53:04 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v3]
In-Reply-To: <YJsL1RLJfEGmTJ1A-LgamE7fXKEP48z0rAh_VSDxmeQ=.e156963e-dd92-41aa-8125-220fa0efe639@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <YJsL1RLJfEGmTJ1A-LgamE7fXKEP48z0rAh_VSDxmeQ=.e156963e-dd92-41aa-8125-220fa0efe639@github.com>
Message-ID: <jnifJ-u4QEzO6PmQmdq-4eMi1c55sSyATedEBdjJEAQ=.7091dfbc-2f6f-4e22-ada6-dc8ffd6bee53@github.com>

On Fri, 23 Aug 2024 08:49:38 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

>> Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
>> 
>> Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.
>> 
>> This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values
>> 
>> Worth noting is that this holds true even if getSystemCpuLoad() is called. 
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.
>
> Joakim Nordstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added implNote and made some re-arrangements

Reworked the text after suggestions, added `@implNote`, and re-structured a bit.

Please have another look. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/20546#issuecomment-2306615160

From mcimadamore at openjdk.org  Fri Aug 23 09:03:32 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 23 Aug 2024 09:03:32 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v10]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <HA3_7MIOfWFK3QKeLQUsXDMtbDGiEBaTnijTfbQxbj8=.17f3d5b1-ad76-431f-91a5-b2f95816db7a@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

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

 - Merge branch 'master' into restricted_jni
 - Merge branch 'master' into restricted_jni
 - Address review comments
 - Add note on --illegal-native-access default value in the launcher help
 - Address review comment
 - Refine warning text for JNI method binding
 - Address review comments
   Improve warning for JNI methods, similar to what's described in JEP 472
   Beef up tests
 - Address review comments
 - Fix another typo
 - Fix typo
 - ... and 3 more: https://git.openjdk.org/jdk/compare/f7ea738c...04622748

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/ff51ac6a..04622748

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

  Stats: 51278 lines in 1477 files changed: 28775 ins; 15348 del; 7155 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

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

From kevinw at openjdk.org  Fri Aug 23 11:56:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 23 Aug 2024 11:56:03 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v3]
In-Reply-To: <YJsL1RLJfEGmTJ1A-LgamE7fXKEP48z0rAh_VSDxmeQ=.e156963e-dd92-41aa-8125-220fa0efe639@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <YJsL1RLJfEGmTJ1A-LgamE7fXKEP48z0rAh_VSDxmeQ=.e156963e-dd92-41aa-8125-220fa0efe639@github.com>
Message-ID: <Iue1fFEjJ0ZWKrKDNLMAWZ6ljREl8ZFMxJoZlFGhHm4=.bba0fc59-32e4-4d5a-860d-fce84ab8dbf1@github.com>

On Fri, 23 Aug 2024 08:49:38 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

>> Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
>> 
>> Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.
>> 
>> This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values
>> 
>> Worth noting is that this holds true even if getSystemCpuLoad() is called. 
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.
>
> Joakim Nordstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added implNote and made some re-arrangements

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20546#pullrequestreview-2257051431

From alanb at openjdk.org  Fri Aug 23 12:04:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Aug 2024 12:04:04 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v3]
In-Reply-To: <YJsL1RLJfEGmTJ1A-LgamE7fXKEP48z0rAh_VSDxmeQ=.e156963e-dd92-41aa-8125-220fa0efe639@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <YJsL1RLJfEGmTJ1A-LgamE7fXKEP48z0rAh_VSDxmeQ=.e156963e-dd92-41aa-8125-220fa0efe639@github.com>
Message-ID: <E1scl0orlr3jrgk8BKFOSKlsYJbD76pp-IxnNtihMKw=.ee93c847-90fd-4288-94e6-20f2fd0e24ea@github.com>

On Fri, 23 Aug 2024 08:49:38 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

>> Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
>> 
>> Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.
>> 
>> This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values
>> 
>> Worth noting is that this holds true even if getSystemCpuLoad() is called. 
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.
>
> Joakim Nordstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added implNote and made some re-arrangements

src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java line 154:

> 152:      * affecting the observation period and the result.
> 153:      *
> 154:      * @implNote There is only one observation period for the entire JVM

This version looks good, I'm just wondering about the implNote, is the statement true for all implementations (Linux, macOS, Windows, ...)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20546#discussion_r1728859410

From mcimadamore at openjdk.org  Mon Aug 26 09:20:18 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Aug 2024 09:20:18 GMT
Subject: jmx-dev Integrated: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <3nep7-Z8_feW39di9cTU1O07lgFQD4WmSHQia-UUS7c=.18fb2776-9f8a-47c8-be58-8cd1dd30d45f@github.com>

On Mon, 13 May 2024 10:42:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

This pull request has now been integrated.

Changeset: 20d8f58c
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20d8f58c92009a46dfb91b951e7d87b4cb8e8b41
Stats:     532 lines in 107 files changed: 341 ins; 52 del; 139 mod

8331671: Implement JEP 472: Prepare to Restrict the Use of JNI

Reviewed-by: jpai, prr, ihse, kcr, alanb

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

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

From jnordstrom at openjdk.org  Mon Aug 26 13:54:36 2024
From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Mon, 26 Aug 2024 13:54:36 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v4]
In-Reply-To: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
Message-ID: <T2MZhGn7ZTjyp1u1qmoKt0d6MX3PrY0h3GxjUa_Dshk=.db381567-c069-48d7-b570-627c49bd50e5@github.com>

> Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
> 
> Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.
> 
> This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.
> 
> double cpuLoad1 = getCpuLoad();
> double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values
> 
> Worth noting is that this holds true even if getSystemCpuLoad() is called. 
> 
> double cpuLoad1 = getCpuLoad();
> double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.

Joakim Nordstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Removed implNote

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20546/files
  - new: https://git.openjdk.org/jdk/pull/20546/files/af69aa88..ba7484e4

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

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

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

From jnordstrom at openjdk.org  Mon Aug 26 13:54:37 2024
From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Mon, 26 Aug 2024 13:54:37 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v3]
In-Reply-To: <E1scl0orlr3jrgk8BKFOSKlsYJbD76pp-IxnNtihMKw=.ee93c847-90fd-4288-94e6-20f2fd0e24ea@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <YJsL1RLJfEGmTJ1A-LgamE7fXKEP48z0rAh_VSDxmeQ=.e156963e-dd92-41aa-8125-220fa0efe639@github.com>
 <E1scl0orlr3jrgk8BKFOSKlsYJbD76pp-IxnNtihMKw=.ee93c847-90fd-4288-94e6-20f2fd0e24ea@github.com>
Message-ID: <20FHiJlXh6EuhjMJYSv6cprHkjnHDRX5kDiOnssxx_c=.3a14de4f-0167-4f47-8958-fc292c5a40aa@github.com>

On Fri, 23 Aug 2024 12:01:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joakim Nordstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added implNote and made some re-arrangements
>
> src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java line 154:
> 
>> 152:      * affecting the observation period and the result.
>> 153:      *
>> 154:      * @implNote There is only one observation period for the entire JVM
> 
> This version looks good, I'm just wondering about the implNote, is the statement true for all implementations (Linux, macOS, Windows, ...)?

Reviewing the current implementation this seems to be the case. 

The `@implNote` was more meant as an explanation to why the result could be affected by other callers. Since the `@apiNote` also states that the "observation period and result" can be affected, I think its an unnecessary implementation note to have.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20546#discussion_r1731275288

From alanb at openjdk.org  Mon Aug 26 13:54:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Aug 2024 13:54:37 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v3]
In-Reply-To: <20FHiJlXh6EuhjMJYSv6cprHkjnHDRX5kDiOnssxx_c=.3a14de4f-0167-4f47-8958-fc292c5a40aa@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <YJsL1RLJfEGmTJ1A-LgamE7fXKEP48z0rAh_VSDxmeQ=.e156963e-dd92-41aa-8125-220fa0efe639@github.com>
 <E1scl0orlr3jrgk8BKFOSKlsYJbD76pp-IxnNtihMKw=.ee93c847-90fd-4288-94e6-20f2fd0e24ea@github.com>
 <20FHiJlXh6EuhjMJYSv6cprHkjnHDRX5kDiOnssxx_c=.3a14de4f-0167-4f47-8958-fc292c5a40aa@github.com>
Message-ID: <YStI5SsadOs9ZxVsIEWYlFoew63rS4MC3CwhmiGDMwo=.ace1a44a-fada-45c1-be33-17499d58551e@github.com>

On Mon, 26 Aug 2024 13:46:41 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

>> src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java line 154:
>> 
>>> 152:      * affecting the observation period and the result.
>>> 153:      *
>>> 154:      * @implNote There is only one observation period for the entire JVM
>> 
>> This version looks good, I'm just wondering about the implNote, is the statement true for all implementations (Linux, macOS, Windows, ...)?
>
> Reviewing the current implementation this seems to be the case. 
> 
> The `@implNote` was more meant as an explanation to why the result could be affected by other callers. Since the `@apiNote` also states that the "observation period and result" can be affected, I think its an unnecessary implementation note to have.

Okay, if this is the case for all implementations then it would be okay to use "In the JDK implementation, there is only one ...".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20546#discussion_r1731281656

From jnordstrom at openjdk.org  Mon Aug 26 14:00:08 2024
From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Mon, 26 Aug 2024 14:00:08 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v3]
In-Reply-To: <YStI5SsadOs9ZxVsIEWYlFoew63rS4MC3CwhmiGDMwo=.ace1a44a-fada-45c1-be33-17499d58551e@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <YJsL1RLJfEGmTJ1A-LgamE7fXKEP48z0rAh_VSDxmeQ=.e156963e-dd92-41aa-8125-220fa0efe639@github.com>
 <E1scl0orlr3jrgk8BKFOSKlsYJbD76pp-IxnNtihMKw=.ee93c847-90fd-4288-94e6-20f2fd0e24ea@github.com>
 <20FHiJlXh6EuhjMJYSv6cprHkjnHDRX5kDiOnssxx_c=.3a14de4f-0167-4f47-8958-fc292c5a40aa@github.com>
 <YStI5SsadOs9ZxVsIEWYlFoew63rS4MC3CwhmiGDMwo=.ace1a44a-fada-45c1-be33-17499d58551e@github.com>
Message-ID: <hnbSJmvFpWKvECl-P9y9vD9mp12v1vAJYz8CfGYOQ0M=.f2ccfd2c-382a-4f09-b935-ee51d072fd58@github.com>

On Mon, 26 Aug 2024 13:51:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Reviewing the current implementation this seems to be the case. 
>> 
>> The `@implNote` was more meant as an explanation to why the result could be affected by other callers. Since the `@apiNote` also states that the "observation period and result" can be affected, I think its an unnecessary implementation note to have.
>
> Okay, if this is the case for all implementations then it would be okay to use "In the JDK implementation, there is only one ...".

Then again, I don't know the purpose the comment serves. 

For Windows, the observation period is at least 500 ticks. There is however still only one observation period, meaning any caller using this method will change that observation period.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20546#discussion_r1731290003

From alanb at openjdk.org  Mon Aug 26 17:40:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Aug 2024 17:40:11 GMT
Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v4]
In-Reply-To: <T2MZhGn7ZTjyp1u1qmoKt0d6MX3PrY0h3GxjUa_Dshk=.db381567-c069-48d7-b570-627c49bd50e5@github.com>
References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com>
 <T2MZhGn7ZTjyp1u1qmoKt0d6MX3PrY0h3GxjUa_Dshk=.db381567-c069-48d7-b570-627c49bd50e5@github.com>
Message-ID: <87MJ3tz1WCBoeNaD0XVRGc62eikSG8V3zhWzTmABurs=.305b9ac2-5e32-4cf5-abdf-ff0c48e5f77a@github.com>

On Mon, 26 Aug 2024 13:54:36 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

>> Can I get a review of this documentation update to clarify the usage of GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
>> 
>> Calling either of these methods in quick succession can lead to unrepresentative results due to too few data points.
>> 
>> This behavior is easy to reproduce on at least Linux (Windows implementation enforces a 500 ticks duration); when calling GetCpuLoad repeatedly CPU load values of either 0, 0.5, or 1 will be returned.
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getCpuLoad();   // not enough ticks has passed to give representative values
>> 
>> Worth noting is that this holds true even if getSystemCpuLoad() is called. 
>> 
>> double cpuLoad1 = getCpuLoad();
>> double cpuLoad2 = getSystemCpuLoad();   // not enough ticks has passed to give representative values, since getSystemCpuLoad effectively calls getCpuLoad.
>
> Joakim Nordstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed implNote

I think where you've ended up is okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20546#pullrequestreview-2261242128