def (a, b, c) = [10, 20, 'foo']assert a == 10 && b == 20 && c == 'foo'

def (int i, String j) = [10, 'foo']assert i == 10 && j == 'foo'

def nums = [1, 3, 5]def a, b, c(a, b, c) = numsassert a == 1 && b == 3 && c == 5

def (_, month, year) = "18th June 2009".split()assert "In $month of $year" == 'In June of 2009'

def (a, b, c) = [1, 2]assert a == 1 && b == 2 && c == null

def (a, b) = [1, 2, 3]assert a == 1 && b == 2

@Immutableclass Coordinates {    double latitude    double longitude    double getAt(int idx) {        if (idx == 0) latitude        else if (idx == 1) longitude        else throw new Exception('Wrong coordinate index, use 0 or 1')    }}

def coordinates = new Coordinates(latitude: 43.23, longitude: 3.67)(1)def (la, lo) = coordinates(2)assert la == 43.23(3)assert lo == 3.67

Groovy supports the usual if - else syntax from Java

Groovy also supports the normal Java "nested" if then else if syntax:

The switch statement in Groovy is backwards compatible with Java code; so you can fall through cases sharing the same code for multiple matches.

One difference though is that the Groovy switch statement can handle any kind of switch value and different kinds of matching can be performed.

Switch supports the following kinds of comparisons:

• Class case values match if the switch value is an instance of the class

• Regular expression case values match if thetoString() representation of the switch value matches the regex

• Collection case values match if the switch value is contained in the collection. This also includes ranges (since they are Lists)

• Closure case values match if the calling the closure returns a result which is true according to theGroovy truth

• If none of the above are used then the case value matches if the case value equals the switch value

Groovy also supports switch expressions as shown in the following example:

Groovy supports the standard Java / C for loop:

The more elaborate form of Java’s classic for loop with comma-separate expressionsis now supported. Example:

Groovy has supported multi-assignment statements since Groovy 1.6:

These can now appear in for loops:

The for loop in Groovy is much simpler and works with any kind of array, collection, Map, etc.

Groovy supports the usual while {…​} loops like Java:

Java’s class do/while loop is now supported. Example:

try {    'moo'.toLong()   // this will generate an exception    assert false     // asserting that this point should never be reached} catch ( e ) {    assert e in NumberFormatException}

def ztry {    def i = 7, j = 0    try {        def k = i / j        assert false        //never reached due to Exception in previous line    } finally {        z = 'reached here'  //always executed even if Exception thrown    }} catch ( e ) {    assert e in ArithmeticException    assert z == 'reached here'}

try {    /* ... */} catch ( IOException | NullPointerException e ) {    /* one block to handle 2 exceptions */}

class FromResource extends ByteArrayInputStream {    @Override    void close() throws IOException {        super.close()        println "FromResource closing"    }    FromResource(String input) {        super(input.toLowerCase().bytes)    }}class ToResource extends ByteArrayOutputStream {    @Override    void close() throws IOException {        super.close()        println "ToResource closing"    }}def wrestle(s) {    try (            FromResource from = new FromResource(s)            ToResource to = new ToResource()    ) {        to << from        return to.toString()    }}def wrestle2(s) {    FromResource from = new FromResource(s)    try (from; ToResource to = new ToResource()) { // Enhanced try-with-resources in Java 9+        to << from        return to.toString()    }}assert wrestle("ARM was here!").contains('arm')assert wrestle2("ARM was here!").contains('arm')

ToResource closingFromResource closingToResource closingFromResource closing

void aMethodFoo() { println "This is aMethodFoo." }(0)

assert ['aMethodFoo'] == this.class.methods.name.grep(~/.*Foo/)

void aMethodBar() { println "This is aMethodBar." }(1)void anotherFooMethod() { println "This is anotherFooMethod." }(2)void aSecondMethodBar() { println "This is aSecondMethodBar." }(3)

assert ['aMethodBar', 'aSecondMethodBar'] as Set == this.class.methods.name.grep(~/.*Bar/) as Set

List<String> methodNames = new ArrayList<String>();for (Method method : this.getClass().getMethods()) {   methodNames.add(method.getName());}return methodNames;

assert 'aSecondMethodBar' == this.class.methods.name.grep(~/.*Bar/).sort()[1]

def xmlText = """              | <root>              |   <level>              |      <sublevel id='1'>              |        <keyVal>              |          <key>mykey</key>              |          <value>value 123</value>              |        </keyVal>              |      </sublevel>              |      <sublevel id='2'>              |        <keyVal>              |          <key>anotherKey</key>              |          <value>42</value>              |        </keyVal>              |        <keyVal>              |          <key>mykey</key>              |          <value>fizzbuzz</value>              |        </keyVal>              |      </sublevel>              |   </level>              | </root>              """def root = new XmlSlurper().parseText(xmlText.stripMargin())assert root.level.size() == 1(1)assert root.level.sublevel.size() == 2(2)assert root.level.sublevel.findAll { it.@id == 1 }.size() == 1(3)assert root.level.sublevel[1].keyVal[0].key.text() == 'anotherKey'(4)

interface Predicate<T> {    boolean accept(T obj)}

abstract class Greeter {    abstract String getName()    void greet() {        println "Hello, $name"    }}

Predicate filter = { it.contains 'G' } as Predicateassert filter.accept('Groovy') == trueGreeter greeter = { 'Groovy' } as Greetergreeter.greet()

Predicate filter = { it.contains 'G' }assert filter.accept('Groovy') == trueGreeter greeter = { 'Groovy' }greeter.greet()

boolean doFilter(String s) { s.contains('G') }Predicate filter = this.&doFilterassert filter.accept('Groovy') == trueGreeter greeter = GroovySystem.&getVersiongreeter.greet()

public <T> List<T> filter(List<T> source, Predicate<T> predicate) {    source.findAll { predicate.accept(it) }}

assert filter(['Java','Groovy'], { it.contains 'G'} as Predicate) == ['Groovy']

assert filter(['Java','Groovy']) { it.contains 'G'} == ['Groovy']

interface FooBar {    int foo()    void bar()}

def impl = { println 'ok'; 123 } as FooBar

assert impl.foo() == 123impl.bar()

class FooBar {    int foo() { 1 }    void bar() { println 'bar' }}def impl = { println 'ok'; 123 } as FooBarassert impl.foo() == 123impl.bar()

Thegroovy.transform.TypeChecked annotation enables type checking. It can be placed on a class:

Or on a method:

In the first case, all methods, properties, fields, inner classes, …​ of the annotated class will be type checked, whereasin the second case, only the method and potential closures or anonymous inner classes that it contains will be type checked.

The scope of type checking can be restricted. For example, if a class is type checked, you can instruct the type checkerto skip a method by annotating it with@TypeChecked(TypeCheckingMode.SKIP):

In the previous example,SentenceBuilder relies on dynamic code. There’s no realHello method or property, so thetype checker would normally complain and compilation would fail. Since the method that uses the builder is marked withTypeCheckingMode.SKIP, type checking isskipped for this method, so the code will compile, even if the rest of theclass is type checked.

The following sections describe the semantics of type checking in Groovy.

@groovy.transform.TupleConstructorclass Person {    String firstName    String lastName}Person classic = new Person('Ada','Lovelace')

Person list = ['Ada','Lovelace']

Person map = [firstName:'Ada', lastName:'Lovelace']

@groovy.transform.TupleConstructorclass Person {    String firstName    String lastName}Person map = [firstName:'Ada', lastName:'Lovelace', age: 24](1)

class MyService {    void doSomething() {        printLine 'Do something'(1)    }}

@groovy.transform.TypeCheckedclass MyService {    void doSomething() {        printLine 'Do something'(1)    }}

When code is annotated with@TypeChecked, the compiler performs type inference. It doesn’t simply rely on static types, but also uses varioustechniques to infer the types of variables, return types, literals, …​ so that the code remains as clean as possible even if you activate thetype checker.

The simplest example is inferring the type of a variable:

The reason the call totoUpperCase works is because the type ofmessage wasinferred as being aString.

It is worth noting that although the compiler performs type inference on local variables, it doesnot perform any kindof type inference on fields, always falling back to thedeclared type of a field. To illustrate this, let’s take alook at this example:

Why such a difference? The reason isthread safety. At compile time, we can’t makeany guarantee about the type ofa field. Any thread can access any field at any time and between the moment a field is assigned a variable of sometype in a method and the time is used the line after, another thread may have changed the contents of the field. Thisis not the case for local variables: we know if they "escape" or not, so we can make sure that the type of a variable isconstant (or not) over time. Note that even if a field is final, the JVM makes no guarantee about it, so the type checkerdoesn’t behave differently if a field is final or not.

Groovy provides a syntax for various type literals. There are three native collection literals in Groovy:

• lists, using the[] literal

• maps, using the[:] literal

• ranges, usingfrom..to (inclusive),from..<to (right exclusive),from<..to (left exclusive) andfrom<..<to (full exclusive)

The inferred type of a literal depends on the elements of the literal, as illustrated in the following table:

As you can see, with the noticeable exception of theIntRange, the inferred type makes use of generics types to describethe contents of a collection. In case the collection contains elements of different types, the type checker still performstype inference of the components, but uses the notion ofleast upper bound.

In Groovy, theleast upper bound of two typesA andB is defined as a type which:

• superclass corresponds to the common super class ofA andB

• interfaces correspond to the interfaces implemented by bothA andB

• ifA orB is a primitive type and thatA isn’t equal toB, the least upper bound ofA andB is the leastupper bound of their wrapper types

IfA andB only have one (1) interface in common and that their common superclass isObject, then the LUB of bothis the common interface.

The least upper bound represents the minimal type to which bothA andB can be assigned. So for example, ifA andBare bothString, then the LUB (least upper bound) of both is alsoString.

In those examples, the LUB is always representable as a normal, JVM supported, type. But Groovy internally represents the LUBas a type which can be more complex, and that you wouldn’t be able to use to define a variable for example. To illustrate this,let’s continue with this example:

What is the least upper bound ofBottom andSerializableFooImpl? They don’t have a common super class (apart fromObject),but they do share 2 interfaces (Serializable andFoo), so their least upper bound is a type which represents the union oftwo interfaces (Serializable andFoo). This type cannot be defined in the source code, yet Groovy knows about it.

In the context of collection type inference (and generic type inference in general), this becomes handy, because the type of thecomponents is inferred as the least upper bound. We can illustrate why this is important in the following example:

The error message will look like:

which indicates that theexit method is neither defines onGreeter norSalute, which are the two interfaces definedin the least upper bound ofA andB.

In normal, non type checked, Groovy, you can write things like:

The method call works because of dynamic dispatch (the method is selected at runtime). The equivalent code in Java wouldrequire to casto to aGreeter before calling thegreeting method, because methods are selected at compile time:

However, in Groovy, even if you add@TypeChecked (and thus activate type checking) on thedoSomething method, thecast isnot necessary. The compiler embedsinstanceof inference that makes the cast optional.

Flow typing is an important concept of Groovy in type checked mode and an extension of type inference. The idea is thatthe compiler is capable of inferring the type of variables in the flow of the code, not just at initialization:

So the type checker isaware of the fact that the concrete type of a variable is different over time. In particular,if you replace the last assignment with:

The type checker will now fail at compile time, because it knows thato is adouble whentoUpperCase is called,so it’s a type error.

It is important to understand that it is not the fact of declaring a variable withdef that triggers type inference.Flow typing works forany variable of any type. Declaring a variable with an explicit type only constrains what youcan assign to the variable:

You can also note that even if the variable is declaredwithout generics information, the type checker knows what isthe component type. Therefore, such code would fail compilation:

Fixing this requires adding an explicit, non-wildcard type argument:

Flow typing has been introduced to reduce the difference in semantics between classic and static Groovy. In particular,consider the behavior of this code in Java:

In Java, this code will outputNope, because method selection is done at compile time and based on thedeclared types.So even ifo is aString at runtime, it is still theObject version which is called, becauseo has been declaredas anObject. To be short, in Java, declared types are most important, be it variable types, parameter types or returntypes.

In Groovy, we could write:

But this time, it will return6, because the method which is chosenat runtime, based on theactualargument types. So at runtime,o is aString so theString variant is used. Note that this behavior has nothingto do with type checking, it’s the way Groovy works in general: dynamic dispatch.

In type checked Groovy, we want to make sure the type checker selects the same methodat compile time, that the runtimewould choose. It is not possible in general, due to the semantics of the language, but we can make things better with flowtyping. With flow typing,o isinferred as aString when thecompute method is called, so the version which takesaString and returns anint is chosen. This means that we can infer the return type of the method to be anint, andnot aString. This is important for subsequent calls and type safety.

So in type checked Groovy, flow typing is a very important concept, which also implies that if@TypeChecked is applied,methods are selected based on theinferred types of the arguments, not on the declared types. This doesn’t ensure 100%type safety, because the type checkermay select a wrong method, but it ensures the closest semantics to dynamic Groovy.

A combination offlow typing andleast upper bound inference is used to performadvanced type inference and ensure type safety in multiple situations. In particular, program control structures arelikely to alter the inferred type of a variable:

When the type checker visits anif/else control structure, it checks all variables which are assigned inif/else branchesand computes theleast upper bound of all assignments. This type is the type of the inferred variableafter theif/else block, so in this example,o is assigned aTop in theif branch and aBottom in theelsebranch. TheLUB of those is aTop, so after the conditional branches, the compiler inferso as beingaTop. CallingmethodFromTop will therefore be allowed, but notmethodFromBottom.

The same reasoning exists with closures and in particular closure shared variables. A closure shared variable is a variablewhich is defined outside of a closure, but used inside a closure, as in this example:

Groovy allows developers to use those variables without requiring them to be final. This means that a closure sharedvariable can be reassigned inside a closure:

The problem is that a closure is an independent block of code that can be executed (or not) atany time. In particular,doSomething may be asynchronous, for example. This means that the body of a closure doesn’t belong to the main controlflow. For that reason, the type checker also computes, for each closure shared variable, theLUB of allassignments of the variable, and will use thatLUB as the inferred type outside of the scope of the closure, like inthis example:

Here, it is clear that whenmethodFromBottom is called, there’s no guarantee, at compile-time or runtime that thetype ofo willeffectively be aBottom. There are chances that it will be, but we can’t make sure, because it’sasynchronous. So the type checker will only allow calls on theleast upper bound, which is here aTop.

The first thing that the type checker is capable of doing is inferring thereturn type of a closure. This is simply illustrated in the following example:

As you can see, unlike a method which declares its return type explicitly, there’s no need to declare the return typeof a closure: its type is inferred from the body of the closure.

In addition to the return type, it is possible for a closure to infer its parameter types from the context. There aretwo ways for the compiler to infer the parameter types:

• throughimplicit SAM type coercion

• through API metadata

To illustrate this, lets start with an example that will fail compilation due to the inability for the type checkerto infer the parameter types:

In this example, the closure body containsit.age. With dynamic, not type checked code, this would work, because thetype ofit would be aPerson at runtime. Unfortunately, at compile-time, there’s no way to know what is the typeofit, just by reading the signature ofinviteIf.

Explicit closure parameters

inviteIf(p) { Person it ->(1)    it.age >= 18}

Parameters inferred from single-abstract method types

interface Predicate<On> { boolean apply(On e) }(1)void inviteIf(Person p, Predicate<Person> predicate) {(2)    if (predicate.apply(p)) {        // send invite        // ...    }}@groovy.transform.TypeCheckedvoid passesCompilation() {    Person p = new Person(name: 'Gerard', age: 55)    inviteIf(p) {(3)        it.age >= 18(4)    }}

The@ClosureParams annotation

import groovy.transform.stc.ClosureParamsimport groovy.transform.stc.FirstParamvoid inviteIf(Person p, @ClosureParams(FirstParam) Closure<Boolean> predicate) {(1)    if (predicate.call(p)) {        // send invite        // ...    }}inviteIf(p) {(2)    it.age >= 18}

import groovy.transform.stc.FirstParamvoid doSomething(String str, @ClosureParams(FirstParam) Closure c) {    c(str)}doSomething('foo') { println it.toUpperCase() }

import groovy.transform.stc.SecondParamvoid withHash(String str, int seed, @ClosureParams(SecondParam) Closure c) {    c(31*str.hashCode()+seed)}withHash('foo', (int)System.currentTimeMillis()) {    int mod = it%2}

import groovy.transform.stc.ThirdParamString format(String prefix, String postfix, String o, @ClosureParams(ThirdParam) Closure c) {    "$prefix${c(o)}$postfix"}assert format('foo', 'bar', 'baz') {    it.toUpperCase()} == 'fooBAZbar'

import groovy.transform.stc.FirstParampublic <T> void doSomething(List<T> strings, @ClosureParams(FirstParam.FirstGenericType) Closure c) {    strings.each {        c(it)    }}doSomething(['foo','bar']) { println it.toUpperCase() }doSomething([1,2,3]) { println(2*it) }

import groovy.transform.stc.SimpleTypepublic void doSomething(@ClosureParams(value=SimpleType,options=['java.lang.String','int']) Closure c) {    c('foo',3)}doSomething { str, len ->    assert str.length() == len}

import groovy.transform.stc.MapEntryOrKeyValuepublic <K,V> void doSomething(Map<K,V> map, @ClosureParams(MapEntryOrKeyValue) Closure c) {    // ...}doSomething([a: 'A']) { k,v ->    assert k.toUpperCase() == v.toUpperCase()}doSomething([abc: 3]) { e ->    assert e.key.length() == e.value}

import groovy.transform.stc.FromAbstractTypeMethodsabstract class Foo {    abstract void firstSignature(int x, int y)    abstract void secondSignature(String str)}void doSomething(@ClosureParams(value=FromAbstractTypeMethods, options=["Foo"]) Closure cl) {    // ...}doSomething { a, b -> a+b }doSomething { s -> s.toUpperCase() }

import groovy.transform.stc.FromStringvoid doSomething(@ClosureParams(value=FromString, options=["String","String,Integer"]) Closure cl) {    // ...}doSomething { s -> s.toUpperCase() }doSomething { s,i -> s.toUpperCase()*i }

import groovy.transform.stc.FromStringvoid doSomething(@ClosureParams(value=FromString, options=["String","String,Integer"]) Closure cl) {    // ...}doSomething { s -> s.toUpperCase() }doSomething { s,i -> s.toUpperCase()*i }

import groovy.transform.stc.FromStringpublic <T> void doSomething(T e, @ClosureParams(value=FromString, options=["T","T,T"]) Closure cl) {    // ...}doSomething('foo') { s -> s.toUpperCase() }doSomething('foo') { s1,s2 -> assert s1.toUpperCase() == s2.toUpperCase() }

The@DelegatesTo annotation is used by the type checker to infer the type of the delegate. It allows the API designerto instruct the compiler what is the type of the delegate and the delegation strategy. The@DelegatesTo annotation isdiscussed in aspecific section.

class Computer {    int compute(String str) {        str.length()    }    String compute(int x) {        String.valueOf(x)    }}@groovy.transform.TypeCheckedvoid test() {    def computer = new Computer()    computer.with {        assert compute(compute('foobar')) =='6'    }}

Computer.metaClass.compute = { String str -> new Date() }

class Computer {    int compute(String str) {        str.length()    }    String compute(int x) {        String.valueOf(x)    }}@groovy.transform.CompileStaticvoid test() {    def computer = new Computer()    computer.with {        assert compute(compute('foobar')) =='6'    }}Computer.metaClass.compute = { String str -> new Date() }test()

def builder = new MarkupBuilder(out)builder.html {    head {        // ...    }    body {        p 'Hello, world!'    }}

@TypeChecked(extensions='/path/to/myextension.groovy')void foo() { ...}

beforeVisitMethod { methodNode -> println "Entering ${methodNode.name}"}

robot.move 100

class Robot {    Robot move(int qt) { this }}

def config = new CompilerConfiguration()config.addCompilationCustomizers(    new ASTTransformationCustomizer(TypeChecked)(1))def shell = new GroovyShell(config)(2)def robot = new Robot()shell.setVariable('robot', robot)shell.evaluate(script)(3)

[Static type checking] - The variable [robot] is undeclared.

config.addCompilationCustomizers(    new ASTTransformationCustomizer(        TypeChecked,        extensions:['robotextension.groovy']))

unresolvedVariable { var ->    if ('robot'==var.name) {        storeType(var, classNodeFor(Robot))        handled = true    }}

The type checking API is a low level API, dealing with the AbstractSyntax Tree. You will have to know your AST well to develop extensions,even if the DSL makes it much easier than just dealing with AST codefrom plain Java or Groovy.

The type checker sends the following events, to which an extensionscript can react:

Of course, an extension script may consist of several blocks, and youcan have multiple blocks responding to the same event. This makes theDSL look nicer and easier to write. However, reacting to events is farfrom sufficient. If you know you can react to events, you also need todeal with the errors, which implies severalhelper methods that willmake things easier.

The DSL relies on a support class called org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport .This class itself extends org.codehaus.groovy.transform.stc.TypeCheckingExtension .Those two classes define a number ofhelper methods that will make workingwith the AST easier, especially regarding type checking. One interestingthing to know is that you have access to the type checker. This meansthat you can programmatically call methods of the type checker,including those that allow you tothrow compilation errors.

The extension script delegates to the org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport class,meaning that you have direct access to the following variables:

• context: the type checker context, of type org.codehaus.groovy.transform.stc.TypeCheckingContext

• typeCheckingVisitor: the type checker itself, a org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor instance

• generatedMethods: a list of "generated methods", which is in fact the list of "dummy" methods that you can createinside a type checking extension using the newMethod calls

The type checking context contains a lot of information that is usefulin context for the type checker. For example, the current stack ofenclosing method calls, binary expressions, closures, … This informationis in particular important if you have to knowwhere you are when anerror occurs and that you want to handle it.

In addition to facilities provided byGroovyTypeCheckingExtensionSupport andStaticTypeCheckingVisitor,a type-checking DSL script imports static members fromorg.codehaus.groovy.ast.ClassHelper andorg.codehaus.groovy.transform.stc.StaticTypeCheckingSupport granting access to common types viaOBJECT_TYPE,STRING_TYPE,THROWABLE_TYPE, etc. and checks likemissesGenericsTypes(ClassNode),isClassClassNodeWrappingConcreteType(ClassNode) and so on.

Handling class nodes is something that needs particular attention whenyou work with a type checking extension. Compilation works with anabstract syntax tree (AST) and the tree may not be complete when you aretype checking a class. This also means that when you refer to types, youmust not use class literals such as String or HashSet, but to classnodes representing those types. This requires a certain level ofabstraction and understanding how Groovy deals with class nodes. To makethings easier, Groovy supplies several helper methods to deal with classnodes. For example, if you want to say "the type for String", you canwrite:

You would also note that there is a variant of classNodeFor that takesa String as an argument, instead of a Class. In general, youshould not use that one, because it would create a class node forwhich the name isString, but without any method, any property, …defined on it. The first version returns a class node that is resolvedbut the second one returns one that is not. So the latter should bereserved for very special cases.

The second problem that you might encounter is referencing a type whichis not yet compiled. This may happen more often than you think. Forexample, when you compile a set of files together. In that case, if youwant to say "that variable is of type Foo" butFoo is not yetcompiled, you can still refer to theFoo class nodeusing lookupClassNodeFor:

Say that you know that variable foo is of type Foo and you want totell the type checker about it. Then you can use the storeType method,which takes two arguments: the first one is the node for which you wantto store the type and the second one is the type of the node. If youlook at the implementation of storeType, you would see that itdelegates to the type checker equivalent method, which itself does a lotof work to store node metadata. You would also see that storing the typeis not limited to variables: you can set the type of any expression.

Likewise, getting the type of an AST node is just a matter ofcalling getType on that node. This would in general be what you want,but there’s something that you must understand:

• getType returns the inferred type of an expression. This meansthat it will not return, for a variable declared of type Object theclass node for Object, but the inferred type of this variable at thispoint of the code (flow typing)

• if you want to access the origin type of a variable (orfield/parameter), then you must call the appropriate method on the ASTnode

To throw a type checking error, you only have to call theaddStaticTypeError method which takes two arguments:

• a message which is a string that will be displayed to the end user

• anAST node responsible for the error. It’s better to provide the bestsuiting AST node because it will be used to retrieve the line and columnnumbers

It is often required to know the type of an AST node. For readability,the DSL provides a special isXXXExpression method that will delegate tox instance of XXXExpression. For example, instead of writing:

you can just write:

When you perform type checking of dynamic code, you may often face thecase when you know that a method call is valid but there is no "real"method behind it. As an example, take the Grails dynamic finders. Youcan have a method call consisting of a method named findByName(…). Asthere’s no findByName method defined in the bean, the type checkerwould complain. Yet, you would know that this method wouldn’t fail atruntime, and you can even tell what is the return type of this method.For this case, the DSL supports two special constructs that consist ofphantom methods. This means that you will return a method node thatdoesn’t really exist but is defined in the context of type checking.Three methods exist:

• newMethod(String name, Class returnType)

• newMethod(String name, ClassNode returnType)

• newMethod(String name, Callable<ClassNode> return Type)

All three variants do the same: they create a new method node which nameis the supplied name and define the return type of this method.Moreover, the type checker would add those methods inthe generatedMethods list (see isGenerated below). The reason why weonly set a name and a return type is that it is only what you need in90% of the cases. For example, in the findByName example upper, theonly thing you need to know is that findByName wouldn’t fail atruntime, and that it returns a domain class. The Callable version ofreturn type is interesting because it defers the computation of thereturn type when the type checker actually needs it. This is interestingbecause in some circumstances, you may not know the actual return typewhen the type checker demands it, so you can use a closure that will becalled each time getReturnType is called by the type checker on thismethod node. If you combine this with deferred checks, you can achievepretty complex type checking including handling of forward references.

Should you need more than the name and return type, you can alwayscreate a new MethodNode by yourself.

Scoping is very important in DSL type checking and is one of the reasonswhy we couldn’t use a pointcut based approach to DSL type checking.Basically, you must be able to define very precisely when your extensionapplies and when it does not. Moreover, you must be able to handlesituations that a regular type checker would not be able to handle, suchas forward references:

Say for example that you want to handle a builder:

Your extension, then, should only be active once you’ve enteredthe foo method, and inactive outside this scope. But you could havecomplex situations like multiple builders in the same file or embeddedbuilders (builders in builders). While you should not try to fix allthis from start (you must accept limitations to type checking), the typechecker does offer a nice mechanism to handle this: a scoping stack,using the newScope and scopeExit methods.

• newScope creates a new scope and puts it on top of the stack

• scopeExits pops a scope from the stack

A scope consists of:

• a parent scope

• a map of custom data

If you want to look at the implementation, it’s simply aLinkedHashMap(org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport.TypeCheckingScope),but it’s quite powerful. For example, you can use such a scope to storea list of closures to be executed when you exit the scope. This is howyou would handle forward references: 

That is to say, that if at some point you are not able to determine thetype of an expression, or that you are not able to check at this pointthat an assignment is valid or not, you can still make the check later…This is a very powerful feature. Now, newScope and scopeExitprovide some interesting syntactic sugar:

At anytime in the DSL, you can access the current scopeusing getCurrentScope() or more simply currentScope:

The general schema would then be:

• determine apointcut where you push a new scope on stack andinitialize custom variables within this scope

• using the various events, you can use the information stored in yourcustom scope to perform checks, defer checks,…

• determine apointcut where you exit the scope, call scopeExitand eventually perform additional checks

For the complete list of helper methods, please refer tothe org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport and org.codehaus.groovy.transform.stc.TypeCheckingExtension classes. However,take special attention to those methods:

• isDynamic: takes a VariableExpression as argument and returns trueif the variable is a DynamicExpression, which means, in a script, thatit wasn’t defined using a type ordef.

• isGenerated: takes a MethodNode as an argument and tells if themethod is one that was generated by the type checker extension usingthe newMethod method

• isAnnotatedBy: takes an AST node and a Class (or ClassNode), andtells if the node is annotated with this class. For example:isAnnotatedBy(node, NotNull)

• getTargetMethod: takes a method call as argument and returnsthe MethodNode that the type checker has determined for it

• delegatesTo: emulates the behaviour of the @DelegatesToannotation. It allows you to tell that the argument will delegate to aspecific type (you can also specify the delegation strategy)

import org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupportclass PrecompiledExtension extends GroovyTypeCheckingExtensionSupport.TypeCheckingDSL {(1)    @Override    Object run() {(2)        unresolvedVariable { var ->            if ('robot'==var.name) {                storeType(var, classNodeFor(Robot))(3)                handled = true            }        }    }}

config.addCompilationCustomizers(    new ASTTransformationCustomizer(        TypeChecked,        extensions:['typing.PrecompiledExtension']))

import org.codehaus.groovy.ast.ClassHelper;import org.codehaus.groovy.ast.expr.VariableExpression;import org.codehaus.groovy.transform.stc.AbstractTypeCheckingExtension;import org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor;public class PrecompiledJavaExtension extends AbstractTypeCheckingExtension {(1)    public PrecompiledJavaExtension(final StaticTypeCheckingVisitor typeCheckingVisitor) {        super(typeCheckingVisitor);    }    @Override    public boolean handleUnresolvedVariableExpression(final VariableExpression vexp) {(2)        if ("robot".equals(vexp.getName())) {            storeType(vexp, ClassHelper.make(Robot.class));            setHandled(true);            return true;        }        return false;    }}

robot.move 100

def config = new CompilerConfiguration()config.addCompilationCustomizers(    new ASTTransformationCustomizer(        CompileStatic,(1)        extensions:['robotextension.groovy'])(2))def shell = new GroovyShell(config)def robot = new Robot()shell.setVariable('robot', robot)shell.evaluate(script)

move 100

def config = new CompilerConfiguration()config.scriptBaseClass = 'groovy.util.DelegatingScript'(1)def shell = new GroovyShell(config)def runner = shell.parse(script)(2)runner.setDelegate(new Robot())(3)runner.run()(4)

config.addCompilationCustomizers(    new ASTTransformationCustomizer(        CompileStatic,(1)        extensions:['robotextension2.groovy'])(2))

methodNotFound { receiver, name, argList, argTypes, call ->    if (isMethodCallExpression(call)(1)        && call.implicitThis(2)        && 'move'==name(3)        && argTypes.length==1(4)        && argTypes[0] == classNodeFor(int)(5)    ) {        handled = true(6)        newMethod('move', classNodeFor(Robot))(7)    }}

java.lang.NoSuchMethodError: java.lang.Object.move()Ltyping/Robot;

methodNotFound { receiver, name, argList, argTypes, call ->    if (isMethodCallExpression(call)        && call.implicitThis        && 'move'==name        && argTypes.length==1        && argTypes[0] == classNodeFor(int)    ) {        makeDynamic(call, classNodeFor(Robot))(1)    }}