Let's look at some script as follows:

def name = 'john'
printn naame

The Groovy compiler groovyc is perfectly happy to compile the previous code. Can you spot the error?

But, if we try to execute the code we get, not surprisingly, the following exception:

Caught: groovy.lang.MissingPropertyException:
  No such property: naame
  for class: DynamicTypingExample

Dynamic typing is a very controversial topic. Proponents of static typing argue that the benefits of static typing encompass:

Defenders of dynamic typing return fire by claiming that static typing is inflexible and has a negative impact on prototyping systems with volatile or unknown requirements. Furthermore, writing code in dynamic languages requires more discipline than writing in statically typed languages. This is often translated into a greater awareness for testing—and unit testing in particular—among developers who decide to produce code with dynamic languages.

It is worth noting that Groovy also supports optional static typing, even though the name is slightly misleading. In Groovy, we can declare a variable's type as follows:

int var = 10

or

String computeFrequency(List<String> listOfWords) {  }

Still, the compiler would not catch any compilation error if we assigned the wrong type to a typed variable:

int var = "Hello, I'm not a number!"

Groovy has optional typing mostly for Java compatibility and to support better code readability.

To mitigate some of the criticism inherent to dynamic typing, the Groovy team has introduced static type-checking since v2.0 of the language. Static type-checking enables the verification of the proper type and ensures that the methods we call and properties we access are valid for the type at compile time, hence decreasing the number of bugs pushed to the runtime.

Forcing the compiler to enable static type-checking it is simply a matter of annotating the code that we want to be checked with the @groovy.transform.TypeChecked annotation. The annotation can be placed on classes or individual methods:

If we place the annotation on a class, then type-checking is performed on all the methods, closures, and inner classes in the class. If we place it on a method, the type-checking is performed only on the members of the target method, including closures.

Static type-checking is implemented through an AST Transformation (see more on AST Transformations in Chapter 9, Metaprogramming and DSLs in Groovy) and can be used to enforce proper typing for a number of different cases. The following list shows a collection of bugs that would not be caught by the compiler but are caught by the TypeChecked annotation.

As you may have suspected, static type-checking doesn't play very nice with a dynamic language. Metaprogramming capabilities are effectively shut down when using the @TypeChecked annotation on a class or method.

Here is an example that uses metaprogramming to inject a new method into the class String (the Dynamically extending classes with new methods recipe in Chapter 9, Metaprogramming and DSLs in Groovy has more information about method injections):

class Sample {
  def test() {
    String.metaClass.hello = { "Hello, $delegate"  }
    println 'some String'.hello()
  }
}
new Sample().test()

When executed, this script yields the following output:

Hello, some String

If we add the @TypeChecked annotation to the class and try to run the script, we get the following error from the compiler:

[Static type checking] -
Cannot find matching method java.lang.String#hello().
Please check if the declared type is rightand if the method exists.

The reason for the error is that the compiler doesn't see the new dynamic method and therefore fails. Another case where static type-checking is too picky is when using implicit parameters in closures. Let's take an example:

class Sample {
  def test() {
    ['one','two','three'].collect { println it.toUpperCase() }
  }
}
new Sample().test()

This example, when executed, prints the following output:

ONE
TWO
THREE

If the Sample class is annotated with @TypeChecked, the compiler will return:

[Static type checking] -
Cannot find matching method java.lang.Object#toUpperCase().
Please check if the declared type is right
and if the method exists.
@ line 77, column 44.
wo','three'].collect { println it.toUpper
                              ^

What is happening here? Simply, the compiler has no idea of the type of the implicit variable it, which is often used inside closures to make the code even more terse. This compilation error can be solved by explicitly declaring the closure variable as follows:

['one','two','three'].collect {
  myString -> println myString.toUpperCase()
}