Proposal: Moving/refactoring some more bundles/packages/classes from application into core

[Jie Kang]

Hi,

For 8.0.0 and beyond I would like to propose moving some portion of
the below bundles/packages/classes from application module into core
module for easier re-use by third-party applications. I've tried to
divide things into sensible sets and provide a quick explanation for
each. I'm willing to prepare patches for sets on a case-by-case basis
but would like some opinions now before I start to put in a large amount
of work.

Bundle:
org.openjdk.jmc.flightrecorder.configuration

This bundle contains classes used to manipulate the configuration for
a Flight Recording. For example to describe which events should be
enabled and with what parameters when starting a recording. It
requires one bundle and imports one package, both from core. I think
moving the entire bundle is low risk.

Bundle:
org.openjdk.jmc.jdp

This bundle contains classes used to discover JVM services on a
network. It has zero imports. I think moving the entire bundle is low
risk.

Bundles:
org.openjdk.jmc.rjmx
org.openjdk.jmc.rjmx.services.jfr

These bundles are used to provide jfr rjmx client side API to connect
to a JVM and start/stop/extract flight recordings, etc. Moving these,
or some part of these would require some refactoring (yet to analyze),
and would be higher risk. Conceptually, I think it makes sense to
provide these features in core for third-party applications to use.

Bundle:
org.openjdk.jmc.ui.common
Package group:
org.openjdk.jmc.ui.common.security

Some of the packages in this bundle don't seem to fit the term 'ui'.
Specifically the security package provides a SecurityManager, one use
being secure rjmx connections for the above org.openjdk.jmc.rjmx and
org.openjdk.rjmx.services.jfr functionality. In general it's used to
securely store usernames/passwords in various configuration pages.
This comes about as a dependency from using the rjmx code; moving this
may also require some refactoring and rework.


Usage of these bundles comes from work to reuse existing code
to manage connections to JVMs for JFR related tasks, starting,
stopping, extracting recordings, etc. I think it makes sense to have
this capability in the exported API, core. I'd appreciate your
opinions on this proposal, thanks!


Regards,