On Wed, Sep 6, 2023 at 3:47 PM Alan Bateman <alan.bate...@oracle.com> wrote: > > On 06/09/2023 14:02, Volker Simonis wrote: > > : > > > > I wonder why "sun.management" was encapsulated in the first place? I > > understand that it is not an "officially supported" API, but I find it > > still quite useful. > sun.management.* is JDK internal so not something for code outside the > JDK to use directly. The only sun.* packages that are exported to all > modules are the "critical internal APIs" in the jdk.unsupported module. > JEP 260 has the details.
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. 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? 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
