June 2007

Monthly Archive

Bugs you can write in Groovy, but can’t in Java

Whenever the dynamic language faithful passionately dismiss types, invariably a hip religious war ensues that pits those that feel static typing offers a level of safety (does this make you think “We can dance if we want to“?) and those that feel that types are about as useful as platform shoes (myself, I wear them daily). Nevertheless, without types, you can introduce bugs that wouldn’t otherwise exist. Of course, with proper testing, those bugs do tend to show up quickly– type errors and cast exceptions almost always blow up immediately. In my copasetic career, I’ve been fortunate enough to write applications in Python, Groovy, Jython, and Ruby and haven’t yet been bitten by a bogue bug related to an incorrect type at runtime (that wasn’t otherwise unearthed in a hip test).

Yet, without types, and the related rule that return statements are optional, the runtime engine of your favorite dynamic language does have to make some guesses. And it is in this highly magic process that you can inadvertently create a subtle bug.

For example, check out this highly contrived, yet completely legal example written in Groovy:

def calculateNormLength(str){
 if(str.length() == 0)
  return 0
 println "wasn't 0"

 if(str.length() > 3)
  return 3
}

There is, of course, a logical bug in the code above (what happens when someone passes in “cat” for str? The method will return null), but the key point is that the same corresponding code written in Java doesn’t compile:

public int calculateNormLength(String str){
 if(str.length() == 0)
  return 0;
 System.out.println("wasn't 0");

 if(str.length() > 3)
  return 3;
}

If you try and compile the source file containing this dubious method, you’ll get a nice “This method must return a result of type int” message from the compiler.

As you can see, each trippn’ code example is the same, yet, the Groovy one isn’t caught by a compiler– you must actually find this one. You could spot this nefarious defect via a code review or through a few diligently written tests, but nevertheless, you actually have to be proactive.

It should be noted, however, that if you replace the def with int, you’ll find the bug at runtime with a hip GroovyCastException. Of course, you’re trading flexibility for safety in this case.

The static types/no static types religious war doesn’t show any signs of abating, yet, it seems that in some cases, types (and the associated rules that follow) can save you a small bit of trouble. Can you dig it, man?

9 comments Monday 25 Jun 2007 | Andy | Dynamic Languages, Groovy

The weekly bag– June 22

Lot’s of interesting stuff this week, man:

0 comments Sunday 24 Jun 2007 | Andy | Weekly Bag

The skinney on Continuous Integration

If you are in the Washington, D.C area and are looking for something to do on Thursday, June 28th, Stelligent is hosting a CI war stories discussion at our offices in Reston. There will be plenty of fine wine, but unfortunately, no disco music (and therefore, no disco dancing), but other than that, it promises to be a hip time. Plus, we’ll be raffling off a copasetically signed copy of Continuous Integration: Improving Software Quality and Reducing Risk.

If you ever wanted to chew the fat over a glass of wine with people obsessed with accelerating development, then you should stop by, man! See the post on testearly.com for more details.

2 comments Thursday 21 Jun 2007 | Andy | Continuous Integration

The weekly bag– June 15

This one is one time, man:

0 comments Friday 15 Jun 2007 | Andy | Weekly Bag

Native collections are Groovy, man

Hip languages like Ruby, Python, and Groovy (to name a few) are unique in that they make collections (i.e. lists and maps) a part of the syntax of the language. This is distinctly different than Java, C#, and C++, which as you well know, require that you use a collection library. Both options have their pros and cons– a great example of innovation was Doug Lea’s concurrent library for Java, which, because it was his bag, provided a series of enhanced collection objects until they were finally incorporated into J2SE 5.0. But making collections (and their handling) native to a language has its benefits as well.

For example, if I need to create a list of Strings in Java, I’d have to do something like:

Collection<String> coll = new ArrayList<String>();
coll.add("Leesburg");
coll.add("Reston");
coll.add("Herndon");
coll.add("Mclean");

I’d also have to import both Collection and ArrayList. If I’d like to now iterate over this collection of 4 Strings, I have to do two things:

  • Obtain a handle to an Iterator
  • Iterate over the collection via a looping mechanism, like a for or while loop

With my Collection object from above, using these two steps, I could use a for loop as follows:

for(Iterator iter = coll.iterator(); iter.hasNext();){
 String value = (String)iter.next();
 System.out.println(value);
}

When collections are natively available, their usage becomes quite hip. For example, in Groovy, if I’d like to create a list of Strings, I can do something like:

def coll = ["Leesburg","Reston","Herndon"]

In fact, adding another item to the list of 3 Strings doesn’t even require a call to the add method– Groovy has overloaded the << operator to mimic add like so:

coll << "Mclean"

What’s particularly interesting, man, is that the coll object is still a valid Java Collection object– in fact, it’s of type ArrayList (just like the Java code from earlier).

assert coll.class == ArrayList.class

Iteration is also a breeze with languages that support native collections. In Groovy, the bogue Iterator object, so familiar in Java, basically disappears along with traditional looping constructs too:

coll.each{
 println it
}

Note the code above produces the exact same result as the same copasetic for loop in Java from earlier.

Languages like Groovy, Ruby, etc, are in truth, general purpose languages (just like Java’s bag) but are particularly suited to building applications rapidly because, among other things, they offer syntactic sugar that makes everyday programming tasks easier. Plus, what’s seriously appealing about Groovy is that this rapidness is 100% compatible with existing Java code. Can you dig it?

11 comments Wednesday 13 Jun 2007 | Andy | Groovy

The weekly bag– June 8

Without further ado:

0 comments Tuesday 12 Jun 2007 | Andy | Weekly Bag

Princeton is Groovy, baby

I’ll be speaking at the Princeton Java Users Group tonight about Groovy, man. Last year, I gave a number of presentations at various NFJS shows on Groovy and I’ve taken all the feedback and reworked this years presentation to work as a Groovy 101. I’ll be going over the basics of the language and then will focus on Builders, GroovySQL, Templates, and Groovlets.

I’ll be followed by Jason Rudolph, who’ll be giving a presentation on Grails, which promises to wow everyone, baby. If you are in the area, come by and say hi!

2 comments Tuesday 05 Jun 2007 | Andy | Groovy

Continuous Integration is everyone’s bag, baby

The release of the hippest addition to Addison-Wesley’s Martin Fowler Signature series, Continuous Integration: Improving Software Quality and Reducing Risk, is just around the corner, man. Authored by Paul Duvall, with co-authors Stephen Matyas and yours truly, the book is currently available for pre-order and is scheduled to ship June 29, 2007.

Get your copy today, baby– it makes a copasetic Father’s Day gift as well as belated Mother’s Day, Secretary’s Day, Grandparent’s Day, Christmas, Chanukah, Kwanzaa, etc gift.

1 comment Sunday 03 Jun 2007 | Andy | Continuous Integration

The weekly bag– June 1

Because it’s my bag:

0 comments Sunday 03 Jun 2007 | Andy | Weekly Bag