Technical Articles relating to Oracle Development Tools and Frameworks

Launching JConsole as an External Tool From JDeveloper

Duncan Mills

I find JConsole to be a useful tool, particularly for MBean browsing, but frankly getting the correct command line arguments to get it to connect correctly to my WebLogic instances is a bit of a pain. I always have to go and look it up. - generally from here. However, setting all those paths is tedious. Given that I'm usually working in an environment where my JDeveloper, and the WebLogic servers I'm using JConsole on, are matched from a version perspective I can get JDeveloper's external tools capability to do the lifting.

Very simple this. Just choose Tools > External Tools from the menu and press New.  Then run through the wizard:

  1. Type is External Program
  2. Program Options > Program Executable = jconsole 
  3. Program Options > Arguments =  (All on one line of course, reformatted here for readability)

And that's it.  JDeveloper helpfully substitutes both the Java location and the WebLogic location for us saving all that hunting around.  


 Thanks to Torsten Kleiber who discovered and followed up on the twist of ${java.path} not expanding correctly (or rather expanding to null). Before running the tool command with the macro make sure that you have a project open and selected as the actual java path is obtained in the context of the JRE version used by the selected project. (Project Properties > Libraries and Classpath > Java SE Version)

Join the discussion

Comments ( 4 )
  • Torsten Kleiber Friday, June 14, 2013


    I tried this on windows 7 with JDeveloper replace path separator and slash with backslash), but I get following:

    Count not find the main class: sun.tools.jconsole.JConsole. Program will exit.

    The message pane, shows that ${java.path} is not expanded on my side:

    C:\Oracle\JDev111240\jdk160_24\bin\jconsole.exe -J-Djava.class.path=\lib\jconsole.jar;\lib\tools.jar;../../../wlserver_10.3/server\lib\wljmxclient.jar -J-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote

    java.lang.NoClassDefFoundError: sun/tools/jconsole/JConsole

    Caused by: java.lang.ClassNotFoundException: sun.tools.jconsole.JConsole

    at java.net.URLClassLoader$1.run(URLClassLoader.java:202)

    at java.security.AccessController.doPrivileged(Native Method)

    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)

    at java.lang.ClassLoader.loadClass(ClassLoader.java:305)

    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)

    at java.lang.ClassLoader.loadClass(ClassLoader.java:246)

    Exception in thread "main"

    After replacing ${java.path} with C:\Oracle\JDev111240\jdk160_24 jconsole comes up.

    Is this a bug, that ${java.path} is not set on windows?

    Kind regards

  • Duncan Tuesday, June 18, 2013

    java.path is one of the supported macros so yes you should log and SR if it's not on your platform

  • Torsten Kleiber Thursday, June 20, 2013


    With SR we found out, that the java.path comes from the j2se library version of the project, which has the focus.

    I have tested the call without applications/projects opened.

    I thought, that in this case the jre is used, in which jdeveloper itself runs.

    Not very intuitive but now I know it.

    But this leads me to another question: If I use another j2se outside from JDeveloper in my project, must the jconsole match to this j2se? Should the executable set to ${java.path}\bin\jconsole.exe on windows and ${java.path}/bin/jconsole on linux?

    Kind regards

  • Duncan Thursday, June 20, 2013

    Well imp[licitly JConsole is intended to connect to multiple VMs both local and remote so I assume that there must be some flexibility in the versions it can work with. However, you'd best consult the JConsole doc on this to be sure

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.