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:

Our team has a (not so) slight tendency to not immediately follow through with our deployments to production. We’ll create and review our changes, merge and deploy to staging, and dilligently test the changes there. And then…​ nothing happens.

It could be that something else needs our immediate attention, or someone else wants to confirm an issue is fixed; Or we might want to deploy at a different point in time as to not disrupt an ongoing process by a service restart. Any which way the result is the same: changes accumulate in staging, and with that the risk involved with the next production deployment.

To nudge ourselves to deploy to production more often we created a Slack App that gives us a daily report of such pending deployments. In this post I’ll showcase the code we use, and how to set up something similar yourself.

Java 15 introduced the multi-line string value referred to as a text block. With this introduction also the formatted method was added to the String class. The method can be invoked on a String value directly and function exactly as the static String.format method. The nice thing is that now we directly can use a method on the value instead of having to use a static method where the value is passed as argument.

In the following example we use the formatted method for a normal String value and a text block:

In Java 12 the transform method was add to the String class. This method accepts a Function as argument. The function must have a single parameter of type String and can return any other type. The nice thing is that it works on a String instance, so we can directly use the transform method when we have a String value. We don’t have to pass the String object to another method to tranform it, but we can define the tranformation function close to the String value.

In the following example we take a String value and apply some functions with the transform method:

Since Java 12 we can format numbers in a compact style with the CompactNumberFormat class in the java.text package. A number like 23000 is formatted as 23K for the English locale. Instead of the short representation of K for 1000 we can also use a longer style where K is transformed as thousand for the English locale. We can use the same class to parse a String value that is in the compact style into a number.

In the following example we use several options of the CompactNumberFormat class: