-
Bug
-
Resolution: Fixed
-
P3
-
6
-
None
-
b53
-
generic
-
generic
In Tiger, the package java.lang.management (j.l.m) introduced the concept of MXBeans, which are type-mapped MBeans. This package defines a number of predefined MXBeans but does not provide the mechanisms to users to developer their own MXBeans.
In Mustang, the JMX API now does include the ability to create user MXBeans. But the implementation of MXBeans in j.l.m does not use the same code as of now. This means that there are some differences in behavior between the j.l.m MXBeans and user MXBeans:
- User MXBeans have Descriptors that include e.g. fields openType and originalType describing the type mapping.
- User MXBeans use OpenMBeanAttributeInfoSupport and other Open*Info* classes where possible, while j.l.m MXBeans always use plain MBeanAttributeInfo etc.
- User MXBeans can participate in inter-MXBean references (which become ObjectNames after type mapping), while j.l.m MXBeans can't.
In addition to these differences, it is obviously preferable to use the same code everywhere rather than having two different implementations of the same functionality.
In Mustang, the JMX API now does include the ability to create user MXBeans. But the implementation of MXBeans in j.l.m does not use the same code as of now. This means that there are some differences in behavior between the j.l.m MXBeans and user MXBeans:
- User MXBeans have Descriptors that include e.g. fields openType and originalType describing the type mapping.
- User MXBeans use OpenMBeanAttributeInfoSupport and other Open*Info* classes where possible, while j.l.m MXBeans always use plain MBeanAttributeInfo etc.
- User MXBeans can participate in inter-MXBean references (which become ObjectNames after type mapping), while j.l.m MXBeans can't.
In addition to these differences, it is obviously preferable to use the same code everywhere rather than having two different implementations of the same functionality.