class Foo {    static int i}assert Foo.class.getDeclaredField('i').type == int.class(1)assert Foo.i.class != int.class && Foo.i.class == Integer.class(2)

String movie = 'The Matrix'List actors = ['Keanu Reeves', 'Hugo Weaving']

List<String> roles = ['Trinity', 'Morpheus']

def p = new Person()

class Outer {    private String privateStr    def callInnerMethod() {        new Inner().methodA()(1)    }    class Inner {(2)        def methodA() {            println "${privateStr}."(3)        }    }}

class Outer2 {    private String privateStr = 'some string'    def startThread() {       new Thread(new Inner2()).start()    }    class Inner2 implements Runnable {        void run() {            println "${privateStr}."        }    }}

class Computer {    class Cpu {        int coreNumber        Cpu(int coreNumber) {            this.coreNumber = coreNumber        }    }}assert 4 == new Computer().new Cpu(4).coreNumber

The earlier example of an inner class (Inner2) can be simplified with an anonymous inner class.The same functionality can be achieved with the following code:

Thus, there was no need to define a new class to be used just once.

Abstract classes represent generic concepts, thus, they cannot be instantiated, being created to be subclassed.Their members include fields/properties and abstract or concrete methods.Abstract methods do not have implementation, and must be implemented by concrete subclasses.

Abstract classes are commonly compared to interfaces.There are at least two important differences of choosing one or another.First, while abstract classes may contain fields/properties and concrete methods, interfaces may contain only abstract methods (method signatures).Moreover, one class can implement several interfaces, whereas it can extend just one class, abstract or not.

interface Greeter {(1)    void greet(String name)(2)}

interface Greeter {    protected void greet(String name)(1)}

class SystemGreeter implements Greeter {(1)    void greet(String name) {(2)        println "Hello $name"    }}def greeter = new SystemGreeter()assert greeter instanceof Greeter(3)

interface ExtendedGreeter extends Greeter {(1)    void sayBye(String name)}

class DefaultGreeter {    void greet(String name) { println "Hello" }}greeter = new DefaultGreeter()assert !(greeter instanceof Greeter)

greeter = new DefaultGreeter()(1)coerced = greeter as Greeter(2)assert coerced instanceof Greeter(3)

To create an object by using positional parameters, the respective class needs to declare one or moreconstructors. In the case of multiple constructors, each must have a unique type signature. The constructors can alsobe added to the class using thegroovy.transform.TupleConstructor annotation.

Typically, once at least one constructor is declared, the class can only be instantiated by having one of itsconstructors called. It is worth noting that, in this case, you can’t normally create the class with named parameters.Groovy does support named parameters so long as the class contains a no-arg constructor or provides a constructor whichtakes aMap argument as the first (and potentially only) argument - see the next section for details.

There are three forms of using a declared constructor. The first one is the normal Java way, with thenew keyword.The others rely on coercion of lists into the desired types. In this case, it is possible to coerce with theaskeyword and by statically typing the variable.

If no (or a no-arg) constructor is declared, it is possible to create objects by passing parameters in the form of amap (property/value pairs). This can be in handy in cases where one wants to allow several combinations of parameters.Otherwise, by using traditional positional parameters it would be necessary to declare all possible constructors.Having a constructor where the first (and perhaps only) argument is aMap argument is also supported - such aconstructor may also be added using thegroovy.transform.MapConstructor annotation.

It is important to highlight, however, that this approach gives more power to the constructor caller,while imposing an increased responsibility on the caller to get the names and value types correct.Thus, if greater control is desired, declaring constructors using positional parameters might be preferred.

Notes:

• While the example above supplied no constructor, you can also supply a no-arg constructoror a constructor where the first argument is aMap, most typically it’s the only argument.

• When no (or a no-arg) constructor is declared, Groovy replaces the named constructor call by a callto the no-arg constructor followed by calls to the setter for each supplied named property.

• When the first argument is a Map, Groovy combines all named parameters into a Map (regardless of ordering)and supplies the map as the first parameter. This can be a good approach if your properties are declared asfinal (since they will be set in the constructor rather than after the fact with setters).

• You can support both named and positional constructionby supply both positional constructors as well as a no-arg or Map constructor.

• You can support hybrid construction by having a constructor where the first argumentis a Map but there are also additional positional parameters. Use this style with caution.

A method is defined with a return type or with thedef keyword, to make the return type untyped. A method can also receive any number of arguments, which may not have their types explicitly declared. Java modifiers can be used normally, and if no visibility modifier is provided, the method is public.

Methods in Groovy always return some value. If noreturn statement is provided, the value evaluated in the last line executed will be returned. For instance, note that none of the following methods uses thereturn keyword.

Like constructors, normal methods can also be called with named parameters.To support this notation, a convention is used where the first argument to the method is aMap.In the method body, the parameter values can be accessed as in normal maps (map.key).If the method has just a single Map argument, all supplied parameters must be named.

Mixing named and positional parameters

def foo(Map args, Integer number) { "${args.name}: ${args.age}, and the number is ${number}" }foo(name: 'Marie', age: 1, 23)(1)foo(23, name: 'Marie', age: 1)(2)

def foo(Integer number, Map args) { "${args.name}: ${args.age}, and the number is ${number}" }foo(name: 'Marie', age: 1, 23)(1)

def foo(Integer number, Map args) { "${args.name}: ${args.age}, and the number is ${number}" }foo(23, [name: 'Marie', age: 1])(1)

Default arguments make parameters optional.If the argument is not supplied, the method assumes a default value.

Parameters are dropped from the right, however mandatory parameters are never dropped.

The same rule applies to constructors as well as methods.If using@TupleConstructor, additional configuration options apply.

Groovy supports methods with a variable number of arguments. They are defined like this:def foo(p1, …​, pn, T…​ args).Herefoo supportsn arguments by default, but also an unspecified number of further arguments exceedingn.

This example defines a methodfoo, that can take any number of arguments, including no arguments at all.args.length will return the number of arguments given. Groovy allowsT[] as an alternative notation toT…​.That means any method with an array as last parameter is seen by Groovy as a method that can take a variable number of arguments.

If a method with varargs is called withnull as the vararg parameter, then the argument will benull and not an array of length one withnull as the only element.

If a varargs method is called with an array as an argument, then the argument will be that array instead of an array of length one containing the given array as the only element.

Another important point are varargs in combination with method overloading. In case of method overloading Groovy will select the most specific method.For example if a methodfoo takes a varargs argument of typeT and another methodfoo also takes one argument of typeT, the second method is preferred.

Dynamic Groovy supportsmultiple dispatch (aka multimethods).When calling a method, the actual method invoked is determineddynamically based on the run-time type of methods arguments.First the method name and number of arguments will be considered (including allowance for varargs),and then the type of each argument.Consider the following method definitions:

Perhaps as expected, callingmethod withString andInteger parameters,invokes our third method definition.

Of more interest here is when the types are not known at compile time.Perhaps the arguments are declared to be of typeObject (a list of such objects in our case).Java would determine that themethod(Object, Object) variant would be selected in allcases (unless casts were used) but as can be seen in the following example, Groovy uses the runtime typeand will invoke each of our methods once (and normally, no casting is needed):

For each of the first two of our three method invocations an exact match of argument types was found.For the third invocation, an exact match ofmethod(Integer, Integer) wasn’t found butmethod(Object, Object)is still valid and will be selected.

Method selection then is about finding theclosest fit from valid method candidates which have compatibleparameter types.So,method(Object, Object) is also valid for the first two invocations but is not as close a matchas the variants where types exactly match.To determine the closest fit, the runtime has a notion of thedistance an actual argumenttype is away from the declared parameter type and tries to minimise the total distance across all parameters.

The following table illustrates some factors which affect the distance calculation.

In the case where two variants have exactly the same distance, this is deemed ambiguous and will cause a runtime exception:

Casting can be used to select the desired method:

Groovy automatically allows you to treat checked exceptions like unchecked exceptions.This means that you don’t need to declare any checked exceptions that a method may throwas shown in the following example which can throw aFileNotFoundException if the file isn’t found:

Nor will you be required to surround the call to thebadRead method in the previous example within a try/catchblock - though you are free to do so if you wish.

If you wish to declare any exceptions that your code might throw (checked or otherwise) you are free to do so.Adding exceptions won’t change how the code is used from any other Groovy code but can be seen as documentationfor the human reader of your code. The exceptions will become part of the method declaration in the bytecode,so if your code might be called from Java, it might be useful to include them.Using an explicit checked exception declaration is illustrated in the following example:

A field is a member of a class, interface or trait which stores data.A field defined in a Groovy source file has:

• a mandatoryaccess modifier (public,protected, orprivate)

• one or more optionalmodifiers (static,final,synchronized)

• an optionaltype

• a mandatoryname

A field may be initialized directly at declaration:

It is possible to omit the type declaration of a field. This is however considered a bad practice and in general itis a good idea to use strong typing for fields:

The difference between the two is important if you want to use optional type checking later.It is also important as a way to document the class design.However, in some cases like scripting or if you want to rely on duck typing it may be usefulto omit the type.

A property is an externally visible feature of a class. Rather than just using a public field to representsuch features (which provides a more limited abstraction and would restrict refactoring possibilities),the typical approach in Java is to follow the conventions outlined in theJavaBeans Specification, i.e. represent the property using acombination of a private backing field and getters/setters. Groovy follows these same conventionsbut provides a simpler way to define the property. You can define a property with:

• anabsent access modifier (nopublic,protected orprivate)

• one or more optionalmodifiers (static,final,synchronized)

• an optionaltype

• a mandatoryname

Groovy will then generate the getters/setters appropriately. For example:

If a property is declaredfinal, no setter is generated:

Properties are accessed by name and will call the getter or setter transparently, unless the code is in the classwhich defines the property:

It is worth noting that this behavior of accessing the backing field directly is done in order to prevent a stackoverflow when using the property access syntax within a class that defines the property.

It is possible to list the properties of a class thanks to the metaproperties field of an instance:

By convention, Groovy will recognize properties even if there is no backing fieldprovided there are getters or settersthat follow the Java Beans specification. For example:

This syntactic sugar is at the core of many DSLs written in Groovy.

Property naming conventions

Modifiers on a property

Annotations on a property

class Animal {    int lowerCount = 0    @Lazy String name = { lower().toUpperCase() }()    String lower() { lowerCount++; 'sloth' }}def a = new Animal()assert a.lowerCount == 0(1)assert a.name == 'SLOTH'(2)assert a.lowerCount == 1(3)

Split property definition with an explicit backing field

class HasPropertyWithProtectedField {    protected String name(1)    String name(2)}

class HasPropertyWithPackagePrivateField {    String name(1)    @PackageScope String name(2)}

class HasPropertyWithSynchronizedAccessorMethods {    private String name(1)    @Synchronized String name(2)}

Explicit accessor methods

@interface SomeAnnotation {}

@interface SomeAnnotation {    String value()(1)}@interface SomeAnnotation {    String value() default 'something'(2)}@interface SomeAnnotation {    int step()(3)}@interface SomeAnnotation {    Class appliesTo()(4)}@interface SomeAnnotation {}@interface SomeAnnotations {    SomeAnnotation[] value()(5)}enum DayOfWeek { mon, tue, wed, thu, fri, sat, sun }@interface Scheduled {    DayOfWeek dayOfWeek()(6)}

An annotation can be applied on various elements of the code:

In order to limit the scope where an annotation can be applied, it is necessary to declare it on the annotationdefinition, using thejava.lang.annotation.Target annotation. For example, here is how you woulddeclare that an annotation can be applied to a class or a method:

The list of possible targets is available in thejava.lang.annotation.ElementType.

When an annotation is used, it is required to set at least all members that do not have a default value. For example:

However it is possible to omitvalue= in the declaration of the value of an annotation if the membervalue is theonly one being set:

The visibility of an annotation depends on its retention policy. The retention policy of an annotation is set usingthejava.lang.annotation.Retention annotation:

The list of possible retention targets and description is available in thejava.lang.annotation.RetentionPolicy enumeration. Thechoice usually depends on whether you want an annotation to be visible atcompile time or runtime.

An interesting feature of annotations in Groovy is that you can use a closure as an annotation value. Thereforeannotations may be used with a wide variety of expressions and still have IDE support. For example, imagine aframework where you want to execute some methods based on environmental constraints like the JDK version or the OS.One could write the following code:

For the@OnlyIf annotation to accept aClosure as an argument, you only have to declare thevalue as aClass:

To complete the example, let’s write a sample runner that would use that information:

Then the runner can be used this way:

Meta-annotations, also known as annotation aliases are annotations thatare replaced at compile time by other annotations (one meta-annotationis an alias for one or more annotations). Meta-annotations can be used toreduce the size of code involving multiple annotations.

Let’s start with a simple example. Imagine you have the @Serviceand @Transactional annotations and that you want to annotate a classwith both:

Given the multiplication of annotations that you could add to the same class, a meta-annotationcould help by reducing the two annotations with a single one having the very same semantics. For example,we might want to write this instead:

A meta-annotation is declared as a regular annotation but annotated with@AnnotationCollector and thelist of annotations it is collecting. In our case, the@TransactionalService annotation can be written:

Groovy supports bothprecompiled andsource formmeta-annotations. This means that your meta-annotation may beprecompiled, or you can have it in the same source tree as the one youare currently compiling.

INFO: Meta-annotations are a Groovy-only feature. There isno chance for you to annotate a Java class with a meta-annotation andhope it will do the same as in Groovy. Likewise, you cannot write ameta-annotation in Java: both the meta-annotation definition and usagehave to be Groovy code. But you can happily collect Java annotationsand Groovy annotations within your meta-annotation.

When the Groovy compiler encounters a class annotated with ameta-annotation, it replaces it with the collected annotations. So,in our previous example, it willreplace @TransactionalService with @Transactional and @Service:

The conversion from a meta-annotation to the collected annotations is performed during thesemantic analysis compilation phase. 

In addition to replacing the alias with the collected annotations, a meta-annotation is capable ofprocessing them, including arguments.

Meta-annotations can collect annotations which have parameters. To illustrate this,we will imagine two annotations, each of them accepting one argument:

And suppose that you want to create a meta-annotation named @Explosive:

By default, when the annotations are replaced, they will get theannotation parameter valuesas they were defined in the alias. More interesting,the meta-annotation supports overriding specific values:

If two annotations define the same parameter name, the default processorwill copy the annotation value to all annotations that accept this parameter:

In the second case, the meta-annotation value was copied inboth@Foo and@Bar annotations.

It is however possible to customize the behavior of meta-annotations and describe how collectedannotations are expanded. We’ll look at how to do that shortly but first there is an advancedprocessing option to cover.

The@AnnotationCollector annotation supports amode parameter which can be used toalter how the default processor handles annotation replacement in the presence ofduplicate annotations.

INFO: Custom processors (discussed next) may or may not support this parameter.

As an example, suppose you create a meta-annotation containing the@ToString annotationand then place your meta-annotation on a class that already has an explicit@ToStringannotation. Should this be an error? Should both annotations be applied? Does one takepriority over the other? There is no correct answer. In some scenarios it might bequite appropriate for any of these answers to be correct. So, rather than trying topreempt one correct way to handle the duplicate annotation issue, Groovy lets youwrite your own custom meta-annotation processors (covered next) and lets you writewhatever checking logic you like within AST transforms - which are a frequent target foraggregating. Having said that, by simply setting themode, a number of commonlyexpected scenarios are handled automatically for you within any extra coding.The behavior of themode parameter is determined by theAnnotationCollectorModeenum value chosen and is summarized in the following table.

A custom annotation processor will let you choose how to expand ameta-annotation into collected annotations. The behaviour of the meta-annotation is,in this case, totally up to you. To do this, you must:

• create a meta-annotation processor, extendingorg.codehaus.groovy.transform.AnnotationCollectorTransform

• declare the processor to be used in the meta-annotation declaration

To illustrate this, we are going to explore how the meta-annotation@CompileDynamic is implemented.

@CompileDynamic is a meta-annotation that expands itselfto @CompileStatic(TypeCheckingMode.SKIP). The problem is that thedefault meta annotation processor doesn’t support enums and theannotation valueTypeCheckingMode.SKIP is one.

The naive implementation here would not work:

Instead, we will define it like this:

The first thing you may notice is that our interface is no longerannotated with @CompileStatic. The reason for this is that we rely ontheprocessor parameter instead, that references a class whichwill generate the annotation.

Here is how the custom processor is implemented:

In the example, thevisit method is the only method which has to be overridden. It is meant to return a list ofannotation nodes that will be added to the node annotated with the meta-annotation. In this example, we return asingle one corresponding to@CompileStatic(TypeCheckingMode.SKIP).

Declaring a method in a trait can be done like any regular method in a class:

In addition, traits may declareabstract methods too, which therefore need to be implemented in the class implementing the trait:

Then the trait can be used like this:

Traits may also define private methods. Those methods will not appear in the trait contract interface:

If we have a class implementing a trait, conceptually implementations from the trait methodsare "inherited" into the class. But, in reality, there is no base class containing suchimplementations. Rather, they are woven directly into the class. A final modifier on a methodjust indicates what the modifier will be for the woven method. While it would likely beconsidered bad style to inherit and override or multiply inherit methods with the samesignature but a mix of final and non-final variants, Groovy doesn’t prohibit this scenario.Normal method selection applies and the modifier used will be determined from the resulting method.You might consider creating a base class which implements the desired trait(s) if youwant trait implementation methods that can’t be overridden.

trait Introspector {    def whoAmI() { this }}class Foo implements Introspector {}def foo = new Foo()

foo.whoAmI()

assert foo.whoAmI().is(foo)

interface Named {(1)    String name()}trait Greetable implements Named {(2)    String greeting() { "Hello, ${name()}!" }}class Person implements Greetable {(3)    String name() { 'Bob' }(4)}def p = new Person()assert p.greeting() == 'Hello, Bob!'(5)assert p instanceof Named(6)assert p instanceof Greetable(7)

trait Named {    String name(1)}class Person implements Named {}(2)def p = new Person(name: 'Bob')(3)assert p.name == 'Bob'(4)assert p.getName() == 'Bob'(5)

Since traits allow the use of private methods, it can also be interesting to use private fields to store state. Traitswill let you do that:

Public fields work the same way as private fields, but in order to avoid thediamond problem,field names are remapped in the implementing class:

The name of the field depends on the fully qualified name of the trait. All dots (.) in package are replaced with an underscore (_), and the final name includes a double underscore.So if the type of the field isString, the name of the package ismy.package, the name of the trait isFoo and the name of the field isbar,in the implementing class, the public field will appear as:

trait FlyingAbility {(1)        String fly() { "I'm flying!" }(2)}trait SpeakingAbility {    String speak() { "I'm speaking!" }}

class Duck implements FlyingAbility, SpeakingAbility {}(1)def d = new Duck()(2)assert d.fly() == "I'm flying!"(3)assert d.speak() == "I'm speaking!"(4)

class Duck implements FlyingAbility, SpeakingAbility {    String quack() { "Quack!" }(1)    String speak() { quack() }(2)}def d = new Duck()assert d.fly() == "I'm flying!"(3)assert d.quack() == "Quack!"(4)assert d.speak() == "Quack!"(5)

Traits may extend another trait, in which case you must use theextends keyword:

Alternatively, a trait may extend multiple traits. In that case, all super traits must be declared in theimplementsclause:

Traits can call any dynamic code, like a normal Groovy class. This means that you can, in the body of a method, callmethods which are supposed to exist in an implementing class, without having to explicitly declare them in an interface.This means that traits are fully compatible with duck typing:

It is also possible for a trait to implement MOP methods likemethodMissing orpropertyMissing, in which case implementing classeswill inherit the behavior from the trait, like in this example:

It is possible for a class to implement multiple traits. If some trait defines a method with the same signature as amethod in another trait, we have a conflict:

In this case, the default behavior is that the method from thelast declared trait in theimplements clause wins.Here,B is declared afterA so the method fromB will be picked up:

In case this behavior is not the one you want, you can explicitly choose which method to call using theTrait.super.foo syntax.In the example above, we can ensure the method from trait A is invoked by writing this:

Groovy also supports implementing traits dynamically at runtime. It allows you to "decorate" an existing object using atrait. As an example, let’s start with this trait and the following class:

Then if we do:

the call to extra would fail becauseSomething is not implementingExtra. It is possible to do it at runtime withthe following syntax:

Should you need to implement several traits at once, you can use thewithTraits method instead of theas keyword:

interface MessageHandler {    void on(String message, Map payload)}

trait DefaultHandler implements MessageHandler {    void on(String message, Map payload) {        println "Received $message with payload $payload"    }}

class SimpleHandler implements DefaultHandler {}

class SimpleHandlerWithLogging implements DefaultHandler {    void on(String message, Map payload) {(1)        println "Seeing $message with payload $payload"(2)        DefaultHandler.super.on(message, payload)(3)    }}

trait LoggingHandler implements MessageHandler {(1)    void on(String message, Map payload) {        println "Seeing $message with payload $payload"(2)        super.on(message, payload)(3)    }}

class HandlerWithLogger implements DefaultHandler, LoggingHandler {}def loggingHandler = new HandlerWithLogger()loggingHandler.on('test logging', [:])

Seeing test logging with payload [:]Received test logging with payload [:]

trait SayHandler implements MessageHandler {    void on(String message, Map payload) {        if (message.startsWith("say")) {(1)            println "I say ${message - 'say'}!"        } else {            super.on(message, payload)(2)        }    }}

class Handler implements DefaultHandler, SayHandler, LoggingHandler {}def h = new Handler()h.on('foo', [:])h.on('sayHello', [:])

Seeing foo with payload [:]Received foo with payload [:]Seeing sayHello with payload [:]I say Hello!

class AlternateHandler implements DefaultHandler, LoggingHandler, SayHandler {}h = new AlternateHandler()h.on('foo', [:])h.on('sayHello', [:])

Seeing foo with payload [:]Received foo with payload [:]I say Hello!

If a class implements multiple traits and a call to an unqualifiedsuper is found, then:

1. if the class implements another trait, the call delegates to the next trait in the chain

2. if there isn’t any trait left in the chain,super refers to the super class of the implementing class (this)

For example, it is possible to decorate final classes thanks to this behavior:

In this example, whensuper.append is encountered, there is no other trait implemented by the target object, so themethod which is called is the originalappend method, that is to say the one fromStringBuilder. The same trickis used fortoString, so that the string representation of the proxy object which is generated delegates to thetoString of theStringBuilder instance.

If a trait defines a single abstract method, it is candidate for SAM (Single Abstract Method) type coercion. For example,imagine the following trait:

SincegetName is thesingle abstract method in theGreeter trait, you can write:

or even:

In Java 8, interfaces can have default implementations of methods. If a class implements an interface and does not providean implementation for a default method, then the implementation from the interface is chosen. Traits behave the same butwith a major difference: the implementation from the trait isalways used if the class declares the trait in its interfacelistand that it doesn’t provide an implementationeven if a super class does.

This feature can be used to compose behaviors in a very precise way, in case you want to override the behavior of analready implemented method.

To illustrate the concept, let’s start with this simple example:

In this example, we create a simple test case which uses two properties (config andshell) and uses those inmultiple test methods. Now imagine that you want to test the same, but with another distinct compiler configuration.One option is to create a subclass ofSomeTest:

It works, but what if you have actually multiple test classes, and that you want to test the new configuration for allthose test classes? Then you would have to create a distinct subclass for each test class:

Then what you see is that thesetup method of both tests is the same. The idea, then, is to create a trait:

Then use it in the subclasses:

It would allow us to dramatically reduce the boilerplate code, and reduces the risk of forgetting to change the setupcode in case we decide to change it. Even ifsetup is already implemented in the super class, since the test class declaresthe trait in its interface list, the behavior will be borrowed from the trait implementation!

This feature is in particular useful when you don’t have access to the super class source code. It can be used tomock methods or force a particular implementation of a method in a subclass. It lets you refactor your code to keepthe overridden logic in a single trait and inherit a new behavior just by implementing it. The alternative, of course,is to override the method inevery place you would have used the new code.

class A { String methodFromA() { 'A' } }(1)class B { String methodFromB() { 'B' } }(2)A.metaClass.mixin B(3)def o = new A()assert o.methodFromA() == 'A'(4)assert o.methodFromB() == 'B'(5)assert o instanceof A(6)assert !(o instanceof B)(7)

trait TestHelper {    public static boolean CALLED = false(1)    static void init() {(2)        CALLED = true(3)    }}class Foo implements TestHelper {}Foo.init()(4)assert Foo.TestHelper__CALLED(5)

Foo.CALLED = true

class Bar implements TestHelper {}(1)class Baz implements TestHelper {}(2)Bar.init()(3)assert Bar.TestHelper__CALLED(4)assert !Baz.TestHelper__CALLED(5)

trait IntCouple {    int x = 1    int y = 2    int sum() { x+y }}

class BaseElem implements IntCouple {    int f() { sum() }}def base = new BaseElem()assert base.f() == 3

class Elem implements IntCouple {    int x = 3(1)    int y = 4(2)    int f() { sum() }(3)}def elem = new Elem()

assert elem.f() == 3

trait IntCouple {    int x = 1    int y = 2    int sum() { getX()+getY() }}class Elem implements IntCouple {    int x = 3    int y = 4    int f() { sum() }}def elem = new Elem()assert elem.f() == 7

Sometimes you will want to write a trait that can only be applied to some type. For example, you may want to apply atrait on a class that extends another class which is beyond your control, and still be able to call those methods.To illustrate this, let’s start with this example:

It is clear, here, that theCommunicating trait can only apply toDevice. However, there’s no explicitcontract to indicate that, because traits cannot extend classes. However, the code compiles and runs perfectlyfine, becauseid in the trait method will be resolved dynamically. The problem is that there is nothing thatprevents the trait from being applied to any class which isnot aDevice. Any class which has anid wouldwork, while any class that does not have anid property would cause a runtime error.

The problem is even more complex if you want to enable type checking or apply@CompileStatic on the trait: becausethe trait knows nothing about itself being aDevice, the type checker will complain saying that it does not findtheid property.

One possibility is to explicitly add agetId method in the trait, but it would not solve all issues. What if a methodrequiresthis as a parameter, and actually requires it to be aDevice?

If you want to be able to callthis in the trait, then you will explicitly need to castthis into aDevice. This canquickly become unreadable with explicit casts tothis everywhere.

In order to make this contract explicit, and to make the type checker aware of thetype of itself, Groovy providesa@SelfType annotation that will:

• let you declare the types that a class that implements this trait must inherit or implement

• throw a compile-time error if those type constraints are not satisfied

So in our previous example, we can fix the trait using the@groovy.transform.SelfType annotation:

Now if you try to implement this trait on a class that isnot a device, a compile-time error will occur:

The error will be:

In conclusion, self types are a powerful way of declaring constraints on traits without having to declare the contractdirectly in the trait or having to use casts everywhere, maintaining separation of concerns as tight as it should be.

Both@Sealed and@SelfType restrict classes which use a trait but in orthogonal ways.Consider the following example:

For the degenerate case where a single class implements a trait, e.g.:

Then, either:

or:

could express this constraint. Generally, the former of these is preferred.

Within traits, prefix and postfix operations are not allowed if they update a field of the trait:

A workaround is to use the+= operator instead.

Records have an implicit constructor. This can be overridden in the normal wayby providing your own constructor - you need to make sure you set all the fieldsif you do this.However, for succinctness, a compact constructor syntax can be used wherethe parameter declaration part of a normal constructor is elided.For this special case, the normal implicit constructor is still providedbut is augmented by the supplied statements in the compact constructor definition:

Groovynative records follow thespecial conventionsfor serializability which apply to Java records.Groovyrecord-like classes (discussed below) follow normal Java class serializability conventions.

Groovy supports default values for constructor arguments.This capability is also available for records as shown in the following record definitionwhich has default values fory andcolor:

Arguments when left off (dropping one or more arguments from the right) are replacedwith their defaults values as shown in the following example:

This processing follows normal Groovy conventions for default arguments for constructors, essentially automatically providing the constructors with the following signatures:

Named arguments may also be used (default values also apply here):

You can disable default argument processing as shown here:

This will produce a single constructor as per the default with Java.It will be an error if you drop off arguments in this scenario.

You can force all properties to have a default value as shown here:

Any property/field without an explicit initial value will be given the default value for the argument’s type (null, or zero/false for primitives).

As per Java, you can customize a record’stoString method by writing your own.If you prefer a more declarative style, you can alternatively use Groovy’s@ToString transformto override the default recordtoString.As an example, you can a three-dimensional point record as follows:

We customise thetoString by including the package name (excluded by default for records)and by caching thetoString value since it won’t change for this immutable record.We are also ignoring null values (the default value forz in our definition).

We can have a similar definition for a two-dimensional point:

We can see here that without the package name it would have the same toString as our previous example.

We can obtain the component values from a record as a list like so:

You can use@RecordOptions(toList=false) to disable this feature.

We can obtain the component values from a record as a map like so:

You can use@RecordOptions(toMap=false) to disable this feature.

We can obtain the number of components in a record like so:

You can use@RecordOptions(size=false) to disable this feature.

We can use Groovy’s normal positional indexing to obtain a particular component in a record like so:

You can use@RecordOptions(getAt=false) to disable this feature.

It can be useful to make a copy of a record with some components changed.This can be done using an optionalcopyWith method which takes named arguments.Record components are set from the supplied arguments.For components not mentioned, a (shallow) copy of the original record component is used.Here is how you might usecopyWith for theFruit record:

ThecopyWith functionality can be disabled by setting theRecordOptions#copyWith annotation attribute tofalse.

As with Java, records by default offer shallow immutability.Groovy’s@Immutable transform performs defensive copying for a range of mutabledata types. Records can make use of this defensive copying to gain deep immutability as follows:

These examples illustrate the principal behindGroovy’s record feature offering three levels of convenience:

• Using therecord keyword for maximum succinctness

• Supporting low-ceremony customization using declarative annotations

• Allowing normal method implementations when full control is required

You can obtain the components of a record as a typed tuple:

Groovy has a limited number ofTupleN classes.If you have a large number of components in your record, you might not be able to use this feature.