Consider the following classes:

public class Gen<T> {
    public T getThing() {...}
}

public class NonGen extends Gen<String> {
    public String getThing() {...}
}

and an MXBean interface that references NonGen:

public interface TestMXBean {
    public NonGen getFoo();
}

We would expect this to work the same as if NonGen had no superclass.  But in fact it does not.  NonGen has a synthetic method (generated by the compiler) which looks like "public Object getThing()" and which calls the declared method "public String getThing()".  The MXBean framework sees the two methods called getThing() and complains.  It should recognize that this is covariance, using the same logic already present for MBean interfaces, and drop the covariantly-overridden method.

Ideally we would also like to be able to use this class:

public class NonGen extends Gen<String> {}

which does not override the getThing() method from Gen at all.  But this would require the MXBean framework to be able to match the return type T of the inherited getThing() method with the parameter T of the superclass.  The logic to do this correctly is not tremendously complicated but it's not trivial either, so given that there's a simple work-around (just override the method and call the superclass method from it) we can afford not to fix that problem for now.  The logic in question would basically have to run up the supertype hierarchy (the transitive closure of all superclasses and superinterfaces) while tracking the meaning of each type parameter as it goes.