United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6190628 Standard MBeans should support covariant return types in MBean interfaces.
JDK-6190628 : Standard MBeans should support covariant return types in MBean interfaces.

Details
Type:
Enhancement
Submit Date:
2004-11-04
Status:
Resolved
Updated Date:
2010-07-29
Project Name:
JDK
Resolved Date:
2005-06-08
Component:
core-svc
OS:
solaris_9
Sub-Component:
javax.management
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0
Fixed Versions:

Related Reports
Relates:
Relates:

Sub Tasks

Description
MBean compliance test doesn't support covariant return types in MBean interfaces.

For instance:

public interface ParentMBean {
    public Object getState();
    public void setState(Object state);
}

public interface ChildMBean extends ParentMBean {
    public String getState();
    public void setState(String state);
}

The code above compiles but when trying to register a ChildMBean
in the MBeanServer the following exception is thrown:

Exception in thread "main" javax.management.NotCompliantMBeanException: Type mismatch between parameters of get or isState, setState methods
	at com.sun.jmx.mbeanserver.Introspector.testConsistency(Introspector.java:399)
	at com.sun.jmx.mbeanserver.Introspector.introspect(Introspector.java:348)
	at com.sun.jmx.mbeanserver.Introspector.testCompliance(Introspector.java:208)
	at com.sun.jmx.mbeanserver.Introspector.testCompliance(Introspector.java:150)
	at com.sun.jmx.mbeanserver.StandardMetaDataImpl.buildMBeanInfo(StandardMetaDataImpl.java:116)
	at com.sun.jmx.mbeanserver.StandardMetaDataImpl.testCompliance(StandardMetaDataImpl.java:149)
	at com.sun.jmx.mbeanserver.MetaDataImpl.testCompliance(MetaDataImpl.java:125)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(DefaultMBeanServerInterceptor.java:300)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(DefaultMBeanServerInterceptor.java:211)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.createMBean(JmxMBeanServer.java:301)
	at Main.main(Main.java:26)
###@###.### 11/4/04 09:36 GMT

                                    

Comments
EVALUATION

Will require some spec work.  In particular this is tricky when you change the type of a read/write attribute:

public interface ParentMBean {
    public Number getNumber();
    public void setNumber(Number n);
}

public interface ChildMBean extends ParentMBean {
    public Integer getNumber();
    public void setNumber(Integer n);
}

ChildMBean overrides getNumber, but overloads setNumber.  An implementation of ChildMBean will need to implement both setNumber methods.  Additionally, it must probably accept any Number argument to setNumber, which is inconsistent with the fact that it will return Integer from getNumber.

Probably this case must be outlawed.  What we can allow is for a subclass to override a read-only attribute covariantly.  It can make the attribute read/write if it wants -- a user of the superclass still sees the attribute as read-only.

Potentially we could also allow a subclass to overload a write-only attribute contravariantly.  For instance:

public interface ParentMBean {
    public void setNumber(Integer n);
}

public interface ChildMBean {
    public void setNumber(Number n);
}

However, the checks for this are more difficult and this case seems unlikely in practice.
###@###.### 11/4/04 10:15 GMT

The formal rules are as follows.  These rules are intended to cover even interfaces that could not have been generated by the Java compiler (for example with two methods called getX() that have unrelated return types).
 
If the Java interface for a standard MBean is I, then we construct the set S of all methods in I and in all superinterfaces of I.  Given two methods msuper and msub with the same name, if the parameters of the two methods are identical (ignoring generics), and if the return type of msuper is a supertype of the return type of msub, and if the most specific interface in which msuper is declared is a superinterface of the most specific interface in which msub is declared, then msub "covariantly overrides" msuper.  Methods in S that are covariantly overridden are ignored when constructing the MBean interface from I.
 
A method is a "getter" if its name is "getX" for some non-empty string X, and it has no parameters, and its return type is not void.  A method is a "setter" if its name is "setX" for some non-empty string X, and it has one parameter, and its return type is void.
 
The operations in the MBean interface are the methods in S that are neither getters nor setters.  If, after eliminating covariantly overridden methods, two operations have the same name and the same parameters (ignoring generics) then the Standard MBean is illegal.
 
If there exists a getter called getX but no setter called setX then the MBean interface has a read-only attribute called X whose type is the return type of getX.  If, after eliminating covariantly overridden methods, there are two methods called getX with different return types (ignoring generics) then the Standard MBean is illegal.
 
If there exists a setter called setX but no getter called getX then the MBean interface has a write-only attribute called X whose type is the parameter type of setX.  If there are two methods called setX with different parameter types (ignoring generics) then the Standard MBean is illegal.
 
If there exist both a getter called getX and a setter called setX then the MBean interface has a read-write attribute called X.  The return type of getX must be the same as the parameter type of setX (ignoring generics), and this is the the type of the attribute X.  If this condition is not met, the Standard MBean is illegal.
 
These rules imply that operations and read-only attributes can be covariantly overridden, but read-write and write-only attributes cannot.  This makes sense because if a subinterface changed the type of a writable attribute to a subtype then it would violate substitutability.
###@###.### 2005-03-22 15:56:20 GMT
###@###.### 2005-03-22 17:13:06 GMT
                                     
2004-11-04



Hardware and Software, Engineered to Work Together