The Tiger JDK introduced a nifty feature whereby you could run an application with -Dcom.sun.management.jmxremote and then later connect to it using the jconsole tool. That allows you to see the JVM's instrumentation (memory, classes, threads) plus any JMX instrumentation you've defined yourself. As Alan Bateman describes, with the Mustang JDK you can now attach jconsole to any application, even if it wasn't launched with the magic -Dcom.sun.management.jmxremote incantation.

This is excellent news, for a few reasons. First of all, what a bummer if you suddenly realize after your uninterruptible app has been running for five days that you really want to get at its instrumentation, but damn, you forgot to incant -Dcom.sun.management.jmxremote! Not a problem any more. You can connect to any of your JVM processes from a jconsole on the same machine. (You can't connect to anyone else's processes, and you can't connect remotely in this way.)

Secondly, there's a small penalty in start-up time and in footprint when you launch with the incantation. On the old slow workstation I'm typing this on, this is almost three seconds and 500K. This isn't enormous, but it's not negligible either. So why not wait to pay the penalty until you actually need to, which might be never?

And finally, enabling this connection, even from the local machine, means creating and listening on a TCP/IP socket. If you're not going to be using it then why bother?

So the new feature is a big plus! If you want to play with it, you can download the latest Mustang snapshot at http://download.java.net/jdk6/binaries/. Both jconsole and the target app must be on Mustang.

By the way, Alan modestly doesn't mention the deep technical wizardry he needed to do to get this to work. Causing a target process to execute code for you (to create the JMX connector server) isn't a piece of cake!