What we're referring to is to remove sun.management.Hotspot*, the
internal MBeans which are never exposed and registered in the platform
MBeanServer. The internal metrics in HotSpot VM should be retained as
they are exposed through other ways like jstat, GC logs, etc.
Mandy
On 9/6/23 11:27 PM, Kirk Pepperdine wrote:
Hi,
It would be a shame to lose these metrics because many of them have been very
useful over time and some would be even more useful with some modifications.
For example, the CPU breakouts found in GC logs has been incredibly useful as a
proxy measure in helping sort out other issues in systems. So much so that I
have analytics built specifically around this in my tooling.
Kind regards,
Kirk Pepperdine
On Sep 6, 2023, at 10:50 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
On 06/09/2023 16:17, Volker Simonis wrote:
:
I'm familiar with JEP 260. But wouldn't you agree that an
"encapsulated" monitoring API is an oxymoron? A monitoring API is by
design intended for external usage and completely useless to the
platform itself. There's no single usage of the "sun.management"
MBeans in the JDK itself (except for jconsole where the encapsulation
broke it). My assumption is that the corresponding MBeans in
"sun.management" are there for historic reasons (added in JDK 1.5) and
would have made much more sense in "com.sun.management" package. But I
doubt that they can be classified in the "internal implementation
details of the JDK and never intended for external use² category of
JEP 260.
It's left over from experiments on exposing some internal metrics, I think
during JDK 5. It's code that should probably have been removed a long time ago.
-Alan
