Groovy 4 added some built-in macros that we can use in our code. A macro is code that will create new code. It does this by manipulating the Abstract Syntax Tree (AST) before the code is compiled. So when we use a macro, the macro will change the AST and those changes will be compiled. The three built-in macros SV, SVI and SVD can create a GString instance with the names and values of the variables that are passed as argument. This can be very useful to create some meaningful debugging statements. Normally we would have to type in the variable name ourselves followed by the value. Now with these macros we don’t have to type the variable as the macro will add that to the AST for us.

DataWeave has a nice language feature called literal types. Literal types are types with a single predefined values and can be defined using a String, Number or Boolean value. So the value of a literal type is a fixed value. We can combine multiple literal types into a new type using a union type to define an enumaration in DataWeave. The enumaration can only be one of the literal types used to define it.
Together with overloaded functions literal types are very useful. We can define a function where one of the input arguments is a literal type to define specific behaviour based on the literal type. Then we can overload the function for other literal types with different behaviour. DataWeave will make sure the correct function is called based on the value of the input argument and how it matches to the literal type value.

Groovy supports ranges for a long time. But Groovy 4 adds a new feature for ranges and that is the support for open (exclusive) ranges at the beginning of a range. Open means the number that defines the range is not part of the actual range result and we must use the less-than character (<). This is also referred to as exclusive, where the value is excluded from the range. When a range is closed the value is included, also called inclusive. Before Groovy 4 we could already define the end of the range to be exclusive or inclusive, but now we can also define the beginning of the range to be exclusive.

SDKMAN! has a home command that will return the absolute path of any SDK we pass as argument. This can be useful in scripts where we need the absolute path to a SDK. We can specify the name of the SDK after the home command and the version. To use the current version that is set as default we can use as version current.

Groovy 4 introduced support for TOML configuration file. In a previous post we already learned how we can parse TOML content. In this post we will see we can use a builder syntax to create TOML content. We need the class TomlBuilder and then define our structure using a nice builder DSL. The DSL is comparable to create JSON using the JsonBuilder. The names of the nodes in the DSL structure will be the names of the properties. Nodes within nodes will result in concatenated property names with the name of each node separated by a dot (.). We can also use collections as arguments and those will translated to TOML arrays. A collection can optionally be followed by a closure that processes each item in the collection to generate the content for the TOML array.

Since Groovy 4 we can parse TOML configuration data into a Map. Once the TOML data is transformed into the Map we can use all possibilities in Groovy to lookup keys and their values in maps. For example we can use GPath expressions to easily get the value of a (nested) key. To parse TOML configuration data we must use the TomlSlurper class that is in the groovy.toml package. We can use the parse method when we have a file, reader or stream with our configuration. To parse a String value with TOML configuration we use the parseText method.

GINQ (Groovy-INtegrated Query) is added since Groovy 4. With GINQ we can query in-memory collections with SQL like statements. If we want to get the row numbers for each row in the query result set we can use the implicit variable _rn. We must specify _rn in the select expression of our GINQ query. We can even use as to give it a meaningful name in the result set.

Groovy supports more classifiers for a switch case statement than Java. Since Groovy 4 we can use switch also as an expression. This means the switch statement returns a value without having to use return. Instead of using a colon (:) and break we use the → notation for a case. We specify the value that the switch expressions returns after →. When we need a code block we simply put the code between curly braces ({…​}).

The dw::core::Strings has a lot of functions to deal with strings. One of the functions is ordinalize that takes a number as argument and returns the ordinal value as string.

To check if a value is of a certain type in DataWeave we must use the is operator. We must specify the type after the is operator and the value before the is operator. For example to check if the value 42 is a Number we write 42 is Number. The result is a Boolean that is either true or false. In the previous example the result is true.

To calculate the modulo of two numbers in DataWeave we can use the mod function from the dw::Core module. We provide two arguments where the first argument is the number that needs to be divided by the number provided as second argument. The number that remains after a division of the input arguments is returned as a result.

In a previous blog post we learned about the zip function. DataWeave also gives us the unzip function that will do the opposite for an array with arrays. The input argument of the unzip function is an array where the elements are also arrays. This could be created by the zip function or just defined as data structure directly. The unzip function will take from each array the same index element and return it as an array with the index elements. For example with the input array [[1, "A"], [2, "B"]] will be unzipped to [[1, 2], ["A", "B"]]. When the number of elements in the arrays that need to unzipped are not equal, the unzip function will only return the elements from the index with the most elements.