Search |
|||||||||||||||||||||||||||||||||||||||||||||
Playing with the JMX 2.0 APIPosted by emcmanus on August 6, 2008 at 9:42 AM PDT
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 sourcesYou 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 wayFor 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, At the time of writing, this will show the change 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 platformUsing 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 Now you can use your new 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 onIf 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! »
Related Topics >>
Open JDK Comments
Comments are listed in date ascending order (oldest first)
Submitted by tvv2000 on Tue, 2008-08-12 22:46.
Look at usage of annotation http://marxsoftware.blogspot.com/2008/08/playing-with-jmx-20-annotations.... 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
Submitted by siderean on Wed, 2008-08-06 11:38.
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
Submitted by dwalend on Sat, 2008-08-23 15:20.
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
Submitted by emcmanus on Mon, 2008-08-25 05:29.
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
Submitted by emcmanus on Mon, 2008-08-25 05:34.
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
|
|||||||||||||||||||||||||||||||||||||||||||||
|
|