RFR: 7069: Move rjmx bundle from application to core [v9]

[Alex Macdonald]

On Tue, 5 Dec 2023 17:49:59 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

>> This PR addresses JMC-6627 [[0]](https://bugs.openjdk.org/browse/JMC-6627) in which it would be nice to bring some bundles from application to core. Most notably, **flightrecorder.configuration** which has a PR open for review [[1]](https://github.com/openjdk/jmc/pull/469) and is also tracked by JMC-7307 [[2]](https://bugs.openjdk.org/browse/JMC-7307), and **RJMX** which is also tracked by JMC-7069 [[3]](https://bugs.openjdk.org/browse/JMC-7069).
>> 
>> While #469 is still under review, I copied a branch of it and squashed all the commits down into one commit [[4]](https://github.com/openjdk/jmc/commit/72c08b3f65671d16fcbb1333a5782e10ac9c874f) for easier rebasing. Review comments for flightrecorder.configuration should go towards #469.  RJMX does have reliance on the flightrecorder.configuration changes (and some still in ui.common), so the second commit [[5]](https://github.com/openjdk/jmc/commit/f1c828dd46f24d9075cd3eedbf5a15bb9daf9a72) here is where this PR really starts. Once #469 is merged I can rebase this PR so that it handles RJMX.
>> 
>> As mentioned in JMC-6627 [[0]](https://bugs.openjdk.org/browse/JMC-6627), because of the way Eclipse is intertwined with the RJMX code, this isn't a straightforward movement of classes. There are some parts that will need to stay on the side of jmc/application, but much of the code can come over to jmc/core with modification. This is accomplished by having a `rjmx.common` module in core, and keeping regular `rjmx` in application.
>> 
>> There are a handful of classes (e.g., `NameConverter`, `SyntheticAttributeRepository`, `SyntheticNotificationRepository`, ..) that use Eclipse to initialize them by parsing through values in plugin.xml, or use classes (like Persistence and Preferences) that are closely tied to the Eclipse RCP side of things. I brought over these classes to core and kept the code that initializes the values from extensions on the application side, so they could be set from application -> core when running JMC, but for third-party applications that want to use the RJMX code then they might not need/require this initialization.
>> 
>> [0] https://bugs.openjdk.org/browse/JMC-6627
>> [1] https://github.com/openjdk/jmc/pull/469
>> [2] https://bugs.openjdk.org/browse/JMC-7307
>> [3] https://bugs.openjdk.org/browse/JMC-7069
>> [4] https://github.com/openjdk/jmc/commit/72c08b3f65671d16fcbb1333a5782e10ac9c874f
>> [5] https://github.com/openjdk/jmc/commit/f1c828dd46f24d9075cd3eedbf5a15bb9daf9a72
>
> Alex Macdonald has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent in rjmx.common.services.jfr package-info.java

As mentioned in the bi-weekly dev team meeting yesterday, Marcus gave this PR the rubber stamp of approval and mentioned it should go in soon to allow more time for testing and potential fixes during rampdown 1. I gave it the day to sit just in-case there were any straggling reviews, but plan on integrating this shortly as a heads up.

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

PR Comment: https://git.openjdk.org/jmc/pull/531#issuecomment-1846025463