JDK Mission Control 9 changed its integration contract vs JMC 8 such that the MANIFEST.MF of a jar to be integrated must have a Fragment-Host as follows:

Fragment-Host: org.openjdk.jmc.rjmx.common

In JMC 8 and earlier the value needed to be "org.openjdk.jmc.rjmx".

Our investigations show no way to provide both values to allow a single jar to integrate with both JMC 9 and later and 8 and earlier.

Since the most recent JMC 8 release came out in late 2022, while 9.0 came out in 2024, with the 9 series up to 9.1.1, for WildFly 37 we should move to the 9+ Fragment-Host integration value.

Note that a downside to aligning with JMC 9 in previous releases was that it requires a minimum of JDK 17 to run, while previous appserver releases had lower minimums. The SE version used for JMC doesn't have to match what is used for the appserver, and newer JMCs can integrate with processes running older SE versions than is required for the JMC process. But still, it's not great to baseline tool integration on a tool version that requires a higher minimum SE than the appserver does. But since WildFly 35, the server baseline is SE 17, so that argument against baselining on JMC 9 is removed.

Note that later versions of JMC require SE 21, but the integration contract is unchanged, so a remoting-jmx library that integrates with JMC 9.0 will work with JMC 9.1.