Eamonn McManus's Blog

Dropping proposed features from the new JMX API

Yesterday I cleaned up the umbrella bug that lists the various things we are planning for version 2.0 of the JMX API, which is the version that should be included in Java SE 7. Here's a list of the things we were thinking of doing but are not now planning to.

In some of these cases, we realized after discussion in the Expert Group that the proposed feature was either not practical or too hard to nail down. For example, support for persistence would be good. But what would it look like? Would we give you some way to take a snapshot of every MBean? How would that snapshot be represented? How would it be restored? Or would we have a way for an MBean to define its own persistence explicitly? Then what could we usefully define that an MBean can't already do today?

In other cases, a reluctant engineering decision was taken because, though the feature would be useful, it would not be useful enough to justify the engineering work to specify it, implement it, and write spec conformance tests for it.

Here's the list, with explanations:

• 4718350 Wildcard support in notification filter

  This is superseded by the new class QueryNotificationFilter, which is more general.

• 5108792 Add abstract base class to make coding DynamicMBeans easier

  Although this would occasionally be useful, the main thing it could do would be to implement getAttributes in terms of getAttribute and setAttributes in terms of setAttribute, and in practice people don't code Dynamic MBeans often enough for that to justify a new class.

• 4718269 Model MBean should be extended to support EJB handles

  This one was never on the cards, because this API is part of the Java SE platform, and EJBs are part of Java EE.

• 4718298 ModelMBeanInfo.getConstructor(String) could be added

  ModelMBeanInfo is an interface so adding a method to it would be an incompatible change. (Existing classes that implement this interface would not have the new method.)

• 6176837 TabularDataSupport.entrySet() should prevent calls to Map.Entry.setValue on returned set elements

  I logged this one a few years ago for aesthetic reasons. The spec basically says "don't do this or things will break". A good spec should never say that. It should say "if you try to do this operation that would break things, you will get an exception". But in practice this is in a pretty obscure corner of the API and making it generate the exception would be a nontrivial amount of work, and probably imply a performance penalty, so the change was hard to justify.

• 5031385 m-let file format should be XML

  Again MLet files are not a core part of the API so making this change would be hard to justify. What's more we'd probably have to work out how to support the previous almost-XML format and the new really-XML format at the same time, and that would be hard.

• 6323896 Support aggregation of multiple MBean Servers

  This is certainly something that we often see people needing, but the Expert Group discussion concluded that it would be very hard to define something that would be general enough to be useful while still simple enough to be understandable.

  I think this is still an interesting area for future work, but it will unfortunately not be part of the JMX 2.0 API.

  We will still support federation, meaning that you can group several MBean Servers into a single "master" MBean Server. But we will not support for example a predefined way to have an MBean in the master that shows the average of a certain attribute across each of the federated MBean Servers. (Users should still find it easy to address any given case by coding it explicitly.)

• 6323795 Metadata repository for JMX API

  The idea here is that you can see the metadata for every JMX MBean that currently exists (for example, its operations and attributes). But you can't see the metadata for every MBean that might exist. It would be great to be able to browse the MBean class hierarchy independently of instances.

  Although this is not planned for the 2.0 API, it would be an interesting project to use the new Namespace support to implement a namespace with one MBean instance for each class of MBean that exists (discovered perhaps by looking through the jars in the classpath). The MBeanInfo of each of these "template MBeans" would be the MBeanInfo that each instance of the corresponding class would have, or as near to that as we could deduce. (This idea is due to Nick Stephen.)

• 5108724 Add support for persistence to JMX API

  I talked about this above.

• 6323764 Add support for client sessions to JMX API

  The idea here was that a client could create an object on the server that represented some part of its state, for example a transaction or a set of notifications that the client is interested in or a long-running operation. However, the Expert Group considered that most of these cases could be addressed using "client contexts", a new feature where the client can communicate a context to the server with every operation. This context could be a locale or a transaction id or whatever.

None of these decisions is completely irreversible of course. But at this stage I think anyone with a very strong desire to see any of the departed features brought back would need to volunteer to do all the relevant engineering work!

[Tags: jmx jdk7 jsr255]

Comments

• Wonderful. I was beginning to think the JMX team was bent on doubling the size of the runtime on their own.

  I am still surprised with some of the things that did get through especially as they seem to be an re-invention of JNDI again (federation, contexts, namespaces). I accept sometimes you must abandon or just plain ignore existing standards in search for innovation but was that what was delivered? I am afraid not.

  William

  Posted by: wlouth on September 19, 2008 at 07:38 AM

• In other words, the only useful additions and changes in Java 7 have been cancelled...

  Posted by: jwenting on September 19, 2008 at 09:58 PM

• Will it be possible for a JMX client to connect to a JMX server through firewall ?
  I know there's a weird workaround described here http://blogs.sun.com/jmxetc/entry/connecting_through_firewall_using_jmx but I think it should be possible by default.

  Posted by: sauvage on September 20, 2008 at 06:31 PM

• Eamonn, I have followed the JMX 2.0 development for quite some time now. There were many interesting and inspiring articles about high-level JMX features, and also about federated MBeans, in your blog.
  I am very disappointed that MBeanServer aggregation or federated MBeans are now cancelled, after all this time.
  I had to write my own implementation back in 2005 and it worked quite good, but I thought there will be surely something better coming out in the next years - yet today there still isn't.
  I cannot understand why after 3 years (you talked about this feature back then I believe) this feature gets canned for dubious reasons - "very hard to define": this is not true, and underestimates the intelligence of Sun's design team. Why is it then, that MBeanServers *could* be aggregated in the then proprietary Sun JDMK?? It seemed to work fine there, but did cost a bit. The documentation did not sound too complex, the concept of "mounting" MBeans seemed a bit UNIXish, but I think it was a good API.
  In my custom implementation, I kept things simple but also included aggregation-methods like average(), min() or max() to perform some often needed calculation on typical MBean data on the master-node (collecting data from slave-nodes). If I can get the source from my former company, I can send it your way,-)
  Anyway, best of luck with JM2.0-- it still looks good and if you leave annotations in at least, it will be a welcome upgrade.

  Posted by: gregorr on October 02, 2008 at 02:46 AM

• Gregor, my apologies for not being clearer. Federation is still part of the JMX 2.0 API, and is now publicly available as I mentioned in my next blog entry. Aggregation is what's not, meaning for example we don't provide a predefined way for you to define an MBean with an attribute which is the sum of n attributes in n other MBeans, for example. For any particular case, it should be rather easy to code an MBean yourself that handles it. But a general feature would ideally have some sort of expression language that would allow you to express an attribute in the aggregation MBean as being an arbitrary function of an arbitrary number of other attributes in other MBeans, and that's what we're not doing for now.

  I've updated the blog entry to make this clearer - thanks for drawing it to my attention!

  Regards,
  Éamonn

  Posted by: emcmanus on October 02, 2008 at 05:07 AM

• Thanks for the quick heads-up, now I am happy again;) I agree that aggregation functions are rather custom and easily added according to own needs. However an expression language, or even a DSL for constructing an MBean-infrastructure sounds interesting... Also looking forward to the new Eventing-system, wow, JMX-EDA-magic:)
  I always come back to JMX when I need a simple user interface for controlling various application functionality in a straight forward manner, very good for prototyping.

  Posted by: gregorr on October 03, 2008 at 02:17 AM

This work is licensed under a Creative Commons License.