From hirt at openjdk.org Thu Feb 1 01:27:15 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 1 Feb 2024 01:27:15 GMT Subject: RFR: 8172: Update to release splash Message-ID: Really no time to do any major rework of the splash. If anyone has ideas, I'm all eyes. ;) ------------- Commit messages: - 8172: Update to release splash Changes: https://git.openjdk.org/jmc/pull/549/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=549&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8172 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/549.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/549/head:pull/549 PR: https://git.openjdk.org/jmc/pull/549 From marcus at hirt.se Thu Feb 1 01:44:32 2024 From: marcus at hirt.se (Marcus Hirt) Date: Thu, 1 Feb 2024 02:44:32 +0100 Subject: CFV: New jmc Committer: Brice Dutheil Message-ID: <083101da54b0$344befa0$9ce3cee0$@hirt.se> I hereby nominate Brice Dutheil to jmc Committer. Brice has been contributing to wide range of JMC issues over the past years, the largest contribution being providing an alternative (Java based) flame graph implementation, solving a long-standing issue where the old flame graph view (java script in the SWT browser component) would not work on Windows. https://github.com/openjdk/jmc/commits/master/?author=bric3 Votes are due by 17:00 CET the 9th of February 2024. Only current jmc Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Kind regards, Marcus [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote From marcus at hirt.se Thu Feb 1 01:55:03 2024 From: marcus at hirt.se (Marcus Hirt) Date: Thu, 1 Feb 2024 02:55:03 +0100 Subject: CFV: New jmc Reviewer: Suchita Chaturvedi Message-ID: <083401da54b1$ac0d7a80$04286f80$@hirt.se> I hereby nominate Suchita Chaturvedi to jmc Reviewer. Suchita has diligently been contributing to jmc over the past few years: https://github.com/openjdk/jmc/pulls?q=is%3Apr+is%3Aclosed+author%3ASuchitainf+label%3Aintegrated Votes are due by 17:00 CET the 9th of February 2024. Only current jmc Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Kind regards, Marcus [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote From vpurnam at openjdk.org Thu Feb 1 03:40:25 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Thu, 1 Feb 2024 03:40:25 GMT Subject: RFR: 8173: 2023-12 target platform needs update to take org.eclipse.ui.themes Message-ID: 2023-12 target platform needs update to take org.eclipse.ui.themes. org.eclipse.ui.themes has been added as part for Dark Mode Fix. Build on master has failed because of this. ------------- Commit messages: - 8173: 2023-12 target platform needs update to take org.eclipse.ui.themes Changes: https://git.openjdk.org/jmc/pull/550/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=550&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8173 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/550.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/550/head:pull/550 PR: https://git.openjdk.org/jmc/pull/550 From virag.purnam at oracle.com Thu Feb 1 05:08:25 2024 From: virag.purnam at oracle.com (Virag Purnam) Date: Thu, 1 Feb 2024 05:08:25 +0000 Subject: CFV: New jmc Committer: Brice Dutheil In-Reply-To: <083101da54b0$344befa0$9ce3cee0$@hirt.se> References: <083101da54b0$344befa0$9ce3cee0$@hirt.se> Message-ID: Yes. Regards, Virag -----Original Message----- From: jmc-dev On Behalf Of Marcus Hirt Sent: Thursday, February 1, 2024 7:15 AM To: jmc-dev at openjdk.java.net Subject: CFV: New jmc Committer: Brice Dutheil I hereby nominate Brice Dutheil to jmc Committer. Brice has been contributing to wide range of JMC issues over the past years, the largest contribution being providing an alternative (Java based) flame graph implementation, solving a long-standing issue where the old flame graph view (java script in the SWT browser component) would not work on Windows. https://github.com/openjdk/jmc/commits/master/?author=bric3 Votes are due by 17:00 CET the 9th of February 2024. Only current jmc Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Kind regards, Marcus [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote From suchita.chaturvedi at oracle.com Thu Feb 1 05:22:49 2024 From: suchita.chaturvedi at oracle.com (Suchita Chaturvedi) Date: Thu, 1 Feb 2024 05:22:49 +0000 Subject: CFV: New jmc Committer: Brice Dutheil In-Reply-To: <083101da54b0$344befa0$9ce3cee0$@hirt.se> References: <083101da54b0$344befa0$9ce3cee0$@hirt.se> Message-ID: Yes. Thanks Suchita Chaturvedi -----Original Message----- From: jmc-dev On Behalf Of Marcus Hirt Sent: 01 February 2024 07:15 To: jmc-dev at openjdk.java.net Subject: CFV: New jmc Committer: Brice Dutheil I hereby nominate Brice Dutheil to jmc Committer. Brice has been contributing to wide range of JMC issues over the past years, the largest contribution being providing an alternative (Java based) flame graph implementation, solving a long-standing issue where the old flame graph view (java script in the SWT browser component) would not work on Windows. https://github.com/openjdk/jmc/commits/master/?author=bric3 Votes are due by 17:00 CET the 9th of February 2024. Only current jmc Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Kind regards, Marcus [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote From jean-philippe.bempel at datadoghq.com Thu Feb 1 06:34:22 2024 From: jean-philippe.bempel at datadoghq.com (Jean-Philippe Bempel) Date: Thu, 1 Feb 2024 07:34:22 +0100 Subject: CFV: New jmc Committer: Brice Dutheil In-Reply-To: <083101da54b0$344befa0$9ce3cee0$@hirt.se> References: <083101da54b0$344befa0$9ce3cee0$@hirt.se> Message-ID: Vote: Yes On Thu, Feb 1, 2024 at 2:44?AM Marcus Hirt wrote: > > I hereby nominate Brice Dutheil to jmc Committer. > > Brice has been contributing to wide range of JMC issues over the past years, the largest contribution being providing an alternative (Java based) flame graph implementation, solving a long-standing issue where the old flame graph view (java script in the SWT browser component) would not work on Windows. > > https://github.com/openjdk/jmc/commits/master/?author=bric3 > > Votes are due by 17:00 CET the 9th of February 2024. > > Only current jmc Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Kind regards, > Marcus > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote > From miro.wengner at gmail.com Thu Feb 1 13:41:54 2024 From: miro.wengner at gmail.com (Miro Wengner) Date: Thu, 1 Feb 2024 14:41:54 +0100 Subject: CFV: New jmc Committer: Brice Dutheil In-Reply-To: References: Message-ID: Vote: Yes ! Regards, Miro Sent from my iPad > On 1. Feb 2024, at 08:48, Jean-Philippe Bempel wrote: > > ?Vote: Yes > >> On Thu, Feb 1, 2024 at 2:44?AM Marcus Hirt wrote: >> >> I hereby nominate Brice Dutheil to jmc Committer. >> >> Brice has been contributing to wide range of JMC issues over the past years, the largest contribution being providing an alternative (Java based) flame graph implementation, solving a long-standing issue where the old flame graph view (java script in the SWT browser component) would not work on Windows. >> >> https://github.com/openjdk/jmc/commits/master/?author=bric3 >> >> Votes are due by 17:00 CET the 9th of February 2024. >> >> Only current jmc Committers [1] are eligible to vote >> on this nomination. Votes must be cast in the open by replying >> to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Kind regards, >> Marcus >> >> [1] https://openjdk.org/census >> [2] https://openjdk.org/projects/#committer-vote >> From aptmac at openjdk.org Thu Feb 1 14:16:10 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 1 Feb 2024 14:16:10 GMT Subject: RFR: 8173: 2023-12 target platform needs update to take org.eclipse.ui.themes In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 03:36:02 GMT, Virag Purnam wrote: > 2023-12 target platform needs update to take org.eclipse.ui.themes. > org.eclipse.ui.themes has been added as part for Dark Mode Fix. Build on master has failed because of this. Marked as reviewed by aptmac (Reviewer). ------------- PR Review: https://git.openjdk.org/jmc/pull/550#pullrequestreview-1856611260 From aptmac at openjdk.org Thu Feb 1 14:18:09 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 1 Feb 2024 14:18:09 GMT Subject: RFR: 8172: Update to release splash In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 01:23:53 GMT, Marcus Hirt wrote: > Really no time to do any major rework of the splash. If anyone has ideas, I'm all eyes. ;) Marked as reviewed by aptmac (Reviewer). ------------- PR Review: https://git.openjdk.org/jmc/pull/549#pullrequestreview-1856617717 From almacdon at redhat.com Thu Feb 1 14:17:34 2024 From: almacdon at redhat.com (Alex Macdonald) Date: Thu, 1 Feb 2024 09:17:34 -0500 Subject: CFV: New jmc Committer: Brice Dutheil In-Reply-To: <083101da54b0$344befa0$9ce3cee0$@hirt.se> References: <083101da54b0$344befa0$9ce3cee0$@hirt.se> Message-ID: Vote: yes On Wed, Jan 31, 2024 at 8:44?PM Marcus Hirt wrote: > > I hereby nominate Brice Dutheil to jmc Committer. > > Brice has been contributing to wide range of JMC issues over the past years, the largest contribution being providing an alternative (Java based) flame graph implementation, solving a long-standing issue where the old flame graph view (java script in the SWT browser component) would not work on Windows. > > https://github.com/openjdk/jmc/commits/master/?author=bric3 > > Votes are due by 17:00 CET the 9th of February 2024. > > Only current jmc Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Kind regards, > Marcus > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote > From almacdon at redhat.com Thu Feb 1 14:19:19 2024 From: almacdon at redhat.com (Alex Macdonald) Date: Thu, 1 Feb 2024 09:19:19 -0500 Subject: CFV: New jmc Reviewer: Suchita Chaturvedi In-Reply-To: <083401da54b1$ac0d7a80$04286f80$@hirt.se> References: <083401da54b1$ac0d7a80$04286f80$@hirt.se> Message-ID: Vote: yes On Wed, Jan 31, 2024 at 8:55?PM Marcus Hirt wrote: > > I hereby nominate Suchita Chaturvedi to jmc Reviewer. > > Suchita has diligently been contributing to jmc over the past few years: > https://github.com/openjdk/jmc/pulls?q=is%3Apr+is%3Aclosed+author%3ASuchitainf+label%3Aintegrated > > Votes are due by 17:00 CET the 9th of February 2024. > > Only current jmc Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Kind regards, > Marcus > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > > From vpurnam at openjdk.org Thu Feb 1 18:50:07 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Thu, 1 Feb 2024 18:50:07 GMT Subject: Integrated: 8173: 2023-12 target platform needs update to take org.eclipse.ui.themes In-Reply-To: References: Message-ID: <8lwYRANmTQGdiHv4nxNLi_6JfQbt8j3bRr0UbA5YU6I=.d0b3ef0a-0d46-4081-90fe-bfdea9ff8246@github.com> On Thu, 1 Feb 2024 03:36:02 GMT, Virag Purnam wrote: > 2023-12 target platform needs update to take org.eclipse.ui.themes. > org.eclipse.ui.themes has been added as part for Dark Mode Fix. Build on master has failed because of this. This pull request has now been integrated. Changeset: ea0b1133 Author: Virag Purnam URL: https://git.openjdk.org/jmc/commit/ea0b1133ebe0c87e2a31ccb1de6a1354408f4350 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8173: 2023-12 target platform needs update to take org.eclipse.ui.themes Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/550 From marcus.hirt at datadoghq.com Thu Feb 1 18:52:03 2024 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Thu, 1 Feb 2024 19:52:03 +0100 Subject: CFV: New jmc Committer: Brice Dutheil In-Reply-To: <083101da54b0$344befa0$9ce3cee0$@hirt.se> References: <083101da54b0$344befa0$9ce3cee0$@hirt.se> Message-ID: Vote: yes /M On Thu, Feb 1, 2024 at 2:44?AM Marcus Hirt wrote: > > I hereby nominate Brice Dutheil to jmc Committer. > > Brice has been contributing to wide range of JMC issues over the past years, the largest contribution being providing an alternative (Java based) flame graph implementation, solving a long-standing issue where the old flame graph view (java script in the SWT browser component) would not work on Windows. > > https://github.com/openjdk/jmc/commits/master/?author=bric3 > > Votes are due by 17:00 CET the 9th of February 2024. > > Only current jmc Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Kind regards, > Marcus > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote > From marcus.hirt at datadoghq.com Thu Feb 1 19:04:39 2024 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Thu, 1 Feb 2024 20:04:39 +0100 Subject: CFV: New jmc Reviewer: Suchita Chaturvedi In-Reply-To: <083401da54b1$ac0d7a80$04286f80$@hirt.se> References: <083401da54b1$ac0d7a80$04286f80$@hirt.se> Message-ID: Vote: yes /M On Thu, Feb 1, 2024 at 2:55?AM Marcus Hirt wrote: > > I hereby nominate Suchita Chaturvedi to jmc Reviewer. > > Suchita has diligently been contributing to jmc over the past few years: > https://github.com/openjdk/jmc/pulls?q=is%3Apr+is%3Aclosed+author%3ASuchitainf+label%3Aintegrated > > Votes are due by 17:00 CET the 9th of February 2024. > > Only current jmc Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Kind regards, > Marcus > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > > From hirt at openjdk.org Thu Feb 1 19:42:09 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 1 Feb 2024 19:42:09 GMT Subject: RFR: 8172: Update to release splash In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 01:23:53 GMT, Marcus Hirt wrote: > Really no time to do any major rework of the splash. If anyone has ideas, I'm all eyes. ;) The errors in the pre-submit tests are unrelated. Integrating. ------------- PR Comment: https://git.openjdk.org/jmc/pull/549#issuecomment-1922092588 From hirt at openjdk.org Thu Feb 1 19:42:09 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 1 Feb 2024 19:42:09 GMT Subject: Integrated: 8172: Update to release splash In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 01:23:53 GMT, Marcus Hirt wrote: > Really no time to do any major rework of the splash. If anyone has ideas, I'm all eyes. ;) This pull request has now been integrated. Changeset: 00e1724c Author: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/00e1724c98c95bfa2c3d39478d80447a0902b102 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod 8172: Update to release splash Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/549 From patrick at reini.net Fri Feb 2 10:50:49 2024 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 2 Feb 2024 11:50:49 +0100 Subject: CFV: New jmc Committer: Brice Dutheil In-Reply-To: <083101da54b0$344befa0$9ce3cee0$@hirt.se> References: <083101da54b0$344befa0$9ce3cee0$@hirt.se> Message-ID: <8e84a5cc-e6a4-45bf-87f1-a2fdc5135abc@reini.net> Vote: yes Cheers, Patrick Am 01.02.24 um 02:44 schrieb Marcus Hirt: > I hereby nominate Brice Dutheil to jmc Committer. > > Brice has been contributing to wide range of JMC issues over the past years, the largest contribution being providing an alternative (Java based) flame graph implementation, solving a long-standing issue where the old flame graph view (java script in the SWT browser component) would not work on Windows. > > https://github.com/openjdk/jmc/commits/master/?author=bric3 > > Votes are due by 17:00 CET the 9th of February 2024. > > Only current jmc Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Kind regards, > Marcus > > [1]https://openjdk.org/census > [2]https://openjdk.org/projects/#committer-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: From duke at openjdk.org Sat Feb 3 08:49:06 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Sat, 3 Feb 2024 08:49:06 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v5] In-Reply-To: References: Message-ID: On Fri, 26 Jan 2024 13:40:58 GMT, Martin Skarsaune wrote: >> Replaces parts of https://github.com/openjdk/jmc/pull/332 > > Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: > > JMC-7455: Clean up some test comments application/org.openjdk.jmc.jolokia/plugin.xml line 38: > 36: > 37: 38: point="org.openjdk.jmc.rjmx.descriptorProvider"> So, this extension is what used to work to support jolokia as a protocol in 8.3.0, but it fails (at least when connecting to a discovered VM from the browser): `org.openjdk.jmc.rjmx.common.ConnectionException caused by java.net.MalformedURLException: Unsupported protocol: jolokia at org.openjdk.jmc.rjmx.common.internal.RJMXConnection.connect(RJMXConnection.java:364) at org.openjdk.jmc.rjmx.internal.ServerHandle.doConnect(ServerHandle.java:121) at org.openjdk.jmc.rjmx.internal.ServerHandle.connect(ServerHandle.java:111) at org.openjdk.jmc.console.ui.editor.internal.ConsoleEditor$ConnectJob.run(ConsoleEditor.java:99) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Caused by: java.net.MalformedURLException: Unsupported protocol: jolokia at java.management/javax.management.remote.JMXConnectorFactory.newJMXConnector(JMXConnectorFactory.java:366) at org.openjdk.jmc.rjmx.common.internal.RJMXConnection.connectJmxConnector(RJMXConnection.java:591) at org.openjdk.jmc.rjmx.common.internal.RJMXConnection.establishConnection(RJMXConnection.java:572) at org.openjdk.jmc.rjmx.common.internal.RJMXConnection.connect(RJMXConnection.java:357)` It looks like it relies on `javax.management.remote.JMXConnectorFactory` to connect. There is support in Jolokia for using JMXConnectorFactory directly, however then the jolokia jar has to reside in the same classloader so that the service discovery mechanism picks it up. Furthermore, similar to `org.openjdk.jmc.rjmx` it would be good to use a JMC specific connection implementation, in order to do JMC specific enhancements. I need to debug further ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1477019500 From duke at openjdk.org Sat Feb 3 09:00:16 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Sat, 3 Feb 2024 09:00:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v6] In-Reply-To: References: Message-ID: <0dPvo38QxRl1942nYYCwH9ZIZRr4loAM8mMxYBJQV9o=.b6ee0e26-93d8-4ec6-b758-37ea455af6ab@github.com> > Replaces parts of https://github.com/openjdk/jmc/pull/332 Martin Skarsaune has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge remote-tracking branch 'origin/master' into jolokia-support-only - JMC-7455: Provide env map for discovered jolokia connections - JMC-7455: Clean up some test comments - JMC-7455: Ensure that jolokia version is set - JMC-7455: Fix copy paste and outdated errors in Jolokia plugin manifest - JMC-7455: Fixed whitespace of feature declaration - JMC-7455: Fix copyright notices (change year) in Jolokia plugin - JMC-7455: Fix rjmx imports after rebasing with master - JMC-7455: Add plugin with support for Jolokia connections ------------- Changes: https://git.openjdk.org/jmc/pull/548/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=05 Stats: 1623 lines in 35 files changed: 1614 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jmc/pull/548.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/548/head:pull/548 PR: https://git.openjdk.org/jmc/pull/548 From duke at openjdk.org Sun Feb 4 16:35:06 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Sun, 4 Feb 2024 16:35:06 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v6] In-Reply-To: <0dPvo38QxRl1942nYYCwH9ZIZRr4loAM8mMxYBJQV9o=.b6ee0e26-93d8-4ec6-b758-37ea455af6ab@github.com> References: <0dPvo38QxRl1942nYYCwH9ZIZRr4loAM8mMxYBJQV9o=.b6ee0e26-93d8-4ec6-b758-37ea455af6ab@github.com> Message-ID: On Sat, 3 Feb 2024 09:00:16 GMT, Martin Skarsaune wrote: >> Replaces parts of https://github.com/openjdk/jmc/pull/332 > > Martin Skarsaune has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge remote-tracking branch 'origin/master' into jolokia-support-only > - JMC-7455: Provide env map for discovered jolokia connections > - JMC-7455: Clean up some test comments > - JMC-7455: Ensure that jolokia version is set > - JMC-7455: Fix copy paste and outdated errors in Jolokia plugin manifest > - JMC-7455: Fixed whitespace of feature declaration > - JMC-7455: Fix copyright notices (change year) in Jolokia plugin > - JMC-7455: Fix rjmx imports after rebasing with master > - JMC-7455: Add plugin with support for Jolokia connections Ok, so at least in JMC 7.1.0 and 8.3.0 this use to work by the fact that the plugin uses the extension point for JMX protocol: https://github.com/skarsaune/jmc/blob/e2c2275d05ee2e2215ea2a48b720ef2fef456810/application/org.openjdk.jmc.jolokia/plugin.xml#L43 However this no longer seems to work in 9.0.0 :(?). Does anyone know about particular changes in this area? For instance when trying to connect to a JMC console from the JVM browser I get this: `!ENTRY org.openjdk.jmc.console.ui 4 4 2024-02-04 17:14:27.250 !MESSAGE Could not connect to 127.0.0.1:8778 : Unsupported protocol: jolokia !STACK 0 org.openjdk.jmc.rjmx.common.ConnectionException caused by java.net.MalformedURLException: Unsupported protocol: jolokia at org.openjdk.jmc.rjmx.common.internal.RJMXConnection.connect(RJMXConnection.java:364) at org.openjdk.jmc.rjmx.internal.ServerHandle.doConnect(ServerHandle.java:121) at org.openjdk.jmc.rjmx.internal.ServerHandle.connect(ServerHandle.java:111) at org.openjdk.jmc.console.ui.editor.internal.ConsoleEditor$ConnectJob.run(ConsoleEditor.java:99) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Caused by: java.net.MalformedURLException: Unsupported protocol: jolokia at java.management/javax.management.remote.JMXConnectorFactory.newJMXConnector(JMXConnectorFactory.java:366) at org.openjdk.jmc.rjmx.common.internal.RJMXConnection.connectJmxConnector(RJMXConnection.java:591) at org.openjdk.jmc.rjmx.common.internal.RJMXConnection.establishConnection(RJMXConnection.java:572) at org.openjdk.jmc.rjmx.common.internal.RJMXConnection.connect(RJMXConnection.java:357) ... 4 more ` This appears to use Javas native JMXConnectorFactory directly . This may fail for a number of reasons: 1. Jolokia _does_ support service discovery, but only if the Jolokia library jar is on the classpath/same classsloader. 2. Furthermore this rules out providing a JMC specific connection that could allow us to put in optimizations for JMC. Anyone know more about the setup of connections or how this may have changed recently. ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-1925822198 From duke at openjdk.org Sun Feb 4 16:44:17 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Sun, 4 Feb 2024 16:44:17 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v7] In-Reply-To: References: Message-ID: > Replaces parts of https://github.com/openjdk/jmc/pull/332 Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: JMC-7455: Remove explicit package imports, as they are exported from source packabge ------------- Changes: - all: https://git.openjdk.org/jmc/pull/548/files - new: https://git.openjdk.org/jmc/pull/548/files/e2c2275d..b41db313 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=06 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/548.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/548/head:pull/548 PR: https://git.openjdk.org/jmc/pull/548 From duke at openjdk.org Sun Feb 4 20:26:18 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Sun, 4 Feb 2024 20:26:18 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v8] In-Reply-To: References: Message-ID: > Replaces parts of https://github.com/openjdk/jmc/pull/332 Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: JMC-7455: Include jolokia in latest platform definition ------------- Changes: - all: https://git.openjdk.org/jmc/pull/548/files - new: https://git.openjdk.org/jmc/pull/548/files/b41db313..95f48a9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=07 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=06-07 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/548.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/548/head:pull/548 PR: https://git.openjdk.org/jmc/pull/548 From duke at openjdk.org Sun Feb 4 21:31:06 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Sun, 4 Feb 2024 21:31:06 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v6] In-Reply-To: References: <0dPvo38QxRl1942nYYCwH9ZIZRr4loAM8mMxYBJQV9o=.b6ee0e26-93d8-4ec6-b758-37ea455af6ab@github.com> Message-ID: On Sun, 4 Feb 2024 16:32:19 GMT, Martin Skarsaune wrote: > Ok, so at least in JMC 7.1.0 and 8.3.0 this use to work by the fact that the plugin uses the extension point for JMX protocol: https://github.com/skarsaune/jmc/blob/e2c2275d05ee2e2215ea2a48b720ef2fef456810/application/org.openjdk.jmc.jolokia/plugin.xml#L43 However this no longer seems to work in 9.0.0 :(?). Does anyone know about particular changes in this area? > > For instance when trying to connect to a JMC console from the JVM browser I get this: > > `!ENTRY org.openjdk.jmc.console.ui 4 4 2024-02-04 17:14:27.250 !MESSAGE Could not connect to 127.0.0.1:8778 : Unsupported protocol: jolokia !STACK 0 org.openjdk.jmc.rjmx.common.ConnectionException caused by java.net.MalformedURLException: Unsupported protocol: jolokia at org.openjdk.jmc.rjmx.common.internal.RJMXConnection.connect(RJMXConnection.java:364) at org.openjdk.jmc.rjmx.internal.ServerHandle.doConnect(ServerHandle.java:121) at org.openjdk.jmc.rjmx.internal.ServerHandle.connect(ServerHandle.java:111) at org.openjdk.jmc.console.ui.editor.internal.ConsoleEditor$ConnectJob.run(ConsoleEditor.java:99) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Caused by: java.net.MalformedURLException: Unsupported protocol: jolokia at java.management/javax.management.remote.JMXConnectorFactory.newJMXConnector(JMXConnectorFactory.java:366) at org.openjdk.jmc.rjmx.common.internal.RJMXConnection.connectJmxConnector(RJMXConnection.java:591) at org.openjdk.jmc.rjmx.common.internal.RJ MXConnection.establishConnection(RJMXConnection.java:572) at org.openjdk.jmc.rjmx.common.internal.RJMXConnection.connect(RJMXConnection.java:357) ... 4 more ` > > This appears to use Javas native JMXConnectorFactory directly . This may fail for a number of reasons: > > 1. Jolokia _does_ support service discovery, but only if the Jolokia library jar is on the classpath/same classsloader. > 2. Furthermore this rules out providing a JMC specific connection that could allow us to put in optimizations for JMC. > > Anyone know more about the setup of connections or how this may have changed recently. Hmm, or is `OsgiServicesJmxProviderProxy` supposed to be picked up by `JMXConnectorFactory`, and that in turn will use the protocol providers registered in JMC?. Do you know @aptmac ? ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-1925923700 From duke at openjdk.org Tue Feb 6 08:51:01 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Tue, 6 Feb 2024 08:51:01 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v8] In-Reply-To: References: Message-ID: On Sun, 4 Feb 2024 20:26:18 GMT, Martin Skarsaune wrote: >> Replaces parts of https://github.com/openjdk/jmc/pull/332 > > Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: > > JMC-7455: Include jolokia in latest platform definition Update 2: So https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx.ext/META-INF/services/javax.management.remote.JMXConnectorProvider is not detected by `javax.management.remote.JMXConnectorFactory`' s classloader. I also tried to use environment ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-1929038577 From aptmac at openjdk.org Tue Feb 6 21:08:58 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Tue, 6 Feb 2024 21:08:58 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v8] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 08:48:44 GMT, Martin Skarsaune wrote: > Update 2: So https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx.ext/META-INF/services/javax.management.remote.JMXConnectorProvider is not detected by `javax.management.remote.JMXConnectorFactory`' s classloader. I also tried to use `org.openjdk.jmc.rjmx.common.internal.RJMXConnection` 's classloader, but that no longer works as the `.ext` module is not visible from `rjmx.common` (?). > > ``` > Map envCopy = new HashMap<>(env); > envCopy.put(JMXConnectorFactory.PROTOCOL_PROVIDER_CLASS_LOADER, this.getClass().getClassLoader()); > ``` > > Bottom line seems to me that the JMX protocol extension mechanism no longer works in JMC 9 (?) Hi! What you mentioned about how the `.ext` module is not visible from common is what I think the issue here is. When bringing over the bulk of the rjmx code from jmc/application to jmc/core one of the problems I faced was how to get the Services loaded by the core-side code if they are only visible in jmc/application. For the rjmx services, I came up with an initializer class [[0]](https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/internal/ServiceFactoryInitializer.java#L49) that looks at the `rjmx.service` extension and adds them to a List to be consumed by `ServerHandle` when creating a `ConnectionHandle`. This way the services can be passed from jmc/application into jmc/core through the ConnectionHandle. Unfortunately it looks like I only considered the case of the rjmx.service extension, and not rjmx.ext. I think the `ServiceFactoryInitializer` is probably the best place to start looking to fix this, and making sure it can also handle the other valid extension points. [0] https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/internal/ServiceFactoryInitializer.java#L49 ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-1930749297 From jbachorik at openjdk.org Sat Feb 10 09:58:12 2024 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Sat, 10 Feb 2024 09:58:12 GMT Subject: RFR: 7992: Add API to easily write annotated Java JFR events Message-ID: Yay. Non empty PR body to make jcheck happy. ------------- Commit messages: - Update copyright year - JMC-7992: Add API to easily write annotated Java JFR events Changes: https://git.openjdk.org/jmc/pull/457/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=457&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7992 Stats: 409 lines in 4 files changed: 402 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jmc/pull/457.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/457/head:pull/457 PR: https://git.openjdk.org/jmc/pull/457 From hirt at openjdk.org Sat Feb 10 09:58:12 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Sat, 10 Feb 2024 09:58:12 GMT Subject: RFR: 7992: Add API to easily write annotated Java JFR events In-Reply-To: References: Message-ID: <2hZ4-3eYYdxTUI9QrSW6bZXTbvS7fc_XGsislVEDyVg=.e489d228-4179-40e6-a701-801ab91d8359@github.com> On Wed, 7 Dec 2022 10:05:32 GMT, Jaroslav Bachorik wrote: > Yay. Non empty PR body to make jcheck happy. Hi Jaroslav! This one is still in draft. Want to get it into JMC 9? ------------- PR Comment: https://git.openjdk.org/jmc/pull/457#issuecomment-1875791205 From jbachorik at openjdk.org Sat Feb 10 10:08:11 2024 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Sat, 10 Feb 2024 10:08:11 GMT Subject: RFR: 7992: Add API to easily write annotated Java JFR events [v2] In-Reply-To: References: Message-ID: <0L8i3Vf8yGRf4rdvOpwMndAUsZz4XXLstGv6sGZyiXY=.e7de7476-3105-4214-b00f-ebeeaf7a2d00@github.com> > This PR extends the JFR Writer API with the ability to use the custom JFR event types (eg. classes extending `jdk.jfr.Event`) and register new writer type for them and also directly accept the instances of those types to write them in the recording. Jaroslav Bachorik has updated the pull request incrementally with two additional commits since the last revision: - Add more explanatory comments - Add javadoc for the new public methods ------------- Changes: - all: https://git.openjdk.org/jmc/pull/457/files - new: https://git.openjdk.org/jmc/pull/457/files/eecdda83..e4e6c7cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=457&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=457&range=00-01 Stats: 19 lines in 2 files changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/457.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/457/head:pull/457 PR: https://git.openjdk.org/jmc/pull/457 From duke at openjdk.org Sun Feb 11 19:12:24 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Sun, 11 Feb 2024 19:12:24 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v9] In-Reply-To: References: Message-ID: <4fTzZKYstMzYZiaTl0vXZRO5SiazUSh5ZHw5DXmvITs=.fe144160-8a27-42a2-bbc5-178c4c2aeee6@github.com> > Replaces parts of https://github.com/openjdk/jmc/pull/332 Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: JMC-7455: fix copyrigt notice ------------- Changes: - all: https://git.openjdk.org/jmc/pull/548/files - new: https://git.openjdk.org/jmc/pull/548/files/95f48a9a..a7774a0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=08 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/548.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/548/head:pull/548 PR: https://git.openjdk.org/jmc/pull/548 From aptmac at openjdk.org Mon Feb 12 16:54:23 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Mon, 12 Feb 2024 16:54:23 GMT Subject: RFR: 8174: Check license year script may check files not changed by a PR Message-ID: <8w3BwD4fAfjERjq9cTzKUOIQRF-kAZdQSBbVQA46kx0=.3d0b2322-e9b1-4801-9425-4cb40974e504@github.com> This short PR addresses JMC-8174 [[0]](https://bugs.openjdk.org/browse/JMC-8174), in which the check license year script may fail when checking files not modified by the PR it's running against. The issue is that I originally had `origin/master` as the branch the PR would be checked against, forgetting that these checks are run on our own forks and not openjdk/jmc. As a result, if the PR owner's `origin/master` is out of date, then the check license script may incorrectly error even if the PR is okay against `upstream/master`. To amend this I've added a line that greps the result of `git remote -v` and looks for `upstream`, and if it doesn't exist then it adds a new remote and fetches it. Now we can compare the PR commits against `upstream/master` [0] https://bugs.openjdk.org/browse/JMC-8174 ------------- Commit messages: - 8174: Check license year script may check files not changed by a PR Changes: https://git.openjdk.org/jmc/pull/552/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=552&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8174 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/552.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/552/head:pull/552 PR: https://git.openjdk.org/jmc/pull/552 From aptmac at openjdk.org Mon Feb 12 17:13:12 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Mon, 12 Feb 2024 17:13:12 GMT Subject: RFR: 8174: Check license year script may check files not changed by a PR [v2] In-Reply-To: <8w3BwD4fAfjERjq9cTzKUOIQRF-kAZdQSBbVQA46kx0=.3d0b2322-e9b1-4801-9425-4cb40974e504@github.com> References: <8w3BwD4fAfjERjq9cTzKUOIQRF-kAZdQSBbVQA46kx0=.3d0b2322-e9b1-4801-9425-4cb40974e504@github.com> Message-ID: > This short PR addresses JMC-8174 [[0]](https://bugs.openjdk.org/browse/JMC-8174), in which the check license year script may fail when checking files not modified by the PR it's running against. > > The issue is that I originally had `origin/master` as the branch the PR would be checked against, forgetting that these checks are run on our own forks and not openjdk/jmc. As a result, if the PR owner's `origin/master` is out of date, then the check license script may incorrectly error even if the PR is okay against `upstream/master`. To amend this I've added a line that greps the result of `git remote -v` and looks for `upstream`, and if it doesn't exist then it adds a new remote and fetches it. Now we can compare the PR commits against `upstream/master` > > [0] https://bugs.openjdk.org/browse/JMC-8174 Alex Macdonald 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 one additional commit since the last revision: 8174: Check license year script may check files not changed by a PR ------------- Changes: - all: https://git.openjdk.org/jmc/pull/552/files - new: https://git.openjdk.org/jmc/pull/552/files/283f04db..603ccdc7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=552&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=552&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/552.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/552/head:pull/552 PR: https://git.openjdk.org/jmc/pull/552 From aptmac at openjdk.org Wed Feb 14 16:29:13 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Wed, 14 Feb 2024 16:29:13 GMT Subject: RFR: 8175: Flightrecorder UI-tests are failing Message-ID: This PR addresses JMC-8175 [[0]](https://bugs.openjdk.org/browse/JMC-8175), in which there are three uitests in ControlRecordingsTest that have sporadic failures. The root cause looks to be https://bugs.openjdk.org/browse/JDK-8286740, which affects the jdk.ActiveSetting event in JDK 17. This issue, among other things, can lead to Active Setting events sharing the same timestamp due to the event object being cached (which you can see in my screenshots below). The failing uitests operate by dumping a recording, finding an event that can have it's threshold/enablement/period changed, changing said value, and then verifying the result of the latest timestamp in the Event Settings table in the Recording Page. Because these events in jdk17 can share the same timestamp, we may end up in a situation where the uitest is trying to filter the table based on timestamp and verifying that the enabled setting is true, but there is a false & true for the same timestamp (or a 1s and 5ms in the case of `modifyEventPeriod()`). I've attached two images below, one using jdk17 and one using jdk21. I dumped a recording of the jvm running jmc, enabled the allocation gc event, and then re-dumped the recording. The left jfr page shows the results for the initial recording, and the page on the right for the one with allocation gc enabled. In jdk17 we can see events sharing the same timestamp, and in jdk21 they're unique. Based on Marcus' comment on the issue [[2]](https://bugs.openjdk.org/browse/JMC-8175?focusedId=14648937&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14648937) I've ignored these tests with a comment mentioning they'll require a backport of JDK-8286740 to jdk17. JDK 17 (duplicated timestamps) ![jdk17](https://github.com/openjdk/jmc/assets/10425301/2bd1278b-775b-476b-a801-9ae121ac4529) JDK 21 (expected) ![jdk21](https://github.com/openjdk/jmc/assets/10425301/55b9c47f-225d-4d25-83c2-0d71a7d045a5) [0] https://bugs.openjdk.org/browse/JMC-8175 [1] https://bugs.openjdk.org/browse/JDK-8286740 [2] https://bugs.openjdk.org/browse/JMC-8175?focusedId=14648937&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14648937 ------------- Commit messages: - 8175: Flightrecorder UI-tests are failing Changes: https://git.openjdk.org/jmc/pull/553/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=553&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8175 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/553.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/553/head:pull/553 PR: https://git.openjdk.org/jmc/pull/553 From marcus.hirt at datadoghq.com Wed Feb 14 18:27:57 2024 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Wed, 14 Feb 2024 19:27:57 +0100 Subject: Result: New jmc Committer: Brice Dutheil Message-ID: Voting for Brice Dutheil [1] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Kind regards, Marcus [1] https://mail.openjdk.org/pipermail/jmc-dev/2024-February/005928.html From vpurnam at openjdk.org Mon Feb 19 06:21:59 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Mon, 19 Feb 2024 06:21:59 GMT Subject: RFR: 8175: Flightrecorder UI-tests are failing In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 16:23:49 GMT, Alex Macdonald wrote: > This PR addresses JMC-8175 [[0]](https://bugs.openjdk.org/browse/JMC-8175), in which there are three uitests in ControlRecordingsTest that have sporadic failures. > > The root cause looks to be https://bugs.openjdk.org/browse/JDK-8286740, which affects the jdk.ActiveSetting event in JDK 17. This issue, among other things, can lead to Active Setting events sharing the same timestamp due to the event object being cached (which you can see in my screenshots below). > > The failing uitests operate by dumping a recording, finding an event that can have it's threshold/enablement/period changed, changing said value, and then verifying the result of the latest timestamp in the Event Settings table in the Recording Page. Because these events in jdk17 can share the same timestamp, we may end up in a situation where the uitest is trying to filter the table based on timestamp and verifying that the enabled setting is true, but there is a false & true for the same timestamp (or a 1s and 5ms in the case of `modifyEventPeriod()`). > > I've attached two images below, one using jdk17 and one using jdk21. I dumped a recording of the jvm running jmc, enabled the allocation gc event, and then re-dumped the recording. The left jfr page shows the results for the initial recording, and the page on the right for the one with allocation gc enabled. > > In jdk17 we can see events sharing the same timestamp, and in jdk21 they're unique. Based on Marcus' comment on the issue [[2]](https://bugs.openjdk.org/browse/JMC-8175?focusedId=14648937&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14648937) I've ignored these tests with a comment mentioning they'll require a backport of JDK-8286740 to jdk17. > > JDK 17 (duplicated timestamps) > ![jdk17](https://github.com/openjdk/jmc/assets/10425301/2bd1278b-775b-476b-a801-9ae121ac4529) > > JDK 21 (expected) > ![jdk21](https://github.com/openjdk/jmc/assets/10425301/55b9c47f-225d-4d25-83c2-0d71a7d045a5) > > [0] https://bugs.openjdk.org/browse/JMC-8175 > [1] https://bugs.openjdk.org/browse/JDK-8286740 > [2] https://bugs.openjdk.org/browse/JMC-8175?focusedId=14648937&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14648937 Looks good to me. ------------- Marked as reviewed by vpurnam (Committer). PR Review: https://git.openjdk.org/jmc/pull/553#pullrequestreview-1887631552 From hirt at openjdk.org Mon Feb 19 21:49:58 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Mon, 19 Feb 2024 21:49:58 GMT Subject: RFR: 8175: Flightrecorder UI-tests are failing In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 16:23:49 GMT, Alex Macdonald wrote: > This PR addresses JMC-8175 [[0]](https://bugs.openjdk.org/browse/JMC-8175), in which there are three uitests in ControlRecordingsTest that have sporadic failures. > > The root cause looks to be https://bugs.openjdk.org/browse/JDK-8286740, which affects the jdk.ActiveSetting event in JDK 17. This issue, among other things, can lead to Active Setting events sharing the same timestamp due to the event object being cached (which you can see in my screenshots below). > > The failing uitests operate by dumping a recording, finding an event that can have it's threshold/enablement/period changed, changing said value, and then verifying the result of the latest timestamp in the Event Settings table in the Recording Page. Because these events in jdk17 can share the same timestamp, we may end up in a situation where the uitest is trying to filter the table based on timestamp and verifying that the enabled setting is true, but there is a false & true for the same timestamp (or a 1s and 5ms in the case of `modifyEventPeriod()`). > > I've attached two images below, one using jdk17 and one using jdk21. I dumped a recording of the jvm running jmc, enabled the allocation gc event, and then re-dumped the recording. The left jfr page shows the results for the initial recording, and the page on the right for the one with allocation gc enabled. > > In jdk17 we can see events sharing the same timestamp, and in jdk21 they're unique. Based on Marcus' comment on the issue [[2]](https://bugs.openjdk.org/browse/JMC-8175?focusedId=14648937&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14648937) I've ignored these tests with a comment mentioning they'll require a backport of JDK-8286740 to jdk17. > > JDK 17 (duplicated timestamps) > ![jdk17](https://github.com/openjdk/jmc/assets/10425301/2bd1278b-775b-476b-a801-9ae121ac4529) > > JDK 21 (expected) > ![jdk21](https://github.com/openjdk/jmc/assets/10425301/55b9c47f-225d-4d25-83c2-0d71a7d045a5) > > [0] https://bugs.openjdk.org/browse/JMC-8175 > [1] https://bugs.openjdk.org/browse/JDK-8286740 > [2] https://bugs.openjdk.org/browse/JMC-8175?focusedId=14648937&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14648937 Marked as reviewed by hirt (Lead). ------------- PR Review: https://git.openjdk.org/jmc/pull/553#pullrequestreview-1889206861 From aptmac at openjdk.org Tue Feb 20 14:28:59 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Tue, 20 Feb 2024 14:28:59 GMT Subject: Integrated: 8175: Flightrecorder UI-tests are failing In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 16:23:49 GMT, Alex Macdonald wrote: > This PR addresses JMC-8175 [[0]](https://bugs.openjdk.org/browse/JMC-8175), in which there are three uitests in ControlRecordingsTest that have sporadic failures. > > The root cause looks to be https://bugs.openjdk.org/browse/JDK-8286740, which affects the jdk.ActiveSetting event in JDK 17. This issue, among other things, can lead to Active Setting events sharing the same timestamp due to the event object being cached (which you can see in my screenshots below). > > The failing uitests operate by dumping a recording, finding an event that can have it's threshold/enablement/period changed, changing said value, and then verifying the result of the latest timestamp in the Event Settings table in the Recording Page. Because these events in jdk17 can share the same timestamp, we may end up in a situation where the uitest is trying to filter the table based on timestamp and verifying that the enabled setting is true, but there is a false & true for the same timestamp (or a 1s and 5ms in the case of `modifyEventPeriod()`). > > I've attached two images below, one using jdk17 and one using jdk21. I dumped a recording of the jvm running jmc, enabled the allocation gc event, and then re-dumped the recording. The left jfr page shows the results for the initial recording, and the page on the right for the one with allocation gc enabled. > > In jdk17 we can see events sharing the same timestamp, and in jdk21 they're unique. Based on Marcus' comment on the issue [[2]](https://bugs.openjdk.org/browse/JMC-8175?focusedId=14648937&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14648937) I've ignored these tests with a comment mentioning they'll require a backport of JDK-8286740 to jdk17. > > JDK 17 (duplicated timestamps) > ![jdk17](https://github.com/openjdk/jmc/assets/10425301/2bd1278b-775b-476b-a801-9ae121ac4529) > > JDK 21 (expected) > ![jdk21](https://github.com/openjdk/jmc/assets/10425301/55b9c47f-225d-4d25-83c2-0d71a7d045a5) > > [0] https://bugs.openjdk.org/browse/JMC-8175 > [1] https://bugs.openjdk.org/browse/JDK-8286740 > [2] https://bugs.openjdk.org/browse/JMC-8175?focusedId=14648937&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14648937 This pull request has now been integrated. Changeset: 0d823a9f Author: Alex Macdonald URL: https://git.openjdk.org/jmc/commit/0d823a9fc7540e942da16e853836a563a8fde323 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8175: Flightrecorder UI-tests are failing Reviewed-by: vpurnam, hirt ------------- PR: https://git.openjdk.org/jmc/pull/553 From geniusgaurav27 at gmail.com Fri Feb 23 05:26:12 2024 From: geniusgaurav27 at gmail.com (Gaurav Gupta) Date: Fri, 23 Feb 2024 10:56:12 +0530 Subject: JFR causes spike in HeapMemoryAfterGC in prod ssystems Message-ID: Hi Team, I am Gaurav Gupta, Principal Engineer at Amazon India (gagup at amazon.com). My team is trying to enable JFR on production systems for studying any issues using custom events in JMC. Also we plan to study the impact of code changes in our application on system performance by studying JFR dumps using JMC and Flamescope (sub-second profiling). We tried enabling JFR in our prod system by adding following JVM args in our application startup (we have not yet added any custom event in our code: -XX:+FlightRecorder -XX:StartFlightRecording=name=SomeServiceJFR,disk=false,path-to-gc-roots=false -XX:FlightRecorderOptions=stackdepth=256,memorysize=60M,numglobalbuffers=2,globalbuffersize=30M,old-object-queue-size=64 (The reason we turned off the disk parameter is to avoid disk space issues during spiky traffic. We plan to take JFR dump on demand basis by running JFR.dump command line option to study application behavior and keep JFR recording on all the time). We saw the system performance metrics on HeapMemoryAfterGC rising from 5% to 30% (on our test fleet) after starting our application with above JVM args (i.e. with JFR enabled). As per our reading about JFR, it is claimed to be safe in prod systems with continuous JFR profiling. But the rise of the HeapMemory use raised concern. I seek your advice in this regard, if we are missing anything (wrt parameter configuration above) or are there other options to try without affecting the prod system. Also, is there a slack channel that I join for live discussion in this regard? How can I get added? PS: I won't be able to share the JFR dump file outside Amazon as it records events and stack traces for our proprietary software. But I am happy to come to a meeting on slack or other means and discuss this. Slack email: gagup at amazon.com -- Best regards, *Gaurav Gupta* ------------------------------------------------------------------------------------------------------------------------------- *"Perfection is achieved not when there is nothing more to add,but rather when there is nothing more to take away."* -------------- next part -------------- An HTML attachment was scrubbed... URL: From vpurnam at openjdk.org Fri Feb 23 11:08:06 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Fri, 23 Feb 2024 11:08:06 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option Message-ID: Focus Trapped Issue. Keyboard focus is trapped in three specific scenarios mentioned below: 1. Focus is trapped in JMC Agent Preset Manager Select Window -> JMC Agent Preset Manager Click on "Import Fils..."/ "Export File" button Press Esc button when dialog is displayed Press "Tab" button for multi times 2. Focus is trapped in Description of Template Manager Select JVM Browser Start Flight Recording Template Manager Click New Click Edit Focus to Description 3. Focus is trapped in search tool in Flame Graph (Mostly on Windows) Launch JDK Mission Control Open any JFR file Navigate to "Outline" tab In Java Application, choose "Threads" Move focus to search tool in Flame Graph Solution: 1. PresetManagerPage.java : Setting the focus back to tableInspector. 2. TemplateEditPage.java : Added TraverseListener() for description field. 3. FlamegraphSwingView.java : Fix is not straight forward as SWT to Swing and back to SWT traversal is creating issue here. I have just implemented work around for this. I have added KeyListener() to all the swing components. Once it traverse through all the components, I am setting the Focus back to SWT. With this there is no keyboard focus trap. These issues are kind of blocker with respect to accessibility. Could someone please review the changes. ------------- Commit messages: - 8204: Keyboard traps in flamegraph view for search option - 8204: Keyboard traps in flamegraph view for search option Changes: https://git.openjdk.org/jmc/pull/554/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=554&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8204 Stats: 196 lines in 3 files changed: 164 ins; 15 del; 17 mod Patch: https://git.openjdk.org/jmc/pull/554.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/554/head:pull/554 PR: https://git.openjdk.org/jmc/pull/554 From vpurnam at openjdk.org Fri Feb 23 12:14:20 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Fri, 23 Feb 2024 12:14:20 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v2] In-Reply-To: References: Message-ID: > Focus Trapped Issue. Keyboard focus is trapped in three specific scenarios mentioned below: > > 1. Focus is trapped in JMC Agent Preset Manager > > Select Window -> JMC Agent Preset Manager > Click on "Import Fils..."/ "Export File" button > Press Esc button when dialog is displayed > Press "Tab" button for multi times > > 2. Focus is trapped in Description of Template Manager > > Select JVM Browser > Start Flight Recording > Template Manager > Click New > Click Edit > Focus to Description > > 3. Focus is trapped in search tool in Flame Graph (Mostly on Windows) > > Launch JDK Mission Control > Open any JFR file > Navigate to "Outline" tab > In Java Application, choose "Threads" > Move focus to search tool in Flame Graph > > Solution: > 1. PresetManagerPage.java : Setting the focus back to tableInspector. > 2. TemplateEditPage.java : Added TraverseListener() for description field. > 3. FlamegraphSwingView.java : Fix is not straight forward as SWT to Swing and back to SWT traversal is creating issue here. I have just implemented work around for this. I have added KeyListener() to all the swing components. Once it traverse through all the components, I am setting the Focus back to SWT. With this there is no keyboard focus trap. > > These issues are kind of blocker with respect to accessibility. Could someone please review the changes. Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: 8204: Keyboard traps in flamegraph view for search option ------------- Changes: - all: https://git.openjdk.org/jmc/pull/554/files - new: https://git.openjdk.org/jmc/pull/554/files/0166ed2e..64519e33 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=554&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=554&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/554.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/554/head:pull/554 PR: https://git.openjdk.org/jmc/pull/554 From clanger at openjdk.org Fri Feb 23 21:54:18 2024 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 23 Feb 2024 21:54:18 GMT Subject: RFR: 8174: Check license year script may check files not changed by a PR [v2] In-Reply-To: References: <8w3BwD4fAfjERjq9cTzKUOIQRF-kAZdQSBbVQA46kx0=.3d0b2322-e9b1-4801-9425-4cb40974e504@github.com> Message-ID: On Mon, 12 Feb 2024 17:13:12 GMT, Alex Macdonald wrote: >> This short PR addresses JMC-8174 [[0]](https://bugs.openjdk.org/browse/JMC-8174), in which the check license year script may fail when checking files not modified by the PR it's running against. >> >> The issue is that I originally had `origin/master` as the branch the PR would be checked against, forgetting that these checks are run on our own forks and not openjdk/jmc. As a result, if the PR owner's `origin/master` is out of date, then the check license script may incorrectly error even if the PR is okay against `upstream/master`. To amend this I've added a line that greps the result of `git remote -v` and looks for `upstream`, and if it doesn't exist then it adds a new remote and fetches it. Now we can compare the PR commits against `upstream/master` >> >> [0] https://bugs.openjdk.org/browse/JMC-8174 >> >> Examples: >> >> Current (checks out own fork of jmc): https://github.com/aptmac/jmc/actions/runs/7904023625/job/21573338057#step:2:463 >> >> 8174 (checks out openjdk/jmc): https://github.com/aptmac/jmc/actions/runs/7875363437/job/21487103607#step:3:5 > > Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8174: Check license year script may check files not changed by a PR Makes sense. LGTM. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jmc/pull/552#pullrequestreview-1898997998 From erik.gahlin at oracle.com Sat Feb 24 10:08:35 2024 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Sat, 24 Feb 2024 10:08:35 +0000 Subject: JFR causes spike in HeapMemoryAfterGC in prod ssystems In-Reply-To: References: Message-ID: Hi Guarav, > it is claimed to be safe in prod systems with continuous JFR profiling. The overhead should be less than 1% by default (-XX:StartFlightRecording, no other options) and it should not crash, cause memory leaks etc. if you run it for a long time. I don't know where the HeapMemoryAfterGC metric comes from. Is it something shown in JMC? We don't have targets for memory usage. That said, JFR should probably not use more than 50 MB of the Java heap, so if 30% is normal or not depends on how large heap you are using. There is a slack channel for JMC developers. I don't manage it and I'm not sure if this is really a bug. https://wiki.openjdk.org/display/jmc/Contributing Best regards, Erik ________________________________ From: hotspot-jfr-dev on behalf of Gaurav Gupta Sent: Friday, February 23, 2024 6:26 AM To: hotspot-jfr-dev at openjdk.org ; jmc-dev at openjdk.org Subject: JFR causes spike in HeapMemoryAfterGC in prod ssystems Hi Team, I am Gaurav Gupta, Principal Engineer at Amazon India (gagup at amazon.com). My team is trying to enable JFR on production systems for studying any issues using custom events in JMC. Also we plan to study the impact of code changes in our application on system performance by studying JFR dumps using JMC and Flamescope (sub-second profiling). We tried enabling JFR in our prod system by adding following JVM args in our application startup (we have not yet added any custom event in our code: -XX:+FlightRecorder -XX:StartFlightRecording=name=SomeServiceJFR,disk=false,path-to-gc-roots=false -XX:FlightRecorderOptions=stackdepth=256,memorysize=60M,numglobalbuffers=2,globalbuffersize=30M,old-object-queue-size=64 (The reason we turned off the disk parameter is to avoid disk space issues during spiky traffic. We plan to take JFR dump on demand basis by running JFR.dump command line option to study application behavior and keep JFR recording on all the time). We saw the system performance metrics on HeapMemoryAfterGC rising from 5% to 30% (on our test fleet) after starting our application with above JVM args (i.e. with JFR enabled). As per our reading about JFR, it is claimed to be safe in prod systems with continuous JFR profiling. But the rise of the HeapMemory use raised concern. I seek your advice in this regard, if we are missing anything (wrt parameter configuration above) or are there other options to try without affecting the prod system. Also, is there a slack channel that I join for live discussion in this regard? How can I get added? PS: I won't be able to share the JFR dump file outside Amazon as it records events and stack traces for our proprietary software. But I am happy to come to a meeting on slack or other means and discuss this. Slack email: gagup at amazon.com -- Best regards, Gaurav Gupta ------------------------------------------------------------------------------------------------------------------------------- "Perfection is achieved not when there is nothing more to add,but rather when there is nothing more to take away." -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus at hirt.se Sat Feb 24 12:32:54 2024 From: marcus at hirt.se (Marcus Hirt) Date: Sat, 24 Feb 2024 13:32:54 +0100 Subject: JFR causes spike in HeapMemoryAfterGC in prod ssystems In-Reply-To: References: Message-ID: <032401da671d$971ddc40$c55994c0$@hirt.se> Hi Gaurav, I?ve invited you to the JMC slack. Kind regards, Marcus From: jmc-dev On Behalf Of Erik Gahlin Sent: Saturday, 24 February 2024 11:09 To: Gaurav Gupta ; hotspot-jfr-dev at openjdk.org; jmc-dev at openjdk.org Subject: Re: JFR causes spike in HeapMemoryAfterGC in prod ssystems Hi Guarav, > it is claimed to be safe in prod systems with continuous JFR profiling. The overhead should be less than 1% by default (-XX:StartFlightRecording, no other options) and it should not crash, cause memory leaks etc. if you run it for a long time. I don't know where the HeapMemoryAfterGC metric comes from. Is it something shown in JMC? We don't have targets for memory usage. That said, JFR should probably not use more than 50 MB of the Java heap, so if 30% is normal or not depends on how large heap you are using. There is a slack channel for JMC developers. I don't manage it and I'm not sure if this is really a bug. https://wiki.openjdk.org/display/jmc/Contributing Best regards, Erik _____ From: hotspot-jfr-dev > on behalf of Gaurav Gupta > Sent: Friday, February 23, 2024 6:26 AM To: hotspot-jfr-dev at openjdk.org >; jmc-dev at openjdk.org > Subject: JFR causes spike in HeapMemoryAfterGC in prod ssystems Hi Team, I am Gaurav Gupta, Principal Engineer at Amazon India (gagup at amazon.com ). My team is trying to enable JFR on production systems for studying any issues using custom events in JMC. Also we plan to study the impact of code changes in our application on system performance by studying JFR dumps using JMC and Flamescope (sub-second profiling). We tried enabling JFR in our prod system by adding following JVM args in our application startup (we have not yet added any custom event in our code: -XX:+FlightRecorder -XX:StartFlightRecording=name=SomeServiceJFR,disk=false,path-to-gc-roots=false -XX:FlightRecorderOptions=stackdepth=256,memorysize=60M,numglobalbuffers=2,globalbuffersize=30M,old-object-queue-size=64 (The reason we turned off the disk parameter is to avoid disk space issues during spiky traffic. We plan to take JFR dump on demand basis by running JFR.dump command line option to study application behavior and keep JFR recording on all the time). We saw the system performance metrics on HeapMemoryAfterGC rising from 5% to 30% (on our test fleet) after starting our application with above JVM args (i.e. with JFR enabled). As per our reading about JFR, it is claimed to be safe in prod systems with continuous JFR profiling. But the rise of the HeapMemory use raised concern. I seek your advice in this regard, if we are missing anything (wrt parameter configuration above) or are there other options to try without affecting the prod system. Also, is there a slack channel that I join for live discussion in this regard? How can I get added? PS: I won't be able to share the JFR dump file outside Amazon as it records events and stack traces for our proprietary software. But I am happy to come to a meeting on slack or other means and discuss this. Slack email: gagup at amazon.com -- Best regards, Gaurav Gupta ------------------------------------------------------------------------------------------------------------------------------- "Perfection is achieved not when there is nothing more to add,but rather when there is nothing more to take away." -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdutheil at openjdk.org Mon Feb 26 10:18:03 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Mon, 26 Feb 2024 10:18:03 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v2] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 12:14:20 GMT, Virag Purnam wrote: >> Focus Trapped Issue. Keyboard focus is trapped in three specific scenarios mentioned below: >> >> 1. Focus is trapped in JMC Agent Preset Manager >> >> Select Window -> JMC Agent Preset Manager >> Click on "Import Fils..."/ "Export File" button >> Press Esc button when dialog is displayed >> Press "Tab" button for multi times >> >> 2. Focus is trapped in Description of Template Manager >> >> Select JVM Browser >> Start Flight Recording >> Template Manager >> Click New >> Click Edit >> Focus to Description >> >> 3. Focus is trapped in search tool in Flame Graph (Mostly on Windows) >> >> Launch JDK Mission Control >> Open any JFR file >> Navigate to "Outline" tab >> In Java Application, choose "Threads" >> Move focus to search tool in Flame Graph >> >> Solution: >> 1. PresetManagerPage.java : Setting the focus back to tableInspector. >> 2. TemplateEditPage.java : Added TraverseListener() for description field. >> 3. FlamegraphSwingView.java : Fix is not straight forward as SWT to Swing and back to SWT traversal is creating issue here. I have just implemented work around for this. I have added KeyListener() to all the swing components. Once it traverse through all the components, I am setting the Focus back to SWT. With this there is no keyboard focus trap. >> >> These issues are kind of blocker with respect to accessibility. Could someone please review the changes. > > Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: > > 8204: Keyboard traps in flamegraph view for search option For the different cases reported: 1. I'm not sure what's the issue, in previous versions, the focus doesn't seem to be trapped. Pressing tab seem to cycle correctly on the buttons of the _JMC Agent Preset Manager_ dialog 2. Looks good 3. I can cycle out of the search text field, but I don't know on which SWT component the focus lands. Note: I don't know if they are "quirks" on focus traversal depending on the OS, I'm using macOs. application/org.openjdk.jmc.console.agent/src/main/java/org/openjdk/jmc/console/agent/manager/wizards/PresetManagerPage.java line 209: > 207: > 208: tableInspector.getViewer().refresh(); > 209: tableInspector.setFocus(); **suggestion:** Might be worth extracting all `setFocus()` statements in a single method with a comment, since the issue is not quite straightforward. application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 184: > 182: private AttributeSelection attributeSelection; > 183: private IToolBarManager toolBar; > 184: private static boolean traverseAlready = false; **question:** Why this flag needs to be `static` ? application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 519: > 517: flamegraphComponent.setFocusTraversalKeysEnabled(true); > 518: > 519: flamegraphComponent.addKeyListener(new KeyAdapter() { **suggestion:** Add a comment as what is the purpose of this listener, and why it's different from the other. Maybe extract in method as well. application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 563: > 561: panel.setFocusTraversalKeysEnabled(true); > 562: > 563: panel.addKeyListener(new KeyAdapter() { **suggestion:** Add a comment as what is the purpose of this listener, and why it's different from the other. Maybe extract in method as well. application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 571: > 569: public void run() { > 570: setTraverseAlready(!traverseAlready); > 571: if (traverseAlready) { **suggestion:** Having a setter and a direct access to `traverseAlready` is a bit awkward. I suggest to either get rid of the setter, or add a getter. About this flag, the setter seems to only `toggle`, so if the method is kept I suggest instead to replace the setter by a `void toggleAlreadyTraversed() { traverseAlready = !traverseAlready }`. application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 688: > 686: public void keyPressed(KeyEvent e) { > 687: if (e.getKeyCode() == KeyEvent.VK_TAB) { > 688: if (e.getModifiersEx() > 0) { **suggestion:** `e.getModifiersEx() > 0` comes up a lot, I believe the idea here is to handle Shift Tab, I believe it's the same on all OSes. Might be worth extracting this as util method. application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 696: > 694: } > 695: } > 696: }); **suggestion:** This looks like the same code as above I suggest extracting this to a method with some comment on the intent. ------------- PR Review: https://git.openjdk.org/jmc/pull/554#pullrequestreview-1900263605 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1502227435 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1502287654 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1502315103 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1502314852 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1502311783 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1502302815 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1502300184 From bdutheil at openjdk.org Mon Feb 26 10:19:58 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Mon, 26 Feb 2024 10:19:58 GMT Subject: RFR: 8174: Check license year script may check files not changed by a PR [v2] In-Reply-To: References: <8w3BwD4fAfjERjq9cTzKUOIQRF-kAZdQSBbVQA46kx0=.3d0b2322-e9b1-4801-9425-4cb40974e504@github.com> Message-ID: On Mon, 12 Feb 2024 17:13:12 GMT, Alex Macdonald wrote: >> This short PR addresses JMC-8174 [[0]](https://bugs.openjdk.org/browse/JMC-8174), in which the check license year script may fail when checking files not modified by the PR it's running against. >> >> The issue is that I originally had `origin/master` as the branch the PR would be checked against, forgetting that these checks are run on our own forks and not openjdk/jmc. As a result, if the PR owner's `origin/master` is out of date, then the check license script may incorrectly error even if the PR is okay against `upstream/master`. To amend this I've added a line that greps the result of `git remote -v` and looks for `upstream`, and if it doesn't exist then it adds a new remote and fetches it. Now we can compare the PR commits against `upstream/master` >> >> [0] https://bugs.openjdk.org/browse/JMC-8174 >> >> Examples: >> >> Current (checks out own fork of jmc): https://github.com/aptmac/jmc/actions/runs/7904023625/job/21573338057#step:2:463 >> >> 8174 (checks out openjdk/jmc): https://github.com/aptmac/jmc/actions/runs/7875363437/job/21487103607#step:3:5 > > Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8174: Check license year script may check files not changed by a PR Marked as reviewed by bdutheil (Committer). Looks good to me as well. Thanks for this ! ------------- PR Review: https://git.openjdk.org/jmc/pull/552#pullrequestreview-1900466610 PR Comment: https://git.openjdk.org/jmc/pull/552#issuecomment-1963766091 From vpurnam at openjdk.org Mon Feb 26 11:39:03 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Mon, 26 Feb 2024 11:39:03 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 10:15:03 GMT, Brice Dutheil wrote: > For the different cases reported: > > 1. I'm not sure what's the issue, in previous versions, the focus doesn't seem to be trapped. Pressing tab seem to cycle correctly on the buttons of the _JMC Agent Preset Manager_ dialog > 2. Looks good > 3. I can cycle out of the search text field, but I don't know on which SWT component the focus lands. > > Note: I don't know if they are "quirks" on focus traversal depending on the OS, I'm using macOs. Hi @bric3, Thanks for the review and your comments. I have tried on Windows and keyboard focus trapped in all the three cases. I will work on the other review comments. ------------- PR Comment: https://git.openjdk.org/jmc/pull/554#issuecomment-1963939086 From aptmac at openjdk.org Mon Feb 26 15:40:57 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Mon, 26 Feb 2024 15:40:57 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v2] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 12:14:20 GMT, Virag Purnam wrote: >> Focus Trapped Issue. Keyboard focus is trapped in three specific scenarios mentioned below: >> >> 1. Focus is trapped in JMC Agent Preset Manager >> >> Select Window -> JMC Agent Preset Manager >> Click on "Import Fils..."/ "Export File" button >> Press Esc button when dialog is displayed >> Press "Tab" button for multi times >> >> 2. Focus is trapped in Description of Template Manager >> >> Select JVM Browser >> Start Flight Recording >> Template Manager >> Click New >> Click Edit >> Focus to Description >> >> 3. Focus is trapped in search tool in Flame Graph (Mostly on Windows) >> >> Launch JDK Mission Control >> Open any JFR file >> Navigate to "Outline" tab >> In Java Application, choose "Threads" >> Move focus to search tool in Flame Graph >> >> Solution: >> 1. PresetManagerPage.java : Setting the focus back to tableInspector. >> 2. TemplateEditPage.java : Added TraverseListener() for description field. >> 3. FlamegraphSwingView.java : Fix is not straight forward as SWT to Swing and back to SWT traversal is creating issue here. I have just implemented work around for this. I have added KeyListener() to all the swing components. Once it traverse through all the components, I am setting the Focus back to SWT. With this there is no keyboard focus trap. >> >> These issues are kind of blocker with respect to accessibility. Could someone please review the changes. > > Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: > > 8204: Keyboard traps in flamegraph view for search option I'll make a reminder to take a look at this on my Windows machine later tonight, but I did take a quick look at these changes in Linux.. > Focus is trapped in JMC Agent Preset Manager > Select Window -> JMC Agent Preset Manager > Click on "Import Fils..."/ "Export File" button > Press Esc button when dialog is displayed > Press "Tab" button for multi times Exiting out of the Import Files dialog still doesn't return focus to the Preset Manager window. > Focus is trapped in Description of Template Manager > Select JVM Browser > Start Flight Recording > Template Manager > Click New > Click Edit > Focus to Description This one looks to be fixed. > Focus is trapped in search tool in Flame Graph (Mostly on Windows) > Launch JDK Mission Control > Open any JFR file > Navigate to "Outline" tab > In Java Application, choose "Threads" > Move focus to search tool in Flame Graph Is the idea that you type something into the Flame Graph and then try to use Tab to cycle back through all the pages back to the Flame Graph page? FWIW, on Linux regardless of which JFR Outline page I start on the Tab navigation seems to get stuck behind the Results tab. I can see there's a little white artifact that gets drawn so I think it's getting stuck here: ![Screenshot from 2024-02-26 10-29-17](https://github.com/openjdk/jmc/assets/10425301/1223693b-f7d2-44b2-89d2-ab92350f26c4) If I start at the Flame Graph page and repeatedly tab, the navigation goes: 1. Flame Graph search bar 2. ??? (Can't find the visual clue as to what it's active on, but it's not stuck) 3. Outline 4. Outline Minimize 5. Lock Page Structure 6. View Menu 7. Selected JFR Outline Page (i.e., Java Application/Threads/etc.) 8. Results tab 9. Results Minimize 10. **Stuck** behind Results tab If I start for example on the Java Application Page instead of the Flame Graph, it still gets stuck in the same way as above but can jump straight to number 7. ------------- PR Comment: https://git.openjdk.org/jmc/pull/554#issuecomment-1964442212 From aptmac at openjdk.org Mon Feb 26 15:42:51 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Mon, 26 Feb 2024 15:42:51 GMT Subject: Integrated: 8174: Check license year script may check files not changed by a PR In-Reply-To: <8w3BwD4fAfjERjq9cTzKUOIQRF-kAZdQSBbVQA46kx0=.3d0b2322-e9b1-4801-9425-4cb40974e504@github.com> References: <8w3BwD4fAfjERjq9cTzKUOIQRF-kAZdQSBbVQA46kx0=.3d0b2322-e9b1-4801-9425-4cb40974e504@github.com> Message-ID: On Mon, 12 Feb 2024 16:49:56 GMT, Alex Macdonald wrote: > This short PR addresses JMC-8174 [[0]](https://bugs.openjdk.org/browse/JMC-8174), in which the check license year script may fail when checking files not modified by the PR it's running against. > > The issue is that I originally had `origin/master` as the branch the PR would be checked against, forgetting that these checks are run on our own forks and not openjdk/jmc. As a result, if the PR owner's `origin/master` is out of date, then the check license script may incorrectly error even if the PR is okay against `upstream/master`. To amend this I've added a line that greps the result of `git remote -v` and looks for `upstream`, and if it doesn't exist then it adds a new remote and fetches it. Now we can compare the PR commits against `upstream/master` > > [0] https://bugs.openjdk.org/browse/JMC-8174 > > Examples: > > Current (checks out own fork of jmc): https://github.com/aptmac/jmc/actions/runs/7904023625/job/21573338057#step:2:463 > > 8174 (checks out openjdk/jmc): https://github.com/aptmac/jmc/actions/runs/7875363437/job/21487103607#step:3:5 This pull request has now been integrated. Changeset: 110de067 Author: Alex Macdonald URL: https://git.openjdk.org/jmc/commit/110de0673ad794db78ad163962f33747aa20dc20 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8174: Check license year script may check files not changed by a PR Reviewed-by: clanger, bdutheil ------------- PR: https://git.openjdk.org/jmc/pull/552 From vpurnam at openjdk.org Mon Feb 26 15:50:51 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Mon, 26 Feb 2024 15:50:51 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v2] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 12:14:20 GMT, Virag Purnam wrote: >> Focus Trapped Issue. Keyboard focus is trapped in three specific scenarios mentioned below: >> >> 1. Focus is trapped in JMC Agent Preset Manager >> >> Select Window -> JMC Agent Preset Manager >> Click on "Import Fils..."/ "Export File" button >> Press Esc button when dialog is displayed >> Press "Tab" button for multi times >> >> 2. Focus is trapped in Description of Template Manager >> >> Select JVM Browser >> Start Flight Recording >> Template Manager >> Click New >> Click Edit >> Focus to Description >> >> 3. Focus is trapped in search tool in Flame Graph (Mostly on Windows) >> >> Launch JDK Mission Control >> Open any JFR file >> Navigate to "Outline" tab >> In Java Application, choose "Threads" >> Move focus to search tool in Flame Graph >> >> Solution: >> 1. PresetManagerPage.java : Setting the focus back to tableInspector. >> 2. TemplateEditPage.java : Added TraverseListener() for description field. >> 3. FlamegraphSwingView.java : Fix is not straight forward as SWT to Swing and back to SWT traversal is creating issue here. I have just implemented work around for this. I have added KeyListener() to all the swing components. Once it traverse through all the components, I am setting the Focus back to SWT. With this there is no keyboard focus trap. >> >> These issues are kind of blocker with respect to accessibility. Could someone please review the changes. > > Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: > > 8204: Keyboard traps in flamegraph view for search option > I'll make a reminder to take a look at this on my Windows machine later tonight, but I did take a quick look at these changes in Linux.. > > > Focus is trapped in JMC Agent Preset Manager > > Select Window -> JMC Agent Preset Manager > > Click on "Import Fils..."/ "Export File" button > > Press Esc button when dialog is displayed > > Press "Tab" button for multi times > > Exiting out of the Import Files dialog still doesn't return focus to the Preset Manager window. > > > Focus is trapped in Description of Template Manager > > Select JVM Browser > > Start Flight Recording > > Template Manager > > Click New > > Click Edit > > Focus to Description > > This one looks to be fixed. > > > Focus is trapped in search tool in Flame Graph (Mostly on Windows) > > Launch JDK Mission Control > > Open any JFR file > > Navigate to "Outline" tab > > In Java Application, choose "Threads" > > Move focus to search tool in Flame Graph > > Is the idea that you type something into the Flame Graph and then try to use Tab to cycle back through all the pages back to the Flame Graph page? > > FWIW, on Linux regardless of which JFR Outline page I start on the Tab navigation seems to get stuck behind the Results tab. I can see there's a little white artifact that gets drawn so I think it's getting stuck here: > > ![Screenshot from 2024-02-26 10-29-17](https://private-user-images.githubusercontent.com/10425301/307850892-1223693b-f7d2-44b2-89d2-ab92350f26c4.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDg5NjI0MzMsIm5iZiI6MTcwODk2MjEzMywicGF0aCI6Ii8xMDQyNTMwMS8zMDc4NTA4OTItMTIyMzY5M2ItZjdkMi00NGIyLTg5ZDItYWI5MjM1MGYyNmM0LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDAyMjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwMjI2VDE1NDIxM1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWFhODAzOWZlOGMzNTJkNzYxOWVhZmIxODZlYjFjOTM1MTE4NGEzNjczMTA2NDIxZTBmODVmNTQ0NjBiYjMwNmUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.DGW5043WIomt9cjIo0eSBTFhPt2fiJOXr_Jb5a8_qQ0) > > If I start at the Flame Graph page and repeatedly tab, the navigation goes: > > 1. Flame Graph search bar > 2. ??? (Can't find the visual clue as to what it's active on, but it's not stuck) > 3. Outline > 4. Outline Minimize > 5. Lock Page Structure > 6. View Menu > 7. Selected JFR Outline Page (i.e., Java Application/Threads/etc.) > 8. Results tab > 9. Results Minimize > 10. **Stuck** behind Results tab > > If I start for example on the Java Application Page instead of the Flame Graph, it still gets stuck in the same way as above but can jump straight to number 7. Thanks @aptmac for the review and comments. It will be great if you could please review these changes on Windows as well. ------------- PR Comment: https://git.openjdk.org/jmc/pull/554#issuecomment-1964464715 From aptmac at openjdk.org Mon Feb 26 20:03:47 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Mon, 26 Feb 2024 20:03:47 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v2] In-Reply-To: References: Message-ID: <4Db9Sr3C-zht3lZC7jQ-YOMdYV7fLrs0vmRCL6yHnzo=.b5625020-243d-435d-b9bc-3a1ecdabbf6f@github.com> On Mon, 26 Feb 2024 15:37:50 GMT, Alex Macdonald wrote: >> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: >> >> 8204: Keyboard traps in flamegraph view for search option > > I'll make a reminder to take a look at this on my Windows machine later tonight, but I did take a quick look at these changes in Linux.. > >> Focus is trapped in JMC Agent Preset Manager >> Select Window -> JMC Agent Preset Manager >> Click on "Import Fils..."/ "Export File" button >> Press Esc button when dialog is displayed >> Press "Tab" button for multi times > > Exiting out of the Import Files dialog still doesn't return focus to the Preset Manager window. > > (Edit: I'm seeing this on my old 8.3.0 as well. Interesting that the "Import File" in the Template Manager doesn't exhibit the same behaviour ..) > >> Focus is trapped in Description of Template Manager >> Select JVM Browser >> Start Flight Recording >> Template Manager >> Click New >> Click Edit >> Focus to Description > > This one looks to be fixed. > >> Focus is trapped in search tool in Flame Graph (Mostly on Windows) >> Launch JDK Mission Control >> Open any JFR file >> Navigate to "Outline" tab >> In Java Application, choose "Threads" >> Move focus to search tool in Flame Graph > > Is the idea that you type something into the Flame Graph and then try to use Tab to cycle back through all the pages back to the Flame Graph page? > > FWIW, on Linux regardless of which JFR Outline page I start on the Tab navigation seems to get stuck behind the Results tab. I can see there's a little white artifact that gets drawn so I think it's getting stuck here: > > ![Screenshot from 2024-02-26 10-29-17](https://github.com/openjdk/jmc/assets/10425301/1223693b-f7d2-44b2-89d2-ab92350f26c4) > > If I start at the Flame Graph page and repeatedly tab, the navigation goes: > > 1. Flame Graph search bar > 2. ??? (Can't find the visual clue as to what it's active on, but it's not stuck) > 3. Outline > 4. Outline Minimize > 5. Lock Page Structure > 6. View Menu > 7. Selected JFR Outline Page (i.e., Java Application/Threads/etc.) > 8. Results tab > 9. Results Minimize > 10. **Stuck** behind Results tab > > If I start for example on the Java Application Page instead of the Flame Graph, it still gets stuck in the same way as above but can jump straight to number 7. > Thanks @aptmac for the review and comments. It will be great if you could please review these changes on Windows as well. Gave it a try on Windows and it looks good on that front. I haven't dug through the code yet but do agree with the points that Brice mentioned. ------------- PR Comment: https://git.openjdk.org/jmc/pull/554#issuecomment-1965151348 From vpurnam at openjdk.org Tue Feb 27 16:56:14 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Tue, 27 Feb 2024 16:56:14 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v3] In-Reply-To: References: Message-ID: > Focus Trapped Issue. Keyboard focus is trapped in three specific scenarios mentioned below: > > 1. Focus is trapped in JMC Agent Preset Manager > > Select Window -> JMC Agent Preset Manager > Click on "Import Fils..."/ "Export File" button > Press Esc button when dialog is displayed > Press "Tab" button for multi times > > 2. Focus is trapped in Description of Template Manager > > Select JVM Browser > Start Flight Recording > Template Manager > Click New > Click Edit > Focus to Description > > 3. Focus is trapped in search tool in Flame Graph (Mostly on Windows) > > Launch JDK Mission Control > Open any JFR file > Navigate to "Outline" tab > In Java Application, choose "Threads" > Move focus to search tool in Flame Graph > > Solution: > 1. PresetManagerPage.java : Setting the focus back to tableInspector. > 2. TemplateEditPage.java : Added TraverseListener() for description field. > 3. FlamegraphSwingView.java : Fix is not straight forward as SWT to Swing and back to SWT traversal is creating issue here. I have just implemented work around for this. I have added KeyListener() to all the swing components. Once it traverse through all the components, I am setting the Focus back to SWT. With this there is no keyboard focus trap. > > These issues are kind of blocker with respect to accessibility. Could someone please review the changes. Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: 8204: Keyboard traps in flamegraph view for search option ------------- Changes: - all: https://git.openjdk.org/jmc/pull/554/files - new: https://git.openjdk.org/jmc/pull/554/files/64519e33..0e0afbc6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=554&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=554&range=01-02 Stats: 196 lines in 1 file changed: 94 ins; 85 del; 17 mod Patch: https://git.openjdk.org/jmc/pull/554.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/554/head:pull/554 PR: https://git.openjdk.org/jmc/pull/554 From vpurnam at openjdk.org Tue Feb 27 16:56:15 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Tue, 27 Feb 2024 16:56:15 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 08:45:12 GMT, Brice Dutheil wrote: >> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: >> >> 8204: Keyboard traps in flamegraph view for search option > > application/org.openjdk.jmc.console.agent/src/main/java/org/openjdk/jmc/console/agent/manager/wizards/PresetManagerPage.java line 209: > >> 207: >> 208: tableInspector.getViewer().refresh(); >> 209: tableInspector.setFocus(); > > **suggestion:** Might be worth extracting all `setFocus()` statements in a single method with a comment, since the issue is not quite straightforward. I have addressed this and extracted a method. > application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 184: > >> 182: private AttributeSelection attributeSelection; >> 183: private IToolBarManager toolBar; >> 184: private static boolean traverseAlready = false; > > **question:** Why this flag needs to be `static` ? Removed static. > application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 519: > >> 517: flamegraphComponent.setFocusTraversalKeysEnabled(true); >> 518: >> 519: flamegraphComponent.addKeyListener(new KeyAdapter() { > > **suggestion:** Add a comment as what is the purpose of this listener, and why it's different from the other. > > Maybe extract in method as well. Added comments and extracted to a method. > application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 563: > >> 561: panel.setFocusTraversalKeysEnabled(true); >> 562: >> 563: panel.addKeyListener(new KeyAdapter() { > > **suggestion:** Add a comment as what is the purpose of this listener, and why it's different from the other. > > Maybe extract in method as well. Extracted a method and added comments. > application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 571: > >> 569: public void run() { >> 570: setTraverseAlready(!traverseAlready); >> 571: if (traverseAlready) { > > **suggestion:** Having a setter and a direct access to `traverseAlready` is a bit awkward. I suggest to either get rid of the setter, or add a getter. > > About this flag, the setter seems to only `toggle`, so if the method is kept I suggest instead to replace the setter by a `void toggleAlreadyTraversed() { traverseAlready = !traverseAlready }`. Removed the setter method. > application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 688: > >> 686: public void keyPressed(KeyEvent e) { >> 687: if (e.getKeyCode() == KeyEvent.VK_TAB) { >> 688: if (e.getModifiersEx() > 0) { > > **suggestion:** `e.getModifiersEx() > 0` comes up a lot, I believe the idea here is to handle Shift Tab, I believe it's the same on all OSes. Might be worth extracting this as util method. Extracted a method and added comment. > application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 696: > >> 694: } >> 695: } >> 696: }); > > **suggestion:** This looks like the same code as above I suggest extracting this to a method with some comment on the intent. Extracted a method and added comments. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1504614728 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1504616051 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1504621253 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1504620497 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1504619702 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1504618435 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1504617338 From vpurnam at openjdk.org Tue Feb 27 17:06:55 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Tue, 27 Feb 2024 17:06:55 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v2] In-Reply-To: <4Db9Sr3C-zht3lZC7jQ-YOMdYV7fLrs0vmRCL6yHnzo=.b5625020-243d-435d-b9bc-3a1ecdabbf6f@github.com> References: <4Db9Sr3C-zht3lZC7jQ-YOMdYV7fLrs0vmRCL6yHnzo=.b5625020-243d-435d-b9bc-3a1ecdabbf6f@github.com> Message-ID: On Mon, 26 Feb 2024 20:01:38 GMT, Alex Macdonald wrote: >> I'll make a reminder to take a look at this on my Windows machine later tonight, but I did take a quick look at these changes in Linux.. >> >>> Focus is trapped in JMC Agent Preset Manager >>> Select Window -> JMC Agent Preset Manager >>> Click on "Import Fils..."/ "Export File" button >>> Press Esc button when dialog is displayed >>> Press "Tab" button for multi times >> >> Exiting out of the Import Files dialog still doesn't return focus to the Preset Manager window. >> >> (Edit: I'm seeing this on my old 8.3.0 as well. Interesting that the "Import File" in the Template Manager doesn't exhibit the same behaviour ..) >> >>> Focus is trapped in Description of Template Manager >>> Select JVM Browser >>> Start Flight Recording >>> Template Manager >>> Click New >>> Click Edit >>> Focus to Description >> >> This one looks to be fixed. >> >>> Focus is trapped in search tool in Flame Graph (Mostly on Windows) >>> Launch JDK Mission Control >>> Open any JFR file >>> Navigate to "Outline" tab >>> In Java Application, choose "Threads" >>> Move focus to search tool in Flame Graph >> >> Is the idea that you type something into the Flame Graph and then try to use Tab to cycle back through all the pages back to the Flame Graph page? >> >> FWIW, on Linux regardless of which JFR Outline page I start on the Tab navigation seems to get stuck behind the Results tab. I can see there's a little white artifact that gets drawn so I think it's getting stuck here: >> >> ![Screenshot from 2024-02-26 10-29-17](https://github.com/openjdk/jmc/assets/10425301/1223693b-f7d2-44b2-89d2-ab92350f26c4) >> >> If I start at the Flame Graph page and repeatedly tab, the navigation goes: >> >> 1. Flame Graph search bar >> 2. ??? (Can't find the visual clue as to what it's active on, but it's not stuck) >> 3. Outline >> 4. Outline Minimize >> 5. Lock Page Structure >> 6. View Menu >> 7. Selected JFR Outline Page (i.e., Java Application/Threads/etc.) >> 8. Results tab >> 9. Results Minimize >> 10. **Stuck** behind Results tab >> >> If I start for example on the Java Application Page instead of the Flame Graph, it still gets stuck in the same way as above but can jump straight to number 7. > >> Thanks @aptmac for the review and comments. It will be great if you could please review these changes on Windows as well. > > Gave it a try on Windows and it looks good on that front. I haven't dug through the code yet but do agree with the points that Brice mentioned. Hi @aptmac, Thanks for your review. Hi @bric3, I have addressed all the review points and committed the changes. Could you please review the updated code. ------------- PR Comment: https://git.openjdk.org/jmc/pull/554#issuecomment-1967159482 From duke at openjdk.org Tue Feb 27 21:45:03 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Tue, 27 Feb 2024 21:45:03 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v10] In-Reply-To: References: Message-ID: > Replaces parts of https://github.com/openjdk/jmc/pull/332 Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: JMC-7455: [WIP] try to pick up protocol extensions ------------- Changes: - all: https://git.openjdk.org/jmc/pull/548/files - new: https://git.openjdk.org/jmc/pull/548/files/a7774a0e..a8016ec2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=09 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=08-09 Stats: 189 lines in 3 files changed: 188 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/548.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/548/head:pull/548 PR: https://git.openjdk.org/jmc/pull/548 From bdutheil at openjdk.org Wed Feb 28 10:49:52 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Wed, 28 Feb 2024 10:49:52 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v3] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 16:56:14 GMT, Virag Purnam wrote: >> Focus Trapped Issue. Keyboard focus is trapped in three specific scenarios mentioned below: >> >> 1. Focus is trapped in JMC Agent Preset Manager >> >> Select Window -> JMC Agent Preset Manager >> Click on "Import Fils..."/ "Export File" button >> Press Esc button when dialog is displayed >> Press "Tab" button for multi times >> >> 2. Focus is trapped in Description of Template Manager >> >> Select JVM Browser >> Start Flight Recording >> Template Manager >> Click New >> Click Edit >> Focus to Description >> >> 3. Focus is trapped in search tool in Flame Graph (Mostly on Windows) >> >> Launch JDK Mission Control >> Open any JFR file >> Navigate to "Outline" tab >> In Java Application, choose "Threads" >> Move focus to search tool in Flame Graph >> >> Solution: >> 1. PresetManagerPage.java : Setting the focus back to tableInspector. >> 2. TemplateEditPage.java : Added TraverseListener() for description field. >> 3. FlamegraphSwingView.java : Fix is not straight forward as SWT to Swing and back to SWT traversal is creating issue here. I have just implemented work around for this. I have added KeyListener() to all the swing components. Once it traverse through all the components, I am setting the Focus back to SWT. With this there is no keyboard focus trap. >> >> These issues are kind of blocker with respect to accessibility. Could someone please review the changes. > > Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: > > 8204: Keyboard traps in flamegraph view for search option LGTM albeit a few things to fix. Not tested on either Linux or Windows. application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 523: > 521: // Adding focus traversal and key listener for main panel > 522: setFocusTraversalProperties(panel); > 523: addKeyListenerForBkwdFocustoSWT(panel); **typo:** Small typo here on `toSWT` Suggestion: addKeyListenerForBkwdFocusToSWT(panel); application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 681: > 679: if (e.getKeyCode() == KeyEvent.VK_TAB) { > 680: // Shift + TAB > 681: if (e.getModifiersEx() > 0) { **suggestion:** Same suggestion about using the mask instead of a comment. ------------- PR Review: https://git.openjdk.org/jmc/pull/554#pullrequestreview-1905903822 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1505734553 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1505745168 From bdutheil at openjdk.org Wed Feb 28 10:49:52 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Wed, 28 Feb 2024 10:49:52 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v2] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 16:52:11 GMT, Virag Purnam wrote: >> application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 688: >> >>> 686: public void keyPressed(KeyEvent e) { >>> 687: if (e.getKeyCode() == KeyEvent.VK_TAB) { >>> 688: if (e.getModifiersEx() > 0) { >> >> **suggestion:** `e.getModifiersEx() > 0` comes up a lot, I believe the idea here is to handle Shift Tab, I believe it's the same on all OSes. Might be worth extracting this as util method. > > Extracted a method and added comment. I think I would prefer something like Suggestion: if (e.getModifiersEx() & InputEvent.SHIFT_DOWN_MASK) != 0) { ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1505743526 From vpurnam at openjdk.org Wed Feb 28 11:28:15 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Wed, 28 Feb 2024 11:28:15 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v4] In-Reply-To: References: Message-ID: > Focus Trapped Issue. Keyboard focus is trapped in three specific scenarios mentioned below: > > 1. Focus is trapped in JMC Agent Preset Manager > > Select Window -> JMC Agent Preset Manager > Click on "Import Fils..."/ "Export File" button > Press Esc button when dialog is displayed > Press "Tab" button for multi times > > 2. Focus is trapped in Description of Template Manager > > Select JVM Browser > Start Flight Recording > Template Manager > Click New > Click Edit > Focus to Description > > 3. Focus is trapped in search tool in Flame Graph (Mostly on Windows) > > Launch JDK Mission Control > Open any JFR file > Navigate to "Outline" tab > In Java Application, choose "Threads" > Move focus to search tool in Flame Graph > > Solution: > 1. PresetManagerPage.java : Setting the focus back to tableInspector. > 2. TemplateEditPage.java : Added TraverseListener() for description field. > 3. FlamegraphSwingView.java : Fix is not straight forward as SWT to Swing and back to SWT traversal is creating issue here. I have just implemented work around for this. I have added KeyListener() to all the swing components. Once it traverse through all the components, I am setting the Focus back to SWT. With this there is no keyboard focus trap. > > These issues are kind of blocker with respect to accessibility. Could someone please review the changes. Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: 8204: Keyboard traps in flamegraph view for search option ------------- Changes: - all: https://git.openjdk.org/jmc/pull/554/files - new: https://git.openjdk.org/jmc/pull/554/files/0e0afbc6..66c47719 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=554&range=03 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=554&range=02-03 Stats: 9 lines in 1 file changed: 1 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jmc/pull/554.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/554/head:pull/554 PR: https://git.openjdk.org/jmc/pull/554 From vpurnam at openjdk.org Wed Feb 28 11:28:15 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Wed, 28 Feb 2024 11:28:15 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v3] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 10:37:41 GMT, Brice Dutheil wrote: >> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: >> >> 8204: Keyboard traps in flamegraph view for search option > > application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 523: > >> 521: // Adding focus traversal and key listener for main panel >> 522: setFocusTraversalProperties(panel); >> 523: addKeyListenerForBkwdFocustoSWT(panel); > > **typo:** Small typo here on `toSWT` > > Suggestion: > > addKeyListenerForBkwdFocusToSWT(panel); Changed from addKeyListenerForBkwdFocustoSWT to addKeyListenerForBkwdFocus**T**oSWT > application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 681: > >> 679: if (e.getKeyCode() == KeyEvent.VK_TAB) { >> 680: // Shift + TAB >> 681: if (e.getModifiersEx() > 0) { > > **suggestion:** Same suggestion about using the mask instead of a comment. @bric3, Thanks. I have changed as suggested by you. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1505793897 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1505794877 From duke at openjdk.org Thu Feb 29 10:18:55 2024 From: duke at openjdk.org (duke) Date: Thu, 29 Feb 2024 10:18:55 GMT Subject: Withdrawn: 7576: Remove the need for a local jetty server for dependencies In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 21:33:49 GMT, Austin Brooks wrote: > Using newer Tycho features to achieve result: > > Maven dependencies in a target (Tycho 2.2 ): https://github.com/eclipse/tycho/blob/master/RELEASE_NOTES.md#support-for-m2e-pde-maven-target-locations > Nested target to cut down on duplicate third party code (Tycho 2.6): https://github.com/eclipse/tycho/blob/master/RELEASE_NOTES.md#support-for-nested-targets > > Note: Due to change in 2.7, you must delete a file when switching branches due to changes in the `.m2` folder: https://github.com/eclipse/tycho/blob/master/RELEASE_NOTES.md#caution-when-switching-between-tycho-versions This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jmc/pull/387