Single line comments start with // and can be found at any position in the line. The characters following //, till the end of the line, are considered part of the comment.

A multiline comment starts with /* and can be found at any position in the line. The characters following /* will be considered part of the comment, including new line characters, up to the first */ closing the comment. Multiline comments can thus be put at the end of a statement, or even inside a statement.

Similarly to multiline comments, GroovyDoc comments are multiline, but start with /** and end with */. Lines following the first GroovyDoc comment line can optionally start with a star *. Those comments are associated with:

Although the compiler will not complain about GroovyDoc comments not being associated with the above language elements, you should prepend those constructs with the comment right before it.

GroovyDoc follows the same conventions as Java’s own JavaDoc. So you’ll be able to use the same tags as with JavaDoc.

Beside the single line comment, there is a special line comment, often called the shebang line understood by UNIX systems which allows scripts to be run directly from the command-line, provided you have installed the Groovy distribution and the groovy command is available on the PATH.

Identifiers start with a letter, a dollar or an underscore. They cannot start with a number.

A letter can be in the following ranges:

Then following characters can contain letters and numbers.

Here are a few examples of valid identifiers (here, variable names):

But the following ones are invalid identifiers:

All keywords are also valid identifiers when following a dot:

Quoted identifiers appear after the dot of a dotted expression. For instance, the name part of the person.name expression can be quoted with person."name" or person.'name’. This is particularly interesting when certain identifiers contain illegal characters that are forbidden by the Java Language Specification, but which are allowed by Groovy when quoted. For example, characters like a dash, a space, an exclamation mark, etc.

As we shall see in the following section on strings, Groovy provides different string literals. All kind of strings are actually allowed after the dot:

There’s a difference between plain character strings and Groovy’s GStrings (interpolated strings), as in that the latter case, the interpolated values are inserted in the final string for evaluating the whole identifier:

Single quoted strings are a series of characters surrounded by single quotes:

All the Groovy strings can be concatenated with the + operator:

Triple single quoted strings are a series of characters surrounded by triplets of single quotes:

Triple single quoted strings are multiline. You can span the content of the string across line boundaries without the need to split the string in several pieces, without contatenation or newline escape characters:

If your code is indented, for example in the body of the method of a class, your string will contain the whitespace of the indentation. The Groovy Development Kit contains methods for stripping out the indentation with the String#stripIndent() method, and with the String#stripMargin() method that takes a delimiter character to identify the text to remove from the beginning of a string.

When creating a string as follows:

You will notice that the resulting string contains a newline character as first character. It is possible to strip that character by escaping the newline with a backslash:

Double quoted strings are a series of characters surrounded by double quotes:

Triple double quoted strings behave like double quoted strings, with the addition that they are multiline, like the triple single quoted strings.

Beyond the usual quoted strings, Groovy offers slashy strings, which use / as delimiters. Slashy strings are particularly useful for defining regular expressions and patterns, as there is no need to escape backslashes.

Example of a slashy string:

Only forward slashes need to be escaped with a backslash:

Slashy strings are multiline:

Slashy strings can also be interpolated (ie. a GString):

There are a few gotchas to be aware of.

An empty slashy string cannot be represented with a double forward slash, as it’s understood by the Groovy parser as a line comment. That’s why the following assert would actually not compile as it would look like a non-terminated statement:

Dollar slashy strings are multiline GStrings delimited with an opening $/ and and a closing /$. The escaping character is the dollar sign, and it can escape another dollar, or a forward slash. But both dollar and forward slashes don’t need to be escaped, except to escape the dollar of a string subsequence that would start like a GString placeholder sequence, or if you need to escape a sequence that would start like a closing dollar slashy string delimiter.

Here’s an example:

Unlike Java, Groovy doesn’t have an explicit character literal. However, you can be explicit about making a Groovy string an actual character, by three different means:

The integral literal types are the same as in Java:

You can create integral numbers of those types with the following declarations:

If you use optional typing by using the def keyword, the type of the integral number will vary: it’ll adapt to the capacity of the type that can hold that number.

For positive numbers:

As well as for negative numbers:

The decimal literal types are the same as in Java:

You can create decimal numbers of those types with the following declarations:

Decimals can use exponents, with the e or E exponent letter, followed by an optional sign, and a integral number representing the exponent:

Conveniently for exact decimal number calculations, Groovy choses java.lang.BigDecimal as its decimal number type. In addition, both float and double are supported, but require an explicit type declaration, type coercion or suffix. Even if BigDecimal is the default for decimal numbers, such literals are accepted in methods or closures taking float or double as parameter types.

When writing long literal numbers, it’s harder on the eye to figure out how some numbers are grouped together, for example with groups of thousands, of words, etc. By allowing you to place underscore in number literals, it’s easier to spot those groups:

We can force a number (including binary, octals and hexadecimals) to have a specific type by giving a suffix (see table bellow), either uppercase or lowercase.

Examples:

Although operators are covered later on, it’s important to discuss the behavior of math operations and what their resulting types are.

Division and power binary operations aside (covered below),

The following table summarizes those rules:

The following binary arithmetic operators are available in Groovy:

Here are a few examples of usage of those operators:

The + and - operators are also available as unary operators:

In terms of unary arithmetics operators, the ++ (increment) and -- (decrement) operators are available, both in prefix and postfix notation:

From the binary arithmetic operators we have seen above, certain of them are also available in an assignment form:

Let’s see them in action:

The logical "not" has a higher priority than the logical "and".

The logical "and" has a higher priority than the logical "or".

The logical || operator supports short-circuiting: if the left operand is true, it knows that the result will be true in any case, so it won’t evaluate the right operand. The right operand will be evaluated only if the left operand is false.

Likewise for the logical && operator: if the left operand is false, it knows that the result will be false in any case, so it won’t evaluate the right operand. The right operand will be evaluated only if the left operand is true.

The "not" operator is represented with an exclamation mark (!) and inverts the result of the underlying boolean expression. In particular, it is possible to combine the not operator with the Groovy truth:

The ternary operator is a shortcut expression that is equivalent to an if/else branch assigning some value to a variable.

Instead of:

You can write:

The ternary operator is also compatible with the Groovy truth, so you can make it even simpler:

The "Elvis operator" is a shortening of the ternary operator. One instance of where this is handy is for returning a sensible default value if an expression resolves to false or null. A simple example might look like this:

Usage of the Elvis operator reduces the verbosity of your code and reduces the risks of errors in case of refactorings, by removing the need to duplicate the expression which is tested in both the condition and the positive return value.

The Safe Navigation operator is used to avoid a NullPointerException. Typically when you have a reference to an object you might need to verify that it is not null before accessing methods or properties of the object. To avoid this, the safe navigation operator will simply return null instead of throwing an exception, like so:

Normally in Groovy, when you write code like this:

The user.name call triggers a call to the property of the same name, that is to say, here, to the getter for name. If you want to retrieve the field instead of calling the getter, you can use the direct field access operator:

The method pointer operator (.&) call be used to store a reference to a method in a variable, in order to call it later:

There are multiple advantages in using method pointers. First of all, the type of such a method pointer is a groovy.lang.Closure, so it can be used in any place a closure would be used. In particular, it is suitable to convert an existing method for the needs of the strategy pattern:

Method pointers are bound by the receiver and a method name. Arguments are resolved at runtime, meaning that if you have multiple methods with the same name, the syntax is not different, only resolution of the appropriate method to be called will be done at runtime:

The pattern operator (~) provides a simple way to create a java.util.regex.Pattern instance:

while in general, you find the pattern operator with an expression in a slashy-string, it can be used with any kind of String in Groovy:

Alternatively to building a pattern, you can directly use the find operator =~ to build a java.util.regex.Matcher instance:

Since a Matcher coerces to a boolean by calling its find method, the =~ operator is consistent with the simple use of Perl’s =~ operator, when it appears as a predicate (in if, while, etc.).

The match operator (==~) is a slight variation of the find operator, that does not return a Matcher but a boolean and requires a strict match of the input string:

The Spread Operator (*.) is used to invoke an action on all items of an aggregate object. It is equivalent to calling the action on each item and collecting the result into a list:

The spread operator is null-safe, meaning that if an element of the collection is null, it will return null instead of throwing a NullPointerException:

The spread operator can be used on any class which implements the Iterable interface:

Groovy supports the concept of ranges and provides a notation (..) to create ranges of objects:

Ranges implementation is lightweight, meaning that only the lower and upper bounds are stored. You can create a range from any Comparable object. For example, you can create a range of characters this way:

The spaceship operator (<=>) delegates to the compareTo method:

The subscript operator is a short hand notation for getAt or putAt, depending on whether you find it on the left hand side or the right hand side of an assignment:

The subscript operator, in combination with a custom implementation of getAt/putAt is a convenient way for destructuring objects:

The membership operator (in) is equivalent to calling the isCase method. In the context of a List, it is equivalent to calling contains, like in the following example:

In Groovy, using == to test equality is different from using the same operator in Java. In Groovy, it is calling equals. If you want to compare reference equality, you should use is like in the following example:

The coercion operator (as) is a variant of casting. Coercion converts object from one type to another without them being compatible for assignement. Let’s take an example:

This can be fixed by using coercion instead:

When an object is coerced into another, unless the target type is the same as the source type, coercion will return a new object. The rules of coercion differ depending on the source and target types, and coercion may fail if no conversion rules are found. Custom conversion rules may be implemented thanks to the asType method:

The diamond operator (<>) is a syntactic sugar only operator added to support compatibility with the operator of the same name in Java 7. It is used to indicate that generic types should be inferred from the declaration:

In dynamic Groovy, this is totally unused. In statically type checked Groovy, it is also optional since the Groovy type checker performs type inference whether this operator is present or not.

The call operator () is used to call a method named call implicitly. For any object which defines a call method, you can omit the .call part and use the call operator instead:

Default imports are the imports that Groovy language provides by default. For example look at the following code:

The same code in Java needs an import statement to Date class like this: import java.util.Date. Groovy by default imports these classes for you. There are six packages that groovy imports for you, they are:

A simple import is an import statement where you fully define the class name along with the package. For example the import statement import groovy.xml.MarkupBuilder in the code below is a simple import which directly refers to the a class inside a package.

Groovy, like Java, provides a special way to import all classes from a package using *, a so called Star import. MarkupBuilder is a class which is in package groovy.xml, alongside another class called StreamingMarkupBuilder. In case you need to use both classes, you can do:

That’s perfectly valid code. But with a * import, we can achieve the same effect with just one line, where * imports all the classes under package groovy.xml:

One problem with * imports is that they can clutter your local namespace. But with the kinds of aliasing provided by Groovy, this can be solved easily.

Groovy’s static import capability allows you to reference imported classes as if they were static methods in your own class. This is similar to Java’s static import capability but works with Java 1.4 and above and is a little more dynamic than Java in that it allows you to define methods with the same name as an imported method as long as you have different types. If you have the same types, the imported class takes precedence. Here is a sample of its usage:

As you can see, now we can able to refer to the static variable FALSE in our code base cleanly.

Static imports with the as keyword provide an elegant solution to namespace problems. Suppose you want to get a Calendar instance, using its getInstance() method. It’s a static method, so we can use a static import. But instead of calling getInstance() every time, which can be misleading when separated from its class name, we can import it with an alias, to increase code readability:

Now, that’s clean!

A static star import is very similar to the regular star import. It will import all the static methods from the given class.

For example, lets say we need to calculate sines and cosines for our application. The class java.lang.Math has static methods named sin and cos which fit our need. With the help of a static star import, we can do:

As you can see, we were able to access the methods sin and cos directly, without the Math. prefix.

With type aliasing, we can refer to a fully qualified class name using a name of our choice. This can be done with the as keyword, as before.

Consider the following class, provided by some third-party library code:

Suppose we have some existing code using the library:

Now suppose that, after using this library throughout your codebase, we discover that it doesn’t give correct results. How can we fix it in one place, outside of the original class, without changing all the code that’s using it? Groovy has an elegant solution to this problem.

With a simple import aliasing, we can fix the bug like this:

Thats it! Notice how Groovy allowed us to use the as keyword to rename our imported class and solve this common problem.

Type aliasing is also useful to solve name collision problems which can occur with * imports.

this represents the implementing instance. Think of a trait as a superclass. This means that when you write:

then calling:

will return the same instance:

Traits may implement interfaces, in which case the interfaces are declared using the implements keyword:

A trait may define properties, like in the following example:

Traits can be used to implement multiple inheritance in a controlled way, avoiding the diamond issue. For example, we can have the following traits:

And a class implementing both traits:

Traits encourage the reuse of capabilities among objects, and the creation of new classes by the composition of existing behavior.

Traits provide default implementations for methods, but it is possible to override them in the implementing class. For example, we can slightly change the example above, by having a duck which quacks:

Groovy supports the concept of stackable traits. The idea is to delegate from one trait to the other if the current trait is not capable of handling a message. To illustrate this, let’s imagine a message handler interface like this:

Then you can compose a message handler by applying small behaviors. For example, let’s define a default handler in the form of a trait:

Then any class can inherit the behavior of the default handler by implementing the trait:

Now what if you want to log all messages, in addition to the default handler? One option is to write this:

This works but this approach has drawbacks:

As an alternative, we can write another trait which responsability is limited to logging:

Then our class can be rewritten as this:

which will print:

As the priority rules imply that LoggerHandler wins because it is declared last, then a call to on will use the implementation from LoggingHandler. But the latter has a call to super, which means the next trait in the chain. Here, the next trait is DefaultHandler so both will be called:

The interest of this approach becomes more evident if we add a third handler, which is responsible for handling messages that start with say:

Then our final handler looks like this:

Which means:

This approach is very powerful because it allows you to write handlers that do not know each other and yet let you combine them in the order you want. For example, if we execute the code, it will print:

but if we move the logging handler to be the second one in the chain, the output is different:

prints:

The reason is that now, since the SayHandler consumes the message without calling super, the logging handler is not called anymore.

There are several conceptual differences with mixins, as they are available in Groovy. Note that we are talking about runtime mixins, not the @Mixin annotation which is deprecated in favour of traits.

First of all, methods defined in a trait are visible in bytecode:

Methods added through a mixin are, on the contrary, only visible at runtime:

The last point is actually a very important and illustrates a place where mixins have an advantage over traits: the instances are not modified, so if you mixin some class into another, there isn’t a third class generated, and methods which respond to A will continue responding to A even if mixed in.

It is possible to define static methods in a trait, but it comes with numerous limitations:

Let’s start with a simple example:

As usual, it is not recommended to use public fields. Anyway, should you want this, you must understand that the following code would fail: