DEV Community: Jedrzej Serwa

Towards better functional programming in Java with Vavr

Jedrzej Serwa — Tue, 14 Jul 2020 11:34:16 +0000

The functional paradigm in programming is over 62 years old, first presented in the Lisp language in 1958¹. In the context of the Java language, it began to be widely spoken relatively recently from the perspective of these years because from version 1.8 or 6 years ago. So what is functional programming, can we program functionally in Java, can we reconcile this paradigm with OOP and how can Vavr library help us in all this?

Starting from the beginning

Before we get into the library itself, let’s briefly recall what functional programming is and what its assumptions are.

The most important assumption of functional programming (FP) is the lack of the so-called side effects where there are many approaches, solutions or language features that bring us closer to this goal, and they include:

Immutability
Lazy initialization
Declarative programming language
First-class functions
Higher-order functions

Explanation what each of these mean is beyond the scope of this article, but for those interested in learning more, I’ve listed some good reading material in the references.

As for the FP pillar, lack of side effects, it is a situation where a given function call does not cause a side effect in the system and retains the so-called referential transparency. This means, no less, no more that we should be able to replace the call of our function for given input parameters with its value. In other words, the function should be deterministic for the arguments given to it and should always return the same result without causing any change in the state of the system except the function scope.

However this does not mean that we must completely abandon mutation operations, after all, it would be impossible to write a system based on business requirements without a database, cache or even http requests. The main thing is that actions that change some state should be extracted as far as possible, should be explicitly marked and ideally be performed at one point in the codebase, ideally in the main class or some dedicated module.

Functional Programming in Java?

A common complaint against Java is its simple syntax and the lack of so-called syntactic sugar. The amount of code needed to write a given functionality, compared to the languages that put the functional paradigm in the first place in their foundations², is definitely larger. It is also true that these languages have a higher entry threshold than Java, it is definitely easier to find a Java programmer than Clojure or Scala, which often has an impact on the main language in which the project will be written. In addition, Java is a huge percentage of the current market, many projects have been written or are in the process of writing in Java, and it would often be impossible to rewrite it to a new language with better language constructions to enjoy the benefits of using the FP paradigm. Simply put – sometimes we have no way of changing the language, and yet we would like to try working with a new paradigm. That is why, starting from Java version 8 and thanks to constructions implemented in the Vavr library³, this desire becomes feasible.

Vavr

Vavr, formerly Java Slang, is a library made available under Apache 2.0 license, which provides us with tools that facilitate functional programming using Java. It is worth noting that Vavr does not contain any dependencies on external libraries, and is based solely on the API offered by Java.
Thanks to lambda expressions⁴, functional interfaces⁵, var keyword⁶ along with the use of components from the Vavr library, functional programming in Java becomes possible. The library itself consists of logically separated modules such as: gwt, match, test, jackson, gson, render, which have been implemented around the main core module and we will look at the selected elements of this module.

Scary Monads and how to embrace them

To better understand the concepts implemented in the Vavr library we will need another definition, the definition of Monad. This sinister-sounding name, which has its roots in Category Theory⁷, for the purposes of this article and in simplification, it can be broken down to simple to understand description – a Monad is a container for data, which allows us to operate declaratively on the data, using operations that are common to other Monads. There is a high probability that if you have not come across this term before, you have unwittingly used the Monads themselves, e.g. using the Monad introduced in JDK 1.8 – Optional⁸ class. In the context of the description presented earlier, the Optional class is a container for data or lack thereof, and provides a set of API enabling declarative operations on this data, including among others operations:

map – enabling a function to be performed on a given data
flatmap – enabling a function to be performed on data that is already a monad, in other words, flattening data
filter – filtering-out data that is not of interest for us
stream⁹ – converting from Optional Monad to Stream¹⁰ Monad

It is worth noting that, as already mentioned, the counterparts of these operations can also be found in other Monads, so when we have to work with the Monad supplied from a given library, we should be able to call functions on data, flatten data, filter data or convert to another Monad. These are, of course, only some of the operations available on Monads, and the available API strongly depends on the library provider or own creative invention of the author.

Getting to the point, the Vavr library provides us with 5 basic monads, and these are:

Either

Either represents the result in which we can return one of two values - left or right. Used when the call to our method can have two waveforms, for example in a situation where the result of a given operation may fail – assigning it the value left, and in the case of success the value right.

Option

Monad used in a situation where we explicitly want to express the intention in which calling our method may return the result or lack of result. The main advantage as opposed to using the @Nullable annotation¹¹ or Javadoc describing a possible null result is that we described the situation using an object that is part of the method signature, and thus handling the situation where the result would be not present is required and checked by the compiler. The most important difference between Option and Optional is that the mapping function that returns null will throw an exception. In addition, this Monad provides a richer set of APIs, including the fold method, which allows us to perform a value mapping operation in the absence or existence of it. Examples of using the Option:

In the presented implementation, the Book module provides the operation of finding information about a book based on ISBN using the findBookDetails method, which uses the Option Monad in its signature. The API user is obliged to handle the situation in which the data about the book is not available through the type contained in the signature, otherwise he will receive a compilation error.

An example implementation of operations based on the Option API along with Either API looks following:

Where:
Lines 11-12 handle potential null values from the ISBN object passed from the user of our API, to further on line 13 perform http request which will return the result wrapped in Either Monad. The whole is handled in line 14, where in the absence of values from previous calls we return an empty result, and in the case of having data and invoking the request, we handle the result by mapping Either Monad to the Option Monad and calling the toDto method from the BookData object.

Try

Monad Try is similar to Option Monad, except that in contrast to missing values it stores an exception that may have been thrown when calling the function. It is worth considering using this monad instead of using checked-exception or instead of throwing runtime exceptions and catching them with the help of framework mechanisms. Instead, we can treat our exceptions as standard Objects and handle errors on a regular basis or postpone their handling to a selected place. Examples of using Try Monad with the Either Monad:

Where:
Line 16 starts using Try by wrapping the getBookData method call from the ThirdPartyBookStoreLibrary class with the checked-exception signature.
Thanks to the Vavr library, we can move on and give up the imperative style – the definition of the try catch block, to the declarative style, while handling an exception.
On line 17, in the case of an exception thrown by the getBookData method, we log the situation, then on line 18 we convert to Either Monad by calling mapLeft in line 19, in which we translate the exception from the library into a comprehensible one inside our system.

In addition, on line 19 the property of functional interfaces was used – use of a qualifier, so we can skip the name of the called method.

Lazy

Monad Lazy represents the value obtained not at the stage of initialization, but at the moment of referring to the value itself, in this context we refer to this as lazy initialization. Its operation can be compared to the known from Java 8 interface Supplier<T>, which returns a given value, with the difference that Lazy Monad has implemented the Memoization functionality and meets the aforementioned Referential transparency and which means that for the same set of arguments Monad calculates the result only once and stores it, returning calculated value for further invocations. An example of using Lazy Monad:

Where:
On line 5 we passed a dependency returning a list of available books, the operation of fetching available books was defined outside the Library class and is expensive because it requires invoking multiple HTTP requests. By using Lazy Monad, we postpone the invocation of expensive calls until the first invocation of the getAvailableBooks method, and this result is saved thanks to the previously mentioned memoization functionality.

Future

Last of the Monads provided in the Vavr library – Future Monad represents value, the result of which will be made available somewhere in time. Operations on this monad are non-blocking. In its behaviour, it resembles the Future / CompletableFuture classes known from JDK. An example of using Future Monad:

Where:
Line 13 transforms the passed Set collection to Stream Monad
Line 14 calls the findBookDetails method that wraps the call of the BookService method in the Future.of method call with the use of the injected Executor dependency
Line 15 collects the result, transforms it to a list and then the result is passed to the sequence method from the Future class
Last Lines 16 and 17 are responsible for collecting the result and creating a new AvailableBooksResult object and returning it in the Future monad. In this way we have achieved functionality in which we can, without blocking, download information about available books.

Briefly about collections and pattern matching

When it comes to the modification of state mentioned many times, you might have the irresistible impression that we have a problem in the Java world. This problem is the lack of the immutable collections. They all modify the internal state, and when it comes to unmodifiable view methods from the Collections class, they only make our collection become read only, which in many cases may not be enough. In the case that we would like our collection to be fully immutable, Vavr library provides us with a solution in the form of newly defined “Functional Data Structures”, which includes Seq, Set and Map interfaces, all implementing a common interface – Iterable. The review of implementations available in the Vavr library goes far beyond this article, after all, we have available at the time of writing this article 15 implementations, but I strongly encourage you to read their documentation about it.

Another element provided in the Vavr library, and often a part of many functional languages¹² is Pattern Matching. Simply put, Pattern Matching allows you to declaratively define control based on a given condition so-called “Match predicate”. An example of using Pattern Matching from the Vavr library looks like this:

Where:
Line 2 Starts Pattern Matching consisting of predicates from lines 2 to 5 and when:
Instance of Number object is BigDecimal type, it calls and returns the result of add method from BigDecimal
Instance of Number object is of the BigInteger type, it calls and returns the result of the add method from the BigInteger class.
Instance of the Number object is of the Integer type, sums the value and returns the result.
Instance of the Number object is of the Float type, sums the value and returns the result.

In addition to the predicates provided by the Vavr library, it is possible to define your own predicates and use them with the mechanism presented above by utilizing the vavr-match module.

It is worth adding that Type Pattern Matching is slowly being implemented in Java. Switch expressions have been added the JDK 14¹³ which makes it possible to use the switch statement also as expressions moreover in the JDK 14 version, authors introduced Pattern Matching for the instance of instruction in the preview version, which has been further transferred to the JDK 15 version in the second preview version¹⁴.

Summary

Despite being 62 years old, functional programming is doing very well and has not been forgotten but is a paradigm that is used on a daily basis. Languages are more and more boldly adapting the functional paradigm, and programmers are noticing the benefits behind its use. The world of Java and OOP does not necessarily exclude the use of FP in existing or new projects, Java syntax has been improved over the years, which is why together with the use of libraries supporting functional programming and concepts implemented there, nowadays we can be tempted to introduce a new paradigm to our codebase. This will allow us to better abstract side effects, help us create code resistant to multithreading problems, code that is more predictable and thus better maintained over time. In the article I have included basic concepts regarding FP and briefly presented the use of selected elements of the Vavr library, which are only a brief introduction to the whole range of solutions and approaches that can be implemented. If you first came across the approaches described in the article I strongly encourage you to explore the subject further because this knowledge will definitely pay off in the future and can give a different point of view on certain problems.

¹ For those interested, I present a paper describing the history of functional languages.
² In the world of JVM it will be, for example, Scala or Clojure.
³ For Java, there are other libraries that facilitate functional programming, such as Cyclops or Functional Java, however the article focuses solely on the Vavr library.
⁴ Added in JDK 1.8, JEP 126.
⁵ Added in JDK 1.8.
⁶ Added in JDK 11, JEP 286. The keyword var is not required for a functional approach, but it helps when reading heavily nested Monads for example.
⁷ For those interested, I’m leaving a link to a GitHub page with a source of the book “Category Theory for Programmers” written by Bartosz Milewski. The book in pdf version published under the GNU GPL v.3 license.
⁸ In the context of Monad laws, the Optional class does not meet all the criteria needed to be considered a true Monad, while for the purposes of this article I have adopted a simplified comparison.
⁹ The method added in JDK 9.
¹⁰ Again, for the purposes of the article, I assumed that Stream class meets all Monad laws, in practice this class is not a full-fledged Monad, more can be read in this article.
¹¹ Although current IDEs are able to catch such errors and there are plugins that can analyze our annotations and at the build stage allowing to capture such places, while these are external tools and you should take care of their appropriate configuration.
¹² Scala Pattern Matching, Haskell Pattern Matching.
¹³ JEP 361.
¹⁴ JEP 305 and JEP 375.

Instrumenting Software with Micrometer

Jedrzej Serwa — Mon, 20 Apr 2020 08:34:21 +0000

In recent years many of our clients have embraced microservices. This architectural pattern employs software services that are more fine-grained and heterogeneous than their monolithic predecessors and aim to bring productivity and performance gains by allowing teams to work in parallel and systems to scale horizontally and, in doing so, enable faster feature delivery.

There’s no such thing as a free lunch though – microservices come at an operational cost. In the world of the monolith tracking down a production issue may well be as straightforward as tailing and grepping a single log file. In the world of microservices we may have 10-100s of distributed software services, running containers – how can engineers build a picture of what’s happening in the system? How can they carry out root cause analysis to identify performance bottlenecks?

The answer is by instrumenting the services and exposing meaningful metrics.

Metrics

In the abstract, a metric can be described as a unit of length – any numerical value characterising the software that can be easily compared with other numerical values within the same category. Examples include number of cache hits, time to invoke certain flow/method or, in the context of JVM-based solutions Garbage Collector pause time.

There are many existing approaches to monitoring metrics, with differences in the way metrics are collected (push or pull), differences in architecture (client-side or server-side), as well as differences in metric transport and storage mechanism. Despite these differences, they all aim to solve the same problem and, as developers, we are challenged with making technology choices in a fast-changing monitoring space.

To decouple the software we build from that of the systems we use to instrument it is to make use of an API. Micrometer is a library that exposes such an API and one that we’ve had great success using.

Micrometer

Micrometer is a library that acts as a facade for monitoring systems. As it says on the website, “Think SLF4J, but for metrics”. It provides a unified API to most popular monitoring systems, allowing you to instrument your JVM-based application code without vendor lock-in.

Here’s a selection of the systems Micrometer supports, there are a bunch more listed in the official documentation.

System	Type
Atlas	In-memory dimensional time series database
Datadog	Dimensional time-series SaaS
Elastic	Search and analytics platform
Ganglia	Hierarchical metrics system
Graphite	Hierarchical metrics system
InfluxDB	Time series database
Prometheus	In-memory dimensional time series database
Wavefront	SaaS monitoring platform system

In addition, Micrometer is now included as part of Spring Boot Actuator 2.x so it is already a part of the well known and widely used Spring stack. It provides four main methods of measurements:

Timer – measure short-duration latencies and the frequency of such events
Distribution Summary – track the distribution of non-temporal event attribute
Counter – increment a value by a fixed amount
Gauge – monitor things with natural upper bounds (e.g. CPU load)

I’m not going into the details of what these are used for exactly, since authors of Micrometer already did a great in the documentation.

Within Spring Boot Actuator 2.x, as a part of Spring autoconfiguration, Micrometer gets integrated with applications by providing a set of Beans that can be further used for monitoring purposes. For example, if we want to monitor and measure the time taken for certain methods to end, it’s as simple as annotating the Spring managed Bean method. Alternatively we have the option of using the Micrometer Timer API. In a simplified way implementation will look as follows:

Annotation based

1. @Timed(value = "add-book-flow")
2. public BookDTO addBook(BookDTO bookDTO) {
3.     validate(bookDTO);
4.     
5.     Book book = fromDTO(bookDTO);
6.
7.     return saveBook(book);
8. }

API based

1. public BookDTO addBook(BookDTO bookDTO) {
2.     return timer.record(() -> {
3.         validate(bookDTO);
4.
5.         Book book = fromDTO(bookDTO);
6.
7.         return saveBook(book);
8.     });
9. }

Conveniently, Micrometer also provides a legacy bridge that can be used to integrate older Spring 1.5 applications with Micrometer library.

Visualisation

Assuming that we successfully integrated with a metrics collecting system and exposed desired data the question arises as to what we can do with the data. The most popular answer to that question will likely be Grafana. Grafana is a powerful visualisation and alerting system for metrics. It ships with predefined dashboards and supports over thirty metric data sources. Users can also configure custom dashboards like the one shown below.

I strongly encourage you to visit Grafana demo page – where you can experiment with a running instance and explore the full potential of Grafana dashboards.

Putting it all together

So far we have identified the building blocks of our metrics collecting system. Combining them together allows us to create a system to collect, store and track crucial data during the application runtime, as well as to alert us to undesirable system behaviour.

A sample architecture for a microservice with monitoring is as follows:

For the application we used Spring Boot 2.x along with Spring Boot Actuator and Micrometer. Within the application we have defined metrics that are crucial for our domain such as time to invoke important business methods as well as JVM and response time metrics.

For monitoring we decided to use Prometheus so we included the Micrometer Prometheus registry client dependency in the microservice itself so that Spring can easily detect our client and connect it to Prometheus.

The last element is Grafana. It’s where we query and visualise data stored in Prometheus. We can fetch the metrics and create self-describing dashboards that can be used to easily monitor the application runtime. In addition we can define alerting that can message us via notification providers when some of our metric values change in an undesirable way.

Sample application with Monitoring

Summary

Microservices have made it more difficult to get a coherent view of the state and health of applications. The building blocks presented, in combination with well defined measurement criteria, help us build microservice-based software systems that can be readily monitored, diagnosed, and maintained. The combination of using Spring Boot and Micrometer gives us the flexibility to use a variety of monitoring systems without having to fundamentally change our architecture, while Grafana provides us with a powerful monitoring system.

If you’d like to experiment with the code described, our colleague Jędrzej Serwa has put together a sample repo on GitHub. Feedback welcome!