Bug ID: JDK-6376416 MXBean spec does not forbid parameterized types but implementation does

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
tbdUnresolved

The MXBean specification says how certain parameterized types such as List<String> are handled, but does not say what happens with types that are not in this list.  So for example, if I define...
    public class Whatsit<T> {
        public T getThing() {...}
    }
...then following the rules specified in javax.management.MXBean, I would expect "Mappings for other types" to apply, so that an MXBean interface like this...
    public interface SomeMXBean {
        public Whatsit<String> getA();
    }
...would define an attribute called A with the same type as if I had defined this...
    public class Whatsit {
        public String getThing() {...}
    }
    public interface SomeMXBean {
        public Whatsit getA();
    }
But the current implementation rejects this.  Either the spec should be changed to rule out this case, or the implementation should be changed to accept it.

EVALUATION No time to fix this for Mustang. Revisit for Dolphin. Meanwhile people will have to avoid generic types in MXBeans, except in the limited cases allowed by 6406447.

20-06-2006

EVALUATION There are actually several things that do not work, though they might be expected to. Suppose we have a generic class Gen<T> like this: public class Gen<T> { public T getThing() {...} } Then this MXBean is illegal: public interface TestMXBean { public <T> Gen<T> getFoo(); } So is this one: public interface TestMXBean { public Gen<String> getBar(); } And this one: public class GenMethod { public <T> Gen<T> getWhatever() {...} } public interface TestMXBean { public GenMethod getBaz(); } So far so good. All of these cases would be covered by a spec rule that says that parameterized types are only allowed if they are one of the specific cases covered by the rules (List<String> etc), and the type parameter(s) are types not type variables. It happens that the following MXBean is rejected, but with a ClassCastException (which is not the right exception): public interface TestMXBean { public <T> List<T> getFoo(); } And the following MXBean, which should surely be accepted, is in fact rejected with a ClassCastException too: public class Concrete extends Gen<String> {} public interface TestMXBean { public Concrete getFoo(); } Adding an explicit override of getThing() changes the exception: public class Concrete extends Gen<String> { @Override public String getThing() {...} } -> "javax.management.openmbean.OpenDataException: Class GenericMethodMXBean$Concrete has method name clash: getThing, getThing" In the last case, the compiled class has two getThing() methods, with a synthetic one returning Object which calls the declared one returning String. It is hard to see how we could change the spec to forbid the case of Conrete, with or without an explicit override. Possibly we could say: "A type to be mapped cannot be a parameterized type other than the ones just listed, nor can it have a type parameter that is a type variable, nor can it have a parent class or interface with a type parameter." This is seriously unwieldy, though.

17-03-2006

EVALUATION It's probably not worth complicating the spec and implementation to cover this sort of case, so it should be forbidden explicitly. Parameterized methods such as <T> T getA(); should also be forbidden explicitly.

24-01-2006