The Groovy console is a great way to prototype code. It doesn’t have many text editor or IDE features, but you can run arbitrary Groovy code and inspect the results. You can run it in debug mode and attach to it from a debugger (for example your IDE) to dig deeper and look at the call stack. It’s convenient to test an algorithm or a fix, or to do what-if experiments. And you don’t need to create a class or a main() method - you can execute any valid code snippet. If Groovy is installed and in your PATH, run the console by executing groovyConsole from the command line. I encourage you to test out the code examples as they’re shown to make sure you understand how everything works.

The Groovy console is also a part of Grails - you can run grails console from the command line and start the Grails version of the console. It’s the same application, but it also has Grails-specific hooks like easy access to the Spring ApplicationContext, and automatic application of the PersistenceContextInterceptors. You can use it to call GORM methods, services, and pretty much anything in your application that isn’t related to an HTTP request. As a plugin author I often troubleshoot bean definition issues by running

ctx.beanDefinitionNames.sort().each { println it }
true

as shown in Figure 1.1, “Grails Console”. This grabs all of the Spring bean names (a String[] array) from the ApplicationContext (the ctx binding variable), sorts them (into a new List) and prints each name. The true statement at the end is a trick to avoid printing the entire list again in its toString() form since the console treats the last statement as the return value of the script and renders it in the output window.

Figure 1.1. Grails Console

I highly recommend decompiling Groovy .class files to get a sense for what is added during the compilation process. It’s one thing to believe that getters and setters are added for you, but it’s another to actually see them. And there can be a lot of generated code in some of your classes, for example (jumping ahead a bit here) Grails uses several AST Transformations to add compile-time metaprogramming methods to controllers, domain classes, and other artifacts. JD-GUI is an excellent free decompiler that I’ve had a lot of success with. Figure 1.2, “JD-GUI” shows an example class.

Figure 1.2. JD-GUI

Another option that doesn’t require 3^rd-party software is javap, which is part of the JDK install. Running it with no switches will display the method signatures, e.g. javap target/classes/com.foo.Bar, and passing the -c switch will decompile the code (into a readable form of the bytecode, not the Groovy or analagous Java source), e.g. javap -c target/classes/com.foo.Bar. The output isn’t anywhere near as readable as what you get with a decompiler like JD-GUI but it can be more convenient for a quick look.

This also demonstrates interface coercion; since the Clickable interface has only one method the Closure can implement that method if it has the same parameter type(s); the as keyword tells the Groovy compiler to create a JDK dynamic proxy implementing the interface. This is the simple version, but it also works for interfaces with multiple methods.

To implement an interface with more than one method, create a Map with method names as keys and closures with the corresponding parameter types as values:

import java.sql.Connection

def conn = [
   close: { -> println "closed" },
   setAutoCommit: { boolean autoCommit -> println "autocommit: $autoCommit" }
] as Connection

One useful aspect of this approach is that you aren’t required to implement every method. Calling close or setAutoCommit will invoke the associated closures as if they were methods, but calling an unimplemented method (for example createStatement()) will throw an UnsupportedOperationException. This technique was more common before anonymous inner class support was added to Groovy in version 1.7, but it’s still very useful for creating mock objects when testing. You can implement just the methods that will be called, and configure them to work appropriately for the test environment (for example to avoid making a remote call or doing database access) and switch out the mock implementation in place of the real one.

Although it’s rare to do so, you can create a Closure programmatically (most likely from Java). You might do this if you have some reason to implement some code in Java but need to pass a Closure as a parameter to a Groovy method. The Closure class is abstract but doesn’t have any abstract methods. Instead you declare one or more doCall methods with the supported call signatures:

Closure<String> closure = new Closure<String>(this, this) {
   public String doCall(int x) {
      return String.valueOf(x);
   }
   public String doCall(int x, int y) {
      return String.valueOf(x * y);
   }
};

This can be invoked from Groovy just like one created the typical way:

closure(6) // prints "6"
closure(6, 2) // prints "12"
closure(1, 2, 3) // throws a groovy.lang.MissingMethodException
                 // since there's no 3-param doCall()

this inside a closure is probably not what you expect. Intuitively it seems like it should be the closure itself, but it turns out that it’s actually the class instance where the closure is defined. As such it’s probably not of much use; the owner and delegate are much more useful.

The "owner" of a closure is the surrounding object that contains the closure. It functions as the target of method invocations inside the closure, and if the method isn’t defined then a MissingMethodException will be thrown. In this example if we create a new class instance and call the callClosure method (new SomeClass().callClosure()) it will print "Woof!" since the dogAndCat closure calls the existing woof method, but it will then fail on the meow call since it doesn’t exist:

class SomeClass {

   void callClosure() {

      def dogAndCat = {
         woof()
         meow()
      }

      dogAndCat()
   }

   void woof() {
      println "Woof!"
   }
}

You can assign a "delegate" for a closure to handle method calls. By default the delegate is the owner, but you can change it with the setDelegate method. This is frequently used when parsing DSLs. The DSL can be implemented as a closure and inner method calls and property access can be routed to a helper (i.e. the DSL builder) which implements the logic required when a method or property is called that’s not locally defined but is valid in the DSL.

One example is the mapping block in Grails domain classes. This is a static closure that if defined will be used to customize how the class and fields map to the database:

class User {
   String username
   String password

   static mapping = {
      version false
      table 'users'
      password column: 'passwd'
   }
}

If you were to invoke the mapping closure (User.mapping()) you would get a MissingMethodException for each of the three lines in the closure since the owner of the closure is the User class and there’s no version, table, or password methods (and none added to the metaclass). It’s more clear that these are method calls if we add in the optional parentheses that were omitted:

static mapping = {
   version(false)
   table('users')
   password(column: 'passwd')
}

Now we see that it’s expected that there’s a version method that takes a boolean parameter, a table method that takes a String, and a password method that takes a Map. Grails sets the delegate of the closure to an instance of org.codehaus.groovy.grails.orm.hibernate.cfg.HibernateMappingBuilder (if you’re using Hibernate; it’ll be an analagous NoSQL implementation if you’re using a different persistence provider) and that does have a version and a table method as expected. There’s no password method though. But there’s missing-method handling that looks for a field of the same name as the missing method, and when it finds a match and the parameter is a map, it uses the map data to configure the corresponding column.

So this lets us use an intuitive syntax comprised of regular method calls that are handled by delegate, usually doing a lot of work behind the scenes with a small amount of actual code.

It’s rare to see constructors in Groovy classes. This is because the Groovy compiler adds a constructor that takes a Map and sets field values to map values where the key corresponds to a field name. This gives you named parameters for this constructor syntax, so it’s both more convenient and more clear which values are which. For example a simple POGO like this

class Person {
   String firstName
   String initial
   String lastName
   Integer age
}

can be constructed by setting some or all of the field values:

def author = new Person(firstName: 'Hunter', initial: 's', lastName: 'Thompson')
def illustrator = new Person(firstName: 'Ralph', lastName: 'Steadman', age: 76)
def someoneElse = new Person()

In the examples I’m taking advantage of Groovy letting me omit the [ and ] map characters since it makes the invocations cleaner.

This is especially useful for classes with many fields; in Java you have to either define multiple constructors with various signatures, or pass lots of nulls where you don’t have a value.

Note though that the Map constructor relies on the default constructor that’s added to all classes that don’t define any explicit constructors. It calls that constructor, then sets properties from the provided Map (this is defined in MetaClassImpl.invokeConstructor() if you’re curious). But if you declare one or more parameterized constructors the compiler doesn’t generate an empty one for you, and the Map constructor will fail.

Also, since it’s not a real constructor that’s added to the bytecode, you can use this with Java classes that have a default constructor too. So you could replace this code

MutablePropertyValues propertyValues = ...
def beanDef = new GenericBeanDefinition()
beanDef.setBeanClassName('com.foo.bar.ClassName')
beanDef.setAutowireMode(AbstractBeanDefinition.AUTOWIRE_BY_TYPE)
beanDef.setPropertyValues(propertyValues)

with this:

MutablePropertyValues propertyValues = ...
def beanDef = new GenericBeanDefinition(
      beanClassName: 'com.foo.bar.ClassName',
      autowireMode: AbstractBeanDefinition.AUTOWIRE_BY_TYPE,
      propertyValues: propertyValues)

Groovy also relaxes the requirement to catch and declare checked exceptions. Checked exceptions are widely regarded as a failure in the Java language and a lot of the time there isn’t much you can do once you catch one. So in Groovy you don’t have to wrap calls to methods that throw checked exceptions in try/catch blocks, and you don’t have to declare checked exceptions in method signatures.

For example, consider java.sql.SQLException. A lot of the time a SQLException will be caused by one of two things; temporary connectivity issues with the database, and errors in your SQL. If you can’t connect to the database you probably just have to punt and show an error page, and bad SQL is usually a development-time problem that you’ll fix. But you’re forced to wrap all JDBC code in try/catch blocks, polluting your code.

You can still catch checked (and unchecked) exceptions in Groovy and when you can handle an exception and re-try or perform some action after catching it you certainly should. It’s a good idea to also declare thrown exceptions in your method signatures, both for use by Java and also as a self-documenting code technique.

In Java only boolean variables and expressions (including unboxed Boolean variables) can evaluate to true or false, for example with if checks or as the argument to assert. But Groovy extends this in convenient ways. null Object references evaluate to false. Non-empty collections, arrays, and maps, Iterators and Enumerations with more elements, matching regex patterns, Strings and GStrings (and other implementations of CharSequence) with non-zero length, and non-zero numbers and Characters will all evaluate to true.

This is especially helpful with strings and also collections and maps, so for example you can replace

def someCollection = someMethod(...)
if (someCollection != null && !someCollection.isEmpty()) { ... }

with

def someCollection = someMethod(...)
if (someCollection) { ... }

and

String s = someMethod(...)
if (s != null && s.length() > 0) { ... }

with

String s = someMethod(...)
if (s) { ... }

Semicolons are for the most part unnecessary in Groovy, the exception being the traditional for loop (although you’ll most likely prefer the semicolon-free Groovy for/in version). Also if want to have multiple statements on one line you still need to delimit them with semicolons.

You can omit the return keyword in a method or closure since Groovy treats the last expression value as the return value if you don’t use return.

Scope modifiers are often omitted in Groovy since the default scope is public. You can still define private or protected fields and methods. Since package scope is the default in Java and there’s no keyword for that, Groovy added the groovy.transform.PackageScope annotation in version 1.8 for classes, methods, and fields.

You can often omit parentheses in method calls. This is only true if the method has arguments since otherwise the call would look like property access. So for example all but the last of these are valid:

println("Using parentheses because I can")
println "Omitting parentheses because I can"
println()
println // not valid; looks like property access for a nonexistent getPrintln() method

You can’t omit parentheses from the right side of an assignment however:

int sum = MathUtils.add(2, 2) // ok
int product = MathUtils.multiply 2, 2 // invalid, doesn't compile

Another space saver is the extended list of default imports. Java automatically imports everything from the java.lang package, and Groovy extends this to include java.io.*, java.net.*, java.util.*, groovy.lang.*, and groovy.util.*, as well as the java.math.BigDecimal and java.math.BigInteger classes.

Because Groovy uses braces to declare Closures, you cannot initialize an array the standard Java way:

int[] oddUnderTen = { 1, 3, 5, 7, 9 };

Instead we create the array using List syntax and cast it to the correct array type:

int[] oddUnderTen = [1, 3, 5, 7, 9]

or

def oddUnderTen = [1, 3, 5, 7, 9] as int[]

One other gotcha is that in is a keyword, used by the Groovy for loop, e.g. for (bar in bars) { ... }; def is also a keyword. So Java code that uses either of these as a variable name will need to be updated.

There is also no do/while loop in Groovy, so any code like this will need to be reworked:

do {
   // stuff
}
while (<truth expression>);

Another small difference is that you can’t initialize more than one variable in the first part of a for loop, so this is invalid:

for (int count = someCalculation(), i = 0; i < count; i++) {
   ...
}

and you’ll need to initialize the count variable outside the loop (a rare case where Groovy is more verbose than Java!):

int count = someCalculation()
for (int i = 0; i < count; i++) {
   ...
}

or you could just skip the whole for loop and use times:

someCalculation().times {
   ...
}

or a range with a loop if you need access to the loop variable:

for (i in 0..someCalculation()-1) {
   ...
}

Annotation values that have array types use a different syntax in Groovy than Java. In Java you use { and } to define multi-values attributes:

@Secured({'ROLE_ADMIN', 'ROLE_FINANCE_ADMIN', 'ROLE_SUPERADMIN'})

but since these are used to define closures in Groovy you must use [ and ] instead:

@Secured(['ROLE_ADMIN', 'ROLE_FINANCE_ADMIN', 'ROLE_SUPERADMIN'])

The previous examples will cause compilation errors if you rename a .java class to .groovy and try to compile it, or copy/paste Java code into an existing Groovy class. But checking for object equality actually works differently in Groovy.

In Java == is mostly used for comparing numbers and other primitives, since comparing objects with == just compares object references but not the data in the instances. We use the equals method to test if two objects are equivalent and can be considered equal even though they’re not the same instances. But it’s rare to need the == object comparison, so Groovy overloads it to call equals (or compareTo if the objects implement Comparable). And if you do need to check that two references are the same object, use the is method, e.g. foo.is(bar).

Groovy’s == overload is convenient and avoids having to check for null values, but since it works differently than the Java operator you might want to consider not using it. It’s simple enough to replace x == y with x?.equals(y) which isn’t that many more characters and is still null-safe. If you work with both Java and Groovy it’ll keep you from introducing subtle bugs in your Java code (I’m speaking from experience here …)

Overloaded method selection is another runtime difference between Java and Groovy. Java’s type checking is more strict, so it uses the compilation type of a variable to choose which method to call, whereas Groovy uses the runtime type since it’s dynamically checking all method invocations for metamethods, invokeMethod interception, etc.

So for example consider a few versions of a close utility method:

void close(Closeable c) {
   try { c.close() }
   catch (e) { println "Error closing Closeable" }
}

void close(Connection c) {
   try { c.close() }
   catch (e) { println "Error closing Connection" }
}

void close(Object o) {
   try { o.close() }
   catch (e) { println "Error closing Object" }
}

In Java, this code will invoke the close(Object) variant because the compiler only knows the compile-time type of the connection variable:

Object connection = createConnection(); // a method that returns a Connection
// work with the connection
close(connection);

but if this were Groovy the close(Connection) method would be chosen since it’s resolved at runtime and is based not on the compile type but the actual runtime type of the connection. This is arguably a better approach, but since it’s different from the Java behavior it’s something that you should be aware of.

Many of the methods added to JDK metaclasses are implemented in the org.codehaus.groovy.runtime.DefaultGroovyMethods class. This is a gigantic class (over 18,000 lines as of this writing) with a large number of methods. Many of the convenience methods that you use on a regular basis are implemented here, for example the sort method that’s added to the Collection interface (it sorts lists and creates sorted lists from non-list collections) is implemented by the public static <T> List<T> sort(Collection<T> self) method. It’s interesting to browse this class to see how things work under the covers, and you can use these methods yourself (although this is an internal class, so there may be some risk using it directly since it’s not a public API class).

org.codehaus.groovy.runtime.InvokerHelper is another utility class with a lot of interesting functionality that you should check out.

Since all Groovy objects implement GroovyObject, you can override the invokeMethod method in your class to handle method invocations. There are a few variants of behavior though. By default it’s only called for methods that don’t exist (analagous to methodMissing which we’ll see in a bit), so for example

class MathUtils {

   int add(int i, int j) { i + j }

   def invokeMethod(String name, args) {
      println "You called $name with args $args"
   }
}

def mu = new MathUtils()
println mu.add(2, 3)
println mu.multiply(2, 3)

will generate this output:

5
You called multiply with args [2, 3]

since there is an add method but no multiply. If we change the class to implement the GroovyInterceptable marker interface (which extends GroovyObject)

class MathUtils implements GroovyInterceptable {
...
}

then the result is a java.lang.StackOverflowError. Hmmm. What’s up there? We tend to think of println as just an alias for System.out.println but it’s actually a metamethod added to the Object class that calls System.out.println, so it will be intercepted along with the calls to add and multiply. So the fix is to use System.out.println directly:

class MathUtils implements GroovyInterceptable {

   int add(int i, int j) { i + j }

   def invokeMethod(String name, args) {
      System.out.println "You called $name with args $args"
   }
}

def mu = new MathUtils()
println mu.add(2, 3)
println mu.multiply(2, 3)

and then we’ll see this output:

You called add with args [2, 3]
null
You called multiply with args [2, 3]
null

class Person {
   private String name

   def getProperty(String propName) {
      println "getProperty $propName"
      if ('name'.equals(propName)) {
         return this.name
      }
   }

   void setProperty(String propName, value) {
      println "setProperty $propName -> $value"
      if ('name'.equals(propName)) {
         this.name = value
      }
   }
}

def p = new Person(name: 'me')
println p.name

getProperty name
me

p.name = 'you'

setProperty name -> you

class Person {
   String name

   def propertyMissing(String propName) {
      if ('eman'.equals(propName)) {
         return name.reverse()
      }
      throw new MissingPropertyException(propName, getClass())
   }

   def methodMissing(String methodName, args) {
      if ('knight'.equals(methodName)) {
         name = 'Sir ' + name
         return
      }
      throw new MissingMethodException(methodName, getClass(), args)
   }
}

def p = new Person(name: 'Ralph')
println p.name
println p.eman

p.knight()
println p.name

Ralph
hplaR
Sir Ralph

class Person {
   String name

   static $static_propertyMissing(String propName) {
      println "static_propertyMissing $propName"
   }

   static $static_methodMissing(String methodName, args) {
      println "static_methodMissing $methodName"
   }
}

println Person.foo()
println Person.bar

static_propertyMissing foo
static_methodMissing foo
null
static_propertyMissing bar
null

The most commonly used is the null-safe dereference operator ?. which lets you avoid a NullPointerException when calling a method or accessing a property on a null object. It’s especially useful in a chain of such accesses where a null value could occur at some point in the chain.

For example you can safely call

String name = person?.organization?.parent?.name

and if person, person.organization, or organization.parent are null then null is returned as the expression value. The Java alternative is a lot more verbose:

String name = null;
if (person != null) {
   if (person.organization != null) {
      if (person.organization.parent != null) {
         name = person.organization.parent.name
      }
   }
}

The Elvis operator ?: lets you condense ternary expressions; these two are equivalent:

String name = person.name ?: defaultName

and

String name = person.name ? person.name : defaultName

They both assign the value of person.name to the name variable if it is "Groovy true" (in this case not null and has non-zero length since it’s a String), but using the Elvis operator is more DRY.

The spread operator *. is convenient when access a property or calling a method on a collection of items and collecting the results. It’s essentially a shortcut for the collect GDK method, although it’s limited to accessing one property or calling one method, for example:

def numbers = [1.41421356, 2.71828183, 3.14159265]
assert [1, 2, 3] == numbers*.intValue()

The spaceship operator <=> is useful when comparing values, for example when implementing the compareTo method of the Comparable interface. For example given a POGO where you want to sort by two properties, the spaceship operator makes the implementation very compact:

class Person implements Comparable<Person> {
   String firstName
   String lastName

   int compareTo(Person p) {
       lastName <=> p?.lastName ?: firstName <=> p?.firstName
   }

   String toString() { "$firstName $lastName" }
}

def zakJones = new Person(firstName: 'Zak', lastName: 'Jones')
def jedSmith = new Person(firstName: 'Jed', lastName: 'Smith')
def alJones = new Person(firstName: 'Al', lastName: 'Jones')

def persons = [zakJones, jedSmith, alJones]
assert [alJones, zakJones, jedSmith] == persons.sort(false)

since the operator returns -1 if the left is less than the right, 0 if they’re equal, and 1 if the right is more than the left. So when the first expression (lastName <=> p?.lastName) is non-zero its value is used as the return value and the sort is done by lastName. If the last names match then the Elvis operator kicks in and the second expression (firstName <=> p?.firstName) is used to do a secondary sort by firstName.

You can also use the operator for one-off sorting regardless of whether the items are Comparable, for example

assert [alJones, jedSmith, zakJones] == persons.sort(
    false, { a, b -> a?.firstName <=> b?.firstName })

which sorts just by firstName. Of course Groovy being Groovy, there’s a shorter way of doing that:

assert [alJones, jedSmith, zakJones] == persons.sort(false, { it.firstName })

If you have a need to bypass a getter method (or if there is none) and directly access a field, you can use the .@ operator. For example this class uses some simple logic to return a default value if none is specified, but if you want to know if the value is unspecified you still can:

class Thing {

   private static final String DEF_NAME = 'foo'

   String name

   String getName() { name == null ? DEF_NAME : name }
}

assert 'bar' == new Thing(name: 'bar').name
assert 'foo' == new Thing().name
assert null == new Thing().@name

Note however that this operator only works on the current class; if the field is in a subclass the operator cannot access it and you have to use standard reflection.

The as operator is very useful since it can perform many type coercions. For example there’s no native syntax for a Set like there is for a List, but you can use as with List syntax to create a Set:

def things = ['a', 'b', 'b', 'c'] as Set
assert things.getClass().simpleName == 'HashSet'
assert things.size() == 3

The in operator is a convenient shortcut for the contains method in a Collection:

assert 1 in [1, 2, 5]
assert !(3 in [1, 2, 5])

The .& operator lets you get a reference to a method and treat it like a closure. This might be useful if you’re working with higher-order methods where you pass a closure as a parameter and want the option to pass a method; the .& operator creates an instance of org.codehaus.groovy.runtime.MethodClosure that invokes your method when it’s invoked.

class MathUtils {
   def add(x, y) { x + y }
}

def doMath(x, y, Closure c) {
   c(x, y)
}

def add = new MathUtils().&add
def multiply = { x, y -> x * y }

assert 8 == doMath(4, 2, multiply)
assert 6 == doMath(4, 2, add)
assert 2 == doMath(4, 2, { x, y -> x / y })

There’s a natural tendency to embrace Groovy fully once it becomes apparent how much it has to offer over Java. Writing highly idiomatic Groovy code can lead to the code being hard to understand though. I’ve written cryptic code with no comments that I’ve looked at months later and had to re-learn how it works as if someone else had written it since it was old enough that I didn’t remember working on it, and I had sabotaged myself by writing the code in a way that made sense at the time but not when I came back to it.

The phrase I use for this is "be lazy but not sloppy". By this I mean save yourself time (and typing) and take advantage of Groovy’s cool features, but don’t overdo it and make your code hard to work with and understand.