Checkstyle 3.4

I am readying the 1.0 release of [ehcache](, a popular cache for Java.
I received a patch which I was not happy with, which led me to wonder about tightening my [checkstyle]( rules. Until recently I thought the use of tools such as checkstyle to be near universal on well-engineered projects. After all, it promotes *Shared Code Ownership* and *Coding Standards*, two Agile practices. Some excellent coders from the UK I know don’t use it. They say “Oh, thats that thing you use in Australia. How annoying”.
On my current project, I have the leading Agilist also arguing for fewer rules. So what should you do when your team gets larger? Remove rules that new members find annoying? What about when you find consistent coding errors?
I think the right answer is to start with tight checkstyle rules and then add to them when you find problems. This has always been hard after the event because of all the code that fails. However Checkstyle 3.4 includes a new suppresions.xml file where you can suppress rules in specific lines of a file, a whole file or a set of files, using a regular expression. In the rest of this article I suggest the process of doing just that on the ehcache project.

Continue reading

Change of Blog Technologies – moving from Java to LAMP

I am moving my Blog+Wiki to Movable Type. SnipSnap has served me well. It is Java based, which suits me fine, because I am a Java guy. I run several Linux boxes from my home, which are permanently Internet connected.
However I am planning to move overseas for a year with my family. We will be leasing our house, so I must find a new home for either my servers or my sites. I was quoted a cost of co-location of $200 per month per server, which for my two servers would be $4,800 for the year. I can move the sites to a shared Linux environment for $150 per year.
Doing so requires me to move my commercial software site and my non-commercial blog to LAMP technologies. So that’s what I am doing.
Hosting companies require those wishing to run Java to either use a dedicated server or co-locate. Why is that? In two words, the Virtual Machine. Java is plenty fast enough compared with PHP or Perl. The problem is the memory the VM consumes. On a shared environment, you need to use small amounts of resources, and then hand them back when you are done. The Java VM grows and rarely shrinks. I have never seen one shrink by more than a few percent. This is customisable but still very limited.
So, will Java always be a non-starter for the shared environments of hosting companies? There are two reasons for optimism.
Firstly, JDK5 introduces Class Data Sharing to Sun-based VMs. See Apple have been doing this for a while on OS X. See Sun claims a saving per VM of at least 6MB.
Secondly, there is the Gnu gcj project, which provides Java compiled to native code. It does not use a Virtual Machine. See This project is rapidly maturing. On Fedora Core 2, a whole stack of Java applications compiled with gcj are available, including ant and Tomcat. RedHat are the ones pushing hard for this. I remove these at the moment, because they are the wrong versions for my work and system-wide stuff gets confusing. Having had a read of some user experiences, it seems that it is still a bit raw. If it matures into a first-class Java implementation, then I think the way will be open to use Java on shared hosting environments.
The problem with Virtual Machines is that they generally do not hand back to the OS memory freed from the VM Heap after garbage collection. It depends on the application, but for an application using 100MB of RAM, free memory will be significant, and at times in the order of tens of megabytes. Gcj promises to solve this problem.