On Fri, Mar 15, 2024 at 7:54 PM Kevin Walls <kevin.wa...@oracle.com> 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.
