<< Subscribe by e-mail | Home | My role >>
Twitter RSS feed for Simon Brown [Twitter] simonbrown: Eating cream cakes in the sun at jersey zoo ... chillin'

Coding the Architecture RSS feed for Simon Brown [Coding the Architecture] Just a short note to plug a handful of sessions that Kevin and I are presenting at the upcoming Software Architect 2008 conference, 3rd-5th June, London. 1. Coding the Architecture : From Developer to Architect The first is a re-run of our ...

Why isn't JConsole part of the JRE?

It's a missed opportunity for Java desktop applications in the enterprise

I've been troubleshooting and configuring Tomcat most of the day, some of which was related to configuring java.util.logging for a third party application. To check some configuration options were being picked up, I decided to tweak the Tomcat start script to expose the JVM's MBean server. Since the Tomcat server was running on a Linux box and I didn't have a full X windows session available to me, I decided to remotely expose the MBean server so that I could connect to it from my Windows machine. That all worked fine but I soon ran into some problems.

  • My (borrowed) Windows box only had the 1.4 and 1.5 JREs installed.
  • JConsole isn't included with the JRE.
  • I couldn't install the Java SDK because it requires that you have local admin rights to your box, which I didn't have because I was borrowing the box.

I eventually connected to the MBean server with MC4J.

I think that the decision to not include JConsole with the JRE is crazy. JMX is a fantastic infrastructure for building applications that are easier to monitor and manage, but not including JConsole in consumer JREs is just a barrier to entry that prevents JMX from getting the mainstream usage that it deserves. Just think of the possibilities if JConsole was included with the JRE, particularly if you were writing Java desktop applications within a corporate environment - a user is having problems, walk over to their desk, boot-up JConsole, dig around, modify the logging level, etc. Sun, I think you've missed an opportunity here.



Re: Why isn't JConsole part of the JRE?

The JRE is a "runtime environment" which is meant for regular folk. The JConsole is clearly a developer thing. The screams about BLOAT rise higher and higher the more that's put into the JRE.

Re: Why isn't JConsole part of the JRE?

I'd say that JConsole is for developers as well as support staff. Wouldn't it be nice to more easily monitor and manage the applications that "regular folk" use?

Re: Why isn't JConsole part of the JRE?

It's not like Sun don't bundle enough crap in the JRE already ... What Sun really needs to do is support a modular system that can allow different modules to be brought in on demand. And if they'd used something like OSGi, then you'd be able to use the OSGi console, not to mention remotely installing other modules that provided extra functionality. Sadly, Sun have lost the plot with the bloat that exists in the current JRE/JDK and the situation only gets worse with every release.

Re: Why isn't JConsole part of the JRE?

The JRE includes the JMX agent and once configured for remote management then you should be able to connect with jconsole (or other JMX tools) from somewhere else on the network. I assume you needed to this configuration anyway in order to get MC4J to connect.

Re: Why isn't JConsole part of the JRE?

I agree that it's technically possible to enable desktop apps for remote JMX access, but there are often other constraints that prevent this from happening. It also opens up a whole load of questions.
  • Should the remote JMX connection be secured using authentication and authorisation? If so, where do we store the credentials? Is the jmxremote.password file approach secure enough?
  • Should the remote JMX connection be secured with SSL?
  • What happens if the production users are on another network?
Java 6 includes the ability to dynamically expose the MBean server locally (dynamic attach) and it would be fantastic if this could be used as a support option. For this to be viable, the JRE would need to ship with JConsole.

I guess another option is to have JConsole available as a WebStart-able app somewhere on the network.

Re: Why isn't JConsole part of the JRE?

For the remote case, another alternative is to configure the agent to use LDAP for authentication rather than password files.

Add a comment Send a TrackBack