Architecture Rules

Unfortunately checking Java code for compliance with a given software architecture is not done on every project, as far as I know only a few experts do it. This is not good because "if it's not checked, it's not there". Free tool support for enforcing architectural rules has been lacking since long but recently things have changed. Well, maybe not recently but recently I thought about it :-)

Macker
There have always been a few basic tools to check the references of classes. One of these tools is Macker. It's quite old and not actively maintained any more, but I've been using it for years and it worked great for me. It's small and simple and yet immensely powerful. I love it and use it whenever possible. Everybody should use it. And don't turn it off!

A Shameless Plug
Macker and some other tools that can be used to enforce architecture rules are described in the fourth part of my 'Code Cop' series, published in the German magazine iX last summer: Automatisierte Architektur-Reviews (Automated Architecture Reviews) (iX 6/2010).

Architecture Reviews with Ant
The article describes several free tools (PMD, Macker and Classycle) and how to use them with Ant to verify different aspects of an architecture. Each of them has its advantages and disadvantages and when used together they are useful. The examples of the Ant integration and the PMD/Macker/Classycle architecture rules as given in the article should help you getting started with your own checks.

Macker and Maven
As I said above, Macker comes with proper Ant support, but Maven integration has been lacking. Last year I wanted to use Macker on an Maven project but was disappointed by the immaturity of the MackerMavenPlugin available on Codehaus. So I had to enhance it a bit. I submitted some patches which got accepted but still the MOJO wouldn't get promoted out of its sandbox state. Fortunately I keep an unofficial release (0.9) in my own Maven repository. So finally proper Maven integration of Macker is available.

Other Tools
I guess there are other tools available to be used with Maven. For example there is Architecture Rules with its maven-architecture-rules-plugin which uses JDepend under the hood. It looks promising but I haven't used it in production yet. And I hear that Sonar 2.4 is able to check architecture rules as well but I didn't try it till now.

(List of all my publications with abstracts.)

Testing For All One's Worth

In the end of last year, after a long break, the third part of the 'Code Cop' series has been published in the well known German magazine iX:

Tägliche Builds mit automatisierten Tests (Daily Builds with Automated Testing) (iX 1/2010). [... Automated testing is vital for the quality assurance. Unit-tests are applied easily using JUnit. The same is true for functional testing thanks to a number of already existing tools. By adding testing capabilities to the build, developers are more willing to write tests. In the end the analysis of the code coverage achieved by the tests reveals some possible weak points. ...]

(Download source code of Ant/JUnit/HttpUnit and EMMA integration.)

References

• SourceForge.net, EMMA
• P. Duvall, Continuous testing, IBM developerWorks, 2007
• A. Glover, In pursuit of code quality: Don't be fooled by the coverage report, IBM developerWorks, 2006
• R. Gold, HttpUnit
• R. Miller, The right (XP) tool for the job, IBM developerWorks, 2003

Some other test and code coverage tools mentioned in the article are AgitarOne, dbUnit, Clover, Cobertura, HtmlUnit, JCoverage, Jester, Jtest, JUnitPerf, Selenium, XMLUnit (incomplete list).

(List of all my publications with abstracts.)

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.)

Object Life Time Monitoring

Two years ago, in the dark ages before Java 5 (2004) I needed to do some Java profiling of the Herold website. Recent investigations using commercial profilers like JProbe had failed because their memory and CPU needs made the application virtually unresponsive. So I had to come up with some lightweight profiling solution of my own.

I was only concerned with memory consumption, as performance seemed to be bottle-necked by garbage collection. Based on a method described by Jack Shirazi in his book, I used PhantomReferences and a modified java.lang.Object to track object creation and garbage collection. That's all, very lightweight. Using this (Object) Life Time Monitor (LTM) I got an idea of the number of certain class instances created and active over time. A simple graphical viewer gave an overview of the collected data, the instances' life times, something like that:

Installation
Download LTM 1.01 (49 KB), together with source. It's JDK 1.3 compliant and does not depend on any other libraries. To use it with Java 1.4 extract the ltm-*.zip and put the LTM.jar into your bootclasspath. When using other JREs than 1.4, you have to modify your java.lang.Object as shown below and put it before LTM.jar into your bootclasspath.

// --- code added to object ---
public Object() {
   if (at.herold.test.objlifetime.MonitoringFlag.monitoring) {
     at.herold.test.objlifetime.ObjectLifetimeMonitoring.monitor(this);
   }
}
// --- code added to object ---

Usage
Start your application with LTM enabled by

java -Xbootclasspath/p:LTM.jar
     -cp <your application's classpath>
     at.herold.test.objlifetime.ObjectLifetimeMonitoring
     s
     <your application's main class>
     <your application's parameters if any>

Tell LTM to start collecting data with java -jar LTM.jar start on the same machine running the application. This enables the counting of objects. To stop collecting data run java -jar LTM.jar stop. The application will continue to run normally.

To save the recently collected raw data use java -jar LTM.jar save. This saves the raw data using a constant file name. The file is created in the current folder, depending on your start routines this might be windows/system32 or somewhere else. Now you may stop the application. You can view the saved data with java -jar LTMViewer.jar <raw file>. This loads, analyses and displays the object lifetime statistics. <raw file> is the file saved by LTM earlier. An JPG image is saved as well.

Source
In case you want to add or change something, there are the following Java packages: objlifetime contains the LTM core classes. Monitoring is managed by the AdminThread, which listens to a socket for commands. objlifetime.viewer contains the viewer to analyse the saved data from the LTM. Analysing classes are subclasses of LifeTimeAnalyser. The source is described in detail in the article Überwachung der Anzahl aktiver Objekte in JavaSPEKTRUM, 1/2006. LTM is Open Source under the GPL license.

FAQ
Q: When defining my own java.lang.Object where do I take it's implementation from? A: The original Object shipped with JDK is used. It's source can be found in the src.zip of the JDK. You just have to compile the new Object.java and put in in the bootclasspath before the LTM.jar (because it contains 1.4 Object.class already).

Q: What is all this 'bootclasspath' about? A: See Using the BootClasspath.

Q: Which type of file has to be passed as an argument to LTM? I am running this application by calling the Main.main() method and it's expecting a file name. A: The application is started as usual, LTM just has to sit in its bootclasspath. So <your application> is the qualified class name of the application you want to start for monitoring, e.g. com.company.app.Main. If you want to test a Tomcat web application you need to use the Catalina Bootstrap class here, as found in startup.sh/bat.

Words of Warning
LTM is a simplistic, very specialised kind of profiler. It was written in 2004 targeting J2SE 1.4. Professional profiling tools are much more powerful and reliable. LTM was only developed because we could not suffer the overhead of a full blown memory snapshot algorithm. Note that the newer Java 5 offers better ways to collect the memory information either by using JMX or agents and JVMTI.

References

• H.M. Kabutz, Hooking into the shutdown call, The Java Specialists' Newsletter, 2001.
• R. Shaham, E. Kolodner, M. Sagiv, On the Effectiveness of GC in Java, ISMM, 2000.
• J. Shirazi, K. Pepperdine, Eye on performance: Profiling on the edge, 2004.
• Sun Microsystems, Tuning Garbage Collection with the 1.4.2 JVM, 2003.

(List of all my publications with abstracts.)