JDJ: Tell us what KL Group has been up to since we last spoke with you at JavaOne in 1999.
Armstrong: Lots. We've been very busy over the past year. Now, with the release of version 2.8, JProbe is reinforcing its leadership in the advanced-development tools market by building on the server-side advantage to include speed and ease of use. In September we announced the JProbe ServerSide Suite, which gives developers powerful performance profiling, memory debugging, code coverage and thread analysis capabilities in one integrated suite. Designed for server-side Java development, JProbe ServerSide has been a tremendous success and a leader in the field. It's the most powerful and accurate tool of its kind. Coming up this month we're excited to announce the release of JProbe 2.8, introducing new features such as the Garbage Monitor, Detail Meter and dramatic performance improvements, plus there's also a Quick Start Wizard to guide less experienced developers through the tuning process.
JDJ: How does that differ from JProbe for the normal client site?
Armstrong: Much of it is very similar in that you're still analyzing code, but we've actually introduced a server launch pad that allows you to select from a list of our supported application servers. Also, it's an extensible list that allows you to add your own application server or servers that may not be "in the box." It basically reconfigures JProbe so that it automatically starts up the application server and makes it a breeze to tune servlets, EJBs and other server-side applications.
JDJ: One of the interesting things you explained last time we talked was how Java applications tend to have memory leaks.
Armstrong: Yes. One of the misconceptions about Java is that there are no such things as memory leaks. We've actually done a lot of work in classifying the kinds of memory leaks that can occur in Java. What it amounts to basically is memory that's never released by your application, so there's no way for the garbage collector to know it's actually garbage and thus reclaim it as part of the heap. It has to do with what we call loitering objects objects that are allocated and reference to them is held on to far longer than it should be, so that memory is never reclaimed.
Now the interesting thing about memory leaks in Java and by the way, the JProbe memory debugger is an excellent way to find those loitering objects and those memory leaks is that typically, while less common than they were in C or C++, when they do occur they can be much more severe. That's because one object can hold references to thousands of objects and essentially slow down an application tremendously or even cause it to crash.
JDJ: Other virtual engines are available besides the standard one from Sun. Is any one in particular best at handling, for example, the memory leaks?
Armstrong: That's a good question. Memory leaks are actually independent of the implementation of the virtual machine. There are some changes with the HotSpot technology and how that handles garbage collection, but the fact remains that if there's a loitering object, in Java terminology, it's going to be a loitering object no matter what garbage collection scheme you are using. It would be as if I said, "We just got a better office cleaner, but you've still got a messy desk there." If you've got a messy desk, it doesn't matter how good the office cleaner is, you've got a messy desk. The same applies in Java applications: if you've got memory leaks, you've got memory leaks.
JDJ: What's the procedure for using JProbe? Should I wait until I finish my application to start using one of my analysis tools, or should it be something I evolve with you hand in hand?
Armstrong: It really boils down to your philosophy about development....to how important performance and reliability are to the particular project you're developing. If you consider them to be low risk, not important, and you consider features to be more important than performance or reliability, then maybe it would be okay to leave it to the end of the project. But to be honest with you, we have a lot of customers who leave it that long, and no matter how good JProbe is at showing them where the problems are, it can be very expensive to fix them after the fact. Our most successful customers are those who make this tool available to all of their developers and do so much earlier in the development process.
JDJ: So your advice is to be working from an evolution point of view with your project.
JDJ: Is this at the class level once you've concluded a class and are fairly happy with its implementation, you then run JProbe with that class?
Armstrong: We recommend doing it on a regular basis with your application and there's a right time to start doing it. You know, I'm not going to say you need to analyze every class you develop right from the very start, but pick the time when you want to start testing a set of classes or a component of your application that might be a good time to start. Then again, it depends on the scale of your application and the importance of performance and reliability.