Practical Groovy

Before I explain how to install and set up Groovy, consider this: why would you need to install anything? This is an important question as you don’t necessarily need a Groovy installation in order to develop with Groovy. Build tools and IDEs can quite happily compile Groovy source files without one. What you absolutely must have, though, is a Java runtime installed.

The Java platform comes in several forms, but for the sake of simplicity I want to focus on two of them: the Java Runtime Environment (JRE) and the Java Development Kit (JDK). The first of these allows you to run Java applications and applets (those things that run in a browser and require the Java plugin). The JDK allows you to build Java applications, as well as run them, and it’s the best option for a Groovy developer.

To get hold of the JDK, head to the download page on Oracle’s website and follow the links. Remember, you only need the basic JDK for your platform. Once you have downloaded the package and installed the JDK (I recommend using an installation path without spaces), you just need to set up an environment variable:

If you’re unsure how to do this, a simple web search for "setting environment variable" combined with your platform will produce plenty of links to help out.

That’s all you need as far as the Java side goes. So what about Groovy? You’ll need to install it for the purposes of this book because you will need access to the associated tools, in particular the Groovy console. You also need a Groovy installation if you want to run standalone scripts, which comes in very handy.

You can install Groovy in a number of ways:

My preferred option is GVM as it makes installing Groovy trivially easy and new versions of Groovy (including beta and other milestone releases) become available through it promptly. The fact you can have different versions of Groovy active in different terminals is an added bonus.

Whichever approach you take, you will end up with a GROOVY_HOME environment variable containing the location of the current Groovy installation. Your PATH environment variable will also include the path to the Groovy installation’s 'bin' directory, since that’s where all the useful tools are. You can verify the installation by running

in a terminal. If everything is working, this will println the line "Hello" to the terminal. If you instead get an error message about the groovy command not being found, then check your PATH environment variable as it’s probably not initialized properly.

So what does a Groovy installation give you? The main tools of interest are:

You will start with the Groovy console as it’s the easiest way to learn Groovy through practice. Just start it up with the command

and you’ll then see the window shown in figure 1.3 TODO.

The Groovy console has several options available, including loading and saving scripts as well as the standard cut, copy and paste. The most important options are

I recommend you remember the keyboard shortcuts for clearing the output pane and executing the script as you’ll be using them a lot.

You’re now all set to start coding.

I’m sure your OS has a calculator app, as do most smartphones. Still, using Groovy as a calculator is a gentle way to introduce some of the basic syntax and semantics of the language. You already saw a simple addition. What happens if you now try

? In most programming languages you would end up with the result 13.75 (although Java would give you 13), and that’s exactly what you get with Groovy. In other words, the division has occurred first. To do the sum first, use parentheses to control the order in which the operators are evaluated:

The above results in 4. Groovy supports all the usual suspects when it comes to arithmetic operators, such as - (subtract), * (multiply), and % (modulo). Unlike Java, it also supports an exponentiation operator:

This gives the result of two to the power of 8. If, like me, you’ve spent too much time in the past using Visual Basic, note that ^ does not perform an exponentiation. It’s the XOR bitwise operator. You can see a complete list of operators in appendix A.

Let’s now introduce some verification into the calculations. First, here is a simple equality comparison:

The result now is a word: true. This is a literal boolean value whose counterpart, as you’d expect, is false.

To verify that the expression does indeed result in true, you can prefix it with the keyword assert:

When you run this, nothing different appears to happen. But what if the expression doesn’t evaluate to true? Try

The expression is obviously now false and this time you see an error message:

What’s interesting about this error is that it shows the values of all parts of the expression, including both the left hand and right hand sides. As you might imagine, this makes it relatively easy to diagnose problems in your code. Assertions are particularly useful in unit tests and other verification-based scenarios.

Let’s now try out the Pythagorean Theorem. You do remember that from school, don’t you? In case it’s been too long, it states that the square of the hypotenuse of a right-angled triangle is equal to the sum of the squares of the other two sides. In code:

This little example introduces some new concepts and syntax. First, it declares and uses a few local variables using the keyword def. Variables declared in this way can contain values of any type, not just numbers. In other words, the variables are untyped.

The second item of interest is the sqrt() method call. The syntax is absolutely identical to Java’s and in this case you’re seeing a static method. This is called on the class itself (lava.lang.Math) rather than on an instance of that class.

Last, but not least, the assertion fails to throw an error despite result being a floating point number. Groovy’s == operator is largely value based so that 5 and 5.0 are considered the same despite being different types. This particular behavior is quite different to that of Java, which is very strict on equality.

Here’s another example with some more method calls. It takes a hexidecimal string, converts it to an integer, divides that value by 2 (using integer division) and then prints out the hexidecimal representation of the result:

The output is simply the string "76ac". Hexidecimal representations are fairly common in our line of work, so it’s useful to know that you can easily transform them to and from integers.

The above example looks unassuming, but it highlights a common struggle with Groovy: where do these methods come from? And where are they documented? To answer those questions, you first need to know what type you’re dealing with. With static methods that’s straightforward as you can see the type directly (Integer in the above example, which is short for java.lang.Integer - the fully qualified class name). It’s not much harder for instance methods as you can always see the type of an object by calling the method getClass():

Executing this simple script results in the following output:

All three types are part of the core Java class library, which is fantastic if you already know Java. (And if you already know Java, you might be surprised at the floating point type - I’ll talk about that soon TODO). What this means for you is that you’ll need to bookmark the Java API documentation when coding in Groovy. You’ll find the parseInt() and toHexString() methods described under java.lang.Integer. What you won’t find is the intdiv() method.

What? Where does that come from then? One thing you have to remember is that one of Groovy’s aims is to be as close to Java as possible while providing user-friendly features. What this means in practice is that Groovy extends the core Java class library with methods and properties that it thinks are particularly useful. intdiv() is one of those methods and you can find it nestled away in the Groovy JDK documentation.

The Groovy JDK is the name given to all the extra properties and methods that Groovy adds to the core Java classes. The layout of the documentation is similar to that of the Java API docs, and so you just need to select the Java class you’re interested in to see what Groovy adds. Look under java.lang.Number (the super class of Integer) and you’ll find intdiv(). Unfortunately it’s not always obvious which type to look at for any given property or method, but it becomes easier as you get to know both Groovy and the Java class library.

There may be something nagging you by this point. All the method calls, such as getClass() and sqrt(), have parentheses. So what about println()? Isn’t that a method call too? If so, where are the parentheses?

println() is indeed a method call, equivalent to System.out.println() in Java. Unlike any other method, though, it can be called as if it were a global function. It doesn’t need to be called on an object or class like all other methods. As for the lack of parentheses, Groovy doesn’t require them in certain circumstances. It’s too early in your Groovy career to discuss exactly what those circumstances are, so for the moment, use parentheses for all method calls and only leave them out for println() calls.

One important point to be aware of is that the parentheses are required if you don’t pass any arguments to println():

What happens if you don’t have parentheses? Try it out:

You will now see an error message rather than the "Goodbye" text:

Note the class name of the exception: MissingPropertyException. Groovy is looking for a property called println, not a method. I’ll come to properties soon, but for completeness, try this example where the parentheses are included but the method name is incorrect:

This time, you will see a different error:

Note how Groovy is stating that it can’t find a method this time. It also rather handily displays a list of known methods that are a close match to the unknown method name just in case you have a simple typo or can’t remember the correct name properly. You should always read the exception messages carefully as they are tremendously useful in determining why something isn’t working.

Another interesting facet of the language is that you’re seeing runtime errors for unknown methods and properties. This is because Groovy resolves properties and methods at runtime by default rather than at compile time. This can be changed, as you’ll see in chapter TODO. You can also make use of this runtime resolution to do interesting things such as creating builders (chapter TODO) or mock objects (chapter TODO).

Let’s return to the world of numbers and look at some more examples. In the following script, I perform a floating-point multiplication repeatedly and time how long it takes:

Ignore the for loop and println() statements for the moment and just focus on the results of executing the script. First, the number it displays is ridiculously long. When you run it, you’ll see what I mean. Second, it takes a while to finish - around 2.5 seconds on my laptop. Now add a D suffix to the literal 100.0 and run the script again:

This time the number is significantly shorter and, more to the point, different. The script also finishes much faster - 33ms for me. What’s going on? It all boils down to the number types being used. When you look at the classes behind the two number literals:

you will see that the first value is of type java.math.BigDecimal, while the second one is a java.lang.Double. Double allows for fast calculations at the cost of accuracy, while BigDecimal is accurate at the cost of speed. In fact, Double cannot represent the final result because it’s too small.

As you can guess from running these scripts, Groovy defaults to BigDecimal for floating point literals, which ensures accuracy. This behavior may bother some of you, but it’s not a big deal. As you can see, it’s easy to turn floating point literals into Doubles through a simple suffix if you have the need for speed.

Integer numbers also show some interesting effects. Consider this example for calculating factorials:

A quick work on the implementation before we look at the behavior of this script. The easiest way to implement the factorial algorithm is via recursion, and for that you need functions. As you can see from the example, Groovy allows you to define functions in a script using the syntax

This is also the basic syntax for defining methods within classes, as you’ll see later. As with the local variables earlier, the factorial() function doesn’t specify an explicit type for its return value, using def instead. Once defined, you can then call the function from anywhere inside the script.

You might notice that factorial() doesn’t specify a type for its argument. Nor does it use def. That’s because method arguments are a special case that don’t require def if they are untyped. If you forget this, don’t worry: Groovy happily accepts def in front of method arguments. It’s just unusual amongst more experienced Groovy developers.

Executing the factorial script behaves as you’d expect, displaying the value 3628800 (everyone knows the factorial of 10, right?). But what if I pass a floating point number to the factorial() function instead?

Ouch! Now when you run this you’ll see an ugly StackOverflowError. That’s because the recursion only stops when n becomes 1, which never happens if the initial argument is not an integer. So if the function only works with integers, can we specify that as a constraint? Indeed we can. Change the signature of the method to

The argument is now typed. If you attempt to call the factorial() method with an argument of 10.5 now, you’ll get a MissingMethodException because Groovy can’t find a method whose signature accepts floating point numbers. You’re still seeing a runtime error though, as Groovy doesn’t perform a compile-time check even though we have specified the types.

Are you happy with the implementation of factorial() as it stands? I’m not. To understand why, try using a value of 17:

Were you expecting a negative number? Whether you were or not, that’s what happens and it’s certainly not correct. The reason for this is that int and Integer can only store integers up to a size of 2³¹. If your value goes beyond that, then you end up with something called integer overflow.

You can force Groovy to use a wider integer type by changing the specified type. Long integers are 64 bit, so that will allow us to calculate larger factorials:

Unfortunately, it’s not long before you hit integer overflows again. Just try using a value of 21! The result is negative yet again. This is one occasion where the java.math.BigInteger type is particularly useful. It can handle integers of almost any size. As with BigDecimal, it’s not as fast as using the core types, but it’s speedy enough for many cases:

You can declare types for local variables and method return values, not just method arguments. Groovy will automatically coerce values to the required type. If a particular coercion isn’t supported, then you get a runtime error. Type coercion has a lot of subtleties to it, so there’s a dedicated section for it in chapter TODO.

History has been recorded in the form of text for thousands of years - in stone, on paper, and now electronically. In that time, words have lost none of their power or usefulness. That’s why a basic type representing text is such a fundamental part of any programming language. And of course that type should be able to handle any language.

Groovy uses Java’s java.lang.String class which is able to represent text in any written language supported by Unicode, or more specifically the 16-bit Unicode Transformation Format (UTF-16). If you’re interested, you can find a full list of supported scripts/alphabets on the Unicode website. I’ll be using the latin alphabet almost exclusively in this book, but you can try this short script in the Groovy console to confirm support for other languages:

The above consists of English, Chinese (Simplified), Thai, and Greek (using Google Translate of course - I only wish I could write in so many diverse languages!). Just bear in mind that you need a text editor or IDE that supports UTF-8 if you want to use non-Latin characters in Groovy source code. This is because the Groovy compiler assumes UTF-8 by default.

It’s quite possible to write a book about character encodings and internationalization, but it’s out of scope for a Groovy language introduction. So from here on in, I’ll be sticking to examples based on English. That will certainly make life easy for the next example which will involve some text analysis.

When programming, we often need to deal with collections of objects, not just single instances. That’s why most languages have built-in support for lists (an ordered collection or sequence) and other types of collection. As with strings, it’s the Java class library that provides these types in Groovy. That doesn’t mean that you get the same experience as if you’re developing in Java. In fact, Groovy brings a greater level of consistency and expressiveness.

We’ll start with ordered collections, which are represented by the java.util.List interface. In the following example, I create a list of words (strings) and then proceed to iterate over them to calculate the shortest, longest and average word lengths. Before you critize the implementation (there are better ways to do this), remember that I’m trying to introduce new concepts and APIs gradually!

The first thing that will strike you if you come from Java is how easy it is to create a literal list of values. It’s simply a list of comma-separated values bounded by square brackets. We can put numbers in there, dates, or any other type. We’re not even forced to use the same type for each element, so we can create a list of mixed strings and numbers for example. That said, collections commonly contain objects of the same type.

The for loop also works exactly the same as for strings. If you’re trying the example out in an IDE, you might even notice that it’s not worried about the w.size() method (IDEs with Groovy support tend to underline methods that they can’t be sure exist on a particular object, typically because they can’t be sure what the type of that object is). That’s because Groovy infers that the list only contains strings, so therefore w must be a string too! This is just a taster of how Groovy straddles the usual line between dynamic and static (type-checked) languages. We’ll be delving deeper into that topic later on in chapter TODO.

The previous example shows you how to iterate over a list, but what if you want to access an element at a specific index? As with strings, you can use the array index operator:

At this point, I can almost hear some Java developers drawing breath to point out a flaw in this example. Surely I should be using the equals() method when comparing strings? Fortunately that’s not the case with Groovy. The == operator performs a value comparison rather than an object identity one. In other words, it does what any non-developer would expect it to do.

Sometimes a list literal isn’t sufficient and you need to build one dynamically. Consider a method that creates a list of the powers of two, i.e. f(x) = 2^x:

In this example, we start with an empty list and then add the relevant numbers to it via the << (left shift) operator. Note that we’re modifying the list directly rather than creating a new list with the extra element. If you’d prefer to use a non-mutating approach, you can use + instead:

Yes, this approach has a cost in terms of execution speed and memory usage (you’re creating a new list and copying the existing elements on each iteration), but in many cases it’s not significant within its context.

The + operator can also be used to merge lists, similar to the way it’s used to concatenate strings:

The more memory-efficient, mutating approach requires an explicit method call rather than an operator:

I have noticed that some people try to use the << operator for this, but it doesn’t work. What you end up with is a 4 element list whose last element is also a list: [1, 2, 3, [4, 5, 6]]. Try it!

You can find the addAll() method and others defined on java.util.List. It’s also worth checking the java.util.Collection and java.util.Iterable interfaces too, since List inherits from them.

When it comes to sequences, you should always try to use lists where possible as they have the richest API and widest support. They also enable you to take advantage of the Java 8 stream support. Unfortunately, you may still come across APIs that use another type of sequence: arrays.

If you’re not familiar with Pig Latin, it’s a technique for obfuscating English words so that they aren’t instantly recognisable. The rules I’ll follow are fairly straightforward:

You can find out more information about Pig Latin on Wikipedia. It’s mostly just a game that people play. So how do we go about implementing such a thing?

Let’s start with a script that has a method for doing the conversion plus a bunch of assertions to verify that it works correctly:

As it stands, running this script will result in an assertion error. It’s kind of obvious because the method always returns an empty string. I’m just trying to take the Test Driven Development (TDD) approach!

The logic for the conversion is deceptively simple (if we ignore the hard cases):

Before we start, though, consider how we are going to do the split and merge. We ideally want to retain all the characters between words and make sure that they get merged back in at the right places. Another thing to consider is whether we want to handle hyphens or other characters that can occur in words. Dealing with strings is rarely easy.

Let’s take a quick and dirty approach: split the text on word boundaries using a regular expression. That will at least retain the characters between words, ensuring that they appear in the result. We may still have trouble with some bits of text, but t will work as a simple demonstration. You can experiment with other approaches as you see fit! Here’s my suggested implementation:

Have fun with the example! The only features that I haven’t covered so far are:

In the next chapter, I want to take the foundations set out in the first two chapters and use them to start doing some practical work with scripts, making use of other Java types and libraries.

A lot of scripting needs involve files: finding them, parsing them, creating them, moving them around, and so on. Java’s API has been traditionally weak in this area, which is why you’ll find libraries like Commons IO that provide a lot of extra utility and convenience. That changed with Java 8, which introduced some significant enhancements to the file APIs. Not everyone will be able to use Java 8 though, so I will give examples for both Java 6 and Java 8. Even if you’re able to use the latter, you will certainly find it useful to learn the old API because so many Groovy projects use them and will probably continue to use them.

Let’s start with the basic mechanism of reading and writing files. Imagine you have a comma-separated values (CSV) file containing the first and last names of authors along with the country and date of birth. Your first job is to print out all the names of the authors sorted alphabetically by their surnames (or family names). Here’s a quick script to do that using Java 8, which you can run in the Groovy console:

There’s much to talk about here, starting with the core classes we’re using to work with the filesystem. The FileSystems class provides access to the default FileSystem of the current platform (Windows, Mac OS X, Linux, etc.), which in turn allows you to construct file paths represented by the java.nio.file.Path interface - a contract of behavior without an implementation. Those file paths are then used by the methods of the Files class to perform file operations, such as copying, reading, and listing directories. Charset is simply a representation of a character encoding such as ISO-8859-1 and UTF-8.

Why do we import these classes? It’s to help avoid name clashes. Classes have a name and a package, also known as a namespace in other languages. This means you can have classes with the same name as long as they are in different packages. The result is that you have to tell Groovy (and Java) which class you are referring to in your code, and that’s what the import statement does.

The readAllLines() method assumes that the target file is text with line breaks in it and produces a list of the lines of text. One interesting aspect of this particular method call is that I explicitly specify a character encoding. If you don’t provide one, the method assumes the text is encoded using the default platform encoding, which varies between Windows, Mac OS X and Linux. I like to use UTF-8 everywhere, but that may not be appropriate for you. It largely depends on who creates the files in the first place. Yes it’s a headache if you’re dealing with any non-ASCII characters, but you need to factor it in to your coding right from the start.

The rest of the script uses features I introduced in the previous chapter. It simply breaks each line of text into its component parts, removing the commas in the process. The first name and last name for each entry are then combined into a single author name string, with the last name first. That means we can perform a natural order sort on the resulting list to get the names in last name order before then printing them all.

Hopefully that’s all straightforward for you, even though the code for reading the file seems more verbose than is perhaps necessary. So what happens if you don’t have access to a Java 8 or newer JVM? In that case, you can use the old java.io.File class instead:

I’ve only shown the file reading code because that’s the only difference from the previous example. What’s striking is that I’ve somehow managed to replace 4 lines of code with just one. A big reason for this is the lack of imports, since I’m only using a single class this time, File, and Groovy doesn’t require you to import it. In fact, there are several core packages that don’t need to be imported because they’re so commonly used. Here’s a short list of those exceptions:

These packages cover such classes as File, String, List, and URL, which means that your scripts become a lot cleaner without those import statements. One thing that newcomers may find confusing is how sub-packages are treated. Consider the classes associated with regular expressions, which I’ll talk more about later in this chapter. They reside in the package java.util.regex, which looks like a sub-package of java.util. In fact, packages aren’t hierarchical except in the way we developers interpret them. The concrete result is that you have to explicitly import a class like java.util.regex.Pattern because its not covered by the java.util.* auto import.

Another factor in the reduced amount of code is that File is a simpler API. And that’s one reason why you will continue to see it, even with code that exclusively runs on Java 8 or above. One thing to bear in mind is that in this case, the readLines() method is provided by the Groovy JDK extensions rather than Java. I recommend that you peruse the Groovy JDK documentation for File because you’ll find plenty of useful methods to try out.

This all raises an obvious yet important question: Which API should you use? I would argue that you should move over to the new NIO classes as soon as you can. Although File is generally simpler and less verbose, which is fine for scripts with simple needs, the NIO API has several advantages. First, it’s easier to unit test as Path is an interface and you can implement your own mock FileSystem (or you can use an existing one such as JIMFS). Second, it integrates with Java 8 streams, allowing you to do things like lazily walk a directory tree.

One way to reduce the clutter in the Java 8 version of the CSV script is to make use of some special import features. You can both alias a class, giving it a shorter name, and explicitly import static methods, meaning you don’t have to qualify them with the class name. Here’s a modified version of the script using these techniques:

As you can see, the code for reading the lines of text from the file is now more readable, which is always good for aiding comprehension of your code. You’ll find static imports in Java as well, but the aliasing is specific to Groovy.

I now want to move away from the kinds of scripts that you can run in the Groovy console to something a bit more useful: command line scripts. You can still write them in the Groovy console, but you must first save them to a file before you can run them from the command line.

The first example harks back to the days of Apache Ant, a venerable build tool from the Java world. I often used its Filter task as a simple template engine, replacing occurrences of @TOKEN@ with whatever parameter values I needed. It’s not hard to reproduce this behavior in a Groovy script, as you’ll see from the following example:

You should by now be familiar with most of the code in the script. The key new feature is the setText() method, which allows you to easily write text to a file. If the file doesn’t exist, it gets created. Otherwise, its content is overwritten by the string you provide. The method also closes the file automatically, so you don’t have to worry about leaving file handles open.

This works well for simple cases, but you often want to write to a file in chunks. Imagine you want to read records from a database table, perhaps process them, and then generate a CSV file containing one line per record. You could create the CSV in memory as a string and then write it out using setText(), but this is an inefficient use of memory and could take noticeably longer than writing each line to the file as you go. It depends on how many records you have.

Fortunately, Groovy provides several convenience methods for writing to a file on an as-you-go basis. I’m using withPrintWriter() in the next example to do exactly that, while also ensuring that the underlying file is closed regardless of whether my code throws an exception or not. The script takes a path to a directory and then generates a CSV file containing the filename, file size, and creation date for each file in that directory.

This example doesn’t have many lines, but it does introduce two important features:

Let’s start with the new API.

Before Java 8, developers either got by with the java.util.Date and java.util.Calendar classes, or they used a third-party library called Joda Time. The latter was often the only choice for even moderately complex date and time work because the core JDK classes were awkward to use and underpowered.

The Date and Time API brings coherence to working with dates in Java. Simple things are often easier to accomplish than with the old Date class, while you also gain greater control with more complex requirements. Still, the Date class should work just fine for the file creation dates in our example. So why use the java.time.* classes? For two reasons. First, the file NIO API gives us a java.time.Instant value rather than a java.util.Date. Second, I think you should prioritize the Date and Time API over java.util.Date for your own code because it’s a significant improvement over the older API. For example, the core classes are immutable and thread safe, unlike Date and Calendar.

Figure xxx shows you the most relevant classes of the Date and Time API for right now. The Instant class represents a fixed point in time, independent of calendars and dates. If people around the globe retrieved the current time as an Instant at the same time, they should all get the same value, Of course, this is unlikely as there will almost certainly be variations between the system clocks on their computers. But that’s the ideal.

The java.time.LocalDateTime class is different in that it represents a (Gregorian) calendar date and time, such as New Year’s Day (1st January for any given year). This is not a fixed point in time because it depends on the time zone you’re interested in. New Year’s Day hits Australia well before the west coast of America. To correlate a date and time to an Instant, you need to use either java.time.ZonedDateTime or java.time.OffsetTimeZone, both of which incorporate the time zone information.

It’s often hard work dealing with calendars and keeping track of time zones, but we’re fortunate that the API makes life easy for our simple use case. The idea is to store the file creation date in the CSV file as an ISO 8601 date rather than an instant. To do that, we want to format the Instant we get from the Files class. The date formatters require dates rather than instants, though, so we use the Instant.atZone() method to perform the conversion using the system’s current time zone. We could also perform the conversion using the UTC time zone if we wanted. It all depends on whether we’re interested in which time zone the file was created in. For server-side work, I’d recommend almost always using UTC.

The Date and Time API brings more to the table than just these classes. Durations and periods allow you to readily calculate deadlines and reminders among other things. Overall, it’s a richer API than we had previously in the JDK without it being laboriously hard to work with.

I now want to go onto the second feature the script introduces: closures.

Developers start using Groovy for a variety of reasons. I started because it was the language of the Grails web framework. But if we could narrow down why people then stayed with Groovy to a single language feature, I’m convinced it would be closures. It’s fairly easy these days to explain the basics of them because most of the popular languages have comparable features:

These aren’t all exactly the same feature, but they do allow for higher-order functions. If you’re not familiar with this term, it means that functions can themselves be arguments to other functions. Consider the example of filtering a list of words. You might want all the words that start with the letter 'p'. You might instead be interested words longer than 5 letters. Or perhaps you just want to remove all swear words using a dictionary. The only difference between each of these requirements is the filter constraint. Does the word start with a particular letter? Is it longer than a particular value? The algorithm for filtering the list is always the same, it’s only the constraint that changes.

That constraint can be implemented as a standalone predicate function, i.e. a function that returns true or false. Let’s see what this looks like in Groovy code:

The findAll() method is a Groovy JDK extension that performs collection filtering. In each of the above calls, it effectively applies the given predicate function (in this case a closure) to each word in the list and only retains the word if the function returns true. You can run the example to see the result.

The basic form of a closure is the following:

So the curly braces delimit the closure literal, similar to the way square brackets delimit lists and maps. This can be a bit confusing because methods, loops, and conditions use curly braces as well. I generally ask myself this: are the curly braces part of an assignment or a method call? If so, then I have a closure. Assignments are easy to pick out:

Method calls tend to be harder to identify because Groovy supports several syntaxes. I’ll explain shortly, but first, one question you may be asking yourself is where the word argument comes from. How does it work? It’s important to understand that a closure’s argument list behaves just the same as a method’s. In other words, word only exists within the context of the closure itself. It’s the responsibility of the findAll() method to pass each word as the argument when calling the closure.

To see what I mean, you can try invoking the closure yourself:

Executing this in the Groovy console will show a result of true, because "petal" starts with a 'p'. What happens if you try to call the closure with more than one argument? The following results in a MissingMethodException for call() because the number of arguments don’t match:

If it’s easy to identify a closure that’s assigned to a variable, why is it harder when the closure is an argument of a method call? Let’s look at the first findAll() call from the list filtering example:

It’s clear that findAll() is a method call because of the parentheses and the closure is defined within the parentheses. This makes the closure definition relatively obvious. But this is an uncommon syntax. The following are all more common alternatives:

Of these, the second is probably the most common and it doesn’t even have any parentheses at all! What’s going on? This is simply syntax sugar for a very specific case. If the closure is the last (or only) argument of a method, it can be defined after the parentheses. If it’s the only argument, it’s common to dispense with the parentheses entirely.

Given this information about closures, can you identify the one in the earlier example where we created a CSV file from a directory listing? If you remember, the script writes the lines of text to the file using the withPrintWriter() method:

The closure begins with { writer → …​. Under the hood, withPrintWriter() creates or opens the target file and creates a java.io.PrintWriter for it using the character encoding specified by the first argument. It then calls the second argument - the closure - passing the newly created writer as it’s argument. When the closure returns or throws an exception, withPrintWriter() closes the file. For Java developers, it’s worth noting that this is the Groovy alternative to Java’s try-with-resources statement, as that syntax isn’t supported by Groovy.

A good way to learn and understand something is through plenty of examples. Two (filtering and writing to a file) aren’t really sufficient. To rectify that, I’m going to revisit some examples from earlier chapters and try to rewrite them using closures where appropriate. This should give you an idea of an alternate approach to thinking about coding problems and how to solve them.

A lot of the examples you saw in the previous chapter have more concise and readable implementations once you start thinking in terms of higher order functions. Take the example for counting the number of vowels in a string. Instead of reaching immediately for a loop to solve the problem, think about what we want to achieve: counting characters. Which characters? Vowels. This is a similar problem to filtering a word list, except this time the algorithm is counting. The predicate simply determines whether a particular character should be counted or not. Is there a method available to do this?

If you check out the Groovy JDK documentation, you’ll find a count() method for CharSequence. The problem is that it only counts occurences of a specified string. What we need is the Iterable.count(Closure) method (the groovy.lang.Closure type is one way to identify a method that accepts closure arguments). Since CharSequence is not an Iterable, we first have to convert it to one using iterator(). We can then perform the count, as demonstrated here:

What was originally 5 lines of a loop is now a single line. The example is also easier to reason about because the code is no longer cluttered with the mechanics of how to count the vowels. The focus here is what we want to achieve, not how.

One thing you’ll quickly realise is how useful closures are in the world of collections. Consider the first example of section 3.2 [xcheck] calculates some statistics about a list of words using a loop. Although the implementation is efficient in terms of there only being a single loop, it’s not obvious at first glance what it’s trying to achieve.

A better approach in terms of code comprehension is to use some Groovy JDK extension methods for calculating the maximum, minimum and sum of values in a collection. The key point is that we’re not after the maximum word in this case - you could interpret this as the last word alphabetically perhaps - but the longest word. That’s where closures come in, as you can see from this alternate implementation of that example:

In other words, we can specify exactly what property of the values in the collection we’re interested in by passing a closure to min(), max(), and sum() that extracts the relevant information. If we were interested in the number of vowels in the words instead, we could implement a vowelCount() method and use that from the closure:

The last example I want to revisit is the method for calculating the power of twos. I originally showed you an example based on a for loop, but let’s now take a different tack. Consider what result we want: a list of elements of the form 2^x, where x is a range of numbers 0 to n. Given a sequence of numbers (0..n), applying the function 2^x to each of the numbers in that sequence will generate a new sequence containing the required powers of two.

In code form, this looks like

The collect() method is a general way of mapping the elements in one sequence to a new sequence. For example a list of words to a list of their lengths. Or sequence of integers to a sequence of their doubles. The actual mapping is defined by the closure, which acts as the mapping function.

If you’re new to this style of programming, you may wonder how useful such a method could be in your day-to-day development. I think you’ll find you use it regularly, along with many of the other closure-based extensions to the JDK. That’s certainly been my experience, particularly as we often work a lot with collections.

There is one complication to this whole area of Groovy. Java originally had nothing like the collect() method prior to Java 8, but that all changed with the introduction of lambda functions and the Streams API. You now have an alternative. Here’s a Groovy version of the powers of two method using that API:

There are several important differences between this example and the previous one:

So which API should you use? The Groovy Collections extensions or Java 8’s Streams API? If you have the option, I think the Streams API is more flexible and has more standard names for many of its methods (map() vs collect(), filter() vs findAll(), etc.). They are also type safe, which can be very useful if you like to use the @TypeChecked or @CompileStatic annotations that I discuss later [xcheck] or like your IDE to know what the types of the closure arguments are without explicitly declaring them. The main cost is the small additional complexity of converting to and fro between collections and streams.

Ultimately, both APIs provide an extra avenue of expressiveness for your code. If both satisfy a set of given requirements, just use the one that you’re most comfortable with.

I hope I’ve given you a good idea of just what you can achieve with Groovy when it comes to scripting, and how easy it can be. I’ve touched on the filesystem and date APIs and explored collections a bit further with closures. All that’s left for you to do is explore the API documentation yourself now that you have the information you need to navigate those waters. I’m also hoping that you are at least starting to get a grasp of what closures are and how they can help. You will find extensive use of them throughout this book and in most Groovy code you’ll come across, so it’s an important topic.

In the next chapter I want to move beyond simple scripting and see how you can incorporate Groovy into a project, such as an command line or web application.