In Java, as in other statically-typed languages, variables must first be declared with a type before they can have a value assigned to them. In Groovy, type can be left to be determined at the time of assignment. Groovy supports both static and optional typing as follows:

String str1 = "I'm a String"
def str2 = "I'm also a String"

Both variables str1 and str2 are of the type String. The late binding of the type in the Groovy-style assignment allows for a much less verbose code.

One of the great bugbears of the Java language is the cumbersome interfaces required for list and map manipulation. Groovy adds native support for all of the Java collection types through a very intuitive and readable syntax. The following code:

def authors =  [ 'Shakespeare', 'Beckett', 'Joyce', 'Poe' ]
println authors
println authors[2]

Produces this output:

[Shakespeare, Beckett, Joyce, Poe]
Joyce

Maps are also declared with ease:

def book = [ fileUnder: "Software Development",
         title: "Groovy for DSL" , author: "Fergal Dearle"]
println book
println book['title']
println book.title

This produces the following output:

[fileUnder: Software Development, title: Groovy for DSL, author: Fergal Dearle]
Groovy for DSL
Groovy for DSL

Operator overloading is a powerful feature of the C++ language. Java inherited many of the features of the C++ language, but operator overloading was significantly left out. Groovy introduces operator overloading as a base language feature.

Any Groovy class can implement a full set of operators by implementing the appropriate corresponding method in the class. For example, the plus operator is implemented via the plus() method.

Groovy builds regular expression handling right into the language via the =~ operator and matcher objects. The following example creates a regular expression to match all multiple occurrences of the space character. This creates a matcher object from this expression and applies it to a string by using the replaceAll method:

def lorem = 
"Lorem ipsum dolor sit amet, consectetur adipisicing elit"
println lorem
def matcher = lorem =~ " +"
def removed = matcher.replaceAll(" ")
println removed

Optional typing means that variable type annotations are optional. This does not mean that variables have an unknown variable type. It means that the type will be determined at run time based on the value that gets assigned to the variable. All of the following are legal syntax in Groovy:

int a = 3 
def b = 2
String t = "hello" 
def s = 'there'

Trailing semicolons at the end of statements are optional. The only time that you explicitly need to use a semicolon in Groovy is to separate statements that occur on the same line of code, as shown in the first and third lines in the following code:

int a = 3; int b = 4;
def c = 2 
def d = 5; def e = 6

Method call parentheses are also optional when the method being invoked has passed some parameters. We saw earlier, with closures, that we can invoke a closure through its reference as if it were a method call. When invoking a closure in this way, we can also drop the parentheses when passing parameters, as shown in the following code:

println( a );
c = 2
print c
printit = { println it }
printit c

These make for a much looser programming style, which is closer to the scripting syntax of Ruby or Python. This is a big benefit when we are using Groovy to build DSLs. When our target audience is nontechnical, being able to drop parentheses and semicolons will make our code much more legible. Consider the following example, where we have two methods, or closures, to get an account by ID and then credit the account with some funds:

Account account = getAccountById( 234 );
creditAccount( account, 100.00 );

With optional types, such as parentheses and semicolons, this can be used to write code that is far more legible to our target audience:

account = getAccountById 234
creditAccount account, 100.00

There are a number of builder classes built in Groovy. There are markup builders for HTML, XML, Ant build scripts, and for Swing GUI building. Markup builders allow us to write code to build a tree-based structure directly within our Groovy code. Unlike API-based approaches for building structures, the tree-like structure of the resulting output is immediately obvious from the structure of our Groovy markup code. Consider the following XML structure:

<?xml version="1.0"?>
<book>
   <author>Fergal Dearle</author>
   <title>Groovy for DSL</title>
</book>

In Groovy markup, this XML can be generated simply with the following code fragment:

def builder = new groovy.xml.MarkupBuilder()
builder.book {
   author 'Fergal Dearle'
   title 'Groovy for DSL'
}

At first glance, this looks like strange special case syntax for markup. It's not! The structure of this code can be explained through the use of closures and the optional syntax that we've discussed in this chapter. We will go into this in great detail in Chapter 5, Groovy Closures, but it is interesting at this point to see how the clever use of some language features can yield a powerful DSL-like markup syntax.

Breaking down the preceding code a little, we can rewrite it as:

def builder = new groovy.xml.MarkupBuilder()
def closure = {
   author 'Fergal Dearle'
   title 'Groovy for DSL'
}
// pass a closure to book method
builder.book( closure)
// which can be written without parentheses
builder.book closure
// or just inline the closure as a parameter
builder.book {
…
}

In other words, the code between the curly braces is in fact a closure, which is passed to the book method of MarkupBuilder. Parentheses being optional, we can simply declare the closure inline after the method name, which gives the neat effect of seeming to mirror the markup structure that we expect in the output.

Similarly, author and title are just method invocations on MarkupBuilder with the optional parentheses missing. Extending this paradigm a little further, we can decide to have author take a closure parameter as well:

def builder = new groovy.xml.MarkupBuilder()
builder.book {
   author {
                first_name 'Fergal'
                surname 'Dearle'
         }
   title 'Groovy for DSL'
}

This will output the following nested XML structure:

<?xml version="1.0"?>
<book>
   <author>
              <first_name>Fergal</first_name>
              <surname> Dearle</surname>
   </author>
   <title>Groovy for DSL</title>
</book>

The method calls on MarkupBuilder start off by outputting an opening XML tag, after which they invoke the closure if one has been passed. Finally, the XML tag is properly terminated before the method exits. If we analyze what happens in sequence, we can see that book invokes a closure that contains a call to author. Additionally, the author tag contains a closure with calls to first_name, surname, and so on.

Before you go to the Groovy documentation for MarkupBuilder to look for the book, author, and surname methods in MarkupBuilder, let me save you the effort. They don't exist. These are what we call pretend methods. We will see later in the book how Groovy's metaprogramming features allow us to invoke methods on closure that don't really exist, but have them do something useful anyway.

Already, we are seeing how some of the features of the Groovy language can coalesce to allow the structuring of a very useful DSL. I use the term DSL here for Groovy builders because that is essentially what they are. What initially looks like special language syntax for markup is revealed as being regular closures with a little bit of clever metaprogramming. The result is an embedded or internal DSL for generating markup.