Putting Enerjy Software Tools To The Test at JavaOne 2005. As an independent software developer/consultant starting my career in the early '90s, I was exposed to a large number of different working environments and challenges. My specialty for a while was HP C++ and Motif (often using Interface Architect) on HP-UX, but over the years I migrated towards Sun's C++ and GCC compilers along with X Designer on Solaris.

Putting Enerjy Software Tools to the Test. As an independent software developer/consultant starting my career in the early '90s, I was exposed to a large number of different working environments and challenges. My specialty for a while was HP C++ and Motif (often using Interface Architect) on HP-UX, but over the years I migrated towards Sun's C++ and GCC compilers along with X Designer on Solaris. Regardless of the compiler or platform or challenge, there were a couple of tools I always had to have on hand Purify and Quantify (now available from IBM Rational), because they were absolutely invaluable in helping identify subtle problems in C and C++ code.

However, as the '90s drew to a close, I became an independent Java developer, and things like memory analysis, for example, wasn't necessary. Java's got a garbage collector after all, so we don't have to worry about that sort of thing, do we? Some of you are smirking as you read this, because you know the sarcasm with which I wrote that.

Before I let go of my C++ analogies, there was another tool that I carried around with me in my C/C++ days, but this one was a stack of paper rather than a piece of software. It was a document called "Programming in C++, Rules and Recommendations" by Ellemtel Telecommunication System Laboratories, and was an excellent starting point for getting a new team of disparate software developers coding in a standard fashion. Without any intervention, different developers will write code in different styles, leading to delays and potential comprehension problems. Setting coding standards makes it easier for developers to read and understand each other's code.

I'm sharing my past experiences with C/C++ tools with you as a backdrop to a discovery I made a couple of years ago after I forayed into the world of Java development...a discovery that I'll share with you in this product review.

Early in 2002, I stumbled across the Enerjy Software exhibit at a Sun TechDays event in London and was instantly impressed. This article will tell you about my experience using Enerjy's four Java development tools: Enerjy Code Analyzer, Enerjy Memory Profiler, Enerjy Performance Profiler, and Enerjy Thread Profiler. For any Java developer looking to eliminate coding inconsistencies and establish coding best practices, or wanting to combat memory, performance, and thread deadlock issues with Java, this review is for you.

Before I give you the lowdown on the tools, let me describe the development environment in which I work and the sort of Java applications I write. I use Sun's JDK 1.4.2 with Eclipse 3.0 to write real-time data presentation applications (live data feeds). These apps often involve either an Oracle or Sybase database and/or a Web site. In all cases, I'm working on data presentation, graphics, Java3D, and the like. When I wrote this, I reviewed Edition 6 of the Enerjy tools.

Now on to my review of the tools...

Enerjy Code Analyzer
Enerjy describes Enerjy Code Analyzer as a "best-practices audit tool," but I prefer to think of it in terms of a tool that pinpoints deviations from a "fully configurable" set of rules and recommendations. It's a feature-rich, powerful, low-cost Java code analyzer that I use to rapidly validate the code contributions from the half-dozen Java developers on my project, some of whom are in a different country, making it hard to look over their shoulder as I would if they sat near me.

Enerjy Code Analyzer goes beyond pointing out issues with syntax, layout, and style; it's also extremely language-aware. By that, I mean that it identifies omissions and potential errors such as "Switch statement missing default," "Inner class does not use outer class," and "Field hides a superclass field"; mistakes that even the most experienced developer can make. In all, it identifies violations of over 200 Java and J2EE rules and lets you write your own rules for Java code analysis and reporting if there's something unusual that you want it to watch out for.

Enerjy Code Analyzer integrates tightly with most common IDEs: Eclipse, WebSphere Studio Application Developer, JBuilder, JDeveloper, NetBeans and Sun ONE on Windows, Solaris, and Linux (x86). Alternately, it can be run as an Ant process - as part of a nightly build, for example - producing a text, HTML, or XML report by project or by each developer. Whether looking at the output in report form or highlighting it directly in the IDE (as shown by the tooltip and problem pane in Figure 1), the problems are well described and located for easy identification and resolution.

Code Analyzer's other features include rule prioritization and file filtering.

Rule prioritization lets you prioritize the existing rules as well as the ones you custom-build. And because of its tight IDE integration, the assigned priority looks just like your IDE's prioritization convention. If necessary, you can choose to fail a build if certain rules have been violated.

File filtering is a neat feature that lets a developer ignore certain code...like auto-generated code that will be overwritten later on. Code Analyzer lets you remove single files or entire packages from consideration.

Whether used by a team leader to check that all team members are obeying the coding standard or used by oneself as a constant reminder that there can be no slacking in professional software development, Enerjy Code Analyzer is great for focusing on quality. Over the years I've come to believe that if you establish coding standards with every development project, you'll pre-empt bugs, save time, and develop more stable and reliable applications. And it doesn't make a difference if you're working in a large team for a big corporation or on your own, making a small application for a client - the need for quality and consistency is the same.

Enerjy Profilers
I'll break down the individual profiling tools in a minute, but there are some common features shared by all three of Enerjy's profilers that are worth pointing out upfront.

First of all, just as with Enerjy Code Analyzer, all of the profilers integrate tightly with the IDE. In the case of the profilers, they work with Eclipse, WebSphere Studio Application Developer, and JBuilder on Windows, Solaris, and Linux (x86). Each tool profiles existing launches with minimal configuration from the IDE directly.

All three profilers feature graphical representations of the data and display real-time status views of heap and thread activity while profiling. Finally, the data from the profilers can be exported in tab-delimited or comma-separated format, letting you view, print, or chart your progress.

Enerjy Memory Profiler
Enerjy Memory Profiler exists to help you understand what's really going on behind the scenes of your memory allocation calls. Integrated with the IDEs outlined above, it can display a real-time status view of heap and thread activity, and it associates heap and object graph artifacts directly back to the relevant methods. Figure 2 shows an example of Memory Profiler with the change in memory usage of a particular application over time.

Do you really know how much memory your application or even a particular method is allocating? Memory Profiler can tell you. By monitoring individual methods, it can tell you how often they're called and the number and size of the objects actually being allocated.

Are you certain that you're not leaking any memory every time you use a certain method? Don't forget that the garbage collector can only recycle memory if nothing is holding a reference to it. Memory Profiler identifies Java memory leaks that survive method boundaries, showing where the object was allocated and how it escaped garbage collection.

A cool feature of Memory Profiler - something I haven't seen in other Java profilers - is something called "on-the-fly profiling." Basically a developer can change configuration settings on-the-fly - while the application is being profiled - without having to restart the application. Any developer who's had to do this knows how frustrating it is and the time it takes away from the curly braces and semicolons.