Eamonn McManus's Blog

Playing with the JMX 2.0 API

Version 2.0 of the JMX API is being defined by JSR 255. I've written about some of the features in the new API before. They are trickling into the JDK 7 sources over time, so you can now play with some shiny new things. Here's a description of what they are, and how you can even access them from JDK 6 if you are brave.

As you probably know, the JDK 7 platform is being developed in open source, which means that you can see the changes as soon as the JMX team commits them.

You can browse the current mainline JDK 7 sources directly from the Mercurial repository, at http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip.

These sources correspond to the Javadoc snapshot at http://download.java.net/jdk7/docs/api/index.html, and to the JDK 7 snapshot binary at http://download.java.net/jdk7/binaries/.

If you download the JDK 7 snapshot binary, you can use it the same way you would use any other JDK installation. Of course, this is work in progress, so don't use it for anything critical. But it tends to be surprisingly stable, and I often use it to run NetBeans, for example.

Recent JMX API changes in the JDK 7 sources

You can also see all of the changes that have gone into the JDK 7 sources at http://hg.openjdk.java.net/jdk7/jdk7/jdk/shortlog. At the time of writing, one interesting thing you will see there (if you find the JMX API interesting) is this:

Changes that are on the way

For a project as big and important as the JDK 7 project, there's a lot of extra engineering that has to happen between the time the JMX team pushes a change into a publicly-visible repository and the time that change actually shows up in the snapshots. I think of the changes as being "in the pipes" during this time. You can see our changes as soon as we push them by looking at http://hg.openjdk.java.net/jdk7/tl/jdk. (Here, tl stands for "tools and libraries", which is the subproject where the JMX API lives.)

At the time of writing, this will show the change
5108776: Add reliable event handling to the JMX API
which is the new Event Service. You might have already seen this in the Early Draft Review of the JMX 2.0 API, but if not it will eventually appear in the Javadoc snapshots in the package javax.management.event, or if you can't wait you could always read the source of the javadoc for that package.

There are two other chunks of functionality that should be showing up in the next couple of months, one big and one somewhat smaller. The big one is namespaces. The smaller one is the stuff that will build on namespaces to support "client contexts" (also described in the slides at that link) and localization of descriptions in MBeanInfo.

Once those are in we will be looking at a smallish subset of the various RFEs open against the JMX API. Now would be a good time to agitate for anything you particularly want to see.

Using the JMX 2.0 API with the JDK 6 platform

Using the JDK 7 sources, you can in fact build a jar with just the JMX classes and run that with a JDK 6 installation. Of course this is even less supported than running a JDK 7 snapshot, but once again assuming you're not using it for anything critical here's how you would go about it.

First download the JDK 7 sources, either using Mercurial if you have it, with a command like this...

hg clone http://hg.openjdk.java.net/jdk7/jdk myjdk

...or by downloading the sources from http://download.java.net/jdk7/. The "JDK 7 Source under the JRL license" link on that page is a jar which you download and run using a command like this...

java -jar jdk-7-ea-src-b32-jrl-04_aug_2008.jar

Now cd to the jdk subdirectory of the sources, if you downloaded the bundle, or into the Mercurial repository you cloned if you did that (you only cloned the jdk subdirectory). Run this command...

ant -f make/netbeans/jmx/build.xml

If it works, it'll make you a jmx.jar in dist/lib and that's what you can use with your JDK 6 installation. (If it doesn't work, tell me what went wrong and I'll update the instructions here.)

Now you can use your new jmx.jar in either of two ways. The simplest is to make a directory called endorsed inside the jre/lib subdirectory of your JDK installation (if there isn't one already), and then drop jmx.jar into it. (I would recommend renaming it too, to something like jmx-2.0-snapshot-2008-08-06.jar.) But beware that if you do this you are replacing the JMX implementation for all users of that JDK installation!

The second way is to run your programs like this...

java -Xbootclasspath/p:/path/to/jmx.jar ...

Then only programs that are explicitly run in that way will be using the new JMX implementation.

Let us know how you get on

If you play with the new JMX API, or even if you are just browsing through it, we're very interested in hearing about your experiences. Feel free to add your comments here, or send mail to jmx-spec-comments@sun.com, or write a blog entry with tag "jmx". Thanks!

[Tags: jmx jdk7.]

Comments

• Fantastic, Eamonn, thanks for pointing this out! I'll be brave and try to use the jar with JDK 6.

  I wanted to also say GREAT talk at JavaOne this year! Not only informative, but highly entertaining.
  Don
  

  Posted by: siderean on August 06, 2008 at 11:38 AM

• Look at usage of annotation http://marxsoftware.blogspot.com/2008/08/playing-with-jmx-20-annotations.html. Developers have to make double work, first they describe methods with javadoc, second they make the same in annotations. It looks like as needless work. I do not have any approach how to avoid it but I think you should pay attention to it
  Thanks

  Posted by: tvv2000 on August 12, 2008 at 10:46 PM

• Eamonn,

  Any hope of tightening up NotificationListener's execution thread policy? If I know the NotificationListener's handleNotification() will happen on the calling thread, I know I need to get the job done quickly or spin up my own thread. If I know the NotificationListener's handleNotification() will happen on its own thread, i don't want to waste creating my own thread to do the work. Picking one or the other would help.

  Thanks,

  Dave

  Posted by: dwalend on August 23, 2008 at 03:20 PM

• tvv2000, the @Description annotation is marked with the @Documented meta-annotation, which means that the description string will appear in the javadoc. However it doesn't look the same as a real javadoc description, and it doesn't support the various tags like @param, so I agree this is not ideal. One could imagine various solutions with doclets or annotation processors, but I admit that a good solution is not obvious to me either.

  Regards,
  Éamonn

  Posted by: emcmanus on August 25, 2008 at 05:29 AM

• Dave,

  That's an excellent remark. NotificationBroadcasterSupport is explicitly specified as synchronous by default (so listeners must be punctual), but the specification of the new SendNotification injection doesn't say anything and it surely should.

  We do recommend that listeners always complete quickly because in most contexts, including when the listener is in a remote client, not doing so risks holding up other work.

  Regards,
  Éamonn

  Posted by: emcmanus on August 25, 2008 at 05:34 AM

This work is licensed under a Creative Commons License.