JDK Mission Control 9 changed its integration contract vs JMC 8 such that he 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 EAP 8.1 we should move to the 9+ Fragment-Host integration value.

Note that a downside to aligning with JMC 9 in previous EAP releases was that it requires a minimum of JDK 17 to run, while previous EAP releases had lower minimums. The SE version used for JMC doesn't have to match what is used for EAP, 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 EAP does. But with EAP 8.1, 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.

As a manual verification step for this change I recommend integrated the updated jar with both JMC 9.0 and 9.1 and confirming that JMC can integrate with both an EAP 8.0 and an EAP 7.4 server.

We should also validate that a JMC 8 installation with the EAP 8.0.x and 7.4.x versions of remoting-jmx integrated is able to integrate with an EAP 8.1 server. That's somewhat tangential to this upgrade, but not fully tangential. It demonstrates that there is a path for users who need to stay on JMC 8 to do so. (Note, however, that 8.0.x will stop receiving updates when 8.1 GA is released.)