In a recent IBM DeveloperWorks article, Reducing Code Noise with Groovy, author Scott Hickey, shows several code examples written in both Java and Groovy to demonstrate how Groovy can reduce the volume of code to express the same idea.

For example, he shows a Bike JavaBean in both Java and Groovy. The Groovy example takes advantage of Groovy's default property semantics. If you simply provide a type and a name for an instance variable, such as String manufacturer, Groovy will make that variable private and provide a public set and get method. This makes the code much smaller, if what you want is a private instance variable with public get and set methods.

In addition, he shows an example where Groovy's duck typing (invoking methods based solely on descriptor, irrespective of the type of object) obviates the need for an interface that was required by the corresponding Java example. In this case Groovy allowed you to provide the same functionality with one type instead of two.

In a sidebar, the author admits that although modern Java IDEs can facilitate the coding of the Java version, because code is read more than it is written, Groovy's more concise code is still advantageous.

IDEs such as Eclipse make it easy to automatically create getters and setters. These tools also make it easy to extract interfaces from concrete classes to facilitate refactoring. I'd argue, however, that code is read more often than it is written. Unfortunately, developers still have to wade through generated code and source files to discern what a program is really doing. With the high quality of Java tooling available, it is debatable whether or not there is a huge savings in the keystrokes to create the Groovy source, but at a glance, you can see that the Groovy code is more concise, easier to decipher, and less complex. In practice, this is a powerful advantage across the scope of applications that have hundreds of classes and thousands of lines of code.

In the conclusion, the author makes the point that Groovy helps reduce the "noise" level required by Java:

All in all, using Groovy removes a significant amount of noise that accompanies our typical Java programs. And that's a pleasant sound indeed!

The author doesn't mention tradeoffs of that noise reduction, such as the fact that duck typing makes it harder for IDEs to perform refactorings, or for JVMs to optimize for speed. Nevertheless, the greater code conciseness that Groovy offers is important. For what kinds of tasks have you used Groovy? Where was it a good fit, where not?

public class MapRentABike implements RentABike
{
   private String storeName;
   private HashMap<String, Bike> bikes = new HashMap();

   public void setStoreName(String name) {
      this.storeName = name;
   }

   public String getStoreName() {
      return storeName;
   }

   public MapRentABike(String storeName) {
      this.storeName = storeName;
      addBike( new Bike("Shimano", "Roadmaster", 20, "11111", 15, "Fair"));
      addBike( new Bike("Cannondale", "F2000 XTR", 18, "22222",12, "Excellent"));
      addBike( new Bike("Trek","6000", 19, "33333", 12.4,"Fair"));
   }

   public String toString() { return "com.springbook.RentABike: " + storeName; }

   public List getBikes() { return bikes.values(); }

   public Bike getBike(String serialNo) {
      return bikes.get(serialNo);
   }

   protected void addBike(Bike bike) {
      // TODO check for duplicates???
      bikes.put(bike.getSerianNumber, bike);      
   }
}

class MapRentABike < Hash
  attr_accessor :storename
 
  def to_s; "RentABike: #{@storename}"; end
 
  def add_bike(bike)
    self[bike.serialnumber] = bike
  end
end