JDK 7 has changed its behavior with respect to MBeanInfo 'equals()' comparisons being
true for two mbeans using the same interface definitions either loaded by two different classloaders in the same VM, or across two runs of the same JVM, or for mbeans cascaded from another jvm.

Since MBeanInfo objects are large, this causes heap exhaustion at scale.

Closer examination shows that the mbeanInfos in question have the same hashcode but have a different ordering of either attributes or operations which are each stored in arrays - meaning that the 'equals()' method is no longer returning true, making them unsharable.

Further examination shows that this is due to a change in the behavior of the JDK's reflection, which is no longer returning methods in a deterministic ordering, hence causing the MBeanInfo, which is constructed by reflection, to have its attributes and/or operations in a non-deterministic order - see 7023180