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]