Certain features of the Java language such as automatic garbage collection, multithreading, platform neutrality, absence of pointers, and robust exception handling facilitate the development of large-scale applications with amazing productivity. It is a widely prevalent notion that Java is much easier to learn and use compared to C++ and some even claim that Java has overtaken C++ as the world’s most popular object-oriented language. Although in some contexts Java’s performance might be unacceptable, the number and type of applications built on Java technology are continuing to grow day by day.

In this context it is wise to ask whether the quality of Java applications is automatically better than applications built using other technologies, for example, C++. It must be clearly borne in mind that Java by itself cannot guarantee a bug-free, high performance, reliable, scalable application. Features built into the Java language can only assist to some extent in achieving some of these quality factors. The bottom line is that Java programs can also be buggy and can suffer from performance-related problems. If the architecture, design and coding are not good, a Java program will not be very different from a bad program written in C++ or any other OO language.

There is nothing better than having the code reviewed by an expert developer. However, relying on human beings to perform code review suffers from certain limitations:

If there is a way to perform automatic code review, we could overcome the above problems. Is automatic review possible?

JStyle was designed to expressly address the limitations of manual code review cited above. Before getting into the details of how to use JStyle, it is worth stressing that code review by an expert developer is likely to be more effective than that performed by tools such as JStyle. The reason must be obvious: the intelligence and knowledge possessed by an expert developer is much more than what is built into a tool such as JStyle. However, for various practical reasons, an automated tool might become an important element of the development environment.

In addition to doing code review, JStyle gathers various important object-oriented metrics about the code. Depth of Inheritance Tree, Lack of Cohesion in Methods, and Cyclomatic Method Complexity are just a few of the several metrics that JStyle can derive from the code it reviews (several of these are difficult to compute manually). Many serious practitioners believe that metrics such as these are important health indicators of an object-oriented program.

JStyle’s commenting rules are based on insights that expert Java developers have acquired over a period of time. Starting with about 40 rules at the beginning, JStyle now has close to a hundred rules that have evolved gradually. We have taken special care to eliminate as many spurious comments as possible. However, occasionally JStyle might generate a comment that you, as an expert developer, might want to overrule.

Although JStyle is aware of a large number of bad coding practices, it is necessary in some cases to customize and/or extend the rule set. An example of customization is different project teams or companies following different class naming conventions. For instance, one team might require all classes to begin with C_ as a prefix whereas another might require MMS. Similarly one team might expect all private members to appear first in the class definition whereas another might require public members. The important point here is that although these do not make a program fail at runtime, detecting such violations is an intrinsic part of code review because these violations can adversely affect a program’s maintainability.

Extensibility has to do with the ability to plug in new rules at deployment time. It is conceivable that a particular client follows a set of coding conventions that JStyle does not know of, nor cares about. Consider this: No method should have more than six arguments. A guideline such as this is unlikely to be followed in general, so is not part of JStyle’s default knowledge base. However, unless there is a way of writing such a rule and plugging into JStyle such that it subsequently checked by the tool, there is little value in automating the review process. In support for such rule extensions, JStyle supports two scripting languages: JMScript^TM and VBScript^TM. JMScript is our proprietary scripting language built on top of Java whereas VBScript is standard on the Microsoft platforms. The entire parsed information is available as a set of objects to manipulate within scripts written in either language, so fairly complex and interesting guidelines can be plugged in. Later in this guide, we will look at how to add our own rules in JStyle.

One good question concerning automated review is whether the tool should use the actual Java source file or its compiled form. In order to generate comments JStyle analyzes the Java source file instead of its compiled byte codes. We believe that using the source file has certain advantages:

We would like to point out that although JStyle requires the source code to generate its comments, it is not necessary to have the source for the entire project or application. For instance, if an application has 25 Java files, but has several references to the Java runtime library (which is available as a jar file), source for the Java runtime library is not needed. For correctly resolving references, the Java runtime library must be available to JStyle as a set of class files or a jar file. To take this point further, out of the 25 files that form the application, if it is required to review the source of only 10 files, the remaining 15 files can be made available to JStyle in compiled form. The point is that if a Java file is to be reviewed by JStyle, its source form is needed, but other dependencies can be resolved through the respective compiled files.

These days it is common to find large Java applications where the total number of source files is 500 or more. It is important that the code review tool be able to handle such large projects and is able to produce output relatively quickly. JStyle has been designed to be extremely fast and efficient in its task. One way to appreciate the performance of JStyle is to apply it to the latest release of JDK source.

The following are the salient features of JStyle: