Why aren't MXBeans OpenMBeans?

In a
comment on my last entry, rgreig asks:

One thing that struck me about MXBeans is that they are
really fusion of standard MBeans and OpenMBeans, since they only
use standard types. However they don't actually conform to
OpenMBean conventions.

Why was the decision taken not to make MXBeans OpenMBeans?
(i.e. return an OpenMBeanInfo from getMBeanInfo())

Therein lies a tale!

MXBeans really are OpenMBeans. But as you note they don't
return OpenMBeanInfo. However, in Mustang, all the same information that would have been in the OpenMBeanInfo is present via href="http://download.java.net/jdk6/doc/api/javax/management/Descriptor.html">
Descriptors.

Instead of...

MBeanInfo mbi = mbeanServer.getMBeanInfo(objectName);
MBeanAttributeInfo mbai = mbi.getAttributes()[0];
<b>OpenMBeanAttributeInfo ombai = (OpenMBeanAttributeInfo) mbai;</b>
OpenType ot = <b>ombai.getOpenType();</b>

...you can use...

MBeanInfo mbi = mbeanServer.getMBeanInfo(objectName);
MBeanAttributeInfo mbai = mbi.getAttributes()[0];
<b>Descriptor d = mbai.getDescriptor();</b>
OpenType ot = <b>(OpenType) d.getFieldValue("openType");</b>

This fusion of OpenMBeanInfo functionality into plain MBeanInfo
means that you can have OpenModelMBeans and other strange
beasts.

Nevertheless, we did originally plan for MXBeans to return
OpenMBeanInfo. The reason they don't is subtle.

In the original incarnation of MXBeans, in href="http://download.java.net/jdk6/doc/api/java/lang/management/package-frame.html">
java.lang.management, we wanted to use the type
long[] in the href="http://download.java.net/jdk6/doc/api/java/lang/management/ThreadMXBean.html">
ThreadMXBean. But OpenTypes didn't support arrays of
primitive types - they would only have supported
Long[], substantially less efficient. So we avoided
using OpenMBeanInfo in Tiger with the intent
of fixing this problem in Mustang.

It now is possible to have an href="http://download.java.net/jdk6/doc/api/javax/management/openmbean/ArrayType.html#getPrimitiveArrayType(java.lang.Class)">
array of primitive type as an OpenType, so we could now
describe the ThreadMXBean with an OpenMBeanInfo. However, there
are some interoperability concerns that we didn't foresee.

Suppose you have a Tiger client, say href="http://weblogs.java.net/blog/emcmanus/archive/2005/06/nice_gettingsta.html">
jconsole running on Tiger, talking to a Mustang server. Since
long[] didn't exist as an OpenType in Tiger, if we
sent an OpenMBeanParameterInfo with type
long[] to a Tiger, it will see it as if its type
were Long[]. Suppose it lets the user
call a method like

<a href="http://download.java.net/jdk6/doc/api/java/lang/management/ThreadMXBean.html#getThreadInfo(long[])">
	  ThreadMXBean.getThreadInfo(long[] ids)</a>

src="http://weblogs.java.net/blog/emcmanus/threadmxbean.gif"
width="642" height="350" />

If jconsole saw an OpenMBeanParameterInfo for a
Long[] then it would expect the signature array in href="http://download.java.net/jdk6/doc/api/javax/management/MBeanServerConnection.html#invoke(javax.management.ObjectName,%20java.lang.String,%20java.lang.Object[],%20java.lang.String[])">
MBeanServerConnection.invoke to contain
Long[].class.getName(),
i.e. "[Ljava.lang.Long;". But since the
parameter is really a long[], it should be
long[].class.getName(), i.e. "[J".
If you pass the wrong signature, the method invocation will
fail.

We could have envisaged various hacks to work around this
problem, but we decided it would be simpler to continue to use
MBeanParameterInfo rather than
OpenMBeanParameterInfo, with the Descriptor
containing the OpenType. In the example at hand, we'll have an
MBeanParameterInfo where
getDescriptor().getFieldValue("openType") returns
ArrayType.getPrimitiveArrayType(long[].class). On
Tiger, there's no such OpenType, but there's no Descriptor in
MBeanParameterInfo either so the inconsistency
evaporates. The Tiger client sees just the href="http://download.java.net/jdk6/doc/api/javax/management/MBeanParameterInfo.html#getType()">
MBeanParameterInfo.getType(), which is
"[J" as required.

For what it's worth, our implementation does use an
OpenMBeanParameterInfo when it doesn't contradict
the constraints I mentioned. In particular, if your attribute
or parameter is a CompositeData then even a Tiger
client will be able to see the corresponding
CompositeType using OpenMBeanParameterInfo.getOpenType().