The auto-configuration feature in Spring Boot adds beans to our application context based on conditions. For example based on the availability of a class on the class path or a environment property beans are enabled or disabled. We must apply the @EnableAutoConfiguration or @SpringBootApplicaiton in our Spring Boot application to make this work. To get an overview of all the configurations that had positive and negative conditional matches in our application we can use the --debug command-line option. This will print out a report to System.out with a complete overview. We can check why a configuration is applied or not.

In the following Gradle build file we add the option --debug to the args property of the bootRun task:

Continue reading →

There is a catch when we define a constant field in Groovy. Rob Fletcher blogged about this in the post Groovy the public keyword a while ago. When we omit the public keyword for a method then the method is still accessible as public method, because Groovy makes the method public when the class is compiled. When we leave out the public keyword for fields Groovy creates a getter and setter method for the field at compile time and turns it into a property that applies to the Java Bean specification. This is also true if the field is static. So if we define a constant value as static final we must keep in mind that Groovy will generate a getter method so the constant value is a read only property according to Java Bean specification.

Let's create a simple class with a constant field DEFAULT, a property message and a message method. We leave out any public keyword:

Continue reading →

When we develop a Spring Boot application we can hot reload newly compiled classes using Gradle. The bootRun task of the Spring Boot Gradle plugin has support for Spring Loaded. We must add a dependency to Spring Loaded as a dependency for the classpath configuration in the buildscript block. If we now use the bootRun task everything is ready to reload changed classes. Now we can use the continuous build feature of Gradle to listen for changes in our source files to recompile them. The recompiled classes are then reloaded in the running Spring Boot application started with bootRun. We start a second Gradle instance with the -t option for the classes task. This way when we change a source file it gets recompiled automatically and reloaded.

The following build script shows how we add Spring Loaded:

Continue reading →

The best IDE to use when developing Groovy code is IntelliJ IDEA. The Groovy plugin has some nice intentions for us that we can use to optimise and refactor our code. We will look at some of the intentions that deal with String values in this blog post. The intentions shown here work in the free Community Edition as well in the paid Ultimate Edition. To see the possible intentions in IDEA we must select the Show Intentions Action. We need to check our shortcut keys to see the assigned shortcut. On my Mac it is for example Alt+Enter. Alternatively we can press the Shift key twice and type in Show intentions. IDEA will show the action with the shortcut key for us.

Suppose we have assigned a String value to a variable in our code. We used the double quoted syntax to do so, like in Java. But we want to change it to a single quoted String value, so to make it explicit the value cannot be a GString implementation. In the following screenshot we see our variable s with a value. We use our shortcut key to open the suggested intentions. We type convert to shorten the list with only conversion options. We see that we can change our String value to dollar slashy, regular expression, multiline or plain String syntax:

Continue reading →

The built-in dependency mechanism in Groovy is Grape. With Grape we can define dependencies in our code and Groovy will download them and make them available when we run our Groovy application. The easiest way to use it is with the @Grab annotation with a dependency as the value. If we want to exclude a transitive dependency we use the @GrabExclude annotation. We must specify the attributes group and module of the annotation with the dependency we want to exclude. An alternative syntax is a shorthand version where the group and module are combined into a single String value separated by a colon (:).

In the following Groovy script we have a very simple Spring application with Java (Groovy) based configuration. So we need a dependency on the spring-context module. But we don't want to use the standard Spring logging. Spring used Apache Commons logging and we want to replace it with an SLF4J API implementation: Logback. So we use the @GrabExclude annotation to exclude the commons logging dependency. And we add two extra dependencies to replace it: org.slf4j:jcl-over-slf4j and ch.qos.logback:logback-classic.

Continue reading →

Groovy has a advanced feature to define and download dependencies automatically for our code: grape. To get more information about the progress of the dependency resolution and downloading of the dependencies we must use the Java system property groovy.grape.report.downloads and set it to true. Groovy uses Ivy under the hood to handle the dependency management. We can get Ivy logging messages by setting the system property ivy.message.logger.level to a numeric value. The value 4 gives the most logging and value 0 only shows error messages.

In the following example code we use -Dgroovy.grape.report.downloads=true when we invoke a simple Groovy script with a dependency on Apache Commons library:

Continue reading →

With Grape in Groovy we can add dependency management for our code. Especially the @Grab annotation is very useful to specify dependencies directly in our code. Groovy will download the dependencies if needed and store them in the USER_HOME/.groovy/grapes directory. If we want to change this directory we must set the Java system property grape.root. We specify the new directory to store the downloaded dependencies as a value.

In the following example we have a simple script with a dependency on the Apache Commons library. We use the -Dgrape.root command line option when we run the script and specify the directory deps. After we have run the script we can see the contents of the deps directory to see the downloaded files.

Continue reading →

One of the very nice features of Groovy is that we can implement operator overloading. This blog post is not about how to implement operator overloading, but Groovy's operator overloading also means that operators we know in Java have corresponding methods, which are not available in Java. So instead of using operators in our code we can use the corresponding methods.

The following sample code shows some operators we know in Java and the corresponding methods in Groovy:

Continue reading →

Groovy adds the inspect method to the Object. This means it is available on all objects in our application. It is like the toString method, but adds some extra formatting. The most notable is the addition of single quotes to String values.

In the following example we see the output of the inspect method on different objects:

Continue reading →

There are a lot of methods added to the Java collection classes by Groovy. For example to remove elements from a collection, and indeed modify the collection itself, we can use the removeAll and removeElement methods. With the removeAll method we define a closure with a condition that needs to be true for an element to be removed from the collection. The removeElement method is added to overcome any ambiguity with the standard overloaded remove method for collections with integer values. The remove method accepts both an Object or int value, to remove either an element or an element at the specified index. When the collection contains integer values than the argument is interpreted as index value. The removeElement method will use the remove(Object) method implementation. When the collection is a List Groovy adds the removeAt method. We need to specify the index value of the element we want to remove.

def list = ['Groovy', '=', 'gr8!']

// Groovy adds removeAll method
// to remove items from collection
// that apply to the condition we
// define in the closure.
list.removeAll { it.toLowerCase().startsWith('g') }

// All values starting with a G or g
// are now removed.
// Remember the collection we use the
// removeAll method on is changed.
assert list == ['=']

// Java 8 adds removeIf method with
// a predicate. In Groovy we can implement
// the predicate as closure.
list.removeIf { it instanceof String }

assert list.size() == 0


def values = ['Hello', 'world']

// Groovy adds removeAll(Object[])
// to remove multiple elements
// from a collection.
values.removeAll(['world', 'Hello'] as Object[])

assert values.empty


def items = [1, 2, 3]

// remove method is overloaded
// for Object and index value.
// Because Groovy wraps int to
// Integer object, the method call
// is ambiguous for Integer collections.
items.remove(1)

// We want to remove object
// Integer(1) from the list,
// but item with index 1 is removed.
assert items == [1, 3]

// Groovy adds removeElement
// as alias for remove(Object).
items.removeElement(1)

assert items == [3]

// When the collection is a List
// we can use the removeAt method
// to remove based on index value.
items.removeAt(0)

assert !items

Continue reading →

Section titles in our document (titles start with two or more equals signs) are part of the document hierarchy and therefore can be used in a generated table of contents. If we don't want to include a section title in the table of contents we must make the title discrete. The title is styled like a normal section title, but it is no longer part of the document structure as title. Therefore the section title will not be generated in the table of contents. To make a title discrete we must use the attribute discrete for the title.

In the following document we first have a simple document with two section titles. When we generate the HTML for this document we see both titles in the table of contents.

Continue reading →

In a previous blog post we have seen the IgnoreIf extension. There is also a counterpart: the Requires extension. If we apply this extension to a feature method or specification class than the method or whole class is executed when the condition for the @Requires annotation is true. If the condition is false the method or specification is not executed. As a value for the @Requires annotation we must specify a closure. In the closure Spock adds some properties we can use for our conditions:

• jvm can be used to check a Java version or compatibility.
• sys returns the Java system properties.
• env used to access environment variables.
• os can be used to check for operating system names.
• javaVersion has the Java version as BigDecimal, eg. 1.8.

Continue reading →