In Java, you compile with the javac command and run with the java command.

Groovy has groovyc for compiling and groovy for execution, but you can actually execute the source code.

Use the groovy command to run the source:

The source is actually compiled, but the compiled version is not kept. That’s interesting, but not very common.

In practice, Groovy code is compiled, especially as part of a larger project.

Since the contents of hello_world.groovy are not a class, the file is called a script. Groovy developers often use lowercase with underscores for script filenames. This makes it easy to see which files in a project are scripts and which are classes.

One little-used option is the -e flag on the groovy command, which executes the next argument as a complete script.

Groovy includes an interactive REPL (Read-Eval-Print-Loop) called groovysh. It provides tab completion, history, and line-by-line execution.

Type :help or :h to see all available commands. Exit the Groovy shell using the :exit, :quit, :x, or :q commands.

The Groovy Console is a graphical user interface that allows you to execute Groovy code quickly and easily.

The groovyConsole command starts up the console.

Enter code in the top region and execute it by typing Ctrl-Enter or Ctrl-R on Windows or Cmd-Enter or Cmd-R on a Mac. There is also an Execute Groovy Script icon second from the end on the right.

The Groovy console is great for testing ideas when you don’t want to start up a full-scale IDE.

Java has an assert keyword that is rarely used and turned off by default.

Groovy uses a "power assert" that returns a lot of information when it fails.

All that extra debugging information means most Groovy developers use assert in all their tests

In Java, if you don’t add any import statements you get java.lang.* automatically.

In Groovy, if you don’t add any import statements, you get:

Groovy classes therefore have far fewer import statements than Java classes.

Groovy is optionally typed. If you declare a variable to be of type String, or Date, or Employee, then that’s all that can be assigned to them.

The def keyword tells the compiler we are not declaring a type, which will be determined at runtime.

In Grails, properties in domain classes — which are mapped to database tables — require actual data types. The def keyword is often used as the return type on controller methods, however.

The annotation groovy.transform.ToString triggers an AST transformation that generates a toString method.

The AST transformation did nothing in this case, because the source already had a toString method.

That’s a good general rule:

If you don’t like what Groovy is generating, add your own implementation. Groovy will not change it.

To see the effect of the @ToString transformation, remove the existing toString method

The generated toString method gives the fully-qualified class name followed by the values of the attributes, in order from top down in the class.

If you check the GroovyDocs for groovy.transform.ToString, you’ll find that it takes an optional property called includeNames.

Many AST transformations have optional properties. Check the documentation of the associated annotations for details.

Another transform is provided by @EqualsAndHashCode

The transformation generates an equals method and a hashCode method by the prescription laid down by Joshua Bloch in his Effective Java book. The same methods are also generated by most IDEs, including Eclipse and IntelliJ IDEA.

You can customize the generated methods using the includes or excludes optional properties. See the docs for details.

The @TupleConstructor transformation adds a constructor to the class that takes each attribute in order from top down.

In additional to optional properties like includes and excludes, this transform also allows includeFields, callSuper, and more. See the docs for details.

The combination of @ToString, @EqualsAndHashCode, and @TupleConstructor is so popular that it has a shortcut.

The @Canonical transformation is equivalent to all three.

The sparseness of the code is remarkable. In five lines, this code has:

That’s a lot of power for very little code.

There are many other AST transformations in the Groovy standard library. They include @TypeChecked and @CompileStatic for type safety, @Sortable to automatically implement sorting, @Immutable for generating unmodifiable objects, and @Delegate for implementing composition.

Groovy has native support for collections. To create a list of strings in Java, you would need to write code like:

In Groovy, square brackets ([]) represent a list, whose default implementation is a java.util.ArrayList. Therefore the Groovy equivalent is:

Changing the implementation type can be done in two ways. One is to use the as operator.

The as operator invokes the asType method.

Alternatively, you can replace the def declaration with the desired type.

Groovy will then do the type conversion for you.

This capability is powerful. For example, the split() method returns String[], an array of strings. Converting that into a List is an annoying bit of code, which can be completely eliminated in Groovy.

In Java, a set is a linear collection that is not ordered and does not hold duplicates.

The order here is predictable because the elements are simple integers. Normally the results would not be in insertion order. The duplicates, however, have been eliminated.

The java.util.SortedSet interface sorts elements on insertion.

Duplicates are determined using the equals and hashCode methods. As shown in a previous section, there is an AST transformation called @EqualsAndHashCode available, or you can use the @Canonical annotation which includes it.

Collections have a size method, but Groovy makes that more general.

The native syntax for maps also uses square brackets, but separates keys from values using a colon in each entry.

The keys are assumed to be strings, unless they’re numbers.

Groovy overloads the dot operator to be put or get, and the putAt and getAt methods are also available. Therefore you can write:

Because the dot operator has already been overloaded in the class, you can’t rely on it to convert properties to getter methods.

Groovy’s native syntax for lists, sets, and maps makes coding with those data structures easy. The subject of the next section, closures, shows how to process them.

Consider iterating over a list.

The standard Java loop works in Groovy.

The so-called "for-each" loop introduced in Java 1.5 also works.

You lose the index, but that’s often not a major issue.

Groovy has a similar loop, called a "for-in" loop.

All of these work, but none are the most common way to loop over a collection in Groovy. The most common technique is to use the each method, which takes an instance of groovy.lang.Closure as an argument.

The closure is the code inside the braces, { …​ }. Think of it as the body of a function without a name. The arrow symbol is used to separate the parameters to the function from the function body, which can be written over several lines.

This is a highly contrived, not to mention verbose, example, but it works.

If you do not use the arrow symbol, the default dummy name for one-argument closures is called it.

The each method is defined to take a one-argument closure. The eachWithIndex method takes a two-argument closure.

There are no default argument names for a multi-argument closure, so you must use an arrow to define them.

Groovy closures can access variables defined outside them. For example, here’s way to sum the numbers (though admittedly not a good way):

Though Groovy is not a functional language, it does define some functional capabilities. For example, the collect method transforms a collection into a new one by applying a closure to each element.

Groovy also defines a findAll method that returns all elements that satisfy a closure.

There is a short-cut for collect if you only need to invoke a method on each element.

Anything you can do with the spread-dot operator you can do with collect, but it can be a convenient short-cut.

Consider a map of keys and values.

The each method is defined on maps to take a closure, but the closure can take either one or two arguments.

If the closure takes one argument, it is an instance of the Map.Entry class, which has getKey and getValue methods.

Here accessing the key or value properties invokes the getter methods by the usual Groovy idiom.

If you use a two-argument closure, Groovy splits the keys and values for you.

The names of the dummy variables (k and v) are arbitrary.

All of the map methods are overloaded in this manner. For example, the following transforms a map of keys and values into a list where the keys equal the values.

Since the Groovy JDK adds a join method to Collection that takes a delimiter, here is an easy way to convert a map of parameters and values into a query string for a RESTful web service.

That construct frequently comes in handy.

All the closures considered so far were arguments to pre-defined methods. You can define your own closures and invoke them, however.

Here is a closure representing an add method.

The add variable is defined with the def keyword, but Closure would also be acceptable.

The closure takes two (untyped) arguments, x and y, and returns their sum. The return keyword is optional, because the last evaluated expression is returned automatically.

You invoke the closure by using its call method, or by simply providing the arguments in parentheses.

In each case the closure invokes the plus method on x with argument y. If you check the Groovy JDK docs, you’ll find that the plus method on a list takes another list and performs a union with it.

Once again, if the last argument to a method is a closure, you can place the closure after the parentheses.

In Grails, closures are used to initialize data, to enforce constraints, to customize mappings, and much more. Internally they are used to do some serious metaprogramming, but that’s beyond the scope of this course.

Use ?. to safely navigate associations.

The expression d?.boss?.name asks if d is not null, which if true then evaluates getBoss(). Then it checks whether that result is not null, whereupon it calls getName().

If either are null, it returns null.

Groovy has a spaceship operator, <=>.

The operator uses the compareTo method to evaluate the expression and returns -1 if the left-side is less than the right, 0 if they are equals, and +1 if the left-side is greater than the right.

In Java, only boolean expressions can evaluate to true or false. Groovy generalizes this considerably.

In Groovy, all the following are true:

This makes it much easier to get into trouble, of course, so test cases become more important than ever.

Consider the ternary (three argument) operator in Java:

Because of the Groovy truth, if name is null or empty, it evaluates to false, so this can be simplified.

The question then becomes, why use name twice? What if we could just say, if name is not null and not empty (i.e. true by the Groovy truth) use it, otherwise use a default?

So remove the second instance of the variable:

The expression ?: is known as the Elvis operator, because someone with a vivid imagination looked at it on its side and thought he or she saw Elvis.

Yes, it’s a reach, but a very useful operator.

Java 8 has a method reference operator which uses a double colon. For example, to refer to the random method in the Math class, you can write:

That will generate the first 100 random numbers (between 0 and 1) and print them. The method reference syntax is used both in Math::random and in System.out::println. Each refers the the method and supplies it as a lambda to the method. The forEach method, for example, takes a Consumer as an argument, which is one of the so-called functional interfaces defined in the API.

Groovy doesn’t use the same syntax, but it has a similar technique. Groovy uses the & operator to convert a method into a closure.

Here, the visit method takes a collection and a closure as arguments. The implementation of visit is to apply the closure to each element of the collection and return the transformed values. The idea is to provide a method that can traverse the collection, while letting the client specify what to do with each element.

One way to invoke the method is to use an explicit closure.

This uses the standard Groovy idiom where, since the last argument is a closure, it’s placed after the parentheses. The result is that the visit method prints each element.

Here’s another example. Say you want the total length of all the strings. Then you can use this closure:

Say, however, that you want to use a method that already exists. You can use the method reference operator to convert the method into a closure and use then use it as the second argument.

The echo method simply prints its argument and then returns it.

The result is:

As an aside, experienced developers will recognize that the visit method is essentially a limited form of the Vistor design pattern, which separates the way to traverse a set of elements from what you want to do with them. Here the traversal is pretty trivial, because we’re using a linear collection, but the same process would work for trees or other more complex data structures.

In languages like Groovy that support closures, many of the classic design patterns reduce to practially nothing.

Consider the following XML document.

Say you want to parse this document and get the name of the second person. One Java solution is provided here.

To parse the document, you need a parse method, which is an instance method of DocumentBuilder. You get a DocumentBuilder from a DocumentBuilderFactory, which has a factory method called newDocumentBuilder. To get the DocumentBuilderFactory, you need to use its factory method, newInstance.

Once you’ve done all that, you have a Document instance. To find the element in question, the available search methods are either getElementById (but there are no id’s) or getElementsByTagName. The latter returns a NodeList, which you can then use to get the Node you want.

Then, of course, you have to remember that the value of a Node is not the character data. The character data lives in the text node child of the node, so you need to use getFirstChild to get that child, and then, at long last, you can get the value by calling getNodeValue.

Here, on the other hand, is the Groovy solution:

The difference is almost unfair.

Generating XML using Java is too horrible to include here. Using Groovy is almost trivial. To do that, use a groovy.xml.MarkupBuilder.

The result is the XML data from above.

Builders work through Groovy metaprogramming. They intercept "missing" methods (like person and name) and, in this case, turn them into DOM elements. If the "pretended" method takes an argument with a colon, it becomes an attribute of that element. If it takes a regular argument, it becomes the character data. If there is a closure, it becomes a child element, and so on.

There are other "builder" classes in the standard library, like SwingBuilder and AntBuilder.

Groovy includes a JsonSlurper class that can parse JavaScript Object Notation (JSON) data.

Consider a file with two people in it, in JSON format.

The JsonSlurper class has parse methods that take various sources, but to be different read in the data using the getText method in the File class, then parse it.

Likewise, building JSON data involves a builder class. In this case, it’s groovy.json.JsonBuilder.

The documentation of JsonBuilder is a bit thin. As with most open source projects, better documentation can be found in the test cases. If you look at the subprojects directory under the GitHub repository for Groovy (https://github.com/apache/groovy), you will find several subprojects, one of which is groovy-json. The JsonBuilderTest class can be found there, in the src/spec/test/json folder.

The groovy.util.Expando class has no methods and no attributes, but allows you to add both at runtime.

You add attributes to an expando using the dot notation, as shown. You add methods by assigning a property to a closure. Groovy closures have one argument by default. Using the arrow here with nothing to the left of it means we’re defining a zero-argument closure, which means that the associated method takes no arguments.

Believe it or not, you can add overloaded methods by assigning the proper closure to the same name.

Note we have changed only the single expando instantiated here. If we made another expando, it would not have any of these properties or methods.

Expandos are useful primarly as mock objects for testing, because you can hardwire them to do whatever you like.

More importantly, though, is that we can also modify the class itself, using something called a metaclass.

Every Groovy class implements the GroovyObject interface. One of its methods is invokeMethod, which is called whenever you call a method on an object. Another method is called getMetaClass, which returns the groovy.util.MetaClass instance associated with that object.

The basic idea is that whenever you call a method, Groovy first checks to see if that method exists in the bytecodes. If so, it calls it. If not, it winds up calling invokeMissingMethod on the metaclass.

The cool part is that the metaclass itself is an expando. In fact, the proper name for it is ExpandoMetaClass, or EMC.

Using this is much simpler than it sounds. Consider a class with no attributes and no methods, and modifying it through the metaclass.

The class is modified through its EMC, adding attributes and methods the same way they were added to an expando. Now all instances of the Cat class have those attributes and methods.

This sort of runtime programming is easy and extremely useful in a variety of use cases. In fact, much of the Groovy JDK was created this way.

The @Delegate annotation triggers an AST transformation that exposes all the public methods of a contained class through the container. For example:

The public methods dial in Phone and takePicture in Camera are made available through the SmartPhone class. This means you can invoke either of them on an instance of SmartPhone and the calls will be transferred to the contained objects, then the return values will be sent to the caller.

This is composition, rather than inheritance. The SmartPhone is not a kind of Phone or Camera and can’t be assigned to a reference of either type. In fact, the user doesn’t know how the SmartPhone implements the methods at all.

One question that comes up is, what happens if both the delegates have a method in common? Consider the same example, but with a from property in each delegate representing the manufacturer:

By adding a from property to Phone and Camera, now each class has a public getFrom() and setFrom(String) method. The question is, which one does SmartPhone use?

The answer is, from in SmartPhone uses the version from Phone:

The reason is that the Phone delegate comes first when reading the SmartPhone class from the top down. While transforming, Groovy adds the public methods from Phone to the SmartPhone class. Then it sees the Camera delegate, but the corresponding from methods aren’t missing any more.

This, however, gives a clue on how to resolve the issue in a practical way: add an explicit getFrom() method to SmartPhone:

Now this version will be used because the getFrom method won’t be missing during the transformation phase.

A corresponding setFrom(String) method could also be added, or you can make the from properties final in both delegates.

Immutability is a key property of multi-threaded or multi-processor applications. If you remove "shared mutable state", concurrency becomes much more straightfoward.

Some languages, like Clojure, make everything immutable. Some, like Scala, have both mutable and immutable objects. Some, like Java, make immutability very hard to achieve.

To make a class produce only immutable objects, you have to:

Even that’s not enough. You could try to do all that, or you can use the @Immutable annotation from Groovy, which does all of that for you.

This Contract class has a default and tuple constructor, along with the normal map-based constructor. Dates and strings are defensively copied. The attributes are marked final, and any attempt to change them results in a ReadOnlyPropertyException. There are no getter methods.

The class also provides a toString, an equals, and a hashCode method. Again, all of that from about half a dozen lines of code.

The @Sortable AST transformation adds code to make the class implement Comparable based on its attributes. Here is a class to represent golfers:

Without the annotation, you’d have to write a sorting algorithm yourself. Wtih the annotation, the golfers are sorted by first name, then equal first names are sorted by last name, and equal first and last names are sorted by score.

which yields:

Of course, that’s not how you sort golfers. Fortunately, the annotation takes an includes argument which can list the proper ordering:

Now the sorted list is:

Much better. Note how Webb comes before both Watsons, because of his score, and Bubba comes before Tom because of his first name.

Fans of CaddyShack will recall however, that Ty Webb didn’t sort golfers that way.

With that in mind, here’s the new class:

The new result is now:

Note that since the default sort is ascending, you need to invoke the reverse method in order for Ty to win.

Here’s a quick example. In Groovy, generic types compile correctly, but are not enforced.

Despite the fact that the list has the generic type Integer, you can initialize it with a String and append a Date without a problem.

If this behavior is not acceptable, however, you can use the @TypeChecked annotation, which can be applied to a method or a class. Changing this sample to use a method and adding the annotation results in:

This results in exceptions in both the initialization and the append operation. In each case you get a [Static type checking] error.

Fields are attributes of the test class.

The field is re-instantiated between each test, which helps keep the tests independent. If that’s not what you want, you can add a @Shared annotation.

Here, an instance of groovy.sql.Sql is used internally, presumably to verify the behavior of the dao object.

Fixture methods are used to setup and cleanup information. The built-in methods are:

The analogy with JUnit methods is clear:

The when and then blocks are used as a stimulus/response pair. Code in the when block invokes a method to be tested, or changes the test object in some fashion. It’s properties are then checked in the then block.

Like the expect block, statements in the then block are evaluated according to the Groovy truth, and the test only passes if all conditions in the then block are true.

The previous test can be simplified using a sweet method from the Spock API called old. The argument to the old method is evaluated before the when block executes. That makes it easy to compare values before and after.

This makes it particularly easy to check DAO layers, or other classes that add and remove elements.

The blocks when and then must occur in pairs, but you can have more than one in a given test. In that case, the old method is associated with the previous when block.

The first when block adds two strings to the list. The second when removes them. Since the minus method does not change the original list, it is re-assigned to the strings variable after the subtraction.

In each case, the old method checks the value in the then block before and after its associated when block.

Two blocks are used to indicate setup information: setup and given. Neither of them actually does anything (any code before when or expect is setup), but they indicate to the reader that they are setting up object for use in the test.

Again, the given or setup labels are not necessary. Anything done before when is effectively setup, but they do make the test more readable.

You can also add a cleanup block at the end of the test.

The cleanup block doesn’t actually do anything special — it’s normal Groovy code. It does delimit the then block, however. It will run even if the code in the when block throws an exception, which can be useful.

Most specs don’t need a cleanup block, but it’s available if you want one.

You can also add a string description to each of the blocks.

The added strings are intended to convey the purpose of each block. They don’t actually affect the test in any way.

In JUnit, you can test a method that deliberately throws an exception by using the expected property of the @Test annotation.

Spock goes beyond the JUnit capability, in that you can capture the exception itself and work with it.

To capture the exception use the thrown method. This has two alternative syntax approaches:

Either of these methods capture the exception in the e variable, when can then be checked.

If you want to document that an exception does not occur where you might expect one, use the notThrown method.

The getAt method in List allows you to access the elements using array notation with an index. Unlike arrays, accessing an index in an ArrayList beyond the included number of elements does not throw an exception. Since this behavior may be counterintuitive, it’s helpful to document it with the notThrown method.

Note that this really is syntactic sugar. If an exception is actually thrown, the test will fail. It’s more documentation than anything else.

The resulting object implements all the methods in its argument, which return default values (zero, null, or false) for each method. To change the behavior, use the right-shift operator (>>).

In this case, when the get method is invoked on the list with a zero argument, the mock returns the string data.

The underscore character (_) can be used as a wildcard.

Now all calls to the get method on the mock with any single argument return the string data.

The wildcard syntax is quite flexible and can matach a variety of situations. See the docs for details.

If you want the mock to return different values on each call, you can use the >>> notation.

Now the first call to get(0) will return data1, the second call will return data2, and the third and all subsequent calls will return data3.

You can also declare that a test only passes if a given method is invoked the right number of times. Use a multiplier before the method to do that.

In this case, it doesn’t matter what the get(0) method returns, but the test only passes if it is invoked exactly twice.

This is another place where the wildcard can be useful.

You will often see both multiplicity and expected values combined in the same expression.

Keep in mind that this is two separate conditions: . The get(0) method always returns the string data . The test only passes if the get(0) method is invoked exactly twice

You can also specify that methods are called in the proper order.

When you call myObj.myMethod(), first method1 is invoked on the collaborator object, and then method2 is invoked on the same object. Now the test only passes if the methods are called the right number of times, in the right order. This is known as testing the protocol, or the interaction between the object and its collaborator, rather than just setting an expected value.

Putting everything together, consider a Tribble class.

Tribbles react to Klingons by annoying the Klingon and returning "wheep! wheep!". Tribbles react to Vulcans by soothing the Vulcan and returning "purr, purr". Finally, if you feed a tribble, you get 11 tribbles back.

Klingon and Vulcan are interfaces in this system.

The TribbleSpec can now check all the methods.

If you feed a tribble, you get back 11 tribbles, all of which are instances of the Tribble class (a bit extreme, but it works).

Mocking the Vulcan interface provides implementations for all of its methods, even though the only one we are about is soothe, which we verify is called exactly once.

Mocking the Klingon implements all of its methods. The annoy method is setup to throw an exception when it’s called, so there is no resulting reaction and you can check that an exception is thrown.

Also, the howlAtDeath method is not called, which can be verified by setting its cardinality to zero.