Right, the existing Deprecated tag had me thinking this was a Java SE interface that had begun the deprecation process. But it's not a published API.
Maybe we can go further: HotspotCompilationMBean and HotspotInternalMBean look unused. They are not exposed in the standard PlatformMBeanServer. While looking for who/what uses these, I also found a recent mailing list thread: "Question on why sun.management MBeans are not exported?" https://www.mail-archive.com/[email protected]/msg19878.html ..where the idea of removal also came up. Thanks Kevin From: Eirik Bjørsnøs <[email protected]> Sent: 17 March 2024 18:43 To: Kevin Walls <[email protected]> Cc: [email protected] Subject: [External] : Re: RFD: Can we remove per-thread compiler stats now? On Fri, Mar 15, 2024 at 7:54 PM Kevin Walls <[email protected]<mailto:[email protected]>> wrote: https://openjdk.org/jeps/277 "An API element should not be removed from the Java SE specification unless it has been delivered with an annotation of @Deprecated(forRemoval=true) in a previous version of Java SE." So deprecations need to be "upgraded" to forRemoval, this will take a few updates to get them removed. Hmm.. But if sun.management.HotspotCompilationMBean is an internal class, it's not defined in the Java SE Specification, right? My understanding when working on similar core-libs cleanups is that internal APIs can be removed directly without the need for a forRemoval step. HotspotCompilationMBean: @Deprecated public java.util.List<CompilerThreadStat> getCompilerThreadStats(); .. need to consider whether a method is removed or just "degraded" (not return any information, or throw). I think this is already "degraded" in the sense that it does not return useful information (underlying counters are long removed). My intention here is to remove crufty leftover code. I think the best outcome is if we can remove the code so maintainers no longer need to see or reason about it. That said, I see sun.management.CompilationImpl[java.lang:type=Compilation] ..rather than HotspotCompilation. ManagementFactoryHelper.java: getCompilationMXBean() specifically creates a CompilationImpl, users don’t normally see the HotspotCompilation mbean. This and the rest goes into code and concepts I'm not very familiar with (yet!), so I'm not sure I understand the implications well. But do you think perhaps the whole HotspotCompilationMBean with implementation could be removed? I'm not sure I see any consumers within OpenJDK of this interface? The role of HotspotCompilationMBean needs more investigation, but basically yes to the idea. 8-) Good! It seems there is potential for some level of cleanup here, so I'll go ahead and make a PR where we can continue the discussion. Thanks, Eirik.
