Posts Tagged ‘Java’

h1

Automatic hashcode method generation

March 11, 2010

When reading the book Implementation Patterns on the bus to work one morning I came across a section that talks about implementing the equals and hashcode methods in Java. I don’t know how often I have read this rule by now: “If you implement equals you also have to implement hashcode“. Otherwise you get into trouble when you try to use objects of your class as a key in a Map or Set. These two methods are basically Siamese twins that share vital organs. They can’t be separated.

Every time I implemented the twins I first created equals based on the business logic I wanted to achieve. Then I just used the standard implementation of hashcode from Joshua Bloch’s Effective Java book using the same instance variables as in equals. Pretty straight forward and in 99% of all cases totally sufficient. You just shouldn’t forget about it.

Reading about it again that day made me wonder though: If it’s so straight forward, why doesn’t the compiler do it for me? I also asked myself why I have never questioned this rule before, or anyone else for that matter. Or did someone? A bit of research should prove just that. There are in fact several ways to avoid writing equals or hashcode yourself ever again.

  • Let your favorite IDE generate it for you
    I can’t believe I’ve been developing in Eclipse this long and never noticed the auto-generation function for equals and hashcode.
  • Use the Apache Commons builder classes
    The usual suspect for convenience classes strikes again. The commons-lang library provides the classes EqualsBuilder and HashcodeBuilder that allow you to build standard equals and hashcode methods by appending the required fields to a builder instance. Alternatively, there is a method that uses reflection to determine the fields (all non-static, non-transient) at runtime.
  • Use Lombok annotations
    Lombok generates equals and hashcode at compile time from annotations in your source code and integrates well with Eclipse. Once you finish typing the annotation the methods even show up in the outline. Pretty neat. An additional bonus is that this boilerplate code no longer clutters your source code.

My winner clearly is Lombok. But don’t take my word for it, try it out yourself. For a more detailed comparison of the above with code examples read this review on the SpringFuse blog.

Image via Wikipedia

Posted in Development | Tagged | Leave a Comment »

h1

Java Build Server

January 23, 2010

Update [15.05.2010]: I finally had a chance to try out SecureCI, which is pretty much exactly what I described in this post. The guys from Coveros did a great job, so I suggest after reading this post you head over to their website, download SecureCI and give it a go. Thanks John for pointing this out to me.

In my last Java project, I set up a build server with Continuous Integration (CI) capability. I am a big fan of Test Driven Development (TDD) and I quite enjoyed Hudson telling us right away when someone checked in code that broke the build. It just gives you so much more confidence in your code and keeps it releasable at all times. In addition, we used Sonar to measure the quality of our code. I found it quite interesting to study how the different metrics changed over the course of the project. We paid particular attention to code coverage and tried to keep it as close to 100% as possible. This should happen naturally anyway if you are practicing TDD.

Setting all this up was a good experience to learn how it all fits together – But I learned my lesson and I don’t really want to do it over and over again. So, I started looking for a Virtual Appliance that had most, if not all, of these capabilities. Setting up a build server must have been done by other developers a million times before. Surely, someone along the way stuck it all on a Virtual Machine (VM) and made it open source, right? Well, that’s what I thought, but I couldn’t find any. So, I decided to create one myself. Unfortunately, I am lacking the hardware to do so at the moment. I have even already created a project for it on https://launchpad.net/java-build-server. Although, I haven’t come around to create the VM yet, I still wanted to share my idea here to maybe animate someone else to go ahead and give it a go. So here it is: my idea of a Java build server.

I planned to start with what I think of as a good enough build server: A VM based on Ubuntu Server JeOS with pre-configured installations of Subversion (Source Control), Hudson (Continuous Integration), Sonar (Quality Metrics), MySQL (to store Quality Metrics), Maven (Build) and Nexus (Enterprise Maven Repository). Once this is all working I am going to also install Trac (Wiki and issue tracking system). You might of course have your own preferences for tools to use for the tasks listed above. Feel free to swap out whatever tool you wish. You might already have an enterprise Maven repository. Fine, just use your existing one. All I am saying is, these tools will be on my build server VM; pre-configured as much as possible with standards found in the tools’ documentation, following the convention over configuration paradigm.

Creating the VM

Here is how I am planning to create my Java build server VM. I am using VMware Studio to create the VM. VMware Studio is a Virtual Appliance itself and I deployed it in VMware Server 2.0. First I created a basic VM based on Ubuntu 8.04.1. Studio automatically installs VMware tools and embeds an in-guest management component called Virtual Appliance Management Infrastructure (VAMI), which lets you configure the network settings of your VM after it has been built. This is essential, since you want your development team to be able to connect to your copy of the build server VM. Here is a list of the essential settings I used to create the base VM:

  • ubuntu-8.04.1-dvd-i386
  • 1 CPU
  • 512 MB RAM
  • 8 GB
  • Network settings: DHCP (to automatically find an IP address)
  • Target format: zip

After the build finished, I downloaded the zipped VM and deployed it on my VMware Server instance. I started the VM and assigned it a static IP address on the boot screen. I logged in and carried out the following steps:

Using the VM

Of course there are some project and company specific configurations that cannot be set in advance. Here is what is left to do:

  • Install a VM container on a server (e.g. VMware Server)
  • Download and start the VM in your container
  • Set the network details on the boot screen
  • Add your developers as users to Subversion (in /usr/local/svn/passwd-team)
  • Create a project
  • Create Hudson jobs to monitor your project

What’s next?

To make using this Java build server even easier I am also planning to create the following:

  • a Maven archetype that only needs the IP address of the build server to be configured
  • a script to create a new project on the build server (create SVN project, create Hudson jobs, etc.)
Image by indigoprime via Flickr

Posted in Development | Tagged , , , , , , , , | 6 Comments »