From kevinw at openjdk.org Mon Sep 2 16:00:29 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 2 Sep 2024 16:00:29 GMT Subject: jmx-dev RFR: 8338891: HotSpotDiagnosticsMXBean missing @since tag Message-ID: Trivial "since" tag addition in javadoc: since 1.6 ------------- Commit messages: - 8338891: HotSpotDiagnosticsMXBean missing @since tag Changes: https://git.openjdk.org/jdk/pull/20823/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20823&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338891 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20823.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20823/head:pull/20823 PR: https://git.openjdk.org/jdk/pull/20823 From alanb at openjdk.org Mon Sep 2 16:00:29 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 2 Sep 2024 16:00:29 GMT Subject: jmx-dev RFR: 8338891: HotSpotDiagnosticsMXBean missing @since tag In-Reply-To: References: Message-ID: <3FAP6wgfCMJZW9xHlTZR-y1h7R-8x4FIYU5JGujQtB8=.dbc19375-e56f-47ec-8f03-fa655bdc72de@github.com> On Mon, 2 Sep 2024 15:52:27 GMT, Kevin Walls wrote: > Trivial "since" tag addition in javadoc: since 1.6 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20823#pullrequestreview-2275934152 From kevinw at openjdk.org Tue Sep 3 07:58:25 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 3 Sep 2024 07:58:25 GMT Subject: jmx-dev RFR: 8338891: HotSpotDiagnosticsMXBean missing @since tag In-Reply-To: References: Message-ID: <4CG2LZ01BXLyqcY9XQUk3pntikHd7Nn4G2S2haqB6cc=.ee0afb6c-451a-4424-9389-41368d5b3397@github.com> On Mon, 2 Sep 2024 15:52:27 GMT, Kevin Walls wrote: > Trivial "since" tag addition in javadoc: since 1.6 Thanks Alan! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20823#issuecomment-2325836707 From kevinw at openjdk.org Tue Sep 3 07:58:25 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 3 Sep 2024 07:58:25 GMT Subject: jmx-dev Integrated: 8338891: HotSpotDiagnosticsMXBean missing @since tag In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 15:52:27 GMT, Kevin Walls wrote: > Trivial "since" tag addition in javadoc: since 1.6 This pull request has now been integrated. Changeset: 288fa60e Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/288fa60ebee445bb2835f096d144b9c6dea98df6 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8338891: HotSpotDiagnosticsMXBean missing @since tag Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/20823 From cjplummer at openjdk.org Tue Sep 3 20:13:22 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 3 Sep 2024 20:13:22 GMT Subject: jmx-dev RFR: 8338891: HotSpotDiagnosticsMXBean missing @since tag In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 15:52:27 GMT, Kevin Walls wrote: > Trivial "since" tag addition in javadoc: since 1.6 src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 51: > 49: * @see java.lang.management.ManagementFactory#getPlatformMXBeans(Class) > 50: * > 51: * @since 1.6 Do we need to update the copyright for this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20823#discussion_r1742628119 From kevinw at openjdk.org Thu Sep 5 13:22:19 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 5 Sep 2024 13:22:19 GMT Subject: jmx-dev RFR: 8334165: Remove serialVersionUID compatibility logic from JMX Message-ID: Remove very very old serialization compatibility logic from JMX. This relates to keeping the JDK's JMX implementation compatible with JMX versions from when JMX was a separate component, before being integrated into JDK 5. It should all be removed. ------------- Commit messages: - whitespace - Remove additional jmx.serial.form reference in private javadoc - Remove SuppressWarmnings for SVUID not constant - Remove test - 8334165: remove serialVersionUID compatibility logic from JMX Changes: https://git.openjdk.org/jdk/pull/20856/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20856&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334165 Stats: 1952 lines in 21 files changed: 2 ins; 1785 del; 165 mod Patch: https://git.openjdk.org/jdk/pull/20856.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20856/head:pull/20856 PR: https://git.openjdk.org/jdk/pull/20856 From dfuchs at openjdk.org Thu Sep 5 14:59:50 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 5 Sep 2024 14:59:50 GMT Subject: jmx-dev RFR: 8334165: Remove serialVersionUID compatibility logic from JMX In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 16:27:51 GMT, Kevin Walls wrote: > Remove very very old serialization compatibility logic from JMX. > > This relates to keeping the JDK's JMX implementation compatible with JMX versions from when JMX was a separate component, before being integrated into JDK 5. It should all be removed. Wow. I hadn't realized so many classes were impacted. I thought there was just a few! Look good in general. It could be good to write a test that sets the property with 1.0 and 1.1, and that verifies that something (e.g. an ObjectName?) serialized with property=1.0 can be deserialized with property=1.1, and conversely. That would validate that setting the property no longer has any effect. ------------- PR Review: https://git.openjdk.org/jdk/pull/20856#pullrequestreview-2283335277 From kevinw at openjdk.org Thu Sep 5 17:03:37 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 5 Sep 2024 17:03:37 GMT Subject: jmx-dev RFR: 8334165: Remove serialVersionUID compatibility logic from JMX [v2] In-Reply-To: References:

Message-ID: <4LNZv3--wA-vDzmxbsEqetGraugmVpIEvEghB5o4vnM=.bfe74295-b451-47af-884a-07d73096c9c6@github.com> On Thu, 5 Sep 2024 14:57:16 GMT, Daniel Fuchs wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> Test > > Wow. I hadn't realized so many classes were impacted. I thought there was just a few! > > Look good in general. It could be good to write a test that sets the property with 1.0 and 1.1, and that verifies that something (e.g. an ObjectName?) serialized with property=1.0 can be deserialized with property=1.1, and conversely. > > That would validate that setting the property no longer has any effect. Thanks Daniel @dfuch , we can use a version of what we had before, there was a simple check on ObjectName fields. I added it, will fail in a JDK that respects jmx.serial.version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20856#issuecomment-2332225753 From kevinw at openjdk.org Thu Sep 5 17:03:37 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 5 Sep 2024 17:03:37 GMT Subject: jmx-dev RFR: 8334165: Remove serialVersionUID compatibility logic from JMX [v2] In-Reply-To: References: Message-ID: > Remove very very old serialization compatibility logic from JMX. > > This relates to keeping the JDK's JMX implementation compatible with JMX versions from when JMX was a separate component, before being integrated into JDK 5. It should all be removed. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20856/files - new: https://git.openjdk.org/jdk/pull/20856/files/b55de974..ce8e89c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20856&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20856&range=00-01 Stats: 49 lines in 1 file changed: 49 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20856.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20856/head:pull/20856 PR: https://git.openjdk.org/jdk/pull/20856 From dfuchs at openjdk.org Fri Sep 6 12:45:52 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 6 Sep 2024 12:45:52 GMT Subject: jmx-dev RFR: 8334165: Remove serialVersionUID compatibility logic from JMX [v2] In-Reply-To: References:

Message-ID: <4YHbwwt1OcTA8NBeaOf8KvIFsJxXIwRuVtclETfhUVk=.32b0ca31-20e2-4b02-bca5-871e44fc8c4a@github.com> On Thu, 5 Sep 2024 17:03:37 GMT, Kevin Walls wrote: >> Remove very very old serialization compatibility logic from JMX. >> >> This relates to keeping the JDK's JMX implementation compatible with JMX versions from when JMX was a separate component, before being integrated into JDK 5. It should all be removed. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Test LGTM - might be good to have an other pait of eyes looking at it before integrating... ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20856#pullrequestreview-2286180154 From kevinw at openjdk.org Tue Sep 10 13:06:25 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 10 Sep 2024 13:06:25 GMT Subject: jmx-dev RFR: 8334165: Remove serialVersionUID compatibility logic from JMX [v3] In-Reply-To: References: Message-ID: > Remove very very old serialization compatibility logic from JMX. > > This relates to keeping the JDK's JMX implementation compatible with JMX versions from when JMX was a separate component, before being integrated into JDK 5. It should all be removed. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Remove a list level in Javadoc. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20856/files - new: https://git.openjdk.org/jdk/pull/20856/files/ce8e89c8..df5b0f4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20856&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20856&range=01-02 Stats: 52 lines in 1 file changed: 6 ins; 16 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/20856.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20856/head:pull/20856 PR: https://git.openjdk.org/jdk/pull/20856 From dfuchs at openjdk.org Tue Sep 10 13:14:06 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 10 Sep 2024 13:14:06 GMT Subject: jmx-dev RFR: 8334165: Remove serialVersionUID compatibility logic from JMX [v3] In-Reply-To: References:

Message-ID: On Tue, 10 Sep 2024 13:06:25 GMT, Kevin Walls wrote: >> Remove very very old serialization compatibility logic from JMX. >> >> This relates to keeping the JDK's JMX implementation compatible with JMX versions from when JMX was a separate component, before being integrated into JDK 5. It should all be removed. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove a list level in Javadoc. Changes requested by dfuchs (Reviewer). src/java.management/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java line 104: > 102: > 103: private static final long serialVersionUID = -7445681389570207141L; > 104: private static final ObjectStreamField[] serialPersistentFields = Same here: Suggestion: /** * @serialField notificationDescriptor Descriptor The descriptor * containing the appropriate metadata for this instance */ private static final ObjectStreamField[] serialPersistentFields = ------------- PR Review: https://git.openjdk.org/jdk/pull/20856#pullrequestreview-2292546453 PR Review Comment: https://git.openjdk.org/jdk/pull/20856#discussion_r1751983528 From jnordstrom at openjdk.org Tue Sep 10 13:43:09 2024 From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=) Date: Tue, 10 Sep 2024 13:43:09 GMT Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v4] In-Reply-To: References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com> Message-ID: On Mon, 26 Aug 2024 13:54:36 GMT, Joakim Nordstr?m 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 Thank you all for review and comments! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20546#issuecomment-2340821488 From duke at openjdk.org Tue Sep 10 13:43:09 2024 From: duke at openjdk.org (duke) Date: Tue, 10 Sep 2024 13:43:09 GMT Subject: jmx-dev RFR: 8335625: Update Javadoc for GetCpuLoad [v4] In-Reply-To: References: <_uAx1BE7vqiATiCEtPoBlceAC5GlGig3pZLxu-BJJUI=.fa4432b9-59ca-486e-85c7-2aa2f8d9e8d6@github.com> Message-ID: On Mon, 26 Aug 2024 13:54:36 GMT, Joakim Nordstr?m 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 @jaokim Your change (at version ba7484e4d220c7e728e33f8c3f4490c555effdf7) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20546#issuecomment-2340827450 From kevinw at openjdk.org Tue Sep 10 13:47:47 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 10 Sep 2024 13:47:47 GMT Subject: jmx-dev RFR: 8334165: Remove serialVersionUID compatibility logic from JMX [v4] In-Reply-To: References: Message-ID: > Remove very very old serialization compatibility logic from JMX. > > This relates to keeping the JDK's JMX implementation compatible with JMX versions from when JMX was a separate component, before being integrated into JDK 5. It should all be removed. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Replace the missing serialField comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20856/files - new: https://git.openjdk.org/jdk/pull/20856/files/df5b0f4c..5c44b1d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20856&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20856&range=02-03 Stats: 14 lines in 4 files changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20856.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20856/head:pull/20856 PR: https://git.openjdk.org/jdk/pull/20856 From kevinw at openjdk.org Tue Sep 10 13:47:47 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 10 Sep 2024 13:47:47 GMT Subject: jmx-dev RFR: 8334165: Remove serialVersionUID compatibility logic from JMX [v3] In-Reply-To: References:

Message-ID: On Tue, 10 Sep 2024 13:47:47 GMT, Kevin Walls wrote: >> Remove very very old serialization compatibility logic from JMX. >> >> This relates to keeping the JDK's JMX implementation compatible with JMX versions from when JMX was a separate component, before being integrated into JDK 5. It should all be removed. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Replace the missing serialField comments Thanks Daniel. Additional testing looks good. Will integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20856#issuecomment-2345610859 From kevinw at openjdk.org Thu Sep 12 08:34:15 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 12 Sep 2024 08:34:15 GMT Subject: jmx-dev Integrated: 8334165: Remove serialVersionUID compatibility logic from JMX In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 16:27:51 GMT, Kevin Walls wrote: > Remove very very old serialization compatibility logic from JMX. > > This relates to keeping the JDK's JMX implementation compatible with JMX versions from when JMX was a separate component, before being integrated into JDK 5. It should all be removed. This pull request has now been integrated. Changeset: 3c40afa5 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/3c40afa59c93860150960d478a9d2ffe33d4ce32 Stats: 2050 lines in 22 files changed: 57 ins; 1787 del; 206 mod 8334165: Remove serialVersionUID compatibility logic from JMX Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/20856 From kevinw at openjdk.org Fri Sep 13 09:55:12 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 13 Sep 2024 09:55:12 GMT Subject: jmx-dev RFR: 8310525: DynamicLauncher for JDP test needs to try harder to find a free port Message-ID: JDP tests only make 3 attempts to find a free port, using getFreePort(). We know getFreePort() is racy and you need to make sure the port really is fee when trying to use it. Make 10 attempts. Leave the logic unchanged. Also fix a typo in another test. ------------- Commit messages: - 8310525: DynamicLauncher for JDP test needs to try harder to find a free port Changes: https://git.openjdk.org/jdk/pull/20991/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20991&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310525 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20991/head:pull/20991 PR: https://git.openjdk.org/jdk/pull/20991 From lmesnik at openjdk.org Mon Sep 16 15:15:06 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 16 Sep 2024 15:15:06 GMT Subject: jmx-dev RFR: 8310525: DynamicLauncher for JDP test needs to try harder to find a free port In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 09:47:07 GMT, Kevin Walls wrote: > JDP tests only make 3 attempts to find a free port, using getFreePort(). > We know getFreePort() is racy and you need to make sure the port really is fee when trying to use it. > > Make 10 attempts. Leave the logic unchanged. Also fix a typo in another test. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20991#pullrequestreview-2306969278 From cjplummer at openjdk.org Mon Sep 16 16:16:06 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 16 Sep 2024 16:16:06 GMT Subject: jmx-dev RFR: 8310525: DynamicLauncher for JDP test needs to try harder to find a free port In-Reply-To: References: Message-ID: <_KfLa3dDD0negQak5Ax2wOjob2-7vPHXe4x8CkKhezI=.7d721121-4ea6-4d4c-90b4-4bbc6b4fdaf5@github.com> On Fri, 13 Sep 2024 09:47:07 GMT, Kevin Walls wrote: > JDP tests only make 3 attempts to find a free port, using getFreePort(). > We know getFreePort() is racy and you need to make sure the port really is fee when trying to use it. > > Make 10 attempts. Leave the logic unchanged. Also fix a typo in another test. Bumping the retry count from 3 to 10 seems a bit dubious. Do we really lose out on a race 3 times in a row? It seems like there might be something else going on. However, this change is harmless so I guess it's worth trying. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20991#pullrequestreview-2307118950 From kevinw at openjdk.org Mon Sep 16 16:50:04 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 16 Sep 2024 16:50:04 GMT Subject: jmx-dev RFR: 8310525: DynamicLauncher for JDP test needs to try harder to find a free port In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 09:47:07 GMT, Kevin Walls wrote: > JDP tests only make 3 attempts to find a free port, using getFreePort(). > We know getFreePort() is racy and you need to make sure the port really is fee when trying to use it. > > Make 10 attempts. Leave the logic unchanged. Also fix a typo in another test. Thanks Leonid and Chris, Yes we really do see 3 attempts, on different port numbers, fail with java.net.BindException: Address already in use Let's see if 10 is enough! 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20991#issuecomment-2353425950 From kevinw at openjdk.org Mon Sep 16 18:27:09 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 16 Sep 2024 18:27:09 GMT Subject: jmx-dev Integrated: 8310525: DynamicLauncher for JDP test needs to try harder to find a free port In-Reply-To: References: Message-ID: <74GyzndWgkB4JVsY5OsUHy2RnpgMYze-mNIaRlegYys=.9ced9ba3-d0b4-446b-9abb-7081e6523ea8@github.com> On Fri, 13 Sep 2024 09:47:07 GMT, Kevin Walls wrote: > JDP tests only make 3 attempts to find a free port, using getFreePort(). > We know getFreePort() is racy and you need to make sure the port really is fee when trying to use it. > > Make 10 attempts. Leave the logic unchanged. Also fix a typo in another test. This pull request has now been integrated. Changeset: 59407faf Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/59407faf7b6861d142dbc3700a6fa9615567a275 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod 8310525: DynamicLauncher for JDP test needs to try harder to find a free port Reviewed-by: lmesnik, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/20991 From kevinw at openjdk.org Wed Sep 18 10:10:16 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 18 Sep 2024 10:10:16 GMT Subject: jmx-dev RFR: 8338603: DiagnosticCommandMBean operations should standardize types for parameters Message-ID: DiagnosticCommandImpl should only publish parameter types in a known standard set, and use "STRING" on anything else. e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but the MBean parameter info should contain "STRING". ------------- Commit messages: - Test update - 8338603: DiagnosticCommandMBean operations should standardize types for parameters. Changes: https://git.openjdk.org/jdk/pull/21040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21040&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338603 Stats: 57 lines in 2 files changed: 49 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/21040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21040/head:pull/21040 PR: https://git.openjdk.org/jdk/pull/21040 From kevinw at openjdk.org Wed Sep 18 10:10:16 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 18 Sep 2024 10:10:16 GMT Subject: jmx-dev RFR: 8338603: DiagnosticCommandMBean operations should standardize types for parameters In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 14:10:07 GMT, Kevin Walls wrote: > DiagnosticCommandImpl should only publish parameter types in a known standard set, and use "STRING" on anything else. > e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but the MBean parameter info should contain "STRING". DiagnosticCommandMBean provides JMX/MBean access to DiagnosticCommands, aka jcmds, as operations. https://docs.oracle.com/en/java/javase/22/docs/api/jdk.management/com/sun/management/DiagnosticCommandMBean.html The range of types for operation parameters is not well specified. In "dcmd.arg.type" it is: "the name of a type recognized by the diagnostic command parser. These types are not Java types and are implementation dependent." We never clarify the range of type names an application can see via the MBean. JMC for example has a historical connection, so it just knows the implementation-specific parameter types to expect. I suggested in a jcmd change that we add a FILE parameter type, it is informative for humans and can have specific meaning internally in addition to being a String. However we find JMC does not recognise it and does not permit editing that operation parameter. It wasn't clear to me at the time that these jcmd/DCmd parameter type names were consumed by other software (i.e. not just appearing in the help, for humans). Standardising or at least ensuring the parameter type list is stable, is needed. No need to change the documentation at this stage, this can be still be implementation dependent. We can't standardise on Java or OpenType names or applications such as JMC will break significantly. But we can standardise on the core list of parameter types that we have: BOOLEAN, STRING and INT are the main types. NANOTIME tells the user they can type "6s" or "10m" and be understood (JFR commands use this) "MEMORY SIZE" tells the user they can type "32m" and be understood. (Compiler.memory and JFR commands use this) "STRING SET" is an array of Strings. JMC does handle it (Only JFR.start uses this. Maybe it doesn't need it, but separate issue...) (JULONG had been added, but was not handled by apps e.g. JMC, and replacement with INT is in progress separately, JDK-8340113.) If a DiagnosticCommand parameter has a type which is outside the standard list, it should publish it via the MBean Operation with a dcmd.arg.type of STRING to avoid confusing applications. An existing test (DcmdMBeanTest.java) finds dcmds and shows parameters, e.g. dcmd.arg.type=STRING This test can verify parameter types observed via the MBean are of the known published set. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21040#issuecomment-2358039865