Adding logging support to a class in Groovy is easy. We can choose to add SLF4J, Log4j, Log4j2, Apache Commons or Java Util Logging to our class. The default implementation of the Abstract Syntax Tree (AST) transformation is to add a
log field of the correct type. As category name the complete class name (including the package) is used. We can change the name of the field with the
value attribute. To alter the category name we use the attribute
In a previous post we learned how to use the
toMapString methods. With these methods we create a String representation of a
Map object. With a bit of Groovy code we can take such a
String object and turn it into a
Groovy adds to
Map objects the
toMapString method. With this method we can have a String representation of our
Map. We can specify an argument for the maximum width of the generated
String. Groovy will make sure at least the key/value pairs are added as a pair, before adding three dots (
...) if the maximum size is exceeded.
def course = [
name: 'Groovy 101',
location: 'The Netherlands']
assert course.toMapString(15) == '[name:Groovy 101, ...]'
assert course.toMapString(25) == '[name:Groovy 101, teacher:mrhaki, ...]'
As mentioned in a previous post we can use the
toListString method to represent a
List as a
def names = ['mrhaki', 'hubert']
assert names.toListString(5) == '[mrhaki, ...]'
Written with Groovy 2.4.7.
Original blog post
Groovy has many AST annotations that add code to our class (the Abstract Syntax Tree – AST) before it is compiled. So the compiled class file contains the code added by the AST annotation. With the
@AutoClone annotation a
clone method is added and the class implements the
Cloneable interface. We have different strategies to choose from to support cloning for our class.
I love code. I take care of my code and I like my code to be formatted nicely. No matter if I’m on Eclipse, Netbeans or IntelliJ, I want my code to be formatted the same.
Nowadays we have EditorConfig. In the source code we can place a file
.editorconfig with formatting instructions. These instructions can be read by many Tools like Eclipse, Netbeans, IntelliJ and VisualStudio. If we create an
.editorconfig file with formatting instructions, these rules are automatically applied.
An example of an
.editorconfig file looks like:
root = true
indent_style = space
indent_size = 2
continuation_indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
indent_size = 4
continuation_indent_size = 4
As you see you can define specific formatting rules for different file types.
Happy coding and formatting!
When we write code with a lot of method chaining that involves closures and the use the Reformat code feature of IntelliJ IDEA things might get screwed up. Luckily we can changes some Groovy formatting rules in IntelliJ IDEA to prevent the reformatting.
Usually in our Ratpack application we use a registry to store components that we want to use in our application code. The calling code for the registry doesn’t need to know how the registry is implemented. Ratpack support Google Guice for example, but Spring is also supported. This means we can define the components for our registry using Spring and we only have to tell Ratpack where to look for the Spring configuration files. Ratpack provides for us the
ratpack.spring.Spring class with the static method
spring. This method returns a Ratpack registry implementation we can use in our application.
Groovy has a lot of nice and useful gems. One of them is the
FileTreeBuilder class. With this class we can create directories and files using a nice DSL with a builder syntax. The code already reflects the hierarchy of the directory structure, which makes it so more readable. We can use an explicit way of referring to methods in the
FileTreeBuilder class, but there is also support for a more dynamic version, where Groovy’s dynamic nature comes to play.
Since Grails 3 we use Gradle as the build system. This means we also use Gradle to define dependencies we need. The default Gradle build file that is created when we create a new Grails application contains the Gradle dependency management plugin via the Gradle Grails plugin. With the dependency management plugin we can import a Maven Bill Of Materials (BOM) file. And that is exactly what Grails does by importing a BOM with Grails dependencies. A lot of the versions of these dependencies can be overridden via Gradle project properties.
A tuple is an ordered, immutable list of elements. Groovy has it’s own
groovy.lang.Tuple class. We can create an instance of a
Tuple by providing all elements that need to be in the
Tuple via the constructor. We cannot add new elements to a
Tuple instance or remove elements. We cannot even change elements in a tuple, so it is completely immutable. This makes it very useable as return value for a method where we need to return multiple values. Groovy also provides a
Tuple2 class that can be used for tuple instance of only two elements. The elements are typed in a