There are classic mistakes in Java programming, things like string manipulations that create huge overheads and that developers learn to avoid at the level of application code. Are there similar types of common errors that you encounter at the level of end-to-end application performance analysis?

Narahari: Developers are sometimes negligent about object creation and the management of object lifetime. They assume that Java's garbage collection will handle everything. We look for leaks and for repeated object creation. Fixing those problems can give a lot of improvement.

The second area we see is interaction between the Java layer and the database layer: Your optimization in [JDBC (Java Database Connectivity)] code can give a lot of performance improvement, and it's important to be able to correlate what's happening in J2EE [Java 2 Platform, Enterprise Edition] with what's happening in the database. When you can see that connection, you find yourself saying, 'I didn't realize that the query would execute like this; let me change my JDBC statement on the J2EE side."

It sounds as if you have to maintain a perspective on the full stack, so that you're never limiting yourself to solving "Java problems" but always thinking about "application problems."

Maness: That is exactly the way we built the product. We took a blueprint of the application transaction path. We said, OK, if you really look at performance, you have to have information from each point in the path as well as the network itself. [That lets you] get a real breakdown of what response time means and, if you have a problem, where to find it and troubleshoot it.

Not just each tier, but each component within the tier—in the database, the tables and views; in the Java tier, the methods and strings. These things get complex. At the end of the day, the value is not in managing a silo or a segmented tier but in managing that tier in the context of what the user is doing.

Looking at the arc of complexity of Java, it's almost hard to recognize the language that we first saw in the late 1990s—but the last two years of JavaOne conferences have seen growing emphasis on manageability. Are there any key Java technologies that you expect to see highlighted at this year's conference to help developers handle enterprise workloads?

Maness: I think there will be a lot of discussion around instrumentation: around understanding complexity without hogging the server CPU so that the instrumentation becomes a problem in itself. That's central to the way we're looking at the world [and working to make it] so that J2EE becomes more manageable.

Narahari: One [Java Specification Request] that's very interesting to us is JSR 168, the portlet specification. Our interest is in the adoption of that standard by the portal vendors, which is very much in the interest of the customers.

Maness: That's right. And our [i3 version] 7.5 product instruments and manages performance on any JSR 168-compliant server. That really expands the activity that we're doing around performance management, and it's the JSR we're most interested in driving forward and being part of.

This article was originally published on eWEEK.com.