JavaOne feedback about JMX technology

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 href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5072476">
  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 href="http://www.java.net/download/jdk6/doc/api/java/lang/management/ThreadMXBean.html#setThreadContentionMonitoringEnabled(boolean)">
  setThreadContentionMonitoringEnabled method in href="http://www.java.net/download/jdk6/doc/api/java/lang/management/ThreadMXBean.html">
  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. href="http://www.java.net/download/jdk6/doc/api/javax/management/monitor/package-frame.html">
  Monitors and href="http://www.java.net/download/jdk6/doc/api/javax/management/timer/package-frame.html">
  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 href="http://www.jini.org/nonav/standards/davis/doc/specs/html/js-spec.html">
  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 href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5072267">
  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
  href="http://www.java.net/download/jdk6/doc/api/java/util/ResourceBundle.html">
  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 href="http://www.java.net/download/jdk6/doc/api/javax/management/Descriptor.html">
  annotations in the Standard MBean interface. Also, an href="http://www.java.net/download/jdk6/doc/api/javax/management/MBeanParameterInfo.html">
  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<br>
  public long getUptime() {...}<br>

  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 href="http://www.java.net/download/jdk6/doc/api/java/beans/PropertyEditor.html">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 href="http://en.wikipedia.org/wiki/ACID">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 href="http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html">
  jconsole?

Now, in fairness I should say that the snapshot of the JMX API that
you can see on href="http://www.java.net/download/jdk6/doc/api/">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 href="http://java.sun.com/developer/technicalArticles/J2SE/Desktop/Mustang_build39.html#JMX">
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.