From hdafgard at openjdk.java.net  Mon Aug  2 19:21:36 2021
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 2 Aug 2021 19:21:36 GMT
Subject: RFR: 7371: Make Skara realize master is now 8.2
In-Reply-To: <OUyYvb30kFZpgOEaDpxbMduzK_TgRcJ74ABfwUv5Mbk=.85bedc49-3649-41d1-a540-6eeb98e8de27@github.com>
References: <OUyYvb30kFZpgOEaDpxbMduzK_TgRcJ74ABfwUv5Mbk=.85bedc49-3649-41d1-a540-6eeb98e8de27@github.com>
Message-ID: <79IfVJspx9AZeE7U7e8lA-7ORMZIQFejs99RBAgH5gI=.24e155ca-354c-442f-b665-fd11bf2c2686@github.com>

On Sat, 31 Jul 2021 13:57:35 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Will do a proper update, including splash, later this weekend.

Marked as reviewed by hdafgard (Reviewer).

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

PR: https://git.openjdk.java.net/jmc/pull/297

From hdafgard at openjdk.java.net  Mon Aug  2 19:21:37 2021
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 2 Aug 2021 19:21:37 GMT
Subject: RFR: 7368: Update the 8.1 splash to release splash
In-Reply-To: <GpZMF7-qYWDlrIdd_vCPV9Iw_EmmZn1ufNCbG1vookg=.e36d310c-aef5-4e39-885d-3711f0988fa8@github.com>
References: <GpZMF7-qYWDlrIdd_vCPV9Iw_EmmZn1ufNCbG1vookg=.e36d310c-aef5-4e39-885d-3711f0988fa8@github.com>
Message-ID: <VZdkFQi9Vi0dhDqSOFQ8B2S_svN5MngZWJ7eTSTL4fU=.5af46de2-05b1-460a-a997-a7532ec36394@github.com>

On Sat, 31 Jul 2021 13:48:10 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Updated the splash screen.

Marked as reviewed by hdafgard (Reviewer).

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

PR: https://git.openjdk.java.net/jmc/pull/296

From hirt at openjdk.java.net  Mon Aug  2 19:27:35 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 2 Aug 2021 19:27:35 GMT
Subject: Integrated: 7368: Update the 8.1 splash to release splash
In-Reply-To: <GpZMF7-qYWDlrIdd_vCPV9Iw_EmmZn1ufNCbG1vookg=.e36d310c-aef5-4e39-885d-3711f0988fa8@github.com>
References: <GpZMF7-qYWDlrIdd_vCPV9Iw_EmmZn1ufNCbG1vookg=.e36d310c-aef5-4e39-885d-3711f0988fa8@github.com>
Message-ID: <pleaktxJZtC3fn6XrComep2fE21W8uub4JxILfL0oyY=.7fcf553e-a2f6-4a32-b225-d8e40d1531d5@github.com>

On Sat, 31 Jul 2021 13:48:10 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Updated the splash screen.

This pull request has now been integrated.

Changeset: d0f89f0a
Author:    Marcus Hirt <hirt at openjdk.org>
URL:       https://git.openjdk.java.net/jmc/commit/d0f89f0aa00c1dca2cc89712091d938454a16ff3
Stats:     0 lines in 1 file changed: 0 ins; 0 del; 0 mod

7368: Update the 8.1 splash to release splash

Reviewed-by: jpbempel, hdafgard

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

PR: https://git.openjdk.java.net/jmc/pull/296

From hirt at openjdk.java.net  Mon Aug  2 19:28:30 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 2 Aug 2021 19:28:30 GMT
Subject: Integrated: 7371: Make Skara realize master is now 8.2
In-Reply-To: <OUyYvb30kFZpgOEaDpxbMduzK_TgRcJ74ABfwUv5Mbk=.85bedc49-3649-41d1-a540-6eeb98e8de27@github.com>
References: <OUyYvb30kFZpgOEaDpxbMduzK_TgRcJ74ABfwUv5Mbk=.85bedc49-3649-41d1-a540-6eeb98e8de27@github.com>
Message-ID: <dMOcjbQaYbd_M5pllkjIFA8OAsZ5bSMCM85sGJLmstY=.ceb20e64-da40-457e-abcf-02ab2f19709e@github.com>

On Sat, 31 Jul 2021 13:57:35 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Will do a proper update, including splash, later this weekend.

This pull request has now been integrated.

Changeset: 42a33002
Author:    Marcus Hirt <hirt at openjdk.org>
URL:       https://git.openjdk.java.net/jmc/commit/42a330023d1455db699ed417bebfa7317a741f05
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

7371: Make Skara realize master is now 8.2

Reviewed-by: jpbempel, hdafgard

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

PR: https://git.openjdk.java.net/jmc/pull/297

From duke at openjdk.java.net  Mon Aug  2 22:03:09 2021
From: duke at openjdk.java.net (duke)
Date: Mon, 2 Aug 2021 22:03:09 GMT
Subject: git: openjdk/jmc: Added tag 8.1.0-rc for changeset d0f89f0a
Message-ID: <f9d7d9d7-c02a-4f44-90bd-86464488ee24@openjdk.java.net>

Tagged by: Marcus Hirt <marcus at hirt.se>
Date:      2021-08-03 00:00:21 +0000

Release candidate for JMC 8.1.0
Changeset: d0f89f0a
Author:    Marcus Hirt <hirt at openjdk.org>
Date:      2021-08-02 19:24:03 +0000
URL:       https://git.openjdk.java.net/jmc/commit/d0f89f0aa00c1dca2cc89712091d938454a16ff3


From aptmac at openjdk.java.net  Tue Aug  3 15:01:58 2021
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Tue, 3 Aug 2021 15:01:58 GMT
Subject: RFR: 5904: Merge org.openjdk.jmc.ui.celleditors with
 org.openjdk.jmc.rjmx.ui.celleditors [v3]
In-Reply-To: <U9YY7_Yst0dzuwPDbz_PhKZ4L3fHdNOGtxjt-f5fD88=.efc5d4a1-2e71-4e8e-bcac-41ebf8e71b4f@github.com>
References: <U9YY7_Yst0dzuwPDbz_PhKZ4L3fHdNOGtxjt-f5fD88=.efc5d4a1-2e71-4e8e-bcac-41ebf8e71b4f@github.com>
Message-ID: <U98gOJAOetzszT9rMgTVkl9OaKPf3G81UTxIQKicWCM=.db6079d6-2503-4092-ba09-49c3b6a8338f@github.com>

> This PR addresses JMC-5904 [[0]](https://bugs.openjdk.java.net/browse/JMC-5904), in which it is noted that org.openjdk.jmc.ui.celleditors could be merged with org.openjdk.jmc.rjmx.ui.celleditors instead of separating the code.
> 
> For the most part this is a fairly straightforward migration of code. There are three classes in jmc.ui.celleditors that needed to be moved into rjmx.ui.celleditors:
> 1. ClearableTextCellEditor
> 2. CommonCellEditors
> 3. NullableTextCellEditor
> 
> Once these files are moved there is a slight problem: org.openjdk.jmc.ui.misc.FilterEditor uses CommonCellEditors, and org.openjdk.jmc.rjmx.ui requires org.openjdk.jmc.ui. In this case, adding a dependency from org.openjdk.jmc.rjmx.ui.celleditors.CommonCellEditors to org.openjdk.jmc.ui.misc.FilterEditors would introduce a circular dependency.
> 
> The solution I've gone with here is to move FilterEditor to org.openjdk.jmc.flightrecorder.ui, which IMO makes sense anyways because it's closer to the code it gets consumed by. FilterEditor is used in:
> - _org.openjdk.jmc.flightrecorder.ui_.common.DataPageToolkit
> - _org.openjdk.jmc.flightrecorder.ui_.common.FilterComponent
> - _org.openjdk.jmc.flightrecorder.ui_.common.LaneEditor
> - _org.openjdk.jmc.flightrecorder.ui_.pages.ItemHandlerPage
> 
> **Note:** this issue was originally targeted for 8.1.0, but isn't really critical (it's a P4 task), so if desired we can hold off on integrating it now and keep this around for integration into 8.2.0 as discussed in the jmc bi-weekly calls
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-5904

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 two additional commits since the last revision:

 - update license headers
 - 5904: Merge org.openjdk.jmc.ui.celleditors with org.openjdk.jmc.rjmx.ui.celleditors

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

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/271/files
  - new: https://git.openjdk.java.net/jmc/pull/271/files/a2aad9eb..6c0b8fa4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=271&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=271&range=01-02

  Stats: 12036 lines in 243 files changed: 11454 ins; 308 del; 274 mod
  Patch: https://git.openjdk.java.net/jmc/pull/271.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/271/head:pull/271

PR: https://git.openjdk.java.net/jmc/pull/271

From hirt at openjdk.java.net  Wed Aug  4 23:46:53 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 4 Aug 2021 23:46:53 GMT
Subject: RFR: 7377: Update master to 8.2
Message-ID: <kra22AvR0_IqbxFzaAtcJpwKGmwk45vnwBgko-q77m4=.218d8793-1162-451a-b42c-80a0cf02b0a0@github.com>

Also updating splash.

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

Commit messages:
 - 7377: Update master to 8.2

Changes: https://git.openjdk.java.net/jmc/pull/298/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=298&range=00
  Issue: https://bugs.openjdk.java.net/browse/JMC-7377
  Stats: 209 lines in 144 files changed: 1 ins; 3 del; 205 mod
  Patch: https://git.openjdk.java.net/jmc/pull/298.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/298/head:pull/298

PR: https://git.openjdk.java.net/jmc/pull/298

From jpbempel at openjdk.java.net  Thu Aug  5 08:53:30 2021
From: jpbempel at openjdk.java.net (Jean-Philippe Bempel)
Date: Thu, 5 Aug 2021 08:53:30 GMT
Subject: RFR: 7377: Update master to 8.2
In-Reply-To: <kra22AvR0_IqbxFzaAtcJpwKGmwk45vnwBgko-q77m4=.218d8793-1162-451a-b42c-80a0cf02b0a0@github.com>
References: <kra22AvR0_IqbxFzaAtcJpwKGmwk45vnwBgko-q77m4=.218d8793-1162-451a-b42c-80a0cf02b0a0@github.com>
Message-ID: <8QvCrbstJSBfpuHTQw3bPCGaMX_C_QPRsxw7VVEDN_I=.20eb8c70-09ba-4531-811c-9f0fa9a226c9@github.com>

On Wed, 4 Aug 2021 23:43:22 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Also updating splash.

application/org.openjdk.jmc.console.agent/pom.xml line 47:

> 45: 
> 46: 	<artifactId>org.openjdk.jmc.console.agent</artifactId>
> 47: 	<version>8.1.0-SNAPSHOT</version>

Is it ok to remove this version element?

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

PR: https://git.openjdk.java.net/jmc/pull/298

From ghb at openjdk.java.net  Thu Aug  5 09:31:34 2021
From: ghb at openjdk.java.net (Guru Hb)
Date: Thu, 5 Aug 2021 09:31:34 GMT
Subject: RFR: 7377: Update master to 8.2
In-Reply-To: <kra22AvR0_IqbxFzaAtcJpwKGmwk45vnwBgko-q77m4=.218d8793-1162-451a-b42c-80a0cf02b0a0@github.com>
References: <kra22AvR0_IqbxFzaAtcJpwKGmwk45vnwBgko-q77m4=.218d8793-1162-451a-b42c-80a0cf02b0a0@github.com>
Message-ID: <0nNDJuUZq6We8OaIqhKqqWjUm-EWR4l3IooAUm0RvjY=.7990bcce-5b62-4da0-ae19-d283887de806@github.com>

On Wed, 4 Aug 2021 23:43:22 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Also updating splash.

please update in 
1. README.md (ln 369) 
2. UpdateSiteTest.java ln 59)

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

PR: https://git.openjdk.java.net/jmc/pull/298

From hirt at openjdk.java.net  Thu Aug  5 10:18:33 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 5 Aug 2021 10:18:33 GMT
Subject: RFR: 7377: Update master to 8.2
In-Reply-To: <8QvCrbstJSBfpuHTQw3bPCGaMX_C_QPRsxw7VVEDN_I=.20eb8c70-09ba-4531-811c-9f0fa9a226c9@github.com>
References: <kra22AvR0_IqbxFzaAtcJpwKGmwk45vnwBgko-q77m4=.218d8793-1162-451a-b42c-80a0cf02b0a0@github.com>
 <8QvCrbstJSBfpuHTQw3bPCGaMX_C_QPRsxw7VVEDN_I=.20eb8c70-09ba-4531-811c-9f0fa9a226c9@github.com>
Message-ID: <VIqs0H3OgZ-9lwu1tRPh2FPADQtgxBDaTetUWL3KzQc=.365ec0ef-2b2e-4093-849f-08c15c170905@github.com>

On Thu, 5 Aug 2021 08:50:29 GMT, Jean-Philippe Bempel <jpbempel at openjdk.org> wrote:

>> Also updating splash.
>
> application/org.openjdk.jmc.console.agent/pom.xml line 47:
> 
>> 45: 
>> 46: 	<artifactId>org.openjdk.jmc.console.agent</artifactId>
>> 47: 	<version>8.1.0-SNAPSHOT</version>
> 
> Is it ok to remove this version element?

Yep. It shouldn't be there in the first place, rather inherited.

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

PR: https://git.openjdk.java.net/jmc/pull/298

From hirt at openjdk.java.net  Thu Aug  5 10:23:03 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 5 Aug 2021 10:23:03 GMT
Subject: RFR: 7377: Update master to 8.2 [v2]
In-Reply-To: <kra22AvR0_IqbxFzaAtcJpwKGmwk45vnwBgko-q77m4=.218d8793-1162-451a-b42c-80a0cf02b0a0@github.com>
References: <kra22AvR0_IqbxFzaAtcJpwKGmwk45vnwBgko-q77m4=.218d8793-1162-451a-b42c-80a0cf02b0a0@github.com>
Message-ID: <6gr6_ZAO3I4vC8qP-MBOJGmCBDC3ZQlA3NLyMlWLlGQ=.dfcb1f9c-f95f-4611-a39a-a9c066b86cd4@github.com>

> Also updating splash.

Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision:

  Fixing

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

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/298/files
  - new: https://git.openjdk.java.net/jmc/pull/298/files/2629fd65..73ad144a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=298&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=298&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jmc/pull/298.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/298/head:pull/298

PR: https://git.openjdk.java.net/jmc/pull/298

From jpbempel at openjdk.java.net  Thu Aug  5 10:54:36 2021
From: jpbempel at openjdk.java.net (Jean-Philippe Bempel)
Date: Thu, 5 Aug 2021 10:54:36 GMT
Subject: RFR: 7377: Update master to 8.2 [v2]
In-Reply-To: <6gr6_ZAO3I4vC8qP-MBOJGmCBDC3ZQlA3NLyMlWLlGQ=.dfcb1f9c-f95f-4611-a39a-a9c066b86cd4@github.com>
References: <kra22AvR0_IqbxFzaAtcJpwKGmwk45vnwBgko-q77m4=.218d8793-1162-451a-b42c-80a0cf02b0a0@github.com>
 <6gr6_ZAO3I4vC8qP-MBOJGmCBDC3ZQlA3NLyMlWLlGQ=.dfcb1f9c-f95f-4611-a39a-a9c066b86cd4@github.com>
Message-ID: <ACJUur0JN7eFmygLtYr1wNHN29cnamKGooPjB32yYIE=.8c130485-d1dd-44ce-ad0f-15cba4ba3b54@github.com>

On Thu, 5 Aug 2021 10:23:03 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Also updating splash.
>
> Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing

Marked as reviewed by jpbempel (Committer).

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

PR: https://git.openjdk.java.net/jmc/pull/298

From ghb at openjdk.java.net  Thu Aug  5 20:55:33 2021
From: ghb at openjdk.java.net (Guru Hb)
Date: Thu, 5 Aug 2021 20:55:33 GMT
Subject: RFR: 7377: Update master to 8.2 [v2]
In-Reply-To: <6gr6_ZAO3I4vC8qP-MBOJGmCBDC3ZQlA3NLyMlWLlGQ=.dfcb1f9c-f95f-4611-a39a-a9c066b86cd4@github.com>
References: <kra22AvR0_IqbxFzaAtcJpwKGmwk45vnwBgko-q77m4=.218d8793-1162-451a-b42c-80a0cf02b0a0@github.com>
 <6gr6_ZAO3I4vC8qP-MBOJGmCBDC3ZQlA3NLyMlWLlGQ=.dfcb1f9c-f95f-4611-a39a-a9c066b86cd4@github.com>
Message-ID: <EnE8ZURI5YU_MvCKkIWx1UTVnPNR3GQiJ0go7njidUc=.e55cd538-320c-47d8-86bc-3293dcda8892@github.com>

On Thu, 5 Aug 2021 10:23:03 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Also updating splash.
>
> Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing

Marked as reviewed by ghb (Reviewer).

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

PR: https://git.openjdk.java.net/jmc/pull/298

From hirt at openjdk.java.net  Thu Aug  5 22:24:33 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 5 Aug 2021 22:24:33 GMT
Subject: Integrated: 7377: Update master to 8.2
In-Reply-To: <kra22AvR0_IqbxFzaAtcJpwKGmwk45vnwBgko-q77m4=.218d8793-1162-451a-b42c-80a0cf02b0a0@github.com>
References: <kra22AvR0_IqbxFzaAtcJpwKGmwk45vnwBgko-q77m4=.218d8793-1162-451a-b42c-80a0cf02b0a0@github.com>
Message-ID: <c9u0QZXLXRuJqT48nKedLoCrVRnBVers7GEh66sK6dc=.f8d2c367-6429-4a2f-bb19-cbc09bf1ab20@github.com>

On Wed, 4 Aug 2021 23:43:22 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Also updating splash.

This pull request has now been integrated.

Changeset: 511071d2
Author:    Marcus Hirt <hirt at openjdk.org>
URL:       https://git.openjdk.java.net/jmc/commit/511071d2111a9c303b3aa88219200ad81c04f835
Stats:     211 lines in 146 files changed: 1 ins; 3 del; 207 mod

7377: Update master to 8.2

Reviewed-by: jpbempel, ghb

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

PR: https://git.openjdk.java.net/jmc/pull/298

From duke at openjdk.java.net  Mon Aug  9 14:19:15 2021
From: duke at openjdk.java.net (duke)
Date: Mon, 9 Aug 2021 14:19:15 GMT
Subject: git: openjdk/jmc: Added tag 8.1.0-ga for changeset d0f89f0a
Message-ID: <fd707fa5-f8b4-4127-afe7-4fad7196ed63@openjdk.java.net>

Tagged by: Marcus Hirt <marcus at hirt.se>
Date:      2021-08-09 16:16:52 +0000

GA source release for JMC 8.1.0
Changeset: d0f89f0a
Author:    Marcus Hirt <hirt at openjdk.org>
Date:      2021-08-02 19:24:03 +0000
URL:       https://git.openjdk.java.net/jmc/commit/d0f89f0aa00c1dca2cc89712091d938454a16ff3


From aptmac at openjdk.java.net  Mon Aug  9 21:34:50 2021
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Mon, 9 Aug 2021 21:34:50 GMT
Subject: RFR: 5904: Merge org.openjdk.jmc.ui.celleditors with
 org.openjdk.jmc.rjmx.ui.celleditors [v4]
In-Reply-To: <U9YY7_Yst0dzuwPDbz_PhKZ4L3fHdNOGtxjt-f5fD88=.efc5d4a1-2e71-4e8e-bcac-41ebf8e71b4f@github.com>
References: <U9YY7_Yst0dzuwPDbz_PhKZ4L3fHdNOGtxjt-f5fD88=.efc5d4a1-2e71-4e8e-bcac-41ebf8e71b4f@github.com>
Message-ID: <jyYzbyOp-TYnxFtvegUmYdrqhDUiYwmtxbxuxEFYyA8=.6d1b8803-febe-4357-bdcc-484154be1bfe@github.com>

> This PR addresses JMC-5904 [[0]](https://bugs.openjdk.java.net/browse/JMC-5904), in which it is noted that org.openjdk.jmc.ui.celleditors could be merged with org.openjdk.jmc.rjmx.ui.celleditors instead of separating the code.
> 
> For the most part this is a fairly straightforward migration of code. There are three classes in jmc.ui.celleditors that needed to be moved into rjmx.ui.celleditors:
> 1. ClearableTextCellEditor
> 2. CommonCellEditors
> 3. NullableTextCellEditor
> 
> Once these files are moved there is a slight problem: org.openjdk.jmc.ui.misc.FilterEditor uses CommonCellEditors, and org.openjdk.jmc.rjmx.ui requires org.openjdk.jmc.ui. In this case, adding a dependency from org.openjdk.jmc.rjmx.ui.celleditors.CommonCellEditors to org.openjdk.jmc.ui.misc.FilterEditors would introduce a circular dependency.
> 
> The solution I've gone with here is to move FilterEditor to org.openjdk.jmc.flightrecorder.ui, which IMO makes sense anyways because it's closer to the code it gets consumed by. FilterEditor is used in:
> - _org.openjdk.jmc.flightrecorder.ui_.common.DataPageToolkit
> - _org.openjdk.jmc.flightrecorder.ui_.common.FilterComponent
> - _org.openjdk.jmc.flightrecorder.ui_.common.LaneEditor
> - _org.openjdk.jmc.flightrecorder.ui_.pages.ItemHandlerPage
> 
> **Note:** this issue was originally targeted for 8.1.0, but isn't really critical (it's a P4 task), so if desired we can hold off on integrating it now and keep this around for integration into 8.2.0 as discussed in the jmc bi-weekly calls
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-5904

Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - update license headers
 - 5904: Merge org.openjdk.jmc.ui.celleditors with org.openjdk.jmc.rjmx.ui.celleditors

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

Changes: https://git.openjdk.java.net/jmc/pull/271/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=271&range=03
  Stats: 287 lines in 24 files changed: 93 ins; 172 del; 22 mod
  Patch: https://git.openjdk.java.net/jmc/pull/271.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/271/head:pull/271

PR: https://git.openjdk.java.net/jmc/pull/271

From aptmac at openjdk.java.net  Mon Aug  9 21:44:04 2021
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Mon, 9 Aug 2021 21:44:04 GMT
Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle
 from application to core
Message-ID: <L7gWCRuM7LXgjuNh3ENuHOJgxqXdJPcv3O0FQKCVZts=.589c3b2f-1fa5-4e7f-94d5-c1c896fd7880@github.com>

This PR addresses JMC-7307 [[0]](https://bugs.openjdk.java.net/browse/JMC-7307), in which it would be helpful to have `flightrecorder.configuration` distributed in jmc core.

`flightrecorder.configuration` itself is a pretty straightforward movement of code, as it doesn't have any dependencies. Having said that, there are some flightrecorder-configuration-related classes in `controlpanel.ui` which would be nice to have in core as well, and would probably do well in `flightrecorder.configuration`. This includes VolatileStorageDelegate, and the 12 classes in `configuration.model.xml`. The `controlpanel.ui.configuration` unit tests can also come over to core, because they only tested the model xml code anyways.

So in total, we're looking at `flightrecorder.configuration` and the former `controlpanel.ui.configuration` test coming over to core, and the following classes:
- org.openjdk.jmc.flightrecorder.configuration.model.VolatileStorageDelegate
- org.openjdk.jmc.flightrecorder.configuration.model.xml.IXMLValidator
- org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCGrammar
- org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCXMLValidator
- org.openjdk.jmc.flightrecorder.configuration.model.xml.PrettyPrinter
- org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttribute
- org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttributeInstance
- org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLModel
- org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNode
- org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNodeType
- org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTag
- org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTagInstance
- org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLValidationResult

[0] https://bugs.openjdk.java.net/browse/JMC-7307

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

Commit messages:
 - re-order flightrecorder.configuration.test in test pom
 - update license headers
 - migrate VolatileStorageDelegate to flightrecorder.configuration.model
 - revert .classpath files to their original from application
 - minor cleanup
 - move configuration.model.xml test from application to core; remove controlpanel.ui.configuration.test
 - move flightrecorder.configuration coverage from application to core
 - temporarily silence test modules that are moved, will cleanup after
 - migrate controlpanel.ui.configuration.model.xml to core
 - migrate flightrecorder.configuration to core

Changes: https://git.openjdk.java.net/jmc/pull/299/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=299&range=00
  Issue: https://bugs.openjdk.java.net/browse/JMC-7307
  Stats: 1004 lines in 99 files changed: 373 ins; 475 del; 156 mod
  Patch: https://git.openjdk.java.net/jmc/pull/299.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/299/head:pull/299

PR: https://git.openjdk.java.net/jmc/pull/299

From aptmac at openjdk.java.net  Mon Aug  9 21:44:09 2021
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Mon, 9 Aug 2021 21:44:09 GMT
Subject: RFR: 7308: Move non-Eclipse dependant classes from
 org.openjdk.jmc.ui.common to org.openjdk.jmc.common
Message-ID: <mP3keEeqtNDRTukWKvFdf9T0AS68bTnx94d1wDMA79k=.af5bb961-4fc5-4ab7-a4b9-fa4fc14f46cf@github.com>

This PR addresses JMC-7308 [[0]](https://bugs.openjdk.java.net/browse/JMC-7308), in which it would be helpful to have some of the classes currently in jmc.ui.common shipped in core.

There are a number of classes currently in jmc.ui.common that would be a great asset to the core distribution (and the third-party applications that consume jmc-core), and these classes could live in jmc.common.

It isn't as straightforward as moving all of the packages to core, as there are still classes in these jmc.ui.common packages that have dependencies on Eclipse or rjmx. Having said that, the ones listed below can be moved without much difficulty:

- org.openjdk.jmc.ui.common.action (3)
    Executable, IActionProvider, IUserAction

- org.openjdk.jmc.ui.common.jvm (5)
    Connectable, JVMArch, JVMCommandLineToolkit, JVMDescriptor, JVMType

- org.openjdk.jmc.ui.common.resource (2)
    IImageResource, Resource

- org.openjdk.jmc.ui.common.security (10)
    ActionNotGrantedException, CredentialsNotAvailableException, FailedToSaveException, ICredentials, InMemoryCredentials, ISecurityManager, PersistentCredentials, SecurlyStoredByteArray, SecurityException, SecurityManagerFactory

- org.opendjk.jmc.ui.common.tree (3)
    IArray, IChild, IParent

- org.openjdk.jmc.ui.common.util (4)
    Environment, Filename, ICopyable, IObservable

- org.openjdk.jmc.ui.common.xydata (5)
    DataSeries, DefautlTimestampedData, DefaultXYData, ITimeStampedData, IXYData

[0] https://bugs.openjdk.java.net/browse/JMC-7308

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

Commit messages:
 - update license headers
 - update agent plugin imports
 - migrate classes from ui.common.resource to core
 - migrate interfaces from ui.common.action to core
 - migrate most of the remainder from ui.common.security to core
 - migrate ui.common.xydata to core
 - migrate Environment, Filename, ICopyable, and IObservable from ui.common.util to core
 - migrate ui.common.tree to core
 - migrate ui.common.jvm to core
 - ui.common.security classes to core

Changes: https://git.openjdk.java.net/jmc/pull/300/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=300&range=00
  Issue: https://bugs.openjdk.java.net/browse/JMC-7308
  Stats: 609 lines in 173 files changed: 146 ins; 174 del; 289 mod
  Patch: https://git.openjdk.java.net/jmc/pull/300.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/300/head:pull/300

PR: https://git.openjdk.java.net/jmc/pull/300

From schaturvedi at openjdk.java.net  Mon Aug  9 23:21:51 2021
From: schaturvedi at openjdk.java.net (Suchita Chaturvedi)
Date: Mon, 9 Aug 2021 23:21:51 GMT
Subject: RFR: 7231: JMC createReport for JMC8 Automated Analysis fails to
 evaluate several rules
Message-ID: <7A74lcRU7j2A9qas1BwWturLRNFuLIcUs5fAhv5IoTY=.8e9f35d2-07ec-4347-b5ee-c2c9a2926cce@github.com>

This PR addresses the NullPointerException issue in core module for the following rules:

1. GCs Caused by System.gc()
2. GCs Caused by Heap Inspection
3. GC Stall
4. String Deduplication
5. GCs Caused by GC Locker

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

Commit messages:
 - 7231: JMC createReport for JMC8 Automated Analysis fails to evaluate several rules

Changes: https://git.openjdk.java.net/jmc/pull/302/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=302&range=00
  Issue: https://bugs.openjdk.java.net/browse/JMC-7231
  Stats: 99 lines in 5 files changed: 33 ins; 12 del; 54 mod
  Patch: https://git.openjdk.java.net/jmc/pull/302.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/302/head:pull/302

PR: https://git.openjdk.java.net/jmc/pull/302

From aptmac at openjdk.java.net  Tue Aug 10 19:49:27 2021
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Tue, 10 Aug 2021 19:49:27 GMT
Subject: RFR: 7231: JMC createReport for JMC8 Automated Analysis fails to
 evaluate several rules
In-Reply-To: <7A74lcRU7j2A9qas1BwWturLRNFuLIcUs5fAhv5IoTY=.8e9f35d2-07ec-4347-b5ee-c2c9a2926cce@github.com>
References: <7A74lcRU7j2A9qas1BwWturLRNFuLIcUs5fAhv5IoTY=.8e9f35d2-07ec-4347-b5ee-c2c9a2926cce@github.com>
Message-ID: <LN14tdKOlPSJt86enCNQhaY1ydJ0n2km19nBV1JbhBc=.9d9d2573-f7e5-43bd-b064-9dfd7962571f@github.com>

On Mon, 9 Aug 2021 23:15:26 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

> This PR addresses the NullPointerException issue in core module for the following rules:
> 
> 1. GCs Caused by System.gc()
> 2. GCs Caused by Heap Inspection
> 3. GC Stall
> 4. String Deduplication
> 5. GCs Caused by GC Locker

I think these changes are okay, although they address the issues with the individual rules rather than the system itself. I'd appreciate if @Gunde could lend some expertise or insight here.

>From my time looking through the application-side code, the `RuleManager` makes two checks to determine if a rule should be evaluated [[0]](https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/RuleManager.java#L138), and these are to:

1. check the rule's availability, which happens in `RulesToolkit.matchesEventAvailabilityMap()` [[1]](https://github.com/openjdk/jmc/blob/master/core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/RulesToolkit.java#L494), and
2. check the rule's dependencies (which happens in `RuleManager.shouldEvaluate()` [[2]](https://github.com/openjdk/jmc/blob/511071d2111a9c303b3aa88219200ad81c04f835/core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/java/org/openjdk/jmc/flightrecorder/test/rules/jdk/TestRulesWithJfr.java#L245))

However, the core implementation that leads into `JfrHtmlRulesReport` does not perform these two checks, which results in the errors for this issue.

To address problem 1 listed above, we're in luck because the `matchesEventAvailabilityMap()` is in core already in `RulesToolkit`, so this could be used when evaluating rules at `RulesToolkit.evaluateParallel()` [[3]](https://github.com/openjdk/jmc/blob/master/core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/RulesToolkit.java#L1213). This alleviates the issue from the `StringDeduplicationRule`, although it's still probably nice to have the null check included in this PR just incase something happens. Additionally, for the JFR file I was using to test this bug, by checking the rules with `matchesEventAvailabilityMap()` I was able to bypass several rules (including StringDeduplicationRule) that looked to be handled properly within their own rule implementation however could be omitted in my case. For context they were: Class Loading Pressure, Fatal Errors, Heap Content, DMS Incidents, Class Leak, Code Cache, Heap Dump, Competing Processe
 s, Exceptional Dump Reason, Java Blocking, Socket Write Peak Duration, Process Started, Primitive To Object Conversion. I'm thinking that adding a check for the rules before evaluating might be nice for future-proofing if new rules are potentially added in the future.

To address problem 2, it's not as easy as reusing the `shouldEvaluate()` function because that lies in application, but also because it checks currently evaluated rules to determine if a rule depends on another one that has already ran, which isn't checked in core. There are only four rules with dependencies, and those are the four GC rules that are adjusted in this PR, so this is an okay work around. However, it might be nice to have a way of checking dependent rules here just incase new ones are made down the line.

[0] https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/RuleManager.java#L138
[1] https://github.com/openjdk/jmc/blob/master/core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/RulesToolkit.java#L494
[2] https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/RuleManager.java#L107
[3] https://github.com/openjdk/jmc/blob/master/core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/RulesToolkit.java#L1213

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

PR: https://git.openjdk.java.net/jmc/pull/302

From schaturvedi at openjdk.java.net  Tue Aug 10 21:15:50 2021
From: schaturvedi at openjdk.java.net (Suchita Chaturvedi)
Date: Tue, 10 Aug 2021 21:15:50 GMT
Subject: RFR: 7384: Add option to enable STARTTLS encryption for mail server
 in communication preference
Message-ID: <Qj56U-PcUoWNbC0HMM-ppqh49Bwak0ko169AValypTY=.0697f651-5273-4fbe-9209-c712ad7d2d89@github.com>

This PR addresses a new enhancement of adding the preference for STARTTLS encryption for the email communications triggered in JMX Console. 

<img width="314" alt="starttls" src="https://user-images.githubusercontent.com/11155712/128935485-139b4558-c6aa-406c-92df-cc78883c8f0c.png">

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

Commit messages:
 - 7384: Add option to enable STARTTLS encryption for mail server in communication preference

Changes: https://git.openjdk.java.net/jmc/pull/303/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=303&range=00
  Issue: https://bugs.openjdk.java.net/browse/JMC-7384
  Stats: 24 lines in 6 files changed: 18 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jmc/pull/303.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/303/head:pull/303

PR: https://git.openjdk.java.net/jmc/pull/303

From ghb at openjdk.java.net  Mon Aug 16 04:14:27 2021
From: ghb at openjdk.java.net (Guru Hb)
Date: Mon, 16 Aug 2021 04:14:27 GMT
Subject: RFR: 7384: Add option to enable STARTTLS encryption for mail
 server in communication preference
In-Reply-To: <Qj56U-PcUoWNbC0HMM-ppqh49Bwak0ko169AValypTY=.0697f651-5273-4fbe-9209-c712ad7d2d89@github.com>
References: <Qj56U-PcUoWNbC0HMM-ppqh49Bwak0ko169AValypTY=.0697f651-5273-4fbe-9209-c712ad7d2d89@github.com>
Message-ID: <fs6_3L9DgRMCNyxNZWfJR6uwlA4gIITYvdJM9RWtitc=.85782624-d469-47ea-992d-6d1217e6d000@github.com>

On Tue, 10 Aug 2021 21:11:09 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

> This PR addresses a new enhancement of adding the preference for STARTTLS encryption for the email communications triggered in JMX Console. 
> 
> <img width="314" alt="starttls" src="https://user-images.githubusercontent.com/11155712/128935485-139b4558-c6aa-406c-92df-cc78883c8f0c.png">

can we have Unit tests for these ? if possible Ui test as well ?

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

PR: https://git.openjdk.java.net/jmc/pull/303

From aptmac at openjdk.java.net  Tue Aug 17 18:30:37 2021
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Tue, 17 Aug 2021 18:30:37 GMT
Subject: RFR: 7386: Remove reference to Fedora in the readme
Message-ID: <bLjhSvsgbSG6GQIHnTlbKLvnBZv7VMCPzfe3wQHux8w=.0bcaa089-353f-49ee-9004-1221bacdfb51@github.com>

This PR addresses JMC-7386 [[0]](https://bugs.openjdk.java.net/browse/JMC-7386), in which the README should be updated to remove the reference to Red Hat packaging JMC for Fedora (as we don't do that anymore).

I've also added a bit of context for how JMC is available in RHEL 7 and RHEL 8.

[0] https://bugs.openjdk.java.net/browse/JMC-7386

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

Commit messages:
 - 7386: Remove reference to Fedora in the readme

Changes: https://git.openjdk.java.net/jmc/pull/304/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=304&range=00
  Issue: https://bugs.openjdk.java.net/browse/JMC-7386
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jmc/pull/304.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/304/head:pull/304

PR: https://git.openjdk.java.net/jmc/pull/304

From hirt at openjdk.java.net  Tue Aug 17 21:41:24 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 17 Aug 2021 21:41:24 GMT
Subject: RFR: 7386: Remove reference to Fedora in the readme
In-Reply-To: <bLjhSvsgbSG6GQIHnTlbKLvnBZv7VMCPzfe3wQHux8w=.0bcaa089-353f-49ee-9004-1221bacdfb51@github.com>
References: <bLjhSvsgbSG6GQIHnTlbKLvnBZv7VMCPzfe3wQHux8w=.0bcaa089-353f-49ee-9004-1221bacdfb51@github.com>
Message-ID: <CbDtrwzjcvkanUfS8_MO2z-VtY3Uh3mv8g1O7h1UEI8=.1d34c1c3-2f16-4415-84cc-dca34df893db@github.com>

On Tue, 17 Aug 2021 18:25:53 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

> This PR addresses JMC-7386 [[0]](https://bugs.openjdk.java.net/browse/JMC-7386), in which the README should be updated to remove the reference to Red Hat packaging JMC for Fedora (as we don't do that anymore).
> 
> I've also added a bit of context for how JMC is available in RHEL 7 and RHEL 8.
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-7386

Marked as reviewed by hirt (Lead).

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

PR: https://git.openjdk.java.net/jmc/pull/304

From aptmac at openjdk.java.net  Wed Aug 18 14:20:29 2021
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Wed, 18 Aug 2021 14:20:29 GMT
Subject: Integrated: 7386: Remove reference to Fedora in the readme
In-Reply-To: <bLjhSvsgbSG6GQIHnTlbKLvnBZv7VMCPzfe3wQHux8w=.0bcaa089-353f-49ee-9004-1221bacdfb51@github.com>
References: <bLjhSvsgbSG6GQIHnTlbKLvnBZv7VMCPzfe3wQHux8w=.0bcaa089-353f-49ee-9004-1221bacdfb51@github.com>
Message-ID: <nrm9NVKTj_VvxB5sOXG8QkGTVcYI6uWQsWai-g5MO1U=.44dc2aef-c6d5-446f-9e44-f7d84b214a41@github.com>

On Tue, 17 Aug 2021 18:25:53 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

> This PR addresses JMC-7386 [[0]](https://bugs.openjdk.java.net/browse/JMC-7386), in which the README should be updated to remove the reference to Red Hat packaging JMC for Fedora (as we don't do that anymore).
> 
> I've also added a bit of context for how JMC is available in RHEL 7 and RHEL 8.
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-7386

This pull request has now been integrated.

Changeset: 0e794a9f
Author:    Alex Macdonald <aptmac at openjdk.org>
URL:       https://git.openjdk.java.net/jmc/commit/0e794a9f697c7cc394fb8ad7f52e4af5c0ac5c88
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

7386: Remove reference to Fedora in the readme

Reviewed-by: hirt

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

PR: https://git.openjdk.java.net/jmc/pull/304

From hirt at openjdk.java.net  Wed Aug 18 17:43:25 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 18 Aug 2021 17:43:25 GMT
Subject: RFR: 7338: Add parser support for frame types generated by
 async-profiler [v2]
In-Reply-To: <rTQpT510jcwQ0DcbK-yH8Jb6ofP8LlpOIf-GNaZZj38=.4bea6593-039d-46f2-a09e-5d52b9bcf78c@github.com>
References: <ztIKR7PV42-apsGJ0A8XgcxgKtYTCWYBdwdoGXUdAPU=.34f9f192-9ffa-4695-ab08-a95d707678e1@github.com>
 <rTQpT510jcwQ0DcbK-yH8Jb6ofP8LlpOIf-GNaZZj38=.4bea6593-039d-46f2-a09e-5d52b9bcf78c@github.com>
Message-ID: <FWi--9HX-hac2630Xl4jM1D-9Ei3Y63UT0PBRsvGSYE=.7c07de49-1df9-424b-8905-0c4db887d83c@github.com>

On Fri, 9 Jul 2021 16:22:18 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Async Profiler (https://github.com/jvm-profiling-tools/async-profiler) is able to generate JFR recordings with CPU and allocation sample events spanning full-stack (from Java to OS/kernel).
>> It is adding three new frame types for this reason:
>> 
>> - Native (C)
>> - C++
>> - Kernel
>>  
>> 
>> Currently, the JMC parser will process all those frame types as 'UNKNOWN'. Although it is not breaking the rendering it would be nice to be able to get more info about the actual frame type.
>
> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Marked as reviewed by hirt (Lead).

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

PR: https://git.openjdk.java.net/jmc/pull/274

From hirt at openjdk.java.net  Wed Aug 18 17:51:27 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 18 Aug 2021 17:51:27 GMT
Subject: RFR: 7248: JMC7/8 Automated Analysis taking very long time to
 produce results for Class Leak Rule. [v2]
In-Reply-To: <8MN9KvyumUkhdcxel1wQHcDioJF3WNyuPqWHxjLgkeA=.f38fc47e-2e64-45cd-adfd-22bcadef6b71@github.com>
References: <Z3iBC1F9opjtmLT4pLMnbppdQ6n8HtShSr6VGKPZ9TI=.88ec1592-1ec6-4d2c-901f-e215f6d3dfd5@github.com>
 <8MN9KvyumUkhdcxel1wQHcDioJF3WNyuPqWHxjLgkeA=.f38fc47e-2e64-45cd-adfd-22bcadef6b71@github.com>
Message-ID: <knPLUCRnzZEGte3cQ7TyIzFNOIOj7_XR8UxGpWP7OKc=.15a5b63c-fe5c-4b53-9f95-0d4bc5b664bd@github.com>

On Tue, 27 Jul 2021 14:37:52 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

>> This PR addresses the optimization of Class Leak Rule.
>> 
>> Please refer the JBS for the sample JFR which was taking ~90 minutes to generate results for Class Leak Rule. After the optimization time is reduced to ~10-15 minutes.
>> 
>> Please review the change and let me the know if there are any comments / suggestions.
>
> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Calculation maximum timeout is set via preference and hardcoding removed.

Hi Suchita!

We believe that this rule probably need to be redesigned to be useful in practice. That said, we could take your changes (after acting on @bric3 feedback), as it does at least improve matters, as an improvement until we get around to properly fixing it.

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

PR: https://git.openjdk.java.net/jmc/pull/248

From hirt at openjdk.java.net  Wed Aug 18 17:59:28 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 18 Aug 2021 17:59:28 GMT
Subject: RFR: 5904: Merge org.openjdk.jmc.ui.celleditors with
 org.openjdk.jmc.rjmx.ui.celleditors [v4]
In-Reply-To: <jyYzbyOp-TYnxFtvegUmYdrqhDUiYwmtxbxuxEFYyA8=.6d1b8803-febe-4357-bdcc-484154be1bfe@github.com>
References: <U9YY7_Yst0dzuwPDbz_PhKZ4L3fHdNOGtxjt-f5fD88=.efc5d4a1-2e71-4e8e-bcac-41ebf8e71b4f@github.com>
 <jyYzbyOp-TYnxFtvegUmYdrqhDUiYwmtxbxuxEFYyA8=.6d1b8803-febe-4357-bdcc-484154be1bfe@github.com>
Message-ID: <OufPSDU4d7UBZOpUrLLScLWcuNBXgRGe6RH_4xVaVkQ=.0408fe27-1255-4fd1-8405-7ed8e9ebf638@github.com>

On Mon, 9 Aug 2021 21:34:50 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

>> This PR addresses JMC-5904 [[0]](https://bugs.openjdk.java.net/browse/JMC-5904), in which it is noted that org.openjdk.jmc.ui.celleditors could be merged with org.openjdk.jmc.rjmx.ui.celleditors instead of separating the code.
>> 
>> For the most part this is a fairly straightforward migration of code. There are three classes in jmc.ui.celleditors that needed to be moved into rjmx.ui.celleditors:
>> 1. ClearableTextCellEditor
>> 2. CommonCellEditors
>> 3. NullableTextCellEditor
>> 
>> Once these files are moved there is a slight problem: org.openjdk.jmc.ui.misc.FilterEditor uses CommonCellEditors, and org.openjdk.jmc.rjmx.ui requires org.openjdk.jmc.ui. In this case, adding a dependency from org.openjdk.jmc.rjmx.ui.celleditors.CommonCellEditors to org.openjdk.jmc.ui.misc.FilterEditors would introduce a circular dependency.
>> 
>> The solution I've gone with here is to move FilterEditor to org.openjdk.jmc.flightrecorder.ui, which IMO makes sense anyways because it's closer to the code it gets consumed by. FilterEditor is used in:
>> - _org.openjdk.jmc.flightrecorder.ui_.common.DataPageToolkit
>> - _org.openjdk.jmc.flightrecorder.ui_.common.FilterComponent
>> - _org.openjdk.jmc.flightrecorder.ui_.common.LaneEditor
>> - _org.openjdk.jmc.flightrecorder.ui_.pages.ItemHandlerPage
>> 
>> **Note:** this issue was originally targeted for 8.1.0, but isn't really critical (it's a P4 task), so if desired we can hold off on integrating it now and keep this around for integration into 8.2.0 as discussed in the jmc bi-weekly calls
>> 
>> [0] https://bugs.openjdk.java.net/browse/JMC-5904
>
> Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - update license headers
>  - 5904: Merge org.openjdk.jmc.ui.celleditors with org.openjdk.jmc.rjmx.ui.celleditors

Changes requested by hirt (Lead).

application/org.openjdk.jmc.rjmx.ui/META-INF/MANIFEST.MF line 19:

> 17:    org.openjdk.jmc.console.ui.mbeanbrowser.uitest,
> 18:    org.openjdk.jmc.test.jemmy",
> 19:  org.openjdk.jmc.rjmx.ui.celleditors;x-friends:="org.openjdk.jmc.console.ui.mbeanbrowser,org.openjdk.jmc.flightrecorder.ui",

It would be very nice if this dependency from rjmx.ui to flightrecorder.ui was not needed.

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

PR: https://git.openjdk.java.net/jmc/pull/271

From github.com+803621+bric3 at openjdk.java.net  Thu Aug 19 07:54:27 2021
From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil)
Date: Thu, 19 Aug 2021 07:54:27 GMT
Subject: RFR: 7248: JMC7/8 Automated Analysis taking very long time to
 produce results for Class Leak Rule. [v2]
In-Reply-To: <8MN9KvyumUkhdcxel1wQHcDioJF3WNyuPqWHxjLgkeA=.f38fc47e-2e64-45cd-adfd-22bcadef6b71@github.com>
References: <Z3iBC1F9opjtmLT4pLMnbppdQ6n8HtShSr6VGKPZ9TI=.88ec1592-1ec6-4d2c-901f-e215f6d3dfd5@github.com>
 <8MN9KvyumUkhdcxel1wQHcDioJF3WNyuPqWHxjLgkeA=.f38fc47e-2e64-45cd-adfd-22bcadef6b71@github.com>
Message-ID: <YI9fuRD6lhp-6Zx0pzUcUdRhpEYVUsEA4yRWdOMfsps=.01e0f59d-e867-48c2-a6b6-e5173854b223@github.com>

On Tue, 27 Jul 2021 14:37:52 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

>> This PR addresses the optimization of Class Leak Rule.
>> 
>> Please refer the JBS for the sample JFR which was taking ~90 minutes to generate results for Class Leak Rule. After the optimization time is reduced to ~10-15 minutes.
>> 
>> Please review the change and let me the know if there are any comments / suggestions.
>
> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Calculation maximum timeout is set via preference and hardcoding removed.

core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java line 135:

> 133: 				}
> 134: 				// Timeout can be configured in prefrences (default value is set to 5 minutes)
> 135: 				exec.awaitTermination(ClassLeakingRule.CONFIGURED_TIMEOUT, TimeUnit.MINUTES);

After re-reading this code I don't think `awaitTermination` is enough to terminate the ongoing tasks ; i.e. this call will block until either all tasks are finished or until the given time-out. This means that JMC may still have hanging threads doing some work in this anonymous thread pool.

I believe this statement should be followed by `exec.shutdownNow()` and making the runnables cooperate in this shutdown by checking the thread interrupt status in the for loops. E.g.


if (Thread.currentThread().isInterrupted()) return;

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

PR: https://git.openjdk.java.net/jmc/pull/248

From github.com+803621+bric3 at openjdk.java.net  Thu Aug 19 07:57:29 2021
From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil)
Date: Thu, 19 Aug 2021 07:57:29 GMT
Subject: RFR: 7248: JMC7/8 Automated Analysis taking very long time to
 produce results for Class Leak Rule. [v2]
In-Reply-To: <8MN9KvyumUkhdcxel1wQHcDioJF3WNyuPqWHxjLgkeA=.f38fc47e-2e64-45cd-adfd-22bcadef6b71@github.com>
References: <Z3iBC1F9opjtmLT4pLMnbppdQ6n8HtShSr6VGKPZ9TI=.88ec1592-1ec6-4d2c-901f-e215f6d3dfd5@github.com>
 <8MN9KvyumUkhdcxel1wQHcDioJF3WNyuPqWHxjLgkeA=.f38fc47e-2e64-45cd-adfd-22bcadef6b71@github.com>
Message-ID: <dr8EuTRnje5cfGwcyZgBlsvlvgsSUUonuwGPT2r-8Ko=.702a82d4-f787-4bac-9441-1f6126a533ff@github.com>

On Tue, 27 Jul 2021 14:37:52 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

>> This PR addresses the optimization of Class Leak Rule.
>> 
>> Please refer the JBS for the sample JFR which was taking ~90 minutes to generate results for Class Leak Rule. After the optimization time is reduced to ~10-15 minutes.
>> 
>> Please review the change and let me the know if there are any comments / suggestions.
>
> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Calculation maximum timeout is set via preference and hardcoding removed.

Hi,
Sorry for the late reply, I'm on a _spring-break_ with kids.
I believe the time out constraints solves a part of the issue, but I still think the executor code should be improved before merging this one.

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

PR: https://git.openjdk.java.net/jmc/pull/248

From aptmac at openjdk.java.net  Thu Aug 19 20:40:31 2021
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Thu, 19 Aug 2021 20:40:31 GMT
Subject: RFR: 5904: Merge org.openjdk.jmc.ui.celleditors with
 org.openjdk.jmc.rjmx.ui.celleditors [v4]
In-Reply-To: <OufPSDU4d7UBZOpUrLLScLWcuNBXgRGe6RH_4xVaVkQ=.0408fe27-1255-4fd1-8405-7ed8e9ebf638@github.com>
References: <U9YY7_Yst0dzuwPDbz_PhKZ4L3fHdNOGtxjt-f5fD88=.efc5d4a1-2e71-4e8e-bcac-41ebf8e71b4f@github.com>
 <jyYzbyOp-TYnxFtvegUmYdrqhDUiYwmtxbxuxEFYyA8=.6d1b8803-febe-4357-bdcc-484154be1bfe@github.com>
 <OufPSDU4d7UBZOpUrLLScLWcuNBXgRGe6RH_4xVaVkQ=.0408fe27-1255-4fd1-8405-7ed8e9ebf638@github.com>
Message-ID: <5kaWaZBZJrS_f0ENP99JQFO8BNVvdAS2BG5tKfvAUVQ=.40057afe-f0b0-4456-a25e-e23ca9d98598@github.com>

On Wed, 18 Aug 2021 17:55:54 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - update license headers
>>  - 5904: Merge org.openjdk.jmc.ui.celleditors with org.openjdk.jmc.rjmx.ui.celleditors
>
> application/org.openjdk.jmc.rjmx.ui/META-INF/MANIFEST.MF line 19:
> 
>> 17:    org.openjdk.jmc.console.ui.mbeanbrowser.uitest,
>> 18:    org.openjdk.jmc.test.jemmy",
>> 19:  org.openjdk.jmc.rjmx.ui.celleditors;x-friends:="org.openjdk.jmc.console.ui.mbeanbrowser,org.openjdk.jmc.flightrecorder.ui",
> 
> It would be very nice if this dependency from rjmx.ui to flightrecorder.ui was not needed.

I took another look into this, and I'm not quite sure where it makes sense to fix this.

This dependency happened because `FilterEditor` (currently in jmc.ui.misc) requires celleditors. `FilterEditor` is also only used in flightrecorder.ui.

rjmx.ui has a dependency on jmc.ui. If celleditors moves into rjmx.ui like this and the issue suggests, then FitlerEditor needs to move because it would rely on a cyclic dependency back onto rjmx.ui.

In this case, to have no introduced dependencies `FilterEditor` would need to move to a package that both imports rjmx.ui, and is imported by flightrecorder.ui.. which isn't any I believe. FilterEditor could be moved into something like jmc.console and add that dependency on flightrecorder.ui, but I'm not sure there's a happy path here.

In a different approach, celleditors could be consolidated into jmc.ui.celleditors instead and keep FilterEditor in jmc.ui.misc. This would require a rjmx.subscription.internal rjmx.services be made available to jmc.ui.celleditors, and a jmc.rjmx dependency added onto jmc.ui. I have a branch here that gives that a try: https://github.com/aptmac/jmc/commit/90c54f202ab19ad2dbf4fdc198feaf6dd1e6d2d3

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

PR: https://git.openjdk.java.net/jmc/pull/271

From jkang at openjdk.java.net  Thu Aug 19 20:48:29 2021
From: jkang at openjdk.java.net (Jie Kang)
Date: Thu, 19 Aug 2021 20:48:29 GMT
Subject: RFR: 5904: Merge org.openjdk.jmc.ui.celleditors with
 org.openjdk.jmc.rjmx.ui.celleditors [v4]
In-Reply-To: <5kaWaZBZJrS_f0ENP99JQFO8BNVvdAS2BG5tKfvAUVQ=.40057afe-f0b0-4456-a25e-e23ca9d98598@github.com>
References: <U9YY7_Yst0dzuwPDbz_PhKZ4L3fHdNOGtxjt-f5fD88=.efc5d4a1-2e71-4e8e-bcac-41ebf8e71b4f@github.com>
 <jyYzbyOp-TYnxFtvegUmYdrqhDUiYwmtxbxuxEFYyA8=.6d1b8803-febe-4357-bdcc-484154be1bfe@github.com>
 <OufPSDU4d7UBZOpUrLLScLWcuNBXgRGe6RH_4xVaVkQ=.0408fe27-1255-4fd1-8405-7ed8e9ebf638@github.com>
 <5kaWaZBZJrS_f0ENP99JQFO8BNVvdAS2BG5tKfvAUVQ=.40057afe-f0b0-4456-a25e-e23ca9d98598@github.com>
Message-ID: <sIHJtAk-Wtrz-YrtlwAwMKSDJlsgZcdvkYmHksdklzU=.3d183211-f0bd-4c87-aa8a-e6a772db0aa7@github.com>

On Thu, 19 Aug 2021 20:37:24 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

>> application/org.openjdk.jmc.rjmx.ui/META-INF/MANIFEST.MF line 19:
>> 
>>> 17:    org.openjdk.jmc.console.ui.mbeanbrowser.uitest,
>>> 18:    org.openjdk.jmc.test.jemmy",
>>> 19:  org.openjdk.jmc.rjmx.ui.celleditors;x-friends:="org.openjdk.jmc.console.ui.mbeanbrowser,org.openjdk.jmc.flightrecorder.ui",
>> 
>> It would be very nice if this dependency from rjmx.ui to flightrecorder.ui was not needed.
>
> I took another look into this, and I'm not quite sure where it makes sense to fix this.
> 
> This dependency happened because `FilterEditor` (currently in jmc.ui.misc) requires celleditors. `FilterEditor` is also only used in flightrecorder.ui.
> 
> rjmx.ui has a dependency on jmc.ui. If celleditors moves into rjmx.ui like this and the issue suggests, then FitlerEditor needs to move because it would rely on a cyclic dependency back onto rjmx.ui.
> 
> In this case, to have no introduced dependencies `FilterEditor` would need to move to a package that both imports rjmx.ui, and is imported by flightrecorder.ui.. which isn't any I believe. FilterEditor could be moved into something like jmc.console and add that dependency on flightrecorder.ui, but I'm not sure there's a happy path here.
> 
> In a different approach, celleditors could be consolidated into jmc.ui.celleditors instead and keep FilterEditor in jmc.ui.misc. This would require a rjmx.subscription.internal rjmx.services be made available to jmc.ui.celleditors, and a jmc.rjmx dependency added onto jmc.ui. I have a branch here that gives that a try: https://github.com/aptmac/jmc/commit/90c54f202ab19ad2dbf4fdc198feaf6dd1e6d2d3

Would you be able to do a quick text diagram of the dependency chain? Like 

a->b->c
d->c
...


Is there a parent `org.openjdk.jmc.ui` where any shared classes for `rjmx.ui` and `flightrecorder.ui` can go?

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

PR: https://git.openjdk.java.net/jmc/pull/271

From aptmac at openjdk.java.net  Thu Aug 19 21:09:25 2021
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Thu, 19 Aug 2021 21:09:25 GMT
Subject: RFR: 5904: Merge org.openjdk.jmc.ui.celleditors with
 org.openjdk.jmc.rjmx.ui.celleditors [v4]
In-Reply-To: <sIHJtAk-Wtrz-YrtlwAwMKSDJlsgZcdvkYmHksdklzU=.3d183211-f0bd-4c87-aa8a-e6a772db0aa7@github.com>
References: <U9YY7_Yst0dzuwPDbz_PhKZ4L3fHdNOGtxjt-f5fD88=.efc5d4a1-2e71-4e8e-bcac-41ebf8e71b4f@github.com>
 <jyYzbyOp-TYnxFtvegUmYdrqhDUiYwmtxbxuxEFYyA8=.6d1b8803-febe-4357-bdcc-484154be1bfe@github.com>
 <OufPSDU4d7UBZOpUrLLScLWcuNBXgRGe6RH_4xVaVkQ=.0408fe27-1255-4fd1-8405-7ed8e9ebf638@github.com>
 <5kaWaZBZJrS_f0ENP99JQFO8BNVvdAS2BG5tKfvAUVQ=.40057afe-f0b0-4456-a25e-e23ca9d98598@github.com>
 <sIHJtAk-Wtrz-YrtlwAwMKSDJlsgZcdvkYmHksdklzU=.3d183211-f0bd-4c87-aa8a-e6a772db0aa7@github.com>
Message-ID: <_l_hWqje_ES147tJjeSlUGvRSVi_gv_8S3M9h3CsNfU=.f07850d6-d9a8-4eaf-91ac-bb3801093e85@github.com>

On Thu, 19 Aug 2021 20:45:57 GMT, Jie Kang <jkang at openjdk.org> wrote:

>> I took another look into this, and I'm not quite sure where it makes sense to fix this.
>> 
>> This dependency happened because `FilterEditor` (currently in jmc.ui.misc) requires celleditors. `FilterEditor` is also only used in flightrecorder.ui.
>> 
>> rjmx.ui has a dependency on jmc.ui. If celleditors moves into rjmx.ui like this and the issue suggests, then FitlerEditor needs to move because it would rely on a cyclic dependency back onto rjmx.ui.
>> 
>> In this case, to have no introduced dependencies `FilterEditor` would need to move to a package that both imports rjmx.ui, and is imported by flightrecorder.ui.. which isn't any I believe. FilterEditor could be moved into something like jmc.console and add that dependency on flightrecorder.ui, but I'm not sure there's a happy path here.
>> 
>> In a different approach, celleditors could be consolidated into jmc.ui.celleditors instead and keep FilterEditor in jmc.ui.misc. This would require a rjmx.subscription.internal rjmx.services be made available to jmc.ui.celleditors, and a jmc.rjmx dependency added onto jmc.ui. I have a branch here that gives that a try: https://github.com/aptmac/jmc/commit/90c54f202ab19ad2dbf4fdc198feaf6dd1e6d2d3
>
> Would you be able to do a quick text diagram of the dependency chain? Like 
> 
> a->b->c
> d->c
> ...
> 
> 
> Is there a parent `org.openjdk.jmc.ui` where any shared classes for `rjmx.ui` and `flightrecorder.ui` can go?

Sure I'll give this a try.

So what I'm having trouble with here is that `FilterEditor` ultimately needs to be used by `flightrecorder.ui.common`

FilterEditor requires celleditors, which in HEAD is split between `org.openjdk.jmc.ui.celleditors` and `org.openjdk.jmc.rjmx.ui`. The only celleditors class that FilterEditor needs is CommonCellEditors which is in jmc.ui, so there's no dependency on rjmx.ui. rjmx.ui also has a dependency on jmc.ui.

So we have:

jmc.ui.celleditors.celleditors->jmc.ui.misc.FilterEditor->flightrecorder.ui.common
jmc.ui -> jmc.rjmx.ui


If we're consolidating celleditors into rjmx.ui, then we have:

jmc.rjmx.ui -> jmc.ui.misc.FilterEditor -> flightrecorder.ui.common
jmc.ui -> jmc.rjmx.ui


In this case, we can break the cycle by moving FilterEditor elsewhere else. In the approach here I placed it in flightrecorder.ui because that's ultimately where it gets used anyways. But either way I guess it'd go rjmx.ui.celleditors -> "something" -> flightrecorder.ui, so it's a matter of being a direct dependency or not.

If instead we consolidate celleditors into jmc.ui.celleditors, then we have:

jmc.ui -> jmc.rjmx.ui
jmc.rjmx.services + jmc.rjmx.subscription.internal -> jmc.ui.misc.FilterEditor -> flightrecorder.ui.common

because jmc.ui.celleditors would need the apporpriate files that rjmx.ui had access to from rjmx.

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

PR: https://git.openjdk.java.net/jmc/pull/271

From jkang at openjdk.java.net  Thu Aug 19 21:16:24 2021
From: jkang at openjdk.java.net (Jie Kang)
Date: Thu, 19 Aug 2021 21:16:24 GMT
Subject: RFR: 5904: Merge org.openjdk.jmc.ui.celleditors with
 org.openjdk.jmc.rjmx.ui.celleditors [v4]
In-Reply-To: <_l_hWqje_ES147tJjeSlUGvRSVi_gv_8S3M9h3CsNfU=.f07850d6-d9a8-4eaf-91ac-bb3801093e85@github.com>
References: <U9YY7_Yst0dzuwPDbz_PhKZ4L3fHdNOGtxjt-f5fD88=.efc5d4a1-2e71-4e8e-bcac-41ebf8e71b4f@github.com>
 <jyYzbyOp-TYnxFtvegUmYdrqhDUiYwmtxbxuxEFYyA8=.6d1b8803-febe-4357-bdcc-484154be1bfe@github.com>
 <OufPSDU4d7UBZOpUrLLScLWcuNBXgRGe6RH_4xVaVkQ=.0408fe27-1255-4fd1-8405-7ed8e9ebf638@github.com>
 <5kaWaZBZJrS_f0ENP99JQFO8BNVvdAS2BG5tKfvAUVQ=.40057afe-f0b0-4456-a25e-e23ca9d98598@github.com>
 <sIHJtAk-Wtrz-YrtlwAwMKSDJlsgZcdvkYmHksdklzU=.3d183211-f0bd-4c87-aa8a-e6a772db0aa7@github.com>
 <_l_hWqje_ES147tJjeSlUGvRSVi_gv_8S3M9h3CsNfU=.f07850d6-d9a8-4eaf-91ac-bb3801093e85@github.com>
Message-ID: <yzR7UGCnZWYcMpyQVqm95RWoGahHkhNLi7vzzpvQgGY=.29eb772a-ecb3-4206-9caa-57926cf42dfb@github.com>

On Thu, 19 Aug 2021 21:06:36 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

>> Would you be able to do a quick text diagram of the dependency chain? Like 
>> 
>> a->b->c
>> d->c
>> ...
>> 
>> 
>> Is there a parent `org.openjdk.jmc.ui` where any shared classes for `rjmx.ui` and `flightrecorder.ui` can go?
>
> Sure I'll give this a try.
> 
> So what I'm having trouble with here is that `FilterEditor` ultimately needs to be used by `flightrecorder.ui.common`
> 
> FilterEditor requires celleditors, which in HEAD is split between `org.openjdk.jmc.ui.celleditors` and `org.openjdk.jmc.rjmx.ui`. The only celleditors class that FilterEditor needs is CommonCellEditors which is in jmc.ui, so there's no dependency on rjmx.ui. rjmx.ui also has a dependency on jmc.ui.
> 
> So we have:
> 
> jmc.ui.celleditors.celleditors->jmc.ui.misc.FilterEditor->flightrecorder.ui.common
> jmc.ui -> jmc.rjmx.ui
> 
> 
> If we're consolidating celleditors into rjmx.ui, then we have:
> 
> jmc.rjmx.ui -> jmc.ui.misc.FilterEditor -> flightrecorder.ui.common
> jmc.ui -> jmc.rjmx.ui
> 
> 
> In this case, we can break the cycle by moving FilterEditor elsewhere else. In the approach here I placed it in flightrecorder.ui because that's ultimately where it gets used anyways. But either way I guess it'd go rjmx.ui.celleditors -> "something" -> flightrecorder.ui, so it's a matter of being a direct dependency or not.
> 
> If instead we consolidate celleditors into jmc.ui.celleditors, then we have:
> 
> jmc.ui -> jmc.rjmx.ui
> jmc.rjmx.services + jmc.rjmx.subscription.internal -> jmc.ui.misc.FilterEditor -> flightrecorder.ui.common
> 
> because jmc.ui.celleditors would need the apporpriate files that rjmx.ui had access to from rjmx.

So I do `a -> b` as in a depends on b, but I think you went the opposite is that right? I'm getting confused lol...

I think in the second case of consolidating celleditors into jmc.ui, a bunch of stuff appears that wasn't discussed before (rjmx.services, rjmx.subscription) Where are they coming from? Can they be moved to somewhere better?

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

PR: https://git.openjdk.java.net/jmc/pull/271

From aptmac at openjdk.java.net  Fri Aug 20 13:08:28 2021
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Fri, 20 Aug 2021 13:08:28 GMT
Subject: RFR: 5904: Merge org.openjdk.jmc.ui.celleditors with
 org.openjdk.jmc.rjmx.ui.celleditors [v4]
In-Reply-To: <yzR7UGCnZWYcMpyQVqm95RWoGahHkhNLi7vzzpvQgGY=.29eb772a-ecb3-4206-9caa-57926cf42dfb@github.com>
References: <U9YY7_Yst0dzuwPDbz_PhKZ4L3fHdNOGtxjt-f5fD88=.efc5d4a1-2e71-4e8e-bcac-41ebf8e71b4f@github.com>
 <jyYzbyOp-TYnxFtvegUmYdrqhDUiYwmtxbxuxEFYyA8=.6d1b8803-febe-4357-bdcc-484154be1bfe@github.com>
 <OufPSDU4d7UBZOpUrLLScLWcuNBXgRGe6RH_4xVaVkQ=.0408fe27-1255-4fd1-8405-7ed8e9ebf638@github.com>
 <5kaWaZBZJrS_f0ENP99JQFO8BNVvdAS2BG5tKfvAUVQ=.40057afe-f0b0-4456-a25e-e23ca9d98598@github.com>
 <sIHJtAk-Wtrz-YrtlwAwMKSDJlsgZcdvkYmHksdklzU=.3d183211-f0bd-4c87-aa8a-e6a772db0aa7@github.com>
 <_l_hWqje_ES147tJjeSlUGvRSVi_gv_8S3M9h3CsNfU=.f07850d6-d9a8-4eaf-91ac-bb3801093e85@github.com>
 <yzR7UGCnZWYcMpyQVqm95RWoGahHkhNLi7vzzpvQgGY=.29eb772a-ecb3-4206-9caa-57926cf42dfb@github.com>
Message-ID: <khspaeKBcMFr4o69FeMN3IR3E9_WFnS5LKhAXGFZMKM=.49362fcb-ade2-4406-aa29-8bb19702ad0c@github.com>

On Thu, 19 Aug 2021 21:13:25 GMT, Jie Kang <jkang at openjdk.org> wrote:

>> Sure I'll give this a try.
>> 
>> So what I'm having trouble with here is that `FilterEditor` ultimately needs to be used by `flightrecorder.ui.common`
>> 
>> FilterEditor requires celleditors, which in HEAD is split between `org.openjdk.jmc.ui.celleditors` and `org.openjdk.jmc.rjmx.ui`. The only celleditors class that FilterEditor needs is CommonCellEditors which is in jmc.ui, so there's no dependency on rjmx.ui. rjmx.ui also has a dependency on jmc.ui.
>> 
>> So we have:
>> 
>> jmc.ui.celleditors.celleditors->jmc.ui.misc.FilterEditor->flightrecorder.ui.common
>> jmc.ui -> jmc.rjmx.ui
>> 
>> 
>> If we're consolidating celleditors into rjmx.ui, then we have:
>> 
>> jmc.rjmx.ui -> jmc.ui.misc.FilterEditor -> flightrecorder.ui.common
>> jmc.ui -> jmc.rjmx.ui
>> 
>> 
>> In this case, we can break the cycle by moving FilterEditor elsewhere else. In the approach here I placed it in flightrecorder.ui because that's ultimately where it gets used anyways. But either way I guess it'd go rjmx.ui.celleditors -> "something" -> flightrecorder.ui, so it's a matter of being a direct dependency or not.
>> 
>> If instead we consolidate celleditors into jmc.ui.celleditors, then we have:
>> 
>> jmc.ui -> jmc.rjmx.ui
>> jmc.rjmx.services + jmc.rjmx.subscription.internal -> jmc.ui.misc.FilterEditor -> flightrecorder.ui.common
>> 
>> because jmc.ui.celleditors would need the apporpriate files that rjmx.ui had access to from rjmx.
>
> So I do `a -> b` as in a depends on b, but I think you went the opposite is that right? I'm getting confused lol...
> 
> I think in the second case of consolidating celleditors into jmc.ui, a bunch of stuff appears that wasn't discussed before (rjmx.services, rjmx.subscription) Where are they coming from? Can they be moved to somewhere better?

Er, yeah I guess I was thinking more of a flow diagram, I have it backwards here.

The reason it  looks like most of the classes were in rjmx.ui anyways was because they use classes from rjmx. So if the classes are moved from rjmx.ui to jmc.ui, they'd still need access to those (specifically rjmx.services and subscription.internal), so we'd have to add a dependency on those to jmc.ui.

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

PR: https://git.openjdk.java.net/jmc/pull/271

From jkang at openjdk.java.net  Fri Aug 20 15:28:27 2021
From: jkang at openjdk.java.net (Jie Kang)
Date: Fri, 20 Aug 2021 15:28:27 GMT
Subject: RFR: 5904: Merge org.openjdk.jmc.ui.celleditors with
 org.openjdk.jmc.rjmx.ui.celleditors [v4]
In-Reply-To: <khspaeKBcMFr4o69FeMN3IR3E9_WFnS5LKhAXGFZMKM=.49362fcb-ade2-4406-aa29-8bb19702ad0c@github.com>
References: <U9YY7_Yst0dzuwPDbz_PhKZ4L3fHdNOGtxjt-f5fD88=.efc5d4a1-2e71-4e8e-bcac-41ebf8e71b4f@github.com>
 <jyYzbyOp-TYnxFtvegUmYdrqhDUiYwmtxbxuxEFYyA8=.6d1b8803-febe-4357-bdcc-484154be1bfe@github.com>
 <OufPSDU4d7UBZOpUrLLScLWcuNBXgRGe6RH_4xVaVkQ=.0408fe27-1255-4fd1-8405-7ed8e9ebf638@github.com>
 <5kaWaZBZJrS_f0ENP99JQFO8BNVvdAS2BG5tKfvAUVQ=.40057afe-f0b0-4456-a25e-e23ca9d98598@github.com>
 <sIHJtAk-Wtrz-YrtlwAwMKSDJlsgZcdvkYmHksdklzU=.3d183211-f0bd-4c87-aa8a-e6a772db0aa7@github.com>
 <_l_hWqje_ES147tJjeSlUGvRSVi_gv_8S3M9h3CsNfU=.f07850d6-d9a8-4eaf-91ac-bb3801093e85@github.com>
 <yzR7UGCnZWYcMpyQVqm95RWoGahHkhNLi7vzzpvQgGY=.29eb772a-ecb3-4206-9caa-57926cf42dfb@github.com>
 <khspaeKBcMFr4o69FeMN3IR3E9_WFnS5LKhAXGFZMKM=.49362fcb-ade2-4406-aa29-8bb19702ad0c@github.com>
Message-ID: <h5tkS8L5Yf05mBmklEzUQ_96DYu2kQYBaiUTVrrnd-s=.c62c968c-153e-41e6-a93a-7f90be8a3455@github.com>

On Fri, 20 Aug 2021 13:06:04 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

>> So I do `a -> b` as in a depends on b, but I think you went the opposite is that right? I'm getting confused lol...
>> 
>> I think in the second case of consolidating celleditors into jmc.ui, a bunch of stuff appears that wasn't discussed before (rjmx.services, rjmx.subscription) Where are they coming from? Can they be moved to somewhere better?
>
> Er, yeah I guess I was thinking more of a flow diagram, I have it backwards here.
> 
> The reason it  looks like most of the classes were in rjmx.ui anyways was because they use classes from rjmx. So if the classes are moved from rjmx.ui to jmc.ui, they'd still need access to those (specifically rjmx.services and subscription.internal), so we'd have to add a dependency on those to jmc.ui.

Hm, okay. I took a step back and looked at the actual issue at hand.

I think it's more intended to migrate any cell editors from ooj.rjmx.ui to ooj.ui. The cell editors in ooj.rjmx.ui that have rjmx specific code (ie. import ooj.rjmx packages) should not be moved. (Should still be analyzed whether they can be modified and moved)

rjmx.ui is a specialized subset of ui for rjmx purposes, while ui is a general set for anybody to use (rjmx, flightrecorder, etc.). Why would we want to move things from ui to rjmx if they're not specialized for rjmx purposes? Especially as you note that there's already non-rjmx users of the things.

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

PR: https://git.openjdk.java.net/jmc/pull/271

From hirt at openjdk.java.net  Fri Aug 20 18:14:29 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 20 Aug 2021 18:14:29 GMT
Subject: RFR: 5904: Merge org.openjdk.jmc.ui.celleditors with
 org.openjdk.jmc.rjmx.ui.celleditors [v4]
In-Reply-To: <h5tkS8L5Yf05mBmklEzUQ_96DYu2kQYBaiUTVrrnd-s=.c62c968c-153e-41e6-a93a-7f90be8a3455@github.com>
References: <U9YY7_Yst0dzuwPDbz_PhKZ4L3fHdNOGtxjt-f5fD88=.efc5d4a1-2e71-4e8e-bcac-41ebf8e71b4f@github.com>
 <jyYzbyOp-TYnxFtvegUmYdrqhDUiYwmtxbxuxEFYyA8=.6d1b8803-febe-4357-bdcc-484154be1bfe@github.com>
 <OufPSDU4d7UBZOpUrLLScLWcuNBXgRGe6RH_4xVaVkQ=.0408fe27-1255-4fd1-8405-7ed8e9ebf638@github.com>
 <5kaWaZBZJrS_f0ENP99JQFO8BNVvdAS2BG5tKfvAUVQ=.40057afe-f0b0-4456-a25e-e23ca9d98598@github.com>
 <sIHJtAk-Wtrz-YrtlwAwMKSDJlsgZcdvkYmHksdklzU=.3d183211-f0bd-4c87-aa8a-e6a772db0aa7@github.com>
 <_l_hWqje_ES147tJjeSlUGvRSVi_gv_8S3M9h3CsNfU=.f07850d6-d9a8-4eaf-91ac-bb3801093e85@github.com>
 <yzR7UGCnZWYcMpyQVqm95RWoGahHkhNLi7vzzpvQgGY=.29eb772a-ecb3-4206-9caa-57926cf42dfb@github.com>
 <khspaeKBcMFr4o69FeMN3IR3E9_WFnS5LKhAXGFZMKM=.49362fcb-ade2-4406-aa29-8bb19702ad0c@github.com>
 <h5tkS8L5Yf05mBmklEzUQ_96DYu2kQYBaiUTVrrnd-s=.c62c968c-153e-41e6-a93a-7f90be8a3455@github.com>
Message-ID: <5CKosy5bJVoGxqYolNphdcqrPSsgyGCK4NIRauzqRZo=.0e5eccb3-8acc-4282-b9cb-306b67621531@github.com>

On Fri, 20 Aug 2021 15:25:52 GMT, Jie Kang <jkang at openjdk.org> wrote:

>> Er, yeah I guess I was thinking more of a flow diagram, I have it backwards here.
>> 
>> The reason it  looks like most of the classes were in rjmx.ui anyways was because they use classes from rjmx. So if the classes are moved from rjmx.ui to jmc.ui, they'd still need access to those (specifically rjmx.services and subscription.internal), so we'd have to add a dependency on those to jmc.ui.
>
> Hm, okay. I took a step back and looked at the actual issue at hand.
> 
> I think it's more intended to migrate any cell editors from ooj.rjmx.ui to ooj.ui. The cell editors in ooj.rjmx.ui that have rjmx specific code (ie. import ooj.rjmx packages) should not be moved. (Should still be analyzed whether they can be modified and moved)
> 
> rjmx.ui is a specialized subset of ui for rjmx purposes, while ui is a general set for anybody to use (rjmx, flightrecorder, etc.). Why would we want to move things from ui to rjmx if they're not specialized for rjmx purposes? Especially as you note that there's already non-rjmx users of the things.

Here is some context for my comment. 

Right now you could very well deliver a build of JMC that is only a JMX console. All you'd have to do was to have a few of the features bundled together (core, mbeanbrowser, console, blabla and leave out what you don't want, e.g. leaving out the joverflow and jfr features). Similarly you could package a new tool that is only a JFR tool, used exclusively to open flight recording files, and nothing else.

By requiring rjmx.ui to have a dependency on flightrecorder.ui, the dependency waters get muddied. For building a tool that uses rjmx.ui, you now always need to drag in the entire flightrecorder ui.

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

PR: https://git.openjdk.java.net/jmc/pull/271

From rafer.gluyas at gmail.com  Sun Aug 22 00:03:59 2021
From: rafer.gluyas at gmail.com (Rafer Gluyas)
Date: Sun, 22 Aug 2021 08:03:59 +0800
Subject: dropins failure workaround for IParser implementations: build
 configuration issue
Message-ID: <CA+f1+Akyjp+pYcGJd+Rde2OJoBBM57W2oKbUGpe4yboPj+Do-Q@mail.gmail.com>

I've been having a look at the mission control codebase - with the
intention of implementing custom parsers (that extend the IParser
interface). However, due to https://bugs.openjdk.java.net/browse/JMC-5994
(ie the dropins folder doesn't work) I haven't made progress.

I've since changed direction a bit to try and prove it is possible to get
this working using another method ~ so I shifted the functionality of the
solution into a external module and tried to get JMC-core to include it
when it is built.

I've included this in the dependencies of
core/org.openjdk.jmc.flightrecorder/pom.xml

                </dependency>
+               <dependency>
+                 <groupId>org.rafe</groupId>
+                 <artifactId>jfrProcessor</artifactId>
+                 <version>0.0.1-SNAPSHOT</version>
+               </dependency>
        </dependencies>

And I have visually verified this by checking the dependency tree - and the
relevant jar is there. However when I do 'mvn package' in the root
directory - the jar is not included.

Can anyone point me in the direction of what I'm missing?

From hdafgard at openjdk.java.net  Tue Aug 31 00:05:31 2021
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Tue, 31 Aug 2021 00:05:31 GMT
Subject: RFR: 7231: JMC createReport for JMC8 Automated Analysis fails to
 evaluate several rules
In-Reply-To: <7A74lcRU7j2A9qas1BwWturLRNFuLIcUs5fAhv5IoTY=.8e9f35d2-07ec-4347-b5ee-c2c9a2926cce@github.com>
References: <7A74lcRU7j2A9qas1BwWturLRNFuLIcUs5fAhv5IoTY=.8e9f35d2-07ec-4347-b5ee-c2c9a2926cce@github.com>
Message-ID: <fCtUimh0VFI-ydXidZysSKMdpIZS5Vom2BX6J7N-BoM=.0f773e97-c4b6-48f4-9904-efd7904a56ad@github.com>

On Mon, 9 Aug 2021 23:15:26 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

> This PR addresses the NullPointerException issue in core module for the following rules:
> 
> 1. GCs Caused by System.gc()
> 2. GCs Caused by Heap Inspection
> 3. GC Stall
> 4. String Deduplication
> 5. GCs Caused by GC Locker

The ResultProvider should always be available for a IRule imlementation. If it isn't then that's a bug that we need to fix instead. I'd rather fix that at the source than adding null checks all over the code.

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

PR: https://git.openjdk.java.net/jmc/pull/302