JavaOne is always a huge buzz, and this year was no exception. Of course the technical sessions are very worthwhile, so it's great news that slides and audio for all of them will be available free online. In previous years you had to pay a small subscription fee to access them.

But the biggest plus of JavaOne, like any conference, is meeting people with common interests. I brought back a densely-packed page of notes about things people told me they'd like to see in the JMX API. That should generate enough blog material to last me to autumn.

Here's a terse summary of some of the main questions and requests.

• Metadata repository. Today you can query an MBean Server to find out the management interface of any MBean registered in it. But often you would like to find out the management interface of all possible MBeans, even ones that aren't currently registered. That would allow you to know what classes you can give to createMBean. Some systems like CIM/WBEM already support metadata query so adding this facility to the JMX API would make it easier to implement those systems on top of it.
• Federation and aggregation. The JMX Remote API provides a good solution for a single client connecting to a single server. But what if the client wants to manage a large number of servers? The solution proposed for JMX API 2.0 is cascading. But we probably also want to support some form of aggregation. For example, if all of my 100 servers export an "uptime" statistic, I'd like to be able to obtain an average uptime in a single operation, rather than having to access 100 MBeans and compute the average myself.
• Turning on and off expensive MBeans. Some MBeans may export information that is continuously sampled and that is expensive to gather. You don't necessarily want those MBeans to be running all the time. Ad hoc solutions are easy, for instance the setThreadContentionMonitoringEnabled method in java.lang.management.ThreadMXBean. But perhaps there could be a more general convention, such as a setDetailLevel(int) method.
• Generalized thread handling. There are a number of places where the JMX API can create threads. A connector client needs a thread to receive notifications from the server. Monitors and timers need threads to do their periodic activities. A NotificationBroadcasterSupport can dispatch a notification to listeners asynchronously rather than blocking the sender. Could we have some centralized thread handling for all of this? That might also fit better in contexts like Java EE where random thread creation is frowned on or impossible.
• Improved notification handling. Currently the JMX Remote API has an imperfect guarantee for notification delivery: either you receive all notifications you are subscribed for, or you receive an indication that you may have lost some. (Notifications are not silently lost.) But you might already have an infrastructure like JMS or the JavaSpaces Service that guarantees reliable delivery. Could you exploit this for your notifications? Could you roll your own notification buffering?
• Internationalizing descriptions. An MBean can have a description for itself and for each of its contained attributes, operations, etc. How can we arrange for these descriptions to be internationalized? Ideally we'd like the client to be able to communicate its locale to the server, and the server to send back the descriptions appropriate to that locale. And we'd like some nifty way to use annotations in an MBean interface to specify things like resource bundle names and resource keys.
• More control over Standard MBean info. Now that a Standard MBean can have a Descriptor, it would be nice to be able to populate that Descriptor with annotations in the Standard MBean interface. Also, an MBeanParameterInfo has a name, but that name is always p1, p2, etc for a Standard MBean. It would be nice to be able to specify the name with an annotation. There are similar cases, like the impact of an operation.
• Annotations instead of MBean interfaces. A theme I heard a lot was that people would like to be able to specify the management interface of a class by using annotations rather than having to create a separate MBean interface. For instance, you might say
  @Management
public long getUptime() {...}
in your class to define an Uptime attribute.
• PropertyEditor for attributes. I heard conflicting views on this one. One person thought it would be great if the Descriptor for an attribute could specify a PropertyEditor for it. Then a management console could allow you to view or edit that attribute in some fancy way. Another rather more utilitarian person thought it was a good thing developers couldn't do this because it meant they would do more productive things with their time instead!
• MBean lifecycle support. The JMX API allows an MBean to know when it is created and destroyed through the MBeanRegistration interface. But often there's a distinction between creating the MBean and starting it, and between stopping it and destroying it. It could be good to have a standard interface with start() and stop() methods that MBeans could implement.
• Transactions. It would be good if the JMX API had some form of transactions. Perhaps not the full ACID properties, and perhaps requiring MBeans to be transaction-aware if they want to export transactional semantics, but that would still be good.
• "Weak" MBeans. An MBean frequently manages another Java object that is the "resource" to be monitored or controlled. But what if the only reference to that resource is from the MBean? Could we somehow arrange for the MBean to disappear if the resource is no longer referenced by anyone else?
• Tomcat. So just how do you create your own MBeans in a Tomcat server, and how do you connect to them with jconsole?

Now, in fairness I should say that the snapshot of the JMX API that you can see on java.net is basically what you will get in Mustang (JDK 6) when it comes out. The stuff listed above will almost entirely be addressed in Dolphin (JDK 7) at the earliest. There are already some nifty new JMX API features in Mustang; some of the main ones were listed in a recent java.sun.com feature.

In future entries here, I plan to talk about many of the above items in more detail, and in many cases explain how you can get some or all of the functionality using the existing API.