The residents of Java are waiting. Waiting for the day when another city will rise to supremacy in JVMland. These days they are looking north towards the functional territories and watch with interest as the new cities Kotlin and Ceylon are being built. Many Java inhabitants are tired of the city they live in. Not just since their home town is ruled by Amun, who is said to have just swallowed his predecessor Ra. For years they have been waiting for new facilities to be constructed. Facilities they have seen on weekend trips to other cities like the very hip Ruby or which they got to know and love while going to school in towns like Haskell. The people of Java are restless. While they are very familiar with their home town which provides all the basic features to get by, they are craving for some place new and exciting.

While it is not impossible the move to another city the adventurous have to bear some risks. New cities are having a hard time attracting companies to create jobs for willing new citizens. Often only companies in niche industries are willing to venture outside the secure boundaries of the Java megalopolis. Not few explorers who sought their luck in other cities eventually came back to Java because in the end it turned out to be more convenient. Big companies and with them their employees won’t even consider moving, before a new city has a proven success record. Many cities tried. Non succeeded so far.

The creators of Kotlin, still citizens of Java themselves, claim to have studied and learned from these failed attempts. They are promising all the best features from what is probably their biggest contender – Scala town – while having way easier infrastructure. They are also advertising stellar public transportation (aka Inter Domicile Express), which should help new citizens tremendously with getting to feel at home in the new environment. Like Scala they also aim for seamless communication with all districts in Java.

On first glance Ceylon’s layout looks very similar to Kotlin’s and some even suggest they should join forces to enhance their chances to succeed. But since the foundations of both cities are already done and dusted this seems very unlikely.

Kotlin and Ceylon are planning to open their doors by the end of the year and the weary inhabitants of Java are sitting on their packed bags – waiting.

class BowlingGame {

  var rolls: List[Int] = List()

  def roll(pins: Int): Unit = {
    rolls = rolls :+ pins
  }

  def score: Int = {
    scoreRecursive(0, 1, rolls)
  }

  def scoreRecursive(currentScore: Int, frame: Int, rolls: List[Int]): Int = {
    frame match {
      case 11 => currentScore
      case f => rolls match {
        case 10 :: rollsTail // strike
          => scoreRecursive(currentScore + (rolls take (3) sum), f + 1, rollsTail)
        case first :: second :: rollsTail if (first + second == 10) // spare
          => scoreRecursive(currentScore + (rolls take (3) sum), f + 1, rollsTail)
        case first :: second :: rollsTail // normal
          => scoreRecursive(currentScore + (rolls take (2) sum), f + 1, rollsTail)
        case _ // incomplete game
          => throw new Exception("Only complete games can be scored.")
      }
    }
  }
}

Comparing this piece of code with the Java implementation from Uncle Bob (who, no doubt, knows how to write clean Java code) I would conclude that it is more expressive and concise. The pattern matching is a) shorter and b) makes the algorighm stand out more clearly. I do, however, appreciate that this might have to do with personal taste. But, what this implemenation with pattern matching does make trivial is to also score partial games. It just requires two more lines of code that seem almost obvious.

class BowlingGame {

  var rolls: List[Int] = List()

  def roll(pins: Int): Unit = {
    rolls = rolls :+ pins
  }

  def score: Int = {
    scoreRecursive(0, 1, rolls)
  }

  def scoreRecursive(currentScore: Int, frame: Int, rolls: List[Int]): Int = {
    frame match {
      case 11 => currentScore
      case f => rolls match {
        case 10 :: rollsTail // strike
          => scoreRecursive(currentScore + (rolls take (3) sum), f + 1, rollsTail)
        case first :: second :: rollsTail if (first + second == 10) // spare
          => scoreRecursive(currentScore + (rolls take (3) sum), f + 1, rollsTail)
        case first :: second :: rollsTail // normal
          => scoreRecursive(currentScore + (rolls take (2) sum), f + 1, rollsTail)
        case last :: rollsTail // partial frame
          => currentScore + last
        case nil // partial game
          => currentScore
      }
    }
  }
}

As I described in my previous post (link), the variable rolls might indicate that the above code could be made more functional by replacing it with some other construct like list comprehension or recursion. However, thinking about it, it sort of makes sense since the rolls are indeed what changes as a game progresses. I couldn’t come up with a more functional implementation that is not less expressive. Can you?

I found the following actions helpful in my quest to make my Scala code less imperative and more functional:

• Try to eliminate variables and loops by replacing them with list comprehensions and recursion.
• Try to eliminate if statements by replacing them with pattern matching.

Basically, I look for the key words ‘var’, ‘for’, ‘while’ and ‘if’ in my code and try to think up a way to replace them with something more functional. The result is usually not obvious (for non-(not yet)-functional programmers that is anyway), but I tend to like it more than what I had before.

The most prominent candidates are (in alphabetical order)

• Clojure,
• Groovy and
• Scala.

The ThoughtWorks guys see Groovy ahead of Clojure and Scala, whereas I personally see myself more drawn towards Scala. Which language shall it be? Groovy, Clojure, Scala, some other language? What’s your favorite and why?

Update 13. Aug 2011: With Kotlin there is soon to be a new language in the race for Java’s succession. It certainly sounds very promising. Also follow the discussion on Quora.

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

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:

• Update Ubuntu (sudo apt-get update && sudo apt-get upgrade)
• Add the universe and multiverse Ubuntu repositories
• Install Java and Tomcat (with admin packages)
• Install Subversion (SVN)
• Install Maven
• Install MySQL
• Deploy Hudson to Tomcat
• Deploy Sonar to Tomcat
• Deploy Nexus to Tomcat

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