The Java Development Kit (JDK) includes a tool called jshell that can be used to interactively test Java code. Normally we run jshell and type Java code to be executed from an interactive shell. But we can also use jshell as a tool on the command line to accept standard input containing Java code to be executed. The output of the code can be used as input for another tool on the command line. We run jshell - to run jshell and accept standard input. The simplest way to pass Java code to jshell is to use echo to print the Java code to standard output and pipe it to jshell.

With @ConfigurationProperties in Spring Boot we can bind configuration properties to Java classes. The class annotated with @ConfigurationProperties can be injected into other classes and used in our code. We can use the type DataSize to configure properties that express a size in bytes. When we set the value of the property we can use a long value. The size is then in bytes as that is the default unit. We can also add a unit to the value. Valid units are B for bytes, KB for kilobytes, MB for megabytes, GB for gigabytes and TB for terabytes.

We can also use the @DataSizeUnit annotation to specify the unit of the property in our class annotated with @ConfigurationProperties. In that case a the value without a unit assigned to the property is already in the specified unit.

AssertJ already provides many useful assertions for all kind of types. But sometimes we want to define our own assertions for our own types. We can define new assertions by extending the AbstractAssert class In this class we add methods that will check the values of our type. The names of the methods can reflect the domain model of our type. This can make our tests more readable and understandable.

To compare nested objects we can use the usingRecursiveComparison() method in AssertJ. We can set up the nested objects with values we expect, invoke a method that would return the actual nested objects, and then use the usingRecursiveComparison() method to compare the actual nested objects with the expected nested objects. This is a very clean way to compare nested objects. Also when we would add a new property to the nested objects our test would fail as we didn’t use that new property yet for our expected nested objects.

We have come a long way since the introduction of Servlets back in 1999. Back then, implementing and getting to run a Servlet required a lot of development, class overloading, XML configuration and a host of other tasks. It prompted improvements like Java Servlet pages and the subsequent move towards frameworks like the model-view-controller model with Struts that have evolved from framework to framework to where we are today, with powerful frameworks like Spring Boot, Micronaut et al. But the Servlet component has not remained idle through those times.

A lot of applications seem to either only use runtime exceptions or only use error monads like the Optional for error handling. In this blog I will try to dive a bit deeper into when to use one over the other (tldr: you probably need both)

Since Java 16 we can use the method mapMulti(BiConsumer) of the Stream API. This method allows us to map each element of the stream to multiple elements. We can also do that with the flatMap(Function) method, but if we want to map a limited set of elements, mapMulti is more convenient. Internally a shared stream is used and we don’t have the cost of creating a new stream for each element. Another use case is if the logic to map an element to multiple elements is complex and is hard to implement by returning a stream. Then mapMulti allows us to write that logic in a BiConsumer instead of a Function.

Pattern matching got quite an update in Java 19 (although it does require turning on experimental features).

Recently I gave a talk that included a slide where I briefly discussed single return vs multiple returns. The purpose of this slide was only to give an example of a dogma and basically had nothing to do with the rest of the talk. Therefore it was kinda funny to see that this particular slide caused a lot of discussion afterwards, so it seems natural to write a blog about this topic.

So…​ should a function only have a single return statement or is it better to allow multiple returns?

If we have an Optional instance we can consume the value if it is present using the ifPresent method. Since Java 9 the method ifPresentOrElse has been added to the Optional class. The first argument is of type Consumer and is invoked when there is an optional value. The second argument is of type Runnable and is executed when the the optional is empty. The method in the Consumer and Runnable implementations does not return a type but returns void. Therefore we should use ifPresentOrElse when we need a conditional side effect for an Optional instance.

In the following example we have a method handleName that will update a list if an optional value is present or increases a counter when the optional value is empty:

Outside the Java community, Java is often regarded as an old and verbose language. Though I love writing Java code, I kind of have to agree with this. New features are implemented slowly and looked upon by the language designers with thorough suspicion. For example, support for multi-line strings has been tried multiple times before Java got official support^[1]. If we are talking about verbosity, the Java language needs quite some characters to write a simple function. As I am specializing in functional programming in Java this year, I struggled a lot with this. Read along how I tackled this a little.

If we want to get two types of information from a Stream of objects we can consume the Stream twice and collect the results. But that is not very efficient, especially when the stream has a lot of objects. Since Java 12 we can use the teeing method of the java.util.stream.Collectors class to get multiple results while consuming the stream of objects only once. The teeing method takes two collectors as argument each returning a separate result for the stream items. As third argument we must pass a function that will merge the results of the two collectors into a new object.

In the following code we have two example use cases that use the teeing method to get multiple results while consuming a Stream of objects only one time: