HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

Lee Garrison
Java Product Marketing Manager
Alan Armstrong
JProbe Product Marketing Manager
KL Group

JDJ: Alan, give us a little overview of JProbe 2.0. What does it offer?
Armstrong: JProbe is a tool to help developers search and destroy performance bottlenecks and memory hogs in their applications. It's a way to basically profile an application and then afterwards - and even during - take a look at the memory usage characteristics of the application and also what parts of the application are taking the most amount of time....It helps you quickly focus on the parts of your application that you really need to tune, from a memory perspective and also from a performance perspective.

JDJ: Some new features in 2 aren't available in the previous releases. Can you give us an idea about those?
Armstrong: The whole area of memory debugging has really been improved in version 2, and real-time memory debugging wasn't available in the previous release. You know, in a lot of ways people think that memory in Java is not a problem, but that's not actually the case. When you start developing with Java, you find that because of the number of objects that are created and also because of the way that Java handles memory, things can be left allocated and applications can continue to consume memory when you wouldn't think they would because of garbage collection. So what JProbe memory debugger allows you to do is to find those objects that are no longer being used but are still in memory and then zoom in on that area of the application, change the source code and reduce the memory requirements of your application.

Lee Garrison
Java Product Marketing Manager
Alan Armstrong
JProbe Product Marketing Manager
KL Group

Rhody: A lot of us are used to just running our Java code and seeing the results, and I don't think too many of us think about it. I think you mentioned something that is a viable place to look for these memory leaks. But I guess the biggest question in my mind would be, once you can identify them, what can you do about them? How much of a help can you provide for reducing those kinds of problems?
Armstrong: Let me give you an example. Because Java is such an object-oriented language, a lot of people tend to use objects basically willy-nilly, without thinking about the penalty that you can pay because of overuse of objects. For example, if you're manipulating simple kinds of data, it may be much more effective to just use native types. In fact, in our own JClass product line, we had been using an object for our live table in order to maintain the coordinates of a particular cell in a grid; by using JProbe on our own JClass components, we were able to find out that that was actually a major bottleneck in the component. And we have very experienced object-oriented developers on our staff. So it is in the area of changing the algorithm but also finding out the best ways to use classes in Java.

Rhody: That sounds pretty good. What are some of the kinds of things you can identify with this? What level of detail do you go into and do you hook into the virtual machine?
Armstrong: Sure. It's fairly tunable, actually. You can zoom into a very fine granularity of detail or you can back off and just say I am sort of interested in a core screen of information. It depends on what kind of information you're looking for. For example, you may not have any idea at first what part of the application is taking so much time, why this thing is so slow, and so you look at things from a very high level. But then when you narrow it down, you can turn on some of our unique technology to really get down to the line of source code that's causing the problem.

Lee Garrison
Java Product Marketing Manager
Alan Armstrong
JProbe Product Marketing Manager
KL Group

Rhody: What do you provide in the way of statistics? I mean, what are some of the gross things that you can get on a level like it? Do you tell them how much memory is in use over a given period or that kind of thing?
Armstrong: It depends on whether you're talking about the memory side or the performance side. On the performance side, there are nine different measurements that you can make on code including the cumulative time spent in a method, the sort of exclusive time spent in the method, the number of times a method is called - and I could go on. JProbe collects all of that information and then allows you to sort things and paint the call graph display, which is a graphical thing that highlights where the time is spent. JProbe will sort things, build the call graph and paint it depending on what kind of criteria you're after.

Rhody: Can you tie in JProbe to an IDE like JBuilder?
Armstrong: Yes. JBuilder and Semantic Cafe and also Powersoft and PowerJ - all have opening PIs that we work with.

Rhody: So you could compile your code and then run it using your VM and then get information and still do everything from their API.
Armstrong: Absolutely. The interesting thing is we have an excellent relationship with all of the IDE vendors. Right from the word go, JClass components were embedded in the IDEs. You'll see them in Semantic Visual Café, Inprise JBuilder, Sybase PowerJ and IBM VisualAge. We have very close working relationships with all of those folks, so on the Profiler side we were able to really...to work together well on that. It's something that is very important to us.

Lee Garrison
Java Product Marketing Manager
Alan Armstrong
JProbe Product Marketing Manager
KL Group

Rhody: What about the present with JClass? What do we have to look forward to?
Armstrong: For [an answer to] that I'll pass it over to Lee Garrison. He's the JClass product manager.
Garrison: We were talking about a couple of interesting things today with respect to the JClass announcements. The current release of JClass, the 3.6 version, is out and provides common API support across all of the major JDK releases including Java 2 with Swing 1.1. That's a real benefit for developers who want to have the flexibility of migrating their code across multiple JDK versions without having to rewrite anything. They can use the JClass 3.6 release and simply recompile with the different versions in JClass 3.6. But we're also working on a new generation of JClass, and the next major release of JClass will be specifically structured for Java 2. It will really optimize for the Java 2 features, pluggable looking field, drag-and-drop. Components like JClass chart will make use of the 2D API. So it will really be a benefit for developers who want to start new projects and build specifically for Java 2.
Another interesting question that we often get asked and that I might just point out to you is what the impact of Swing has on the other JClass components, and clearly Swing is a good thing. It's providing base-level functionality in the core classes, and things like JTable, the grid in Swing, are great for very simple display of tabular data. But we found that there are quickly limitations to that, particularly in mission-critical or scalable environments. JTable doesn't perform very well beyond a couple hundred rows, and it's not very customizable if you want to change cell appearance on a cell-by-cell basis. That's where things like JClass Live Table as a premium component come into play. It can handle millions of rows with real-time scrolling performance. It can be completely customized on a cell-by-cell basis. It automatically data-binds to JDBC objects as well as native data sources in Visual Cafe or J-Builder.

Rhody: If I can dive a little bit into that, what about tying something like that into some more abstract data source like a result set or something else that would be transferable or in some sort of three-tiered fashion? I am doing a lot of distributed work with EJB servers and we typically have the database on the back tier and the EJB in the middle and want to transfer data.
Garrison: We have a couple of research projects looking into things like that. We haven't stepped into the EJB space yet, but we are certainly aware of it and looking at it. And there is a natural evolution of something like the JClass Data Source Bean, which is a nonvisual hierarchical data object working in those kinds of environments.
Armstrong: If I could just make a comment. The extent that those middle-tier servers are based upon the standard result sets, there should be no reason why JClass wouldn't work with them.

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.