One of the reactions to my recent blog on JCMD has been “But, why?”. It is a reasonable question – after all, the simple examples I added to the blog can be solved using existing tools (jps, jstack etc) in the bin folder of any recent JDK. The answer is that JCMD provides:

  • A simple framework for easily adding more (self documenting) commands to the JVM.
  • One launcher to learn how to use.
  • The launcher is backwards and forward compatible. In other words, you can use an old version of the command to connect to a more recent version of the JVM, and vice versa.
  • There are already diagnostic commands available that are not covered by the old j* tools, such as the ability to control the JMX agent and the Flight Recorder. In the future more commands will be added.
  • In a future JDK update, a JMX interface will allow programmatic access to the diagnostic commands.

For a hint at what will be available in the future, check the JRCMD chapter in the JVM book.

2 Responses to "Why JCMD?"

  1. Bernd Eckenfelsnd tha says:

    I can understand that you want to reduce the Tools footprint in the Server JRE, so having only jcmd is fine with me. However I really miss the table-view self refreshing jstat Output. Is it planned to integrate that into jcmd? And what would be really cool would be a JMX Interface, so we have an out of the box jmx Client.


  2. Marcus says:

    Nah, no plans to have a self refreshing jcmd UI that I know of. Good news is that there already is a JMX API for accessing the Diagnostic Commands. Also, the JMC JMX Console has a tab for executing the diagnostic commands. Not to mention that the Memory tab does heap histograms with delta calculations. We currently do not do refreshes continuously, as we are weary of the performance implications. If you believe we should have such a mode for the Memory tab, let me know and I’ll add an enhancement entry.

    Kind regards,

Leave a Reply

Your email address will not be published. Required fields are marked *