Both of these classes were deemed internal and no external plugins should be referencing these classes. Also both classes are in the AS feature, so any user updating ONLY the AS feature will have updated versions of both classes. 

Strictly speaking, it would break api compatability in the case where a user updates the jmx.integration plugin (a plugin in the AS tools area, not the jmx area) and does NOT update as.core.  This is a very very unlikely scenario. The way I understand our updates, they're done on a per-feature basis. 

Now, there are in fact two different features here. There's a jbosstools-server/as/features/org.jboss.ide.eclipse.as.jmx.integration.feature (which includes this plugin here)  and a jbosstools-server/as/features/org.jboss.ide.eclipse.as.serverAdapter.wtp.feature (which includes as.core, the old superclass), however, the integration feature requires the serverAdapter.wtp feature, so any update to the integration feature would (I HOPE??) force an update on the serverAdapter.wtp feature, and, again, there'd be no problems. 

I view this as a niche case, but if you genuinely see this as a true issue, I can duplicate the class for maintenance. 

Remember, binary incompatibility only occurs if you have old versions of one jar running against new versions of another. If there are new versions of both jars, then there is no incompatibility. So if you can think of any situation in which an old as.core will be running with the new jmx.integration, then that would be a breakage.