Tuesday, September 23, 2008

It's not a bug; it's an undocumented feature.

One of the reasons that Java has become such a popular and widespread programming language since its introduction doesn't actually come from the features of the language itself. Instead, some of its growing usage can be attributed to the vast number of third party tools that are available to make the Java program development process smoother, more efficient, and with less undocumented features. I've recently started familiarizing myself with some of these Java-oriented tools such as the Eclipse platform, Ant, PMD, FindBugs, Checkstyle, and JUnit. Even with just a small amount of experience, I've already starting to think about how I have been able to get along without such tools and guidelines.

How do they stack up?


After downloading and unpacking Emma, JUnit, Checkstyle, PMD, FindBugs, and SCLC the next step is inserting them into the environmental variables listing of my computer so that Ant will know where to look while it is building your project. With that finished I downloaded a test project supplied by my software engineering professor, Dr. Johnson. It's a simple stack class and test cases which are purposefully broken in various ways. Using these new tools, I plan to get the stack class into both a working as well as efficient and consistent system. By running Ant for each of the build configuration files I find that each except "ant -f verify.build.xml" are successful. At first I think that means each one found no errors in the stack project. However, successful means that PMD, Checkstyle, etc. didn't have any problems running - all my paths were correct - however there were plenty errors to be dealt with and generally nice HTML documents to glean over.

Results and repairs

  • Checkstyle found two violations of our style standards: a misplaced curly brace and a missing javadoc annotation in stack.java. Both easily fixed.
  • FindBugs reported several places that could be changed to be more efficient by changing Integer constructors to Integer.valueOf methods.
  • JUnit found the first true errors in the logic, at this point just in the test cases. Code was corrected to reflect a proper pop order of 3, 2, 1. At this point I also caught a typo in the test cases which had no effect on performance, but wasn't caught by other tools. However upon rerunning the JUnit test I still was finding errors and it took some time to discover that the test cases weren't just written wrong, the stack class itself was incorrectly coded in the top function, which was actually looking at the bottom of the stack.
  • PMD recommended setting some private variables to final and simplifying a return to get rid of an unnecessary temporary variable. It also reminded me to abstract away from unneeded details such as using a List interface even though an ArrayList is being implemented. The final tricky part was an empty catch block. According to my Elements of Java Style book I could simply use a e.printStackTrace, however Dr. Johnson recommended eliminating the try/catch entirely. I implemented this change as well as cleaned up the unnecessary import of the Assert.fail from JUnit.

At this point I gave "ant -f verify.build.xml" a try and behold: my stack distribution.

Overall it was a good experience with some snags but not too much frustration. The various tasks all seemed to have worked in the end. This is of course only a small part of Ant and the associated build tools. I only had to run them, not really understand them, let alone write them, yet. However I got a good appreciation of what they are capable. I expect it to be a steep learning curve, but see the potential for time saved in the long run. I also expect to be able to apply some of the concepts to other non-Java projects when possible.

No comments: