In a previous post we learned about the macros SV
, SVI
and SVD
that return a string representation of variables with their name and value. Groovy 4 also added the NP
and NPL
macros that we can use to inspect variables. Instead of returning a GString
instance these macros return a NamedValue
instance or a list of NamedValue
value instances. The NamedValue
class is a simple class with a property name
, containing the name of the variable, and property val
with the value of the variable. The macro NP
can be used when we have a single variable and result is a single NamedValue
instance. An the macro NVL
can be used with multiple variables. The result is a list of NamedValue
instances where each instance represent a variable passed as argument to NVL
.
Continue reading →
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.
Continue reading →
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.
Continue reading →
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.
Continue reading →
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
.
Continue reading →
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.
Continue reading →
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.
Continue reading →
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.
Continue reading →
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 ({…}
).
Continue reading →
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.
Continue reading →
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
.
Continue reading →
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.
Continue reading →