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 Descriptors.

Instead of...

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

...you can use...

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

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 java.lang.management, we wanted to use the type long[] in the 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 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 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
ThreadMXBean.getThreadInfo(long[] ids)

If jconsole saw an OpenMBeanParameterInfo for a Long[] then it would expect the signature array in 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 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().