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 typelong[] 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. Sincelong[] didn't exist as an OpenType in Tiger, if we sent an OpenMBeanParameterInfo with typelong[] to a Tiger, it will see it as if its type wereLong[]. Suppose it lets the user call a method like
ThreadMXBean.getThreadInfo(long[] ids)

JConsole proposing ThreadMXBean operations 

If jconsole saw an OpenMBeanParameterInfo for aLong[] then it would expect the signature array in MBeanServerConnection.invoke to containLong[].class.getName(), i.e."[Ljava.lang.Long;". But since the parameter is really a long[], it should belong[].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 useMBeanParameterInfo rather thanOpenMBeanParameterInfo, with the Descriptor containing the OpenType. In the example at hand, we'll have anMBeanParameterInfo wheregetDescriptor().getFieldValue("openType") returnsArrayType.getPrimitiveArrayType(long[].class). On Tiger, there's no such OpenType, but there's no Descriptor inMBeanParameterInfo 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 anOpenMBeanParameterInfo 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 CompositeTypeusing OpenMBeanParameterInfo.getOpenType().