Daily Build Articles

In 2007 I started writing articles about Daily Builds for Java applications, which I called the 'Code Cop' Series. Unfortunately I just managed to finish two articles so far, shown below. I have a lot of material for further articles about adding automated testing and enforcing architecture to our daily build, just have to squeeze in the time to do it ;-)

Part 1 - Daily Build with Anthill OS
This article describes my experiences when introducing a daily build in 2004 when I used the Anthill tool. The first steps were to create JavaDoc pages daily and to compile the Java sources. It turned out that the initial set-up of these build routines did not cost much and were supported by the team. Obviously this is only the start of better quality code. Read more in the full article Täglicher Build mit Anthill OS published in JavaSPEKTRUM, 5/2007.

References

• S. McConnell, Daily Build and Smoke Test, in IEEE Software, Vol. 13, No. 4, 1996
• J. Spolsky, Daily Builds Are Your Friend, Joel on Software, 2001
• J. Spolsky, Getting Things Done When You're Only a Grunt, Joel on Software, 2001
• Urbancode, Inc, Anthill OS

Other build tools are Anthill Pro, Continuum, Cruise Control, Maven, Luntbuild (incomplete list).

Part 2 - Daily Code Analysis with PMD
This article introduces static code analysis with PMD. The existing daily build was extended easily. A daily report of the code quality metrics awakened the management and was used as a base to check for a small set of errors. The most serious of them were fixed and part of the coding conventions have been checked automatically since then. Read more in the full article Tägliche Code-Analyse mit PMD published in JavaSPEKTRUM, 1/2008.

References

• P. Duvall, Automation for the people: Continuous Inspection, IBM developerWorks, 2006
• E. R. Harold, Zap bugs with PMD, IBM developerWorks, 2005
• SourceForge.net, PMD

Other code analysis tools are Checkstyle, Enerjy CQ2, Findbugs, JavaNCSS, JLint, Jtest, Optimal Advisor, Sotograph (incomplete list).

(Download source code of Ant-PMD integration and BuildStatistics.java.)

FAQ
Q: Why did you favour Anthill OS instead of all other build tools listed? A: There was no evaluation or decision process. Anthill OS was just the first tool I got my hands on. Everything worked fine, so I did not look further. For a new project I would use Cruise Control because it is actively maintained and has a strong community. Paul Duvall has written a nice comparison of open source CI servers. If your build process is "heavy", you might want to have a look at commercial build servers. Some of them offer build farms. e.g. Anthill Pro, Parabuild or Team City.

Q: You divided all rules of PMD into four groups: error, warning, information and formatting. How can I get this categorisation? A: PMD comes with build in severity. Each rule definition contains an <priority> element. There are also some commercial tools that use PMD under the hood and have their own severity levels. Some of them even have references for each rule, why it's bad.

Q: You use a program called BuildRuleDoc to document used rules. Is it free or home-grown? A: I wrote it myself, but you can use it if you want to. The BuildRuleDoc.zip contains the code, the template to create the rule document, an Ant fragment and some test scripts. You will have to adapt the scripts in order to run them. Finally you need the XML rule set file of active PMD rules to generate the report.

(List of all my publications with abstracts.)

I could disable Macker-check

Do you know Macker by Paul Cantrell? It's a build-time architectural rule checking utility for Java developers. Quite old, but we have been using it for years and it still works great for us.

As I am the code cop here, I tend to torture colleagues with forbidden references ;-) So one made this little modification to a comic from xkcd by Randall Munroe. I came across it recently while organising some project folders... So here it is:

Java Unicode Constants

Java has a strong Unicode support since always. That's nice and is supposed to save us some headache with encodings and code pages as well as allowing us to write real i18n applications (and using fancy symbols). So let's imagine you are working on your revolutionary new application which does some symbolic computations and you need to display an arrow. Maybe you know that it's just '\u2192' or you found it in the tables of the Unicode Database. However, by putting it into your code you will introduce a 'magic' character code. Magic numbers are a coding flaw and should not occur in your code. They need to be defined in some place with some reasonable name. So you end up defining all kind of Unicode letters and symbols you need.

Instead you might want to use these Java UniCode Constants (UCC). Using a small Ruby script these constants were derived directly from the Unicode Database textual representation. For every character there is a constant with its official name and corresponding char or int value. All characters of the Unicode version 4.2.0 up to \u1FFFF are covered except CJK Ideographs. For each Unicode block, e.g. Basic Latin (\u0000..\u007F) or Aegean Numbers (\u10100..\u1013F), there is a separate interface with the block's name defining all code-points defined in this block. First you need to import the blocks, e.g. import unicode.AegeanNumbers. Then you can use the constants in your code like here:

Character.charCount(BasicLatin.DIGIT_NINE)) // 1
Character.getNumericValue(BasicLatin.DIGIT_NINE)) // 9
Character.charCount(NumberForms.ROMAN_NUMERAL_FIVE_HUNDRED)) // 1
Character.getNumericValue(NumberForms.ROMAN_NUMERAL_FIVE_HUNDRED)) // 500
Character.charCount(AegeanNumbers.NUMBER_EIGHT)) // 2
Character.getNumericValue(AegeanNumbers.NUMBER_EIGHT)) // 8

(And yes, I know, interfaces are a poor place for constants. They should only be used to model a behaviour of a class. See the AvoidConstantsInterface rule. But I was young and needed the money... ;-)

Download and Installation
Download UCC 1.00 (330 KB), together with source. Extract the ucc-*.zip and add ucc.jar to your classpath. UCC is JDK 1.1 compliant and does not depend on any other libraries. To use characters beyond \u10000, called code-points, you need Java 1.5 or newer. UCC is Open Source under the GPL license.