On 9/6/23 8:17 AM, Volker Simonis wrote:
Anyway, if you classify the MBeans in "sun.management" as non-critical
internal APIs (with respect to JEP 260) but without any "internal"
usage, than we should really remove them, right, because an internal
API without any internal usage doesn't make any sense?
We added these HotSpot internal MBeans in JDK 5 to expose the internal
metrics. Most of these internal metrics are exposed via jstat tool
too. We didn't receive much feedback regarding these HotSpot internal
MBeans. Removing them is fine and good cleanup effort.
Mandy
I'll then try to come up with a proposal to port some of the more
useful MBeans functionality in "sun.management" to
"com.sun.management".
Thank you and best regards,
Volker
:
So to cut a long story short, I see several options:
1. Publicly export sun.management and restore the JDK 8 (or pre JDK
16) behavior. This would certainly require some polishing (e.g. some
of the corresponding JVM functionality has already been removed [1])
but I think it could still be quite useful.
2. Port the useful functionality from the "sun.management" MBeans to
corresponding "com.sun.management" MBeans and remove the
"sun.management" MBeans.
3. Remove the "sun.management" MBeans without substitution.
What do you think?
If there are JDK-specific or HotSpot VM specific features where there is
a compelling case for a management interface then com.sun.management is
good place to prototype new APIs. You may already be familiar with
com.sun.management.HotSpotDiagnosticMBean.
-Alan
