As of Groovy 2.0, the static type checking and compilation annotations @CompileStatic and @TypeChecked  can be applied on types and methods.
Type checking helps us identify typing errors, or references to undeclared methods as shown in the following code example:
With @TypeChecked we get the following errors during compile-time:
If you ever had the case where a typing error caused serious errors on your Grails production system, you will surely value the use of this annotation.
Custom Type Checking Extensions
Groovy 2.1 takes the conecpt of type checking even further and introduces a way to add custom type checking extensions. Custom type checking extensions are a great way to add compile-time checks that go beyond standard compile validations.
As an example, let's assume we have a type checked Sql utility class to access our relational database. The Sql class has a method named eachRow receiving a SQL query of type String as first argument:
As you can see in the code above, the SQL query is of type String. Syntactical errors we only occur at runtime.
With a custom type checking extension we can evaluate the specified SQL query at compile-time. The first step is to add a Groovy script to our class-path, let's call it SqlExtension.groovy. Groovy 2.1 comes with a custom type checking DSL that can be used within these scripts.
Let's see how a SQL parsing type checking extension could look like:
And that's it. It has to be noted that the @Grab annotation can be used inside type checking extension scripts.
The example above uses the JSQLParser  library but we could of course use any other third party library.
The afterMethodCall is one of the event hooks that can be used in a type checking extension. As can be seen, its only argument is an instance of MethodCall which we use to retrieve the target method's name and the methods receiver type. Once we're sure that it's a call to Sql#eachRow(...), we can check the first argument for being a constant expression (ie. a constant String). After we retrieved the constant, we can fire up our SQL parser and see if the statement is syntactically correct. Let's add the SqlExtension.groovy on a test class:
Obviously, the specified SQL argument string is syntactically not correct. Let's see if we get a compile error when compiling this class:
It worked! We have our first custom type checking extension that checks SQL statements for their syntactical correctness. Cool, isn't it?
GroovyTypeCheckingExtensionSupport  is the class that handles type extension script and therefore defines all available event hooks. During its initialization phase, GTCES adds a custom script base class to our extension script and adds some default imports:
The METHOD_ALIASES constant show all event hooks currently available:
If you seek to implement custom type checking extensions, you should have a closer look at GCTES as this is starting point for the extension DSL.
Groovy 2.1 adds custom type checking extensions to its @TypeChecked annotation. Type checking extensions can be used for additional type checks that go beyond standard compiler validations and offer a great way to perform domain-specific compile-time checks in DSLs or, more general, Groovy code!
Cédric Champeau released the type checking extensions documentation. If you want to implement a type checking extension, this is the place where to get a deeper insight into that topic.