Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6278707

Updates to MXBean specification


    • Type: Enhancement
    • Status: Resolved
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: 6
    • Fix Version/s: 6
    • Component/s: core-svc
    • Labels:
    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:


      After review within the JMX and serviceability teams and feedback from Quality Engineers and the JSR 255 Expert Group, a number of changes are proposed to the MXBean specification as integrated into b40 of Mustang.

      * MBeanServerInvocationHandler acquires getters to retrieve the
        parameters that were supplied to the constructor:

        MBeanServerConnection getMBeanServerConnection();
        ObjectName getObjectName();
        boolean isMXBean();

        Specified: MBeanServerInvocationHandler javadoc.

      * A new method in javax.management.JMX tests whether a Class is an
        MXBean interface:

        public boolean isMXBeanInterface(Class<?> interfaceClass);

        Specified: javax.management.JMX javadoc.

      * The class javax.management.StandardMBean implements the
        MBeanRegistration interface. When it is used to construct an
        MXBean, this allows it to track the name under which the MXBean is
        registered, in order to handle inter-MXBean references correctly.
        In the existing implementation, this was done by a back door between
        the MBean Server and this class, but that isn't available to a
        replacement MBean Server substituted via the MBeanServerBuilder

        Existing subclasses of StandardMBean that already implement
        MBeanRegistration cannot be MXBeans since user MXBeans didn't exist
        in Tiger. The spec recommends that new code that subclasses
        StandardMBean and implements MBeanRegistration insert the
        appropriate super.preRegister etc calls.

        Specified: StandardMBean javadoc.

      * Standard MBeans and MXBeans have a new Descriptor field "mxbean"
        with value "true" or "false" as appropriate. This field is also
        present in every instance of the StandardMBean class.

        Specified: Descriptor javadoc.

      * A number of minor changes are made to the MXBean mapping rules
        describing how to reconstruct an object from a CompositeData:

        - A clearer separation is made between the conditions that must hold
          for a given rule to apply, and the conditions that mean that the
          object is not reconstructible. If one of the second set of
          conditions is not met, later rules are not tried.

        - The order of the rules is changed. If a class has a constructor
          with a @PropertyNames annotation, then that is preferred even if
          the class also has a zero-arg constructor and a setter for every

        - If more than one constructor has a @PropertyNames annotation, then
          the constructor to use must be unambiguous regardless of what
          items are present in any CompositeData. Previously some cases of
          ambiguity were only noticed when a given CompositeData instance
          was being translated.

        Specified: javax.management.MXBean javadoc, section "Reconstructing
        an instance of Java type J from a CompositeData".

      * For compatibility with the existing java.lang.management
        specification, when a primitive type such as int appears in a
        parameter or return value of a method in an MXBean interface, the
        corresponding MBeanParameterInfo, MBeanAttributeInfo, or
        MBeanOperationInfo must return "int" from its getType() or
        getReturnType() method. This means that it cannot be an
        OpenMBeanParameterInfo etc, which in turn means that the overall
        MBeanInfo cannot be an OpenMBeanInfo. The information about
        OpenTypes is still available through the "openType" field of the
        Descriptor for each MBeanParameterInfo etc.

        The specification does not require or forbid using an
        OpenMBeanParameterInfo etc when primitive types are not involved.

        Specified: javax.management.MXBean javadoc, section "MBeanInfo
        contents for an MXBean".

      * For compatibility with the existing java.lang.management behaviour,
        a problem in translating from Open Types or Open Data into Java Types
        or Java Data is signaled with a java.io.InvalidObjectException. Given
        the documented meaning of this exception, we continue to use the more
        appropriate exception OpenDataException for a problem in translating
        Java Types or Java Data to Open Types or Open Data.

        Specified: javax.management.MXBean javadoc, section "Exceptions".
      ###@###.### 2005-06-01 14:18:22 GMT

      Further changes:

      * As for @PropertyNames, items can be missing in the CompositeData from which we are reconstructing a Java class in the case where it comes from a no-arg constructor plus setters. The setters for the missing items are not called.

      * Specify that the MBeanInfo for an MXBean contains an MBeanNotificationInfo[] that is derived with NotificationBroadcaster.getNotificationInfo() at the time the MXBean is registered. If the MXBean does not implement NotificationBroadcaster, then the array is empty.

      * Specify that the MBeanInfo for an MXBean contains an MBeanConstructorInfo[] containing the publicly-visible constructors of the MXBean. MXBean type mappings do not apply to constructor parameters.
      ###@###.### 2005-06-03 13:22:30 GMT


          Issue Links



              • Assignee:
                emcmanus Eamonn McManus
                emcmanus Eamonn McManus
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: