Skip to main content

Dropping proposed features from the new JMX API

Posted by emcmanus on September 18, 2008 at 8:17 AM PDT

Yesterday I cleaned up the
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
, 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

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

  • 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

  • 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

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

    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

    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

  • 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!



Related Topics >>


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 but I think it should be possible by default.

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

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.


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

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.

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.