A Spring Boot application typically consists of several components handling the business functionality and probably some configuration to configure all these components. This configuration consists of defining some properties, setting up some beans with the right conditions and dependencies and wrapping it all together into a class structure. Nevertheless, the configuration of our Spring Boot application is also code. Let’s threat is as code.

In this blog we will se how we can improve our Spring Boot Configuration by splitting up the configuration from the properties and how this effects the design principles.

Lamda expressions were introduced in Java 8 and have been around for a while. They are in my opinion one of the better features of Java 8, allowing for a more functional approach to writing code, and thus enabling most of the java 8 features. So let’s take a closer look at lambda’s and see what they are, how to reason about them, and why they are a good addition.

This is a blog post that tries to give a pragmatic explanation about what a monad is, and what problem it tries to solve. This post is written by Ties van de Ven and Justus Brugman.

When I tried to learn about functional programming, I found myself lost in new words and jargon, I did not know about. Suddenly my vocabulary needed to be extended with terms like Monads, Monoids, Composable, Functors and so on. When trying to understand these terms, it became clear that I found it hard to understand what a monad is.

Since about a month I’m developing some microservices using Javalin, a small, simple and lightweight web-framework that started as a fork from SparkJava. By now it’s a ground-up rewrite, influenced by the Javascript framework koa.js. Don’t let the stuff like Either scare you, we use the Arrow library to make our life a bit more easy :)

When requesting user input from a form, it’s evident that we need to validate our input. Javalin has its own way of doing so (from the docs):

Since Mapstruct version 1.3.0.Final is out, we are able to better integrate with Lombok Builder pattern. Mapstruct is a library that takes away a lot of boilerplate code for mapping between POJO’s. With Mapstruct there is no need for implementing the real mapping itself.

With Lombok we can use a Builder pattern and mark an object as a Value(Object). It will result in an immutable object. This blog post shows how we can use Mapstruct to use the Builder pattern of Lombok.

I like to create immutable classes. When using lombok we can easily create immutable classes.

This class Person with the @Value annotation will create an immutable class with an all args constructor. The @Builder will add a Builder pattern to the Person class, so I can use it like this:

With the release of Asciidoctor 2.0.0 we get nice help on the basic syntax of Asciidoc with the command-line option --help syntax. This gives us samples of the syntax in Asciidoc markup. As mentioned by Dan Allen on Twitter we can pipe the syntax sample to Asciidoctor itself to get a HTML page:

Micronaut can convert String values defined as a number followed by (case-insensitive) KB/MB/GB to a number value in certain cases. The conversion service in Micronaut supports the @ReadableBytes annotation that we can apply to a method parameter. Micronaut will then parse the String value and convert it to a number. The value 1Kb is converted to 1024. We can use this for example in a configuration class or path variable in a controller.

Micronaut supports the RFC-6570 URI template specification to define URI variables in a path definition. The path definition can be a value of the @Controller annotation or any of the routing annotations for example @Get or @Post. We can define a path variable as {?binding*} to support binding of request parameters to all properties of an object type that is defined as method argument with the name binding. We can even use the Bean Validation API (JSR380) to validate the values of the request parameters if we add an implementation of this API to our class path.

Working with SQL database from Groovy code is very easy using the groovy.sql.Sql class. The class has several methods to execute a SQL query, but we have to take special care if we use methods from Sql that take a GString argument. Groovy will extract all variable expressions and use them as values for placeholders in a PreparedStatement constructed from the SQL query. If we have variable expressions that should not be extracted as parameters for a PreparedStatement we must use the Sql.expand method. This method will make the variable expression a groovy.sql.ExpandedVariable object. This object is not used as parameter for a PreparedStatement query, but the value is evaluated as GString variable expression.

Spring Boot 2.1 introduced log groups. A log group is a logical name for one or more loggers. We can define log groups in our application configuration. Then we can set the log level for a group, so all loggers in the group will get the same log level. This can be very useful to change a log level for multiple loggers that belong together with one setting. Spring Boot already provides two log groups by default: web and sql. In the following list we see which loggers are part of the default log groups: