Monday, September 04, 2006

try THE catch IN finally

As widely known the finally clause of Java has be implemented as a mini-subroutine. The subrountine is within the bytecodes of the method containing the finally clause.
The jsr instruction cause a local jump to the sub-routine code and ret instruction cause a return from the sub-routine.
A very interesting impact of this implementation can be seen below.

public int getNum()
{
int i=2;

try
{
return i;
}
finally
{
i=3;
}

}

The return value of the above method is always 2 not 3. The value change in the finally clause doesn't impact the return value.

The reason behind such a behaviour is as follows.

The finally clause is executed prior to the return statement as expected. Before jumping to the code in finally clause, the return value is popped off from the stack and stored in a local variable. The reason for this action is that in Java finally clause can to also place another return value on the stack, can be through a return statement in finally itself.

So the value of i which is 2 is popped-off the stack and stored in a local variable. During the execution of the finally clause the value of i is altered to 3. The finally clause finishes execution and the control is transferred back to the return statement.

~*~Now the return statement uses the stored value as the return value of the method. The return statement is not evaluated again, implies i is not evaluated again, so the change made to i in the finally clause is ineffective.~*~

The change can be made effective only by explicitly adding a return statement to return the value of i in the finally clause.

Thursday, August 31, 2006

Java Code Quality for Programmers- Tools for the trade

Ensuring code quality is an herculean task in J2EE/Java projects today. Fortunately,a lot of tools that help in improving the quality of the Java language code are available as free and open source software. Using these set tools make the code developed conformant to the standards right from the outset of the development phase.


Following is a one such list of usage of different tools to improve the Java code quality that I use in my projects:

1. IDE customization: This constitutes the first line of defense. All the developer IDE must be configured with the same rules for Java code and documentation. Be it Eclipse, Netbeans or Rational Application Developer. This ensures that the code is formatted in similar manner across IDEs and the entire code base is coherent. Further, the IDEs provide a 'Format' option that would automatically format the whole code to the specification provided. This step removes almost all developer 'coding standard' errors.


2.CheckStyle(http://checkstyle.sourceforge.net/): Checkstyle performs a detailed check of code conformance with Java Coding Standards. The tool also points out common functional errors made by programmers. A Checkstyle configuration file customized for the current project coding standards should be created and distributed to the team. This is a better way of communicating the project coding guidelines than a verbal discourse or a huge MS Word/PDF document.Checkstyle plug-ins are available for almost all the popular IDEs. The project Checkstyle configuration can be fed to the IDE plug-in so that any non-conformance is immediately highlighted to the developer in the code. This ensures the code developed is in line with the project coding standards.

3. FindBugs(http://findbugs.sourceforge.net/): FindBugs inspects the Java byte code for bug patterns. Running FindBugs on the code developed reveals a set of issues, majority of runtime bugs, that cannot be caught by the source code analysis tools. Again plug-ins are available for popular IDEs.


Note: Checkstyle and FindBugs can be used without an IDE. The IDE integration is a just an option and left to the discretion of the developer.

Once the above steps/tools have been performed on the code by the developer. The code is ready for the review phase.

Usage of such tools by developers, provide them with a lot of learning about the standards, do's and don'ts of Java programming. These tools free the reviewers from delving into code level laborious issues like documentation, indentation etc, which are best done with automated tools. The reviewer can use the same tools or tools like PMD(http://pmd.sourceforge.net/) and JNCSS(http://www.kclee.de/clemens/java/javancss/) to determine design issues, code complexity.etc.