Dropping proposed features from the new JMX API
Yesterday I cleaned up the
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
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:
Wildcard support in notification filter
This is superseded by the new
which is more general.
Add abstract base class to make coding DynamicMBeans easier
Although this would occasionally be useful, the main thing
it could do would be to
in terms of
setAttribute, and in practice people don't
code Dynamic MBeans often enough for that to justify a new
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.
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.)
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
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.
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.)
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
Add support for persistence to JMX API
I talked about this above.
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!