Java distinguishes between primitive types (such as int, double, char, and byte) and reference types (such as Object and String). There is a fixed set of primitive types, and these are the only types that have value semantics—where the value of a variable of that type is the actual number (or character, or true/false value). You cannot create your own value types in Java.

Reference types (everything apart from primitives) have reference semantics—the value of a variable of that type is only a reference to an object. Readers with a C/C++ background may wish to think of a reference as a pointer—it’s a similar concept. If you change the value of a reference type variable, that has no effect on the object it was previously referring to—you’re just making the variable refer to a different object, or to no object at all.

You cannot call methods on values of primitive types, and you cannot use them where Java expects objects of type java.lang.Object. This is particularly painful when working with collections that cannot handle primitive types, such as java.util.ArrayList. To get around this, Java has a wrapper type for each primitive type—a reference type that stores a value of the primitive type in an object. For example, the wrapper for int is java.lang.Integer.

On the other hand, operators such as * in 3*2 or a*b are not supported for arbitrary reference types, but only for primitive types (with the exception of +, which is also supported for strings). As an example of why this causes pain, let’s consider a situation where you have two lists of integers, and you want to come up with a third list where the first element is the sum of the first elements of the other two lists, and so on. The Java code would be something like this:

// Java code!
ArrayList results = new ArrayList();
for (int i=0; i < listOne.size(); i++)
{
    Integer first  = (Integer)listOne.get(i);
    Integer second = (Integer)listTwo.get(i);

    int sum = first.intValue()+second.intValue();
    results.add (new Integer(sum));
}

New features in Java 5 would make this simpler, but there would still be two types (int and Integer) involved, which adds conceptual complexity. There are good reasons for Java to follow this route: the heritage of C and performance optimization concerns. The Groovy answer puts more burden on the computer and less on the programmer.

Groovy makes the previous scenario easier in so many ways they’re almost hard to count. However, for the moment we’ll only look at why making everything an object helps to keep the code compact and readable. Looking at the code block in the previous section, you can see that the problem is in the last two lines of the loop. To add the numbers, you must convert them from Integers into ints. In order to then store the result in another list, you have to create a new Integer. Groovy adds the plus method to java.lang.Integer, letting you write this instead:

results.add (first.plus(second))

So far, there’s nothing that couldn’t have been done in Java if the library designers had thought to include a plus method. However, Groovy allows operators to work on objects, enabling the replacement of the last section of the loop body

// Java
int sum = first.intValue()+second.intValue();
results.add (new Integer(sum));

with the more readable Groovy solution^[1]

results.add (first + second)

You’ll learn more about what operators are available and how you can specify your own implementations in section 3.3.

In order to make Groovy fully object-oriented, and because at the JVM level Java does not support object-oriented operations such as method calls on primitive types, the Groovy designers decided to do away with primitive types. When Groovy needs to store values that would have used Java’s primitive types, Groovy uses the wrapper classes already provided by the Java platform. Table 3.1 provides a complete list of these wrappers.

Any time you see what looks like a primitive literal value (for example, the number 5, or the Boolean value true) in Groovy source code, that is a reference to an instance of the appropriate wrapper class. For the sake of brevity and familiarity, Groovy allows you to declare variables as if they were primitive type variables. Don’t be fooled—the type used is really the wrapper type. Strings and arrays are not listed in table 3.1 because they are already reference types, not primitive types—no wrapper is needed.

While we have the Java primitives under the microscope, so to speak, it’s worth examining the numeric literal formats that Java and Groovy each use. They are slightly different because Groovy allows instances of java.math.BigDecimal and java.math.BigInteger to be specified using literals in addition to the usual binary floating-point types. Table 3.2 gives examples of each of the literal formats available for numeric types in Groovy.

Notice how Groovy decides whether to use a BigInteger or a BigDecimal to hold a literal with a “G” suffix depending on the presence or absence of a decimal point. Furthermore, notice how BigDecimal is the default type of non-integer literals—BigDecimal will be used unless you specify a suffix to force the literal to be a Float or a Double.

Converting a primitive value into an instance of a wrapper type is called boxing in Java and other languages that support the same notion. The reverse action—taking an instance of a wrapper and retrieving the primitive value—is called unboxing. Groovy performs these operations automatically for you where necessary. This is primarily the case when you call a Java method from Groovy. This automatic boxing and unboxing is known as autoboxing.

You’ve already seen that Groovy is designed to work well with Java, so what happens when a Java method takes primitive parameters or returns a primitive return type? How can you call that method from Groovy? Consider the existing method in the java.lang.String class: int indexOf (int ch).

You can call this method from Groovy like this:

assert 'ABCDE'.indexOf(67) == 2

From Groovy’s point of view, we’re passing an Integer containing the value 67 (the Unicode value for the letter C), even though the method expects a parameter of primitive type int. Groovy takes care of the unboxing. The method returns a primitive type int that is boxed into an Integer as soon as it enters the world of Groovy. That way, we can compare it to the Integer with value 2 back in the Groovy script. Figure 3.1 shows the process of going from the Groovy world to the Java world and back.

Figure 3.1. Autoboxing in action: An Integer parameter is unboxed to an int for the Java method call, and an int return value is boxed into an Integer for use in Groovy.

All of this is transparent—you don’t need to do anything in the Groovy code to enable it. Now that you understand autoboxing, the question of how to apply operators to objects becomes interesting. We’ll explore this question next.

If in 1+1 both numbers are objects of type Integer, are those Integers unboxed to execute the plus operation on primitive types?

No. Groovy is more object-oriented than Java. It executes this expression as 1.plus(1), calling the plus() method of the first Integer object, and passing^[2] the second Integer object as an argument. The method call returns a new Integer object of value 2.

This is a powerful model. Calling methods on objects is what object-oriented languages should do. It opens the door for applying the full range of object-oriented capabilities to those operators.

Let’s summarize. No matter how literals (numbers, strings, and so forth) appear in Groovy code, they are always objects. Only at the border to Java are they boxed and unboxed. Operators are a shorthand for method calls. Now that you have seen how Groovy handles types when you tell it what to expect, let’s examine what it does when you don’t give it any type information.

Groovy offers the choice of assigning types explicitly just as you do in Java. Table 3.3 gives examples of optional static type declarations and the dynamic type used at runtime. The def keyword is used to indicate that no particular type is demanded.

As we stated earlier, it doesn’t matter whether you declare or cast a variable to be of type int or Integer. Groovy uses the reference type (Integer) either way. If you prefer to be concise, and you believe your code’s readers understand Groovy well enough, use int. If you want to be explicit, or you wish to highlight to Groovy newcomers that you really are using objects, use Integer.

It is important to understand that regardless of whether a variable’s type is explicitly declared, the system is type safe. Unlike untyped languages, Groovy doesn’t allow you to treat an object of one type as an instance of a different type without a well-defined conversion being available. For instance, you could never treat a java.lang.String with value “1” as if it were a java.lang.Number, in the hope that you’d end up with an object that you could use for calculation. That sort of behavior would be dangerous—which is why Groovy doesn’t allow it any more than Java does.

The choice between static and dynamic typing is one of the key benefits of Groovy. The Web is full of heated discussions of whether static or dynamic typing is “better.” In other words, there are good arguments for either position.

Static typing provides more information for optimization, more sanity checks at compile-time, and better IDE support; it also reveals additional information about the meaning of variables or method parameters and allows method overloading. Static typing is also a prerequisite for getting meaningful information from reflection.

Dynamic typing, on the other hand, is not only convenient for the lazy programmer who does some ad-hoc scripting, but also useful for relaying and duck typing. Suppose you get an object as the result of a method call, and you have to relay it as an argument to some other method call without doing anything with that object yourself:

def node = document.findMyNode()
log.info node
db.store node

In this case, you’re not interested in finding out what the heck the actual type and package name of that node are. You are spared the work of looking them up, declaring the type, and importing the package. You also communicate: “That’s just something.”

The second usage of dynamic typing is calling methods on objects that have no guaranteed type. This is often called duck typing, and we will explain it in more detail in section 7.3.2. This allows the implementation of generic functionality with a high potential of reuse.

For programmers with a strong Java background, it is not uncommon to start programming Groovy almost entirely using static types, and gradually shift into a more dynamic mode over time. This is legitimate because it allows everybody to use what they are confident with.

Whether you specify your types statically or dynamically, you’ll find that Groovy lets you do a lot more than you may expect. Let’s start by looking at the ability to override operators.

As you saw in section 3.1.2, 1+1 is just a convenient way of writing 1.plus(1). This is achieved by class Integer having an implementation of the plus method.

This convenient feature is also available for other operators. Table 3.4 shows an overview.

You can easily use any of these operators with your own classes. Just implement the respective method. Unlike in Java, there is no need to implement a specific interface.

This is all good in theory, but let’s see how they work in practice.

Listing 3.1 demonstrates an implementation of the equals == and plus + operators for a Money class. It is a low-level implementation of the Value Object pattern.^[3] We allow money of the same form of currency to be added up but do not support multicurrency addition.

We implement equals such that it copes with null comparison. This is Groovy style. The default implementation of the equals operator doesn’t throw any NullPointerExceptions either. Remember that == (or equals) denotes object equality(equal values), not identity (same object instances).

Example 3.1. Operator override

Overriding equals is straightforward, as we show at . We also provide a hashCode method to make sure equal Money objects have the same hashcode. This is required by Java’s contract for java.lang.Object. The use of this operator is shown at , where one dollar becomes equal to any other dollar.

At , the plus operator is not overridden in the strict sense of the word, because there is no such operator in Money’s superclass (Object). In this case, operator implementing is the best wording. This is used at , where we add two Money objects.

To explain the difference between overriding and overloading, here is a possible overload for Money’s plus operator. In listing 3.1, Money can only be added to other Money objects. In case, we would like to add Money as

assert buck + 1 == new Money(2, 'USD')

We can provide the additional method

Money plus (Integer more) {
    return new Money(amount + more, currency)
}

that overloads the plus method with a second implementation that takes an Integer parameter. The Groovy method dispatch finds the right implementation at runtime.

This example leads to the general issue of how to deal with different parameter types when implementing an operator method. We will go through some aspects of this issue in the next section.

Implementing operators is straightforward when both operands are of the same type. Things get more complex with a mixture of types, say

1 + 1.0

This adds an Integer and a BigDecimal. What is the return type? Section 3.6 answers this question for the special case of numbers, but the issue is more general. One of the two arguments needs to be promoted to the more general type. This is called coercion.

When implementing operators, there are three main issues to consider as part of coercion.

Java allows only one way of specifying string literals: placing text in quotes “like this.” If you want to embed dynamic values within the string, you have to either call a formatting method (made easier but still far from simple in Java 1.5) or concatenate each constituent part. If you specify a string with a lot of backslashes in it (such as a Windows file name or a regular expression), your code becomes hard to read, because you have to double the backslashes. If you want a lot of text spanning several lines in the source code, you have to make each line contain a complete string (or several complete strings).

Groovy recognizes that not every use of string literals is the same, so it offers a variety of options. These are summarized in table 3.5.

The aim of each form is to specify the text data you want with the minimum of fuss. Each of the forms has a single feature that distinguishes it from the others:

As we hinted earlier, Groovy uses a similar mechanism for specifying special characters, such as linefeeds and tabs. In addition to the Java escapes, dollar signs can be escaped in Groovy to allow them to be easily specified without the compiler treating the literal as a GString. The full set of escaped characters is specified in table 3.6.

Note that in a double-quoted string, single quotes don’t need to be escaped, and vice versa. In other words, 'I said, "Hi."' and "don't" both do what you hope they will. For the sake of consistency, both still can be escaped in each case. Likewise, dollar signs can be escaped in single-quoted strings, even though they don’t need to be. This makes it easier to switch between the forms.

Note that Java uses single quotes for character literals, but as you have seen, Groovy cannot do so because single quotes are already used to specify strings. However, you can achieve the same as in Java when providing the type explicitly:

char a = 'x'

or

Character b = 'x'

The java.lang.String 'x' is coerced into a java.lang.Character. If you want to coerce a string into a character at other times, you can do so in either of the following ways:

'x' as char

or

'x'.toCharacter()

As a GDK goody, there are more to* methods to convert a string, such as toInteger, toLong, toFloat, and toDouble.

Whichever literal form is used, unless the compiler decides it is a GString, it ends up as an instance of java.lang.String, just like Java string literals. So far, we have only teased you with allusions to what GStrings are capable of. Now it’s time to spill the beans.

GStrings are like strings with additional capabilities.^[7] They are literally declared in double quotes. What makes a double-quoted string literal a GString is the appearance of placeholders. Placeholders may appear in a full ${expression} syntax or an abbreviated $reference syntax. See the examples in listing 3.2.

Example 3.2. Working with GStrings

Within a GString, simple references to variables can be dereferenced with the dollar sign. This simplest form is shown at , whereas shows this being extended to use property accessors with the dot syntax. You will learn more about accessing properties in chapter 7.

The full syntax uses dollar signs and curly braces, as shown at . It allows arbitrary Groovy expressions within the curly braces. The curly braces denote a closure.

In real life, GStrings are handy in templating scenarios. A GString is used in to create the string for an SQL query. Groovy provides even more sophisticated templating support, as shown in chapter 8. If you need a dollar character within a template (or any other GString usage), you must escape it with a backslash as shown in .

Although GStrings behave like java.lang.String objects for all operations that a programmer is usually concerned with, they are implemented differently to capture the fixed and the dynamic parts (the so-called values) separately. This is revealed by the following code:

me      = 'Tarzan'
you     = 'Jane'
line    = "me $me - you $you"
assert line == 'me Tarzan - you Jane'
assert line instanceof GString
assert line.strings[0] == 'me '
assert line.strings[1] == ' - you '
assert line.values[0]  == 'Tarzan'
assert line.values[1]  == 'Jane'

You have seen the Groovy language support for declaring strings. What follows is an introduction to the use of strings in the Groovy library. This will also give you a first impression of the seamless interplay of Java and Groovy. We start in typical Java style and gradually slip into Groovy mode, carefully watching each step.

Now that you have your strings easily declared, you can have some fun with them. Because they are objects of type java.lang.String, you can call String’s methods on them or pass them as parameters wherever a string is expected, such as for easy console output:

System.out.print("Hello Groovy!");

This line is equally valid Java and Groovy. You can also pass a literal Groovy string in single quotes:

System.out.print('Hello Groovy!'),

Because this is such a common task, the GDK provides a shortened syntax:

print('Hello Groovy!'),

You can drop parentheses and semicolons, because they are optional and do not help readability in this case. The resulting Groovy style boils down to

print 'Hello Groovy!'

Looking at this last line only, you cannot tell whether this is Groovy, Ruby, Perl, or one of several other line-oriented scripting languages. It may not look sophisticated, but in a way it is. It shows expressiveness—the art of revealing intent in the simplest possible way.

Listing 3.3 presents more of the mix-and-match between core Java and additional GDK capabilities. How would you judge the expressiveness of each line?

greeting = 'Hello Groovy!'

assert greeting.startsWith('Hello')

assert greeting.getAt(0) == 'H'
assert greeting[0]       == 'H'

assert greeting.indexOf('Groovy') >= 0
assert greeting.contains('Groovy')

assert greeting[6..11]  == 'Groovy'

assert 'Hi' + greeting - 'Hello' == 'Hi Groovy!'

assert greeting.count('o') == 3

assert 'x'.padLeft(3)      == '  x'
assert 'x'.padRight(3,'_') == 'x__'
assert 'x'.center(3)       == ' x '
assert 'x' * 3             == 'xxx'

These self-explanatory examples give an impression of what is possible with strings in Groovy. If you have ever worked with other scripting languages, you may notice that a useful piece of functionality is missing from listing 3.3: changing a string in place. Groovy cannot do so because it works on instances of java.lang.String and obeys Java’s invariant of strings being immutable.

Before you say “What a lame excuse!” here is Groovy’s answer to changing strings: Although you cannot work on String, you can still work on StringBuffer!^[10] On a StringBuffer, you can work with the << left shift operator for appending and the subscript operator for in-place assignments. Using the left shift operator on String returns a StringBuffer. Here is the StringBuffer equivalent to listing 3.3:

Throughout the next sections, you will gradually add to what you have learned about strings as you discover more language features. String has gained several new methods in the GDK. You’ve already seen a few of these, but you’ll see more as we talk about working with regular expressions and lists. The complete list of GDK methods on strings is listed in appendix C.

Working with strings is one of the most common tasks in programming, and for script programming in particular: reading text, writing text, cutting words, replacing phrases, analyzing content, search and replace—the list is amazingly long. Think about your own programming work. How much of it deals with strings?

Groovy supports you in these tasks with comprehensive string support. But this is not the whole story. The next section introduces regular expressions, which cut through text like a chainsaw: difficult to operate but extremely powerful.

How do you put the sequence of symbols that declares a pattern inside a string?

In Java, this causes confusion. Patterns use lots of backslashes, and to get a backslash in a Java string literal, you need to double it. This makes for difficulty reading patterns in Java strings. It gets even worse if you need to match an actual backslash in your pattern—the pattern language escapes that with a backslash too, so the Java string literal needed to match the pattern a is "a\\b".

Groovy does much better. As you saw earlier, there is the slashy form of string literal, which doesn’t require you to escape the backslash character and still works like a normal GString. Listing 3.4 shows how to declare patterns conveniently.

assert "abc" == /abc/
assert "\d" == /d/

def reference = "hello"
assert reference == /$reference/

assert "$" == /$/

The slashy syntax doesn’t require the dollar sign to be escaped. Note that you have the choice to declare patterns in either kind of string.

Applied to a given string, Groovy supports the following tasks for regular expressions:

Listing 3.5 shows how Groovy sets patterns into action. Unlike most other examples, this listing contains some comments. This reflects real life and is not for illustrative purposes. The use of regexes is best accompanied by this kind of comment for all but the simplest patterns.

Example 3.5. Regular expressions

and have an interesting twist. Although the regex find operator evaluates to a Matcher object, it can also be used as a Boolean conditional. We will explore how this is possible when examining the “Groovy Truth” in chapter 6.

See your Javadoc for more information about the java.util.regex.Matcher object: how to walk through all matches and how to work with groupings at each match.

You’re now ready to do everything you wanted to do with regular expressions, except we haven’t covered “do something with each occurrence.” Something and each sounds like a cue for a closure to appear, and that’s the case here. String has a method called eachMatch that takes a regex as a parameter along with a closure that defines what to do on each match.

The match gets passed into the closure for further analysis. In our musical example in listing 3.6, we append each match to a result string.

Example 3.6. Working on each match of a pattern

There are two different ways to iterate through matches with identical behavior: use String.eachMatch(Pattern), or use Matcher.each(), where the Matcher is the result of applying the regex find operator to a string and a pattern. shows a special case for replacing each match with some dynamically derived content from the given closure. The variable it refers to the matching substring. The result is to replace “ain” with underscores, but only where it forms part of a rhyme.

In order to fully understand how the Groovy regular expression support works, we need to look at the java.util.regex.Matcher class. It is a JDK class that encapsulates knowledge about

The GDK enhances the Matcher class with simplified array-like access to this information. This is what happens in the following (already familiar) example that matches all non-whitespace characters:

matcher = 'a b c' =~ /S/

assert matcher[0]    == 'a'
assert matcher[1..2] == 'bc'
assert matcher.count == 3

The interesting part comes with groupings in the match. If the pattern contains parentheses to define groups, the matcher returns not a single string for each match but an array, where the full match is at index 0 and each extracted group follows. Consider this example, where each match finds pairs of strings that are separated by a colon. For later processing, the match is split into two groups, for the left and the right string:

matcher = 'a:1 b:2 c:3' =~ /(S+):(S+)/

assert matcher.hasGroup()
assert matcher[0] == ['a:1', 'a', '1']

In other words, what matcher[0] returns depends on whether the pattern contains groupings.

This also applies to the matcher’s each method, which comes with a convenient notation for groupings. When the processing closure defines multiple parameters, the list of groups is distributed over them:

('xy' =~ /(.)(.)/).each { all, x, y  ->
    assert all == 'xy'
    assert x == 'x'
    assert y == 'y'
}

This matcher matches only one time but contains two groups with one character each.

Matcher and Pattern work in combination and are the key abstractions for regexes in Java and Groovy. You have seen Matcher, and we’ll have a closer look at the Pattern abstraction next.

Finally, let’s look at performance and the pattern operator ~String.

The pattern operator transforms a string into an object of type java.util.regex.Pattern. For a given string, this pattern object can be asked for a matcher object.

The rationale behind this construction is that patterns are internally backed by a so-called finite state machine that does all the high-performance magic. This machine is compiled when the pattern object is created. The more complicated the pattern, the longer the creation takes. In contrast, the matching process as performed by the machine is extremely fast.

The pattern operator allows you to split pattern-creation time from pattern-matching time, increasing performance by reusing the finite state machine. Listing 3.7 shows a poor-man’s performance comparison of the two approaches. The precompiled pattern version is at least 20% faster (although these kinds of measurements can differ wildly).

Example 3.7. Increase performance with pattern reuse.

To find words that start and end with the same character, we used the 1 backmatch to refer to that character. We prepared its usage by putting the word’s first character into a group, which happens to be group 1.

Note the difference in spelling in . This is not a =~ b but a = ~b. Tricky.

Don’t forget that performance should usually come second to readability—at least to start with. If reusing a pattern means bending your code out of shape, you should ask yourself how critical the performance of that particular area is before making the change. Measure the performance in different situations with each version of the code, and balance ease of maintenance with speed and memory requirements.

Listing 3.8 completes our journey through the domain of patterns. The Pattern object, as returned from the pattern operator, implements an isCase(String) method that is equivalent to a full match of that pattern with the string. This classification method is a prerequisite for using patterns conveniently with the grep method and in switch cases.

The example classifies words that consist of exactly four characters. The pattern therefore consists of four dots. This is not an ellipsis!

assert (~/.... /).isCase('bear')

switch('bear'){
    case ~/..../ : assert true; break
    default      : assert false
}

beasts = ['bear','wolf','tiger','regex']

assert beasts.grep(~/..../) == ['bear','wolf']

Regular expressions are difficult beasts to tame, but mastering them adds a new quality to all text-manipulation tasks. Once you have a grip on them, you’ll hardly be able to imagine having programmed (some would say lived) without them. Groovy makes regular expressions easily accessible and straightforward to use.

This concludes our coverage of text-based types, but of course computers have always dealt with numbers as well as text. Working with numbers is easy in most programming languages, but that doesn’t mean there’s no room for improvement. Let’s see how Groovy goes the extra mile when it comes to numeric types.

It is always important to understand what happens when you use one of the numeric operators.

Most of the rules for the addition, multiplication, and subtraction operators are the same as in Java, but there are some changes regarding floating-point behavior, and BigInteger and BigDecimal also need to be included. The rules are straightforward. The first rule to match the situation is used.

For the operations +, -, and *:

Table 3.9 depicts the scheme for quick lookup. Types are abbreviated by uppercase letters.

Other aspects of coercion behavior:

Rules can be daunting without examples, so this behavior is demonstrated in table 3.10.

The only surprise is that there is no surprise. In Java, results like in the fourth row are often surprising—for example, (1/2) is always zero because when both operands of division are integers, only integer division is performed. To get 0.5 in Java, you need to write (1f/2).

This behavior is especially important when using Groovy to enhance your application with user-defined input. Suppose you allow super-users of your application to specify a formula that calculates an employee’s bonus, and it gets specified as businessDone * (1/3). With Java semantics, this will be a bad year for the poor employees.

The GDK defines all applicable methods from table 3.4 to implement overridable operators for numbers such as plus, minus, power, and so forth. They all work without surprises. In addition, the abs, toInteger, and round methods do what you’d expect.

More interestingly, the GDK also defines the methods times, upto, downto, and step. They all take a closure argument. Listing 3.9 shows these methods in action: times is just for repetition, upto is for walking a sequence of increasing numbers, downto is for decreasing numbers, and step is the general version that walks until the end value by successively adding a step width.

Example 3.9. GDK methods on numbers

Calling methods on numbers can feel unfamiliar at first when you come from Java. Just remember that numbers are objects and you can treat them as such.

You have seen that in Groovy, numbers work the natural way and even guard you against the most common errors with floating-point arithmetic. In most cases, there is no need to remember all details of coercion. When the need arises, this section may serve as a reference.

The strategy of making objects available in unexpected places starts to become an ongoing theme. You have seen it with numbers, and section 4.1 shows the same principle applied to ranges.