The goal of this post is to examine whether the cost-benefit trade-off stacks up for functional programming in Java across 3 dimensions

Correctness

Performance

& Complexity

Correctness

An informal definition of correctness is :

an algorithm is correct if it is error free.

In Java we could define hierarchy of errors as something like

Compile time errors : errors the Java compiler catches and alerts us about.

Runtime errors : Runtime exceptions and errors the Java runtime (hopefully) alerts us about.

Logic errors : potentially more insidious errors that provide no explicit feedback that something has gone wrong.

As we move through this hierarchy of errors, the maximum potential cost of an error explodes upwards at each stage. If I introduce a compile time error, I really should only inconvenience myself. With proper processes in place, I will find and fix the problem on my development branch before it is committed to master.

If I cause a Runtime error to appear on our codebase, if we have good unit tests, I may be lucky enough to be alerted to the problem before it gets merged into master. If we are not so well prepared (and lucky!) we may instead get a call late at night when the effected code path is triggered and our monitoring and alerting systems kick in and do their jobs.

With logic errors the situation is worse again, the compiler won’t alert us if we have misunderstood a requirement and no exceptions may be thrown at runtime. Our software could run, incorrectly, for years, giving or storing incorrect data costing our employers or their customers money.

Functional programming (in Java)

As we shall see functional programming imposes a cost (often at the nexus of a performance / complexity trade off), and the main benefit of FP in Java is the ability to improve application correctness by pushing most (if not all) errors that may occur in the Runtime Error Tier down a level to the Compile time Error tier where they are easy to spot and cheap to fix.

Let’s examine functional and imperative Collections

And discover what the trade offs are between application correctness, performance and complexity.

Traditional mutable Collections

The JDK Collections are standard imperative collections that are (or can be) mutated in place. It’s generally easier to implement Mutable Collections (e.g. see the stub for a mutable ArrayList with set method below.

In addition to being straightforward to implement, they also set the gold standard for performance. While it’s possible for functional data structures to approach the performance of imperative ones, this often comes at a cost of increased complexity of implementation.

If we were to summarize the characteristics of mutable Collections in terms of performance and complexity it would look something like this :-

So far — so good! But… You can probably guess that they are going to fall down in terms of application correctness (or otherwise there wouldn’t be much point in this blog post!). Let’s take a look at how these are often used in practice..

This type of method signature is very common in Java applications. It consists of

void return type

mutable input parameters

The void return type indicates that this method is performing a side-effect, hopefully this is limited to some I/O operation, but as we are also providing mutable input parameters we can’t be sure that the scope of this method is limited to I/O. (If we allow the mutation of global state held in static variables we can be even less confident about the nature of this method).

In terms of our List of user ids, because it is mutable we can never really be sure it is unchanged after passing it as a method parameter. In Java it is not uncommon (unfortunately) for methods with signatures like the one above to mutate it’s input parameter 🤮.

With the implementation above we see an I/O operation and a call to a method that in all likelihood has a similar method signature. If we want to be sure that our input parameter hasn’t changed, we’d need to check that method too. It really is mutable turtles all the way down🐢!

We could take a risk and write a method that makes use of our List without making a costly defensive copy first. In the listAndPersistUsers method below we extract the active user ids from the current context and persist them before returning them to the caller for further processing.

But, can we rely on this?

Callers of listAndPersistUsers have to assume that none of the child calls recieving the mutable list of active users change it in any way.

Can we rely on this now and in the future?

At some point in the future we may decide to always persist a Special Admin user, by adding it to our mutable list we also return it to clients of listAndPersistUsers. If this causes problems for them, there is nothing the type system and the compiler can do to help us here.

If we have introduced a bug we are relying on having good unit tests to catch it (in a piece of code that is also performing I/O, so expect the unit tests to be gnarly knot of mocking infrastructure and occasional asserts).

With some additional insight, we can revisit our classification of mutable datastructures. While they are often the easiest to implement, they push uncertainty and complexity down into our application code! Perhaps we should split our complexity classification in two?

complexity of implementation — which remains simple

complexity of client code— which as we have seen can start to become difficult to reason about.

Are JDK Unmodifiable datastructures any better?

These are collections that expose an unmodifiable view into a mutable collection, and if anything, they are worse! Let’s start by looking at the characteristics they share with mutable collections :

We’ve already broken out the performance classification into two aspects (only one of which will be good like mutable collections)

read (or access) performance : remains identical (almost) to mutable collections

write (append / update) performance : well, let’s see

It’s pretty easy to create an unmodifiable collection, and we can modify our current code to pass one in to saveAndLogActiveUsers

But this has no compile time impact on what code is permissable in saveAndLogActiveUsers (but it does have a runtime one).

We can still add our Special Admin, to a supposedly immutable collection and our application will still compile! When we run this code however..

We get an UnsupportedOperationException, and we’ve swapped an insidious logic error for a slightly less insidious runtime one. Perhaps, we should be thankful for small mercies?, But if enough of these sneak into application the probability of us being rudely awakened out-of-hours by our boss with a production issue rapidly approaches 1!

Not only does this introduce the possibility of a new set of exceptions being thrown, the fact that these immutable views also masquerade as mutable ones (and are accepted as input into methods that take mutable collections) makes our code even harder to reason about than it was before.

In order to ensure the correct behaviour of our application once we have introduce unmodidfiable views, we should make a defensive copy of our collection before making changes to it.

Time complexity

But what will this do to performance?

Because, in order to change an unmodifiable view we need to perform a copy-on-write operation performance really suffers as Collection sizes increase. What this means is — to make any change we must make a defensive copy of the existing view into a new mutable collection, make the change and create a new replacement unmodiable view. The performance of modification operations scale linearly with the size of the collection! By contrast changing a single entry in an ArrayList takes the same amount of time regardless of its size!

That leaves us with a set of characteristics that looks like this -

But there is more — and it gets worse! Unmodifiable Views are just wrappers over independently modifiable mutable datastructures. As the underlying datasstructure can still change we can’t rely on Unmodifiable Views to keep our data (and it’s meaning) in tact! Let’s take a look at an example :

We could modify listAndPersistUsers to make the call to saveAndLogActiveUsers on a different thread.

Although we are passing in an Unmodifiable View of the currently active users into saveAndLogActiveUsers, this is not actually immutable.

The mutable list of currently active users still exists, and in the code above, we retain and return a reference to it

If some client code were to change the returned list this would result in a race condition — saveAndLogActiveUsers expects the full list of active users to be past to it, and despite the fact that we pass a List to it we may feel is immutable — it is still possible to change it. Above we remove the first active user from the List and as the Unmodifiable View is a proxy into the List it is gone from there too!

Unmodifiable Collections in the JDK really are a very poor way to implement immutability in your applications introducing needless additional complexity and performance cost. There must be better alternatives..

Immutable Collections (copy-on-write a la Guava)

We could define immutable collections as simply collections that can’t be changed. This would include two distinct types of immutability

1. Datastructures with copy-on-write semantics — that copy the entire datastructure when making a change
2. So-called persistent data structures that utilize shared portions of memory to make updates more efficient.

#1 above is by far the most common type of immutable collection in Java, largely thanks to the immense popularity of Google’s Guava library.

The chief benefit of Immutable copy-on-write collections that continue to implement the mutable JDK collection interfaces over the awful Unmodifiable Views is that they remove the loose reference to the underlying mutable collection. This leaves their core characteristics as looking something like this :

And we can see this in action if we plug Guava into our listAndPersistUsers method :

Because ImmutableList implements List, this is all we need do. Of course if saveAndLogActiveUsers still adds the Special Admin directly to the input parameter we will be in trouble. Because Guava’s ImmutableList implements List we can still attempt to add elements to an immutable Collection and the compiler will not stop us.

Running this code will still result in a nasty Exception.

It would be nice if the compiler could help us out here, and unlike with Unmodifiable Collections Guava does provide us with a specific type ImmutableList.

When we replace the input parameter to saveAndLogActiveUsers the buggy code that attempts to add a new element to that code still compiles! (Albeit with a warning that add has been deprecated on ImmutableList — again we should probably be thankful for small mercies). Running this code will result in the same Exception as before.

We can fix this error (when we are lucky enough to spot it) via a defensive copy-on-write operation. Guava provides us with a nice fluent interface to do this, but the performance impact is the same :

The cost of this operation is going to scale linearly with the size of the collection.

Immutable and Unmodifiable : the risks

We could summarize the downsides of JDK Unmodifiable Views and Guava style Immutable Collections as follows

Reduced compile time safety due to

1. Increased complexity due to the availability of illegal operations on the API
2. Increased complexity due to the ability to masquerade as a completely different and incompatible type (mutable v immutable)

Significantly Reduced runtime performance due to

1. Poor scaling characteristics of modification operations (add, delete, set)

To chart away out of this morass, to unlock the chief benefits of typed functional programming in terms of enhanced compile time safety and roughly comparable performance to imperative & mutable alternatives we need to turn to Chris Okasaki and his seminal paper on Purely Functional Data Structures.

Persistent Collections

Persistent collections are immutable collections that leveraged shared memory a la Chris Okasaki to enable more efficient modification operations ideally approaching the scaling characteristics of their imperative analogues.

Bitmapped Vector Trie an efficient Persistent ArrayList

For persistent ArrayList type structures the Bitmapped Vector Trie, pioneered by Rich Hickey in Clojure offers reasonably close performance to it’s imperative cousin.

At it’s core the Bitmapped Vector Trie is an array of arrays, indexed by groups of bits in a single bitmap index.

Daniel Spiewak walks through one implementation approach in his rather excellent talk “Extreme Cleverness: Functional Data Structures in Scala”, and this was the approach we took when implementing a functional ArrayList (or Vector) in the functional library for Java — Cyclops.

There are some interesting features of this particular approach which I will attempt to cover here. First the Array of Arrays used is sized to the size of the Vector. If the Vector has a less than 32 elements then a 1D “Array-of-arrays” is used, I’ve put Array-of-arrays in quotes as a 1D Array-of-arrays is best implemented as a single Array. A small persistent Vector implemented in this way will have identical look up charcteristics as a standard mutable array (the implementations being virtually identical). The larger the array becomes (as per Guava style copy-on-write collections and JDK Unmodifiable views) the slower modification operations become. But we cap the max array size at 32 elements. This means our most expensive individual copy operation copies 32 entries. Once our 1D array exceeds 32 elements we switch to a 2D array structure. And we’ll need to figure out way to locate each element within that structure.

Indexing a Bitmapped Vector Trie

For a single Array of 32 elements we can use an int to capture the index, and in practice only the first 5 bits are needed.

The index for a 1D Bitmapped Vector Trie looks just like it would for a stanadard Java Array or ArrayList.

But once we move on to a 2D array, we need an index into the root level (or parent array), to extract the active node (or child array) that contains the data we need.

Let’s visualize a numeric sequence from 0 stored in a 2D Array of Arrays sized at 32 elements.

In the truncated diagram above the top level Array contains other Arrays, the child Arrays contain Integers. At position A in the root we have a child array containing 0–31, at position 2 we have a child array containing 32–63 (and so on).

To access any element we need two numbers — the index in the root array, and the index in the child array. As each array as a max size of 32 elements we can store each index in 5 bits, or both together in 10 bits of a single integer. To extract each index we first shift by 5 (if needed) and then mask by anding with 31 (if needed). As our list get bigger we will scale from 2D to 3D, from 3D to 4D and so on.

Performance

Because we have to walk the multi-dimensional array structure retrieval and modification times scale logarthimically with the size of the collection. For small collections, stored in a standard array read performance should even be as fast as for JDK mutable collections! For larger collections modifications should perform orders of magnitude better than for JDK Unmodifiable Views and Guava Immutable collections!

If we run a benchmark for get operations on small (typical most of the time) lists we can see performance is pretty much identical across all 3 types.

In fact we won’t see differences until the sizes are a lot larger. By the time we are accessing Strings from a List with 10k elements the overhead of the indexing and nested array lookup becomes apparent (note these times are in micro-seconds)

But as expected the overhead of mutating large copy-on-write Immutable Collections is extortionate : (note these times are in milli-seconds!!)

Appending to Persistent Vector performs better on average then even a mutable ArrayList because the occasional overhead of having to copy a full (and large) array into an even larger one is avoided entirely.

To put things in perspective the access operation on a very large Persistent Vector is much faster than the relatively performant append operation on a similarly large Vector.

Unlike copy-on-write Immutable datastructures, Persistent shared-memory datastructures in the purely functional style have great all round performance characteristics.

Correctness

Now that we have found away to build immutable datastructures with sound performance, it would be good to ensure that we also cleanly and completely solve the real challenges with imperative mutable datastructures. We should aim to make our code easier to reason about. The core design principal to follow here is to make illegal states unrepresentable in our code.

If we bought a toy for a child that broke when we pulled it’s levers or pressed it’s buttons, we’d consider it exceptionally bad design. We would probably think twice about purchasing from the company again. But, we make heavy use development kits and libraries that will blow up our apps when we call public methods on their APIs. We make heavy use of these libraries in the code that powers our financial markets, our civil infrastructure, our enterprise software, our consumer gadgets, our self-driving cars and our healthcare projects. But it really shouldn’t be this way.

The APIs of our libraries should guide is as developers along the right path and not into states from which the only way out is to throw an Exception. For Immutable Collections this means they can’t implement or extend java.util.Collection. Why not?

If our Persistent Vector implements List we would be forced to implement methods such as add. Look at the method signature — the return type is a boolean, this forces us to make no change or mutate in place. We can either fail silently, and implement an alternative method to add that returns a new Vector — or follow the direction of the spec and throw that nasty UnsupportedOperationException : a Hobson’s choice. Better to start from scratch and create a new API which prevents developers from ever getting the Vector into an exceptional state!

Instead in Cyclops we created a ‘plus’ method instead, this returns a new Vector with the new element efficiently added.

There is no legacy add method. It is just not possible to write code that will cause it to throw an Exception at runtime.

And — we can always rely on listAndPersistUsers returning only (and all of) the currently active users no matter how deep we pass our Vector to other methods before returning it. Our code becomes much easier to reason about.

Not just Collections

If we make all our datastructures efficiently immutable with safe, with helpful and guiding APIs our application code will become much more easy to reason about and much less likely to fall prey to runtime Exceptions.

Within something as simple as a List (or Vector) there are many places where we would traditionally default to throwing Exceptions — when attempting to retrieve an element at an out-of-bounds index for example.

Running this traditional imperative Java code results in another nasty runtime Exception

A better an alternative to throwing an IndexOutOfBoundsException, as shown in the example below is to return an Optional or Option type.

But why not Optional?

Although it is inspired by functional ideas, the JDK’s Optional type does not adhere to the pinciple of making illegal states unrepresentable :-

Running this code also results in a nasty runtime error

So for Cyclops we had to define our own more principled implementation

The key goal is to switch our application call-stack from a messy hierarchy of mutable turtles all the way down, to a safe principled stack of immutable datastructures — simplifying our code.

Because life is complicated enough

Performant, safe immutable datastructures often don’t come for free. The nested multi-dimensional arrays of a Persistent Vector certainly gave a more complex view in the debugger than traditional simple mutable ArrayLists.

The overall characteristics for Persistent Collections looks like this :- shared memory implementation leading to decent performance, and principled implementations will simplify client and help drive application correctness.

Is functional programming in Java worth it?

By adopting functional techniques and principles you introduce a learning curve for your team (e.g. See the standardized ladder of Functional Programming - http://lambdaconf.us/downloads/documents/lambdaconf_slfp.pdf). Although you don’t have to climb high to reap significant benefits in terms of improvements in application correctness and the ability to simplify your code. Immutable datastructures and pure functions are enough to get you started. Just be sure to choose wisely and select those that will help ensure your application is performant and correct!

This weeks functional and reactive Java blogs and talks!

A roundup of the last 2 weeks blogs and talks (with the winding down of conference season the throughput of blogs and talks has fallen slightly).

Links

Full Stack Reactive Java with Project Reactor and Spring Boot by Mark Heckler

Reactive Java a new asynchronous database access API by Kuassi Mensah

From Functional to imperative programming by Francisco Alvarez

Functional Java by Example | Part 6 — Functions as Parameters by Ted Vinke

The Functional Style — Part 7 by Richard Wild

Spring, Kotlin and the Functional Way by Sébastien Deleuze

Java Functional Retry with resilience4j-retry by mahmoud romeh

Object Oriented vs Functional by Tonino Lucca

Powerful, extensible code with Tagless Final in … Java by john mcclean

Embeds

• Powerful, extensible code with Tagless Final in … Java!
• Functional Java by Example | Part 6 - Functions as Parameters
• Spring, Kotlin and the Functional Way
• The Functional Style - Part 7

Defining Mini-DSLs

Much like the Free Monad, Tagless Final allows us to define mini-DSLs and apply different interpreters to them. Unlike the Free Monad, Tagless Final is (relatively) simple.

A high level overview of the process

We need to define the operations available in our mini-language (in Tagless Final parlance — the Algebra, in the Java-world an Interface with some default methods) — methods such as createOrder, deleteOrder, listOrders go here.

We define our programs abstractly in terms of the Algebra. E.g. createOrder -> saveOrder -> listOrders

We provide implementations of our i̶n̶t̶e̶r̶f̶a̶c̶e̶ (sorry I mean Algebra).

So far, so Object Oriented.

A higher level of abstraction (or generality)

The key difference from standard Java is that the i̶n̶t̶e̶r̶f̶a̶c̶e (Algebra) is defined at a higher level of abstraction. Using the library KindedJ we can define a higher order generic type something like this

Hk<W,Order> createOrder(User user, OrderData data);

Hk is an interface that higher order types (such as the Monadic types in Cyclops) can implement, and W is the ‘witness’ type that let’s know which higher order type we are working with. More concretely a Cyclops Option would look something like this

Hk<option,Order> option = Option.some(order);

The Monad ‘pattern’

The nice thing about Monads is they all implement the same general suite of methods (of / map / flatMap and so on) that all behave in predictable ways. This means that if we define our programs to work with Monads, and define our Algebra in a generic manner so that the concrete Monadic type is pluggable — we can reuse the same Algebra and ‘program’ definition with many different Monadic datastructures. In fact we aren’t even constrained to using Monads (but that is for another article!)

Monads all do something different

Option : represents Optionality

Future : represents an asynchronously calculated value

Vector : represents something that can be absent, have one value or many values

Try : represents something that can fail

And so on. By defining our interfaces in a very general way, we can easily extend our application by pluggin in the behaviour we need by switching Monad types. As we shall see later, we can also mix monad types and stack them up too!

Tagless final v Free

A previous blog series dived into the details of creating mini-DSLs using the Free Monad in Java — it may be instructive to compare and contrast the approaches as Tagless Final appears a lot more straightforward.

DSLs with the Free Monad in Java 8 : Part I

Simulating Higher Kinded Types in Java

DSLs with the Free Monad in Java 8 : Part II

Let’s move on to an example

To start with we will convert the simple Account credit and debit example from Chapter 1 of Debasish (দেবাশিস্) Ghosh’s awesome Functional and Reactive Domain Modeling

The first step is to define our algebra or mini language, we could sketch this out as something like the ability to debit or credit an bank account.

AccountAlgebra{

    debit(Account account, double amount);
    credit(Account account, double amount);

}

We might define an interface for this in traditional Java something like this

interface AccountAlgebra{

    Account debit(Account account, double amount) throws Exception;
    Account credit(Account account, double amount) throws Exception;

}

But if you have been following the Dysfunctional Programming in Java series then you’ll know that throwing Exceptions isn’t good functional practice. A better idea would be to return an Either that captures the error as it’s left type value, or even an Option that is empty if debiting or crediting failed.

E.g. using Either

interface AccountAlgebra{

    Either<AccError,Account> debit(Account account, double amount);
    Either<AccError,Account> credit(Account account, double amount);

}

Using Option

interface AccountAlgebra{

    Option<Account> debit(Account account, double amount);
    Option<Account> credit(Account account, double amount);

}

We live in a reactive world and perhaps we should consider debit & credit should be executed asynchronously, we could return a Future here instead.

interface AccountAlgebra{

    Future<Account> debit(Account account, double amount);
    Future<Account> credit(Account account, double amount);

}

One of the nice things about tagless final is.. we don’t have to choose!

A higher level of Abstraction

We simply define AccountAlgebra at a higher level of abstraction with KindedJ :-

interface AccountAlgebra<W>{

    Hk<W,Account> debit(Account account, double amount);
    Hk<W,Account> credit(Account account, double amount);

}

I’m using Cyclops, which defines an interface Higher that extends Hk from KindedJ and adds some handy conversion methods.

interface AccountAlgebra<W>{

    Higher<W,Account> debit(Account account, double amount);
    Higher<W,Account> credit(Account account, double amount);

}

The type parameter W in the above example represents the monad type which we can plug in at compile time. If we want to use the IO monad to perform the actions asynchronously we define an implementation (or interpreter) like so :-

class AccountIO implements AccountAlgebra<io> {
    
    Higher<io, Account> debit(Account account, double amount) {
        return IO.of(()->account,exec)
                 .map(a->a.debit(amount));
    }

    Higher<io, Account> credit(Account account, double amount) {
        return IO.of(()->account,exec)
                 .map(a->a.credit(amount));
    }
}

Constructing a mini-program

With the operators available to us we could construct a simple program to transfer money from one account to another.

class TransferManager {

     Account from;  
     Account to;

}

We should also pass in our Algebra (or interface that defines the allowable operations)

class TransferManager<W>{

     Account from;  
     Account to;
     AccountAlgebra<W> acountService;

}

We’re going to be working with Monads. It’s not normally possible to define an generic Interface for working with Monads in Java (as we can’t directly express higher kinded types — or generic type parameters that themselves accept a type parameter), but we can do it indirectly thanks to KindedJ. Cyclops defines such a higher kinded Monad interface for us.

class TransferManager<W>{

     Account from;  
     Account to;
     AccountAlgebra<W> acountService;
     Monad<W> monad;

}

Now we can leverage our AccountAlgebra with any Monad type (we only need to implement the Monad interface!).

Defining our transfer method

We can define a method to transfer money from each of these accounts

public ??? transfer(double amount)

Inside transfer we can compose the building blocks of our mini-language (defined in AccountAlgebra) to transfer between accounts.

given an amount

debit account ‘from’

credit account ‘to’

return both accounts.

Because we are working with monads, we could call the of (or unit) method on our Monad Interface to create a instance which contains amount, then we can compose calls to AccountAlgebra::credit and AccountAlgebra::debit via flatMap.

monad.flatMap(monad.of(amount), amount-> {

  return monad.flatMap(accountService.credit(to,amount),account-> {

                return accountService.debit(from,amount);

      });
});

Pretty ugly!

But this is a standard pattern. We can easily put together a generic class that will orchestrate these calls for us and allow us to clean up our code (in Cyclops this is the Do builder)

Do.forEach(monad)
        ._of(amount)
        .__(this::debitFrom)
        .__(_1(this::creditTo))
        .yield(__23(Tuple::tuple))

To get a nice fluent flow with method references all we need to do is define a couple of helper methods

private Higher<W,Account> debitFrom(double amount){
    return accountService.debit(from,amount);
}
private Higher<W,Account> creditTo(double amount){
    return accountService.credit(to,amount);
}

When we construct our program object all we need to do is pass in an instance of our AccountIO implementation of AccountAlgebra and the IO Monad Instance. If we want to change to a blocking implementation we could plugin an Option based implementation of the Algebra and it’s Monad instance (for example).

Combining Monads

It’s pretty straight forward to combine different monad types also.

Most Tagless final blogs seem to add some logging at this point (and I don’t really see any reason to break with tradition). So let’s define the algebra for our logging DSL.

LogAlgebra {

    void info(String message);
    void error(String message);

}

Which can translate into Tagless Final form

LogAlgebra<W> {

    Higher<W,Void> info(String message);
    Higher<W, Void> error(String message);

}

And given a LogAlgebra instance, and an AccountAlgebra instance

LogAlgebra<W> logService;
AccountAlgebra<W> accountService;

We can define a method to log account some account details

Higher<W, Void> logBalance(Account a) {
    return  logService.info("Account balance " + a.getBalance());
}

And we can then plug this into our for comprehension

Do.forEach(monad)
  ._of(amount)
  .__(this::debitFrom)
  .__(_2(this::logBalance))
  .__(__1(this::creditTo))
  .__(___4(this::logBalance))
  .yield(____24(Tuple::tuple))

Because we have the same type parameter (which determines the monad type) in both the Log and Account Algebras, everything composes together quite nicely.

LogAlgebra<W> logService;
AccountAlgebra<W> accountService;

But what if they were different?

If the Monad types (as determined by the type parameters specified) were W1 and W2 rather than just W for both :-

LogAlgebra<W1> logService;
AccountAlgebra<W2> accountService;

This is still no problem! We just need to make sure we do a conversion back to one of the types (in this case W2). A NaturalTransformation is an interface for converting between two different monadic structures holding the same type :-

@FunctionalInterface
interface NaturalTransformation<W1,W2>{

    <T> Higher<W2, T> apply(Higher<W1, T> a) ;
}

We pass in Monad <W1,T> and get back Monad<W2,T>.

A logging algebra

Let’s define a blocking LogAlgebra iterpreter that uses the Identity Monad (rather than IO or another non-blocking alternative)

LogID implements LogAlgebra<identity>{ 

Higher<identity, Void> info(String message) {
  return Identity.of(message).peek(logger::info);
}

@Override
Higher<identity, Void> error(String message) {
  return Identity.of(message).peek(logger::error);
}

W1 is the Monad type we want to convert from, and W2 is the Monad type we want to convert to. E.g. to convert between an Identity and an IO the NaturalTransformation would look like this

class IdentityToIO implements NaturalTransformation<identity, io> {

    public <T> IO<T> apply(Higher<identity, T> a) {
        return a.convert(Identity::narrowK)
                .to(IO::sync);
    }
}

Using NaturalTransformations to convert between higher kinded Monads is straight forward as well

NaturalTransformation<W2,W1> natTrans;

Higher<W1, Void> logBalance(Account a) {
    return  logService.info("Account balance " + a.getBalance())
                      .convert(natTrans.asFunction());
}

Which leaves our program — pretty much identical to how it was before

Do.forEach(monad)
  ._of(amount)
  .__(this::debitFrom)
  .__(_2(this::logBalance))
  .__(__1(this::creditTo))
  .__(___4(this::logBalance))
  .yield(____24(Tuple::tuple))

Stacking Monads

It’s possible to stack algebras and interpreters, plugging in different Monads to different effect at each layer. Let’s add in a data store and use to store account balances. In plain Java the Store Algebra might look something like this :-

StoreAlgebra<K,V> {
    Option<V> get(K key);
    void put(K key, V value);
}

With the Tagless Final encoding it becomes :-

StoreAlgebra<W,K,V> {
    Higher<W, Option<V>> get(K key);
    Higher<W, Void> put(K key, V value);
}

We can modify our AccountAlgebra to allow us to make use of the Store, first by making is available somehow on the algebra (the hacky but easy thing to do is just to add a couple of methods directly to the interface definition).

AccountAlgebra<W> {

    StoreAlgebra<W,Long,Account> store();
    Do<W> forEach();

    Higher<W,Option<Account>> debit(Account account, double amount)
    Higher<W, Option<Account>> credit(Account account, double amount);

}

We can even plugin a default implementation that makes use of Store Algebra

AccountAlgebra<W> {

 StoreAlgebra<W,Long,Account> store();
 Do<W> forEach();

Higher<W,Option<Account>> debit(long id, double amount){
 return forEach().__(store().get(id))
                 .__(acc -> acc.debit(amount))
                 .__(_1(a -> store().put(a.getId(),  a)))
                 .yield_1((a, b) -> a);

  }
    
 Higher<W, Option<Account>> credit(long id, double amount){
  return forEach().__(store().get(id))
                  .__(acc -> acc.credit(amount))
                  ._1(acc -> store().put(acc.getId(),  acc))
                  .yield_1((a, b) -> a);
 }

It’s a bit messier this time as we haven’t defined helper methods to use as method references.

Our program code remains very simple (with the logging removed)

Do.forEach(monad)
  ._of(amount)
  .__(this::debitFrom)
  .__(_1(this::creditTo))
  .yield(__23(Tuple::tuple))

Cyclops : a higher kinded functional library for Java

If you want to try this out at home, import the cyclops library for functional programming in Java and play about with the examples, all the code is on the github repo.

Maven

<dependency>
 <groupId>com.oath.cyclops</groupId>
 <artifactId>cyclops-pure</artifactId>
 <version>10.1.0</version>     
</dependency>

Gradle

compile group: 'com.oath.cyclops', name: 'cyclops', version: '10.1.0'

This weeks functional and reactive Java blogs and talks!

A bumper round up of blogs and talks on Functional Programming & Reactive Programming in Java.

Functional and Reactive Blogs and Talks

Lambdas are not functional programming by John McClean

OOP v̶s̶ and FP by Mario Fusco

Functional architecture: a definition by Mark Seemann

FP vs OOP: Choose Two by Brian Goetz

Is Functional Programming worth it? by John McClean

Functional Programming Patterns With Java 8 by Victor Rentea

Introduction to AWS SDK v2 for Java by Maciej Walkowiak

Reactive Java For the Realtime : video and slides by Trayan Iliev

Dysfunctional programming in Java 7 : Immutable Collections by john mcclean

Project Loom Fibre and Continuations on the JVM by Alan Bateman

Real-world Reactive Programming in Java: The Definitive Guide by Erwin

Embeds — watch the talks right here!

• Lambdas are not functional programming
• Functional architecture: a definition

Functional Programming Patterns With Java 8 - DZone Java

Dysfunctional programming in Java 7 : Immutable Collections

Interesting blog post missing? Let me know johnmcclean_ie on Twitter

Just because you are using Lambda expressions, does not mean you are doing functional programming.

Lambda expressions in Java are simply a less verbose way of creating (slightly constrained) Objects and as such the most likely outcome of adopting Lambda’s without a good understanding of core functional concepts is gnarly, twisted, hard to follow, obfuscated imperative Object Oriented code with a nice concise syntax. Yes, we could write exactly the same dodgy code in a more verbose way by creating individual classes and lambdas.

Conversely, even when writing actual functional code in Java we could write the same code with verbose Class definitions and Objects as we can with concise lambdas.

Seek help

For those that disagree passionately with my first sentence, and are busy searching for the (strangely hard to find) reply button on Medium (“well actually.. my team have been doing fp in Java“) — ⛔️stop!⛔️. If for some crazy reason you are doing functional programming in Java, instead of reading my rants you probably should have a good long hard think about your language choices.

Just what the hell is functional programming then?

A lot of people in Java-land are trying to mix traditional imperative Java code and functional-ish code, with varying degrees of success. Java is not a functional language, it is fundamentally an Object Oriented language that allows us to adopt some functional concepts in so far as we enforce their correct implementation through developer discipline. Unlike in Haskell, Idris, Ocaml (and even Scala) the compiler alone won’t save us.

If we are going adopt functional principles to mix Object Oriented and Functional Programming successfully in Java, we had better know what they are. What are the core features of functional languages?

Is it laziness?

Streams in Java are lazy (although Optional and CompletableFuture aren’t). Perhaps laziness is a core tenet of fp, and to be truly functional we also must be lazy. Haskell is lazy language, but unfortunately Ocaml, Idris and ML (to name but 3) are strict (eager) by default. I don’t think anyone would argue that Idris is not a functional language.

Laziness and performance

Laziness can improve performance, after all the most performant code is code not executed. In the simple example below we will stop processing once we have loaded 10 good records from somewhere (rather than load all records first and then filter them).

Stream.generate(this::loadFromSomewhere)
      .filter(this::identifyStuffWeWant)
      .limit(10)
      .collect(Collectors.toList());

Whether this is a real performance benefit or not is debatable, we can always couple our filtering and limit logic with our loading logic in some manner even when processing the data eagerly to avoid doing excess work (we are arguably getting cleaner code not better performance with laziness). The Haskell wiki has this to say on laziness and performance

Laziness can be a useful tool for improving performance, but more often than not it reduces performance by adding a constant overhead to everything. Because of laziness, the compiler can’t evaluate a function argument and pass the value to the function, it has to record the expression in the heap in a suspension (or thunk) in case it is evaluated later. Storing and evaluating suspensions is costly, and unnecessary if the expression was going to be evaluated anyway.

And since at least 2015 it’s been possible to configure Haskell to use strict evaluation by default.

Laziness is a really cool feature of functional languages that we can leverage to our advantage in Java, but I don’t believe it is one of the critical traits of functional languages from which their primary benefits derive.

Is it functional composition?

This is definitely a big part of it. All of the functional languages previously mentioned have functions as first class citizens and once we have that we can chain function calls together by matching the types.

E.g. from A functional approach to dependency injection in Java we can compose a function that accepts a DAO and returns a String with another that accepts a String and returns a String by matching the output with the first, with the input of the second.

public Function<DAO,String> loadName(long id);

loadName(10l).andThen(name->"User's name is "+ name);

Function<DAO,String> sentence = loadName(10l).andThen(name->"User's name is "+ name);

System.out.println(sentence.apply(dao));

The ability to compose functions like this, opens the door to higher order functions and by extension to implementations of concepts / patterns from category theory like Monads and Functors.

But all of this only works if the functions are pure -> that is that they are not mutating or impacting state outside of the function. Which brings us to the next potential core trait.

Is it immutability?

This is also massively important for functional programming. All of the aforementioned languages encourage immutability by default and eschew (to varying degrees) mutability altogether. In the Java ecosystem most of our core datastructures (in the JDK itself) are mutable, and there is limited native support for creating and using immutable objects.

Hoverflies mimic the colouring of wasps to ward of predators. If you are mixing Lambda’s with mutable state, you are creating imperative hoverflies masquerading as functional code. The conciseness of the syntax may well hide implementations that are simply more complex than the typical OO alternatives and miss all of the advantages of their FP analogs.

So yes, immutability matters a lot. In fact in Java this is one of the first places I would start (here are two primers : Dysfunctional programming in Java 2 : Immutability and Dysfunctional programming in Java 7 : Immutable Collections).

Is it the type system?

Grappling with a more powerful type system that enforces that functions are pure is perhaps one the biggest hurdles OO developers have to jump in making the leap to functional programming. Scala, OCaml, ML, Haskell and Idris vary in the power and strictness of their type systems — all offer a type system much more powerful than Javas. The advanced functional languages like Haskell and Idris not only have extremely advanced type systems, but the compiler enforcement of correctness is highly intolerant.

By contrast Java, with it’s weaker type system, also has a highly tolerant compiler (if we ask it nicely, it will allow us to compile just about anything 🙊).

We can cast classes almost at will (the code below compiles).

Object o = 10;
String str =(String)o;

We can mutate external (& even global state) anywhere.

Function<String,Integer> fn = a -> { 
                                     State.set(a);
                                     return a.length();
                                   }

We can extend existing class hierarchies and introduce new sub-types the original developers were entirely unaware of and may not account for in their business logic.

if(animal instanceof Dog){

}else if(animal instanceof Cat){

}else if(animal instanceof Lion){

}

public class MyDinosaur extends Animal { //oops!

}

We can even create new interface implementations via dynamic proxies and new sub-class definitions at runtime (with cglib), and more completely mimic the machinations of dynamic languages (like Ruby, Groovy or Python — all of which have closures, none of which are functional), which can lead to the hair pulling joy of Exceptions like this :-

org.hibernate.HibernateException: No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
    at org.springframework.orm

We can use the ServiceLoader (and other mechanisms) to completely change runtime behaviour of our applications based on the jars present. Got two implementations of a particular provider in your test environment (as you have your compile time dependencies and your test deps), but only one in production — then your application may behave entirely differently in prod than in your unit tests. Good luck with debugging that!

We can throw CheckedExceptions even on methods that don’t declare them (via Exception softening).

public void doIO(){
   throw uncheck(new IOException("not declared!!");
}

private static <T extends Throwable> T uncheck(final Throwable throwable) throws T {
    throw (T) throwable;
}

We can write code like this and the compiler won’t complain :-

List<String> createList(){
   List strs = new ArrayList();
   strs.add(“hello”);
   strs.add(“hello”);
   strs.add(10);

  return strs;
}

By contrast functional languages often have extremely intolerant compilers that take away a lot of our favourite Java hacks. We’ve spent decades figuring out ways to bypass the (limited) Java type system to behave more like a dynamically typed language than a powerfully statically typed one. Most of our popular core libraries rely heavily on these hacks (good luck trying to avoid them!). These restricted functional languages are much more difficult to work with (at least at first) as a result, but also much more reliable once you get used to them.

Is it monads and pro-functor optics?

The introduction of concepts from category theory into typed functional programming helps us work with the compiler enforced constraints. They can offer some very nice patterns for programming, but it is those constraints that liberate us from the tyranny of (often very hard to debug) runtime errors. I’ve spent much of the last week slowly identifying a jar conflict that only manifests at runtime in Java — removing one dependency at a time, stepping deeply through complex 3rd party libraries.

It is compile time correctness

With their crazy type systems, restrictions on mutable state, fetishisation of pure functions the functional languages help pry us away from the bad habits that lead us to runtime errors. Instead the compiler kindly let’s us know that we can’t really flatMap / bind a WriterT[Option[String]] with a WriterT[Either[Error,String]] and expect it to work (or even better that trying to throw new Exception, return null or mutate that input parameter just isn’t going to cut it either).

That way, we pay the cost of figuring out much of the right way to code whatever it is we are working on, up front, at the start when we are in the office during normal work hours, on our own workstations without impacting our collegues. And certainly not at 3am having brought down production because we (or a library we are using) made a illegal reflective call to a method someone had changed since the last time someone else tested it.

If Javac won’t help us, what can we do?

If you are looking to truly adopt the advantages of functional programming in Java and not just create mind bendingly gnarly imperative code with Lambda’s then I believe we need to work with the Java Compiler to help it help us.

Rather than spend our time trying to trick it, we should :-

Make good use of Generic Types. Generics in Java can trace their orgins to Generic Java created by Philip Wadler (Haskell legend), Martin Odersky (creator of Scala), Gilad Bracha, Dave Stoutamire. Don’t ignore type parameters, declare them and enforce them everywhere. Minimize casting and if instanceOfing. Where you do use them (it is still Java after all — they are likely impossible to fully eliminate), centralize each type of cast within a resuable method, use proper type parameters on the inputs and outputs and write good tests!

Make illegal states unrepresentable in our code. The Haskell and Idris compilers will enforce this for you, just pretend Javac is as strict. Avoid nulls, don’t throw Exceptions, avoid locking and synchronization and you will take giant leaps towards this.

Make our own data classes immutable and final where possible, use immutable collections (proper ones). Avoid instanceof checks where possible, and where you use them make sure the types are not extensible.

Use libraries that avoid runtime magic and reflection where pragmatically possible.

OO and FP together

There is no conflict between OO and FP.

You can be Object Oriented and still adopt the core constraints that drive the benefits of the functional paradigm. You can make sensible use of an immutable, strongly and correctly typed domain model with good inheritance / composition trade offs and choices made, with methods that act as pure functions, avoid global state entirely & isolate the IO portions of your application (and you’ll be happier and sleep better as a result!).

The real tension: imperative and fp

In Java you will rely on developer discipline to enforce these liberating constraints. But even as you do so within your own applications, unless and until the eco-system adopts this principles whole heartedly, you will have to make heavy use of libraries and frameworks which do not. The real tension isn’t between OO and FP, it’s between mutual imperative code that by passes where possible compiler checks to maximise runtime dynamism (as if all we needed was to migrate to Ruby) and constrained functional code that enables the compiler to find problems in our code before we do.

From Dysfunctional to Functional

In episode 2 of Dysfunctional Programming in Java we covered why and how to make your Java Objects Immutable, in this article we will dive deeper with Immutable Collections. (Elsewhere in the series we have covered laziness, functional composition, null handling, error handling, and concurrency.)

Recap on Immutability

Method signatures like this are painfully common in Java

Looking at the signature it isn’t clear what it does, but a reasonable guess would be that performs some form of I/O or mutation of it’s input parameters. The void return type let’s us know that it must be an impure statement — there is no return value and thus no way of interacting with outside world other than by changing it’s state in some way.

A good principle to follow when developing imperative applications is Command — Query Separation from wikipedia

It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, Asking a question should not change the answer.[1] More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.

It’s good practice in OO to use void as a return type methods that mutate state or perform I/O. If handleAccounts is only performing I/O and merely reading from it’s parameters then it would be far from the worst method with this type of signature I’ve seen. Even C++ programmers regard the mutation input parameters as inherently dysfunctional (🙊 ). We can prevent the possibility by making our Objects immutable.

Mutable Collections Result in Incidental Complexity

Making use of Immutable Collections in our APIs can prevent ourselves and our teammates producing psuedo functional code like this :-

We managed to put a nice fluent Stream together and then ruin it all by mutating an input parameter. But why do I think that is bad? Three reasons

1. ⚠️🦟Mutation Bugs🕷⚠️ It is a potential source of bugs when clients calling handleAccounts do not expect List<Account> provided to be mutated or it gets mutated in a different way that expected in the future.
2. ⚠️🤷🏽‍♀️Distributed Object Creation😕⚠️. It can be difficult to keep track of the scope of changes made to input parameters (building up an Object or Collection can become incredibly distributed across your code base)
3. ⚠️🏎Race Conditions🏇⚠️. It is not safe to handleAccounts asynchronously if the List<Account> is expected to be used on another thread in some manner (problems can occur whether reading from or writing too the collection)

Immutable Collections Keep Things Simple

A better approach is to make use of an Immutable List type as input and return a new list with the accounts added.

Cyclops and other functional libraries for Java provide a range of immutable collections that efficiently reuse shared memory to allow ‘updates’ or changes to the collections.

We can make use of the Cyclops immutable LinkedList type called Seq for this purpose

Switching to an Immutable (and functional) type offers the following advantages

1. ✅Eliminate Mutation Bugs✅ We avoid bugs caused by client code expecting an unchanged Seq<Account> list passed as an input parameter — it never changes!
2. ✅Eliminate Distributed Object Creation / Population✅ Our ultimate Seq<Account> creation can be managed in a single place
3. ✅Eliminate Race Conditions✅. We can safely share a Seq<Account> list across threads.
4. ✅Eliminate Boilerplate✅ Because Seq has a lot of useful functional combinators!

Imperative code with mutable datastructures

Going back to our application, we have a method where we attempt to load all of a users Data files into memory given a List of the DataFileMetadata Objects that describe where the files are and how to load them. There are a number of constraints

1. We need to ensure that the User is authorized to load files
2. We need to ensure that the User actually has files to load

There are a number of potential pitfalls with the code as it stands

1. It’s not particularly robust

We are throwing three different types of Exceptions and there are as many opportunities to fail as there Data files to load (+2 — empty check and User Authorization check). Any of these failures, fails the entire process.

2. It’s doing a lot of I/O sequentially on a single thread

It’s going to perform like a dog. getContents is loading data either from the file system or the cloud, and we are currently loading each file in turn.

3. Because of the mutable state parallelism is harder to implement

The method is still pretty simple so far, but even moving getContents onto a separate set of threads that populates the mutable List<String> result is fraught with potential gotchas — as our application grows the potential problem areas will multiply!

Let’s simplify with more functional collections

As a first step we can rework the method signature to accept a Vector, which is an efficient Immutable analog of an ArrayList.

Being a functional type Vector supports a number of very useful functional combinators. We can, for example, replace the external iteration over the files and population of a mutable ArrayList with a simple map operation. Map transforms all the contents of the Vector from one state to another, in this case from our input type DataFileMetadata to our output type String.

Making Illegal States Unrepresentable

It is good practice to design our APIs in such a way as they guide developers using them along the correct path, rather than allow illegal states to be represented in code -which forces us to throw an Exception, it would be better to use appropriate types to prevent this.

If a List must have at least one entry, then we should only accept a NonEmptyList!

We can update our functional operations on files to also include a conversion to vector.

Now we can remove the empty check and IllegalArgumentException when files is empty, and our updated code now looks like this :-

Errors as values, not Exceptional control flow

Instead of throwing a UserNotAuthorizedException, we could return an Either instead. That is our return type would either be an Error or the Vector<String>.

Either<Error,Vector<String>> 

The type signature is verbose, but with local variable type inferencing in Java 10 we should be able to avoid having to redeclare it elsewhere.

We can refactor our method implementation to return an Either.left if the user is unauthorized and an Either.right with the Vector of Strings if they are and we download the data.

We can make this code better still, if modify the return type of AuthorizationService::isAuthorized to be an Either e.g.

Either<Error,Vector<DataFileMetadata>>

This means we can simply chain additional operations onto the returned Either.

Where loadContents transforms the Vector<DataFileMetadata> into Vector<String>

While we have reduced our implementation of processUsersFile down into a single line, while capturing or removing validation errors — we still are processing all of the Data files sequentially and a single I/O error will fail the entire batch.

ReactiveStreams : Adding in some concurrency

So far in this article we’ve been making use of the original imperative DataFileMetadata, but in another article we covered its refactor to a more functional style. The Functional version had a loadAsync method that we could use to load the files concurrently.

Also, rather than throw an IOException it gives us an Either Object that allows us to deal separately with the error case without disrupting the applications flow. We can refactor the loadContents method to use the reactive mergeMap operator on Vector and the loadAsync method on DataFileMetadata which returns a reactive-streams Publisher (LazyEither)

⏫The code above⏫ will load 10 data files concurrently and return their contents in a Vector.

How we respond to I/O errors has also changed, the default behavior will be to aggregate the successful results and ignore the errors. While this is better than failing the full batch due to one failure, it is still sub-optimal

Retrying after loading failures

We can build retry functionality into how we handle the result of DataFileMetadata::loadAsync, the first step to keep things clean is to move the call out into it’s own method.

The return type of loadAsync is a LazyEither — a type that is both a reactive-streams Publisher that can handle asynchronous population & processing and has stacksafe recursive support in it’s map and flatMap operators.

We can implement limited retry support by recursively calling back into our retry method on failure.

Let’s unpack what is happening in this very short, but information dense method

1. flatMapLeft : is only ever called if loadAsync fails
2. When flatMapLeft is invoked we recursively call asyncWithRetry (providing additional retries are allowed)
3. We call asyncWithRetry on the current Thread (r->run() is a simple implementation of an Executor which immediately runs the supplied Runnable on the current thread).

If loading fails, on the same thread we recursively call asyncWithRetry until we successfully load the data or run out of retries.

It doesn’t matter how large the number of retries initially supplied is — we won’t blow the stack, because of the built-in trampoline in LazyEither.

Failing if loading fails

Now errors in loading are still ignored, but if we encounter a loading error we will retry for the specified number of times before giving up. We may rather fail the entire batch with an Error value if the retries continue.

The refactoring of loadContents to support this is slightly more involved (don’t worry we will break it down in a moment), but one of this nice features of this implementation is that everything is now asynchronous and non-blocking — and this flow through from loadContents into processUsersFiles. We need to refactor the processUserFiles implementation aswell.

The map operator needs to change to flatMap (because the return type of loadContents is now also an Either).

Let’s unpack what is happening inside loadContents :

1. We create a (potentially) reactive-stream from the Vector
2. mergeMap introduces concurrency & asynchronicity to the Stream, files are loaded on the supplied Executor and any failures are retried up to 10 times
3. reduceAll : collects all of the resultant Strings asynchronously into a Vector (still inside the Stream)
4. findFirstOrError : will return either the successfully collected Strings in a Vector or the first Exception if one occurs
5. mapLeft : converts the Exception into a loading Error error value

The resultant Either is a reactive LazyEither instance that will be populated asynchronously, we can go with the processing of the rest of our application and access data from the LazyEither when we need it, or tee up additional operations to perform.

Our complete code for this session now looks like this :

Testing the code

We can run the processUsersFiles passing in different test fixtures.

If we run it with a failing URL and print out the result we will see an left Either with an Error.

And with a URL we are able to successful download contents from it will look more like this (a right Either with the contents):-

We can demonstrate the non-blocking nature of the code by adding some logging to the console.

Now we are going to print the start time, before we setup our full data flow. Then we will print a couple of messages with their timestamps to test if processUsersFiles has blocked us. Before attempting to print ‘x’ which will contain the result of our asynchronous processing. We won’t be able to print the “Completed at “ time until after the asynchronous processing has complete. If we run the code, the output will look something like this :-

What this shows us is that we are able to print out “Blocked?” and “No…” relatively shortly after setting up the dataflow (about 200ms), but that it took over 10 seconds for us to be able print the completed message. With a relatively few lines of code we have setup a robust, asynchronous & concurrent dataflow for processing our files — free many of bugs and challenges that plagues traditional imperative Java code.

Getting Cyclops

If you are following along, you can install the cyclops library for functional programming in Java by adding it to our Maven our Gradle class paths

Maven

<dependency>
 <groupId>com.oath.cyclops</groupId>
 <artifactId>cyclops</artifactId>
 <version>10.0.3</version>
</dependency>

Gradle

compile group: 'com.oath.cyclops', name: 'cyclops', version: '10.0.3'

This weeks functional and reactive Java blogs and talks!

A bumper round up of blogs and talks on Functional Programming & Reactive Programming in Java.

Functional and Reactive Blogs and Talks

Exploring Reactive Programming with Java by Miro Cupak

Notes

Slides

Introduction to Reactive APIs with Postgres, R2DBC, Spring Data JDBC and Spring WebFlux by Piotr Mińkowski

Full-stack Reactive Kotlin with Project Reactor & Spring Boot 2 by Mark Heckler

Java Streams vs Reactive Streams: Which, When, How, and Why? by Venkat Subramaniam

Reactive Relational Database Connectivity by Ben Hale

Reactive Spring Security 5.1 by Example by Rob Winch (I hope he is not sad! 😀)

Reactor Netty, the Default Spring Boot 2.0 Runtime by Violeta Georgieva

Functional Java by Example | Part 5 — Move I/O to the Outside by Ted Vinke

Functional programming for Java developers, Part 2 by Jeff Friesen

Write a purely functional Bubble Sort application by Jeff Friesen

Under the Hood of Reactive Data Access by Mark Paluch

Multi-Service Reactive Streams Using Spring, Reactor, and RSocket by Rossen Stoyanchev and Ben Hale

Functional Programming in Java When, Why and How by Alasdair Collinson

Thread-local state availability in reactive services by Kamil Szymański

Functional exception handling with Vavr by Grzegorz Piwowarek

Revisiting the Template Method Design Pattern in Java by Grzegorz Piwowarek

Get rid of Null Checks with Vavr’s Option by Jaroslaw Kijanowski

Java Stream Tutorial by Jakob Jenkov

Dysfunctional programming in Java 6 : No Locks or Synchronized Blocks by john mcclean

• Dysfunctional programming in Java 6 : No Locks or Synchronized Blocks
• Thread-local state availability in reactive services
• Functional Java by Example | Part 5 - Move I/O to the Outside
• Write a purely functional Bubble Sort application
• Functional programming for Java developers, Part 2
• Be Functional With Java — get rid of if/else null checks with Vavr’s Option
• Java Stream API

• Reactive Spring Security 5.1 by Example
• Under the Hood of Reactive Data Access
• Reactive Relational Database Connectivity
• Reactor Netty, the Default Spring Boot 2.0 Runtime
• Multi-Service Reactive Streams Using Spring, Reactor, and RSocket

Interesting blog post missing? Let me know johnmcclean_ie on Twitter

From dysfunctional to functional

Its time to see how adopting principles from functional programming can help us simplify the challenge of implementing concurrent and parallel code in Java. So far we’ve explored how laziness, immutability, functional composition, banning null assignments and throwing exceptions can bring calmness and serenity to our code base. Concurrency produces the most hair-pullingly-frustrating bugs of all.

Let’s start with some really dysfunctional imperative code

Mutable non-volatile Fields

Given a number of non-volatile, non-final fields

Imperative data processing

We then have a multi-threaded processData method that populates the List of Results and sets the boolean completion flag.

There are at least 6 areas where this code has serious bugs now (or could develop them in the future). In fact calling this method with the code below, results in an infinite loop on my MacBook Pro.

locking.processData(in);

while(!locking.isCompleted()){

}

Let’s investigate why.

1. If an Exception is thrown while we are working with the lock, the lock will never be released
2. After we have exposed the local Results by adding them into the field resultList we continue to process them — opening up the possibility of a race condition should another thread also try to read or write to those same Result objects
3. Incrementing complete may suffer from thread visibility problems and / or race conditions with other threads
4. Comparing expect and complete may suffer from thread visibility problems and / or race conditions with other threads
5. Setting complete to true may may suffer from thread visibility problems
6. Incrementing expect may suffer from thread visibility problems and / or race conditions with other threads (where expect is read on a separate thread before being incremented).

Growing imperative, mutable, multi-threaded code is hard

All of these problem areas come from our decision to share mutable state across threads and mediate access to and changes to that state via locking. ⛔️Don’t do this⛔️ We could exert some mental energy and clean up the holes in this code — but that isn’t the right approach. The challenge here, is that even if we fix it (for now) in this small part of the code, we will likely have client code (now or in the future) that reads this data, and perhaps performs further processing on it. The increase in interactions, across threads, on mutable data structures will increase the complexity and difficulty in getting locking correct exponentially. Even if we get it right, and with reasonable performance now, the code will have to be maintained in to the future. New team members with perhaps less expertise in our code base and in the nature of those interactions (or ourselves after working on something else for a couple of months) will find it easy to introduce bugs and / or performance problems.

Avoiding mutating state

We should refactor our application so that, we are not updating a mutable List as results arrive. Instead, each task should return its own list containing partial results. We can then aggregate those lists safely and performantly (using some functional apis). All of our state will become local, our methods will return immutable values.

This means we can remove all our current fields, perhaps replacing them only with an Executor on which our new asynchronous tasks should run. Let’s see why

1. We don’t need List<Result> resultList as we are not going to have shared mutable state
2. We don’t need to track expected or complete threads
3. We don’t need a boolean value to track if the entire process is complete
4. With no mutable state, we have no need for a Lock.

Welcome to the Future

The method signature of our processData method can look something like this :-

That is at some point in the future a List of Result Objects will be returned. It will be returned asynchronously so it won’t block any code that calls processData.

Future in this case is Future from cyclops (cyclops.control.Future) which provides a more standard functional API over CompletableFuture. It includes methods such as isDone (which we could use to check if the asynchronous task is complete) and options for chaining additional tasks functionally such as map.

Implementing processData

We can refactor our for loop, in particular we can replace the Thread creation code with Future creation.

Thread::start and Thead::join have void return types, which means that neither offer a mechanism to return results back the the original calling thread of execution. The ability to work with and share results across threads is a core feature and benefit of Future.

We can create a Future that loadsResults from disk asynchronously

Executor ex;
Future.of(() -> loadResults(id, data.get(id)), ex);

That will give us a skeleton implementation to work with :-

Doing additional work on the same thread

In the original imperative version once we had loaded up the data on a new Thread, we continued to process it (on the same Thread) making some changes to the mutable Result Objects. We can use the map operator to continue processing our data inside the Future on the same thread.

In this case we are following lambda best practices of making use of a single line expression — a method reference to a processResults method. The implementation of which (making use of Lombok @Wither annotation instead of @Setter) should look something like this :-

Sequence : the swiss arm knife of functional programming

We can collect all of our Future instances inside a List (with a scary verbose type signature 🙀 — a list of futures each with a list of results)

The return type of our method really should be something more like a single Future value with a List of Results (not a List of Futures each with their own result)

It turns out that this is a very common problem in Functional Programming, and luckily there is a very handy pattern that can be used to solve it sequence.

Sequence is a method that takes a List of Futures and converts it into a Future with a List (with the pattern being generalizable to a wide range of functional container types). Sequence will operate asynchronously, the new Future will collate the results of each of the sequenced Futures for us, in an entirely non-blocking manner. So the code to convert our list of Futures (allTasks) into a single Future with a list of Results should look something like this

NB: We perform a concatMap operation to flatten out the List of Lists that Sequence will return in this case (as each individual Future returns a List).

Putting it all together our code is still a little too imperative and more verbose than it needs to be, but the problem of shared mutable state (and associated locks and potential bugs) has been eradicated.

If we move the call to loadResults from disk into the processResults method and change the return types from List to cyclops powerful Stream type ReactiveSeq we can reduce the code required

Future creation can now be simplified to just a call to the process method

Future.of(() -> this.process(e.getKey(), e.getValue()), ex)

We can replace the imperative for loop with ReactiveSeq and a map operation

If we plop this inside our Future::sequence call, we could express the whole method in a single functional expression

Which is certainly a lot simpler, cleaner and more brief than the imperative mess we started out with. You may prefer to break this out a little, and if you do I highly recommend making use of Java 10 local type inferencing support via var to stay out of generics hell!

Continuing processing and the SOLID Principles

A reasonable ask from a performance point of view would be to continue processing results as they come in. Using the map method on the Future returned from processData won’t help, as map will not get called until all the results are available.

One way to implement support for this would be to dig deep into our existing process method and add any additional steps required to that method. ⛔️Stop — don’t do this⛔️. Adding code to an existing method like this is not the best way forward, at a minimum this violates the Open Closed Principle from the SOLID Principles. Wikipedia states

In object-oriented programming, the open/closed principle states “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”; that is, such an entity can allow its behaviour to be extended without modifying its source code.

Modifying the process method means we are relying on future modification (not closing it off) — with all the attendant risk of introducing bugs. Other risks here are that by adding continually to process we will wind up mixing high level abstractions with low level abstractions in our code, out of neccessity, potentially violating the Dependency Inversion Principle. In addition adding code in such a fashion risks violating the design principle of Single Responsibility. None of these things are desirable.

Asynchronous Streaming

There is a better way. If we require the ability to continue to asynchronously process the data as it arrives is to make that data available as a continuous, asynchronous (reactive!) Stream (not a discrete scalar result). We can refactor (simplify!) the return type of processData to be just ReactiveSeq<Data>

We have a number of options to do this in cyclops. Currently processData is implemented by creating and the sequencing a Stream of Futures. The mdoule cyclops-futurestream provides an implementation of ReactiveSeq that is exactly that (using a custom FastFuture implementation under the hood). FutureStream will allow us to tee up additional operations to be applied to each Result as it arrives asynchronously.

FutureStream : a simpler & faster implementation

The implementation with FutureStream is both more powerful and much more simple!

Now when after calling processData, we can tee up additional operations via map, peek, flatMap etc and they will be applied appropriately as the data streams in.

If we write some simple example code that calls processData we can get a feel for future-streams in action.

Executing the code

1. Create a test fixture Map with 10 entries to process asynchronously
2. Work with the returned FutureStream to capture the current thread processing is happening on
3. Asynchronously printout the results

If we run the code above, we will get output something like this :-

Each of the records will be loaded asynchronously on a separate thread (Threads 15–24 above), but once loaded we can continue processing on that same thread!

reactive-streams

It is possible to configure reactive-streams implementations to execute concurrently (typically via a flatMap-style operator for Publishers). By executing the user supplied input function multiple times we can spawn into action multiple asynchronous publishers at the same time. In the cyclops world we do this via the mergeMap operator

In the example above we are telling cyclops to call our Future (a reactive-streams Publisher!) generating function a maximum of 10 times, before any of the returned Futures generate their onComplete call. In practice this would mean that 10 Future instances would be created to load and process the data asynchronously.

The complete method using cyclops’ reactive-streams support would look like this :-

When demand is signalled, mergeMap will execute the supplied Function that will create a new Future which runs asynchronously on a Thread pool. Future is also a reactive-streams publisher and mergeMap will subscribe, when the Future has loaded the data and done it’s initial processing it will push those results down into our connected Stream.

A different kind of concurrency when executing the code

If we run the example code above, we will get a very different result (😳)! This may come as a surprise (or not to some), when we continue to process our Stream and print out the current thread we will tend to get the same single thread that does the additional processing. While mergeMap triggers concurrent processing, continued processing beyond that is single-threaded.

Our output will look something like this :-

We are printing out the thread within an operator that is asynchronously processing the results of the concurrent futures (in a single thread way).

Our process diagram for the map operator when using reactive-streams looks more like this :-

If we add a peek operator call to our Future that prints out the current thread we can see this in action.

When we run our example code, we see the Futures operating concurrently using different threads and additional processing happening on a single

Working with Reactor

If you would prefer to plugin the operators from Project Reactor, we can switch ReactiveSeq implementations to FluxReactiveSeq

In fact if you decide just want to use Flux, cyclops types support excellent conversion and integration with reactive-streams Publishers (and Reactor / RxJava 2 in particular).

How to choose between FutureStreams and ReactiveStreams?

We refactored from Futures to a form of Stream in this example, because we had largeish result sets and wanted to process them as soon as they were available (Futures are perfect for when you have a single result, or at least don’t want to break and immediately process chunks of it). Which Stream type we’d use in practice would depend on what additional work was required.

If you are doing additional I/O bound work, particularly when working with typical Java blocking APIs — future-streams offer good simplicity of implementation mixed with decent performance. On the other hand if most additional processing is CPU bound using Spouts / reactive-streams for additional processing on a single core may give you a performance boost (at the cost of perhaps a slightly more complex implementation).

The code

The code below is for the future-stream version which is the shortest and the simplest implementation that offers good performance for tasks that involve blocking I/O. All of the functional approaches greatly simplify the challenge of building highly concurrent applications, this is true advantage of reactive!

There is also gist with an implementation with all of the approaches included as separate methods.

Summary

Once you are aware of the knack / trick required to refactor to the functional style of concurrency it becomes second nature with practice. The key is use Data Structures (Future ftw ✅) or Dataflows (futurestreams and reactive-streams ✅) that receive results asynchronously and manage the passing of data across threads for you. 🚫Never share mutable state across threads yourself🚫. Start by working with Futures (or CompletableFutures) and then work your way up to some form of Streams. FutureStreams are conceptually Streams of Futures and are extremely useful for working with typically Java APIs which still block when performing I/O. With advanced modern APIs such a RDBC and Reactive HTTP clients, plugin a reactive-streams implementation to get better responsiveness and performance.

This weeks functional and reactive Java blogs and talks!

Functional Blogs and Talks

The Functional Style — Part 6 by Richard Wild

Functional Programming (not necessarily with Java!) by Alex Macavei

Introduction to the Functional Web Framework in Spring 5 by Eugen (Baeldung)

Dysfunctional programming in Java 5 : No Exceptions by john mcclean

Imperative Loop or Functional Stream Pipeline? Beware of the Performance Impact! by Lukas Eder

Reactive Blogs and Talks

Bringing Reactive To Enterprise Java developers by Thomas Segismont and Julien Ponge

Reactive Microservices using RSocket by Ryland Degnan

Understanding Spring Reactive by Naveen Katiyar

Exploring Reactive Programming in Java by Miro Cupak

Embeds

Schedule - Reactive Summit 2018 - @reactivesummit

• The Functional Style - Part 6
• Functional Programming (not necessarily with Java!)
• Introduction to the Functional Web Framework in Spring 5 | Baeldung
• Understanding Spring Reactive: Client-to-Server Communication - DZone Java
• Imperative Loop or Functional Stream Pipeline? Beware of the Performance Impact!
• Dysfunctional programming in Java 5 : No Exceptions
• Bringing Reactive to Enterprise Java developers - @reactivesummit
• Reactive Microservices using RSocket - @reactivesummit

Interesting blog post missing? Let me know johnmcclean_ie on Twitter

8 examples of working with Java 8 Functions with Cyclops FluentFunctions

Error and recovery

Example 1. Handling exceptions with FluentFunctions

Given suspended method that throws an Exception (in this case suspended contrived example where the first call always fails, but subsequent calls succeed).

int times =0;
public String exceptionalFirstTime(String input) throws IOException{
        if(times==0){
            times++;
            throw new IOException();
        }
        return input + " world";
}

We can make use of FluentFunctions to retry the method twice 500ms apart.

FluentFunctions.ofChecked(this::exceptionalFirstTime)
               .println()
               .retry(2,500)
               .apply("hello");

And the output will look something like this (thanks to the println operator).

(fluent-function-Parameter[hello])
java.io.IOException
    at com.aol.cyclops2-react.functions.fluent.FunctionsTest.exceptionalFirstTime(FunctionsTest.java:95)
   ...
(fluent-function-Parameter[hello])
(fluent-function-Result[hello world])

Alternatively we could decide to recover from the thrown exception.

FluentFunctions.ofChecked(this::exceptionalFirstTime)
               .recover(IOException.class, in->in+"boo!")
               .println()
               .apply("hello ");

And the output would look like this (notice the missing StackTrace as the Exception has now been handled!.

(fluent-function-Parameter[hello ])
(fluent-function-Result[hello boo!])

Example 2. Caching method calls with FluentFunctions

With suspended method that does simple addition, we can keep track of the number of times it is called.

int called;
public int addOne(int i ){
        called++;
       return i+1;
}

If we use the memoize (cache) method on FluentFunctions, all calls to our method will be cached.

Function fn = FluentFunctions.of(this::addOne)
                             .name("myFunction")
                             .memoize();

Calling apply multiple times will result in called being incremented only once.

fn.apply(10);
fn.apply(10);
fn.apply(10);

called is 1

But, c’mere, there’s more..

We can plugin any cache implementation we like, so let’s set up suspended Guava cache (Caffiene has suspended similar API).

Cache<Object, Integer> cache = CacheBuilder.newBuilder()
                   .maximumSize(1000)
                   .expireAfterWrite(10, TimeUnit.MINUTES)
                   .build();

Now we can use our cache by passing suspended lambda expression in the format below to memoize. Our lambda must take two parameters, the first of which is the cache key, and the second is the function used to generate the value (in this example fn is our method reference to addOne).

Function fn = FluentFunctions.of(this::addOne)
                             .name("myFunction")
                             .memoize((key,fn)->cache.get(key,()->fn.apply(key)));

fn.apply(10);
fn.apply(10);
fn.apply(10);

called is 1

Aspect Oriented Programming

FluentFunctions makes it very easy to apply AOP-style advice.

Example 3. Before Adivce

First let’s create suspended method that returns true if suspended variable has already been set to the input value the method takes.

int set;
public boolean events(Integer i){
        return set==i;
}

Events will return true, if set has already been set to i. Let’s use this method to illustrate the application of before advice.

Before advice

We can use before advice, to capture the input to our method, before that method is called.

set = 0;
FluentFunctions.of(this::events)
               .before(i->set=i)
               .println()
               .apply(10);

Using the println() operator our output looks like this

(fluent-function-Parameter[10])
(fluent-function-Result[true])

As you can see events returns true, because the input 10 has been captured and the variable set has been set to 10 in our before advice.

Example 4. After Advice

With After Advice we can capture the input to our method, and the output from our method after it has been called. So, let’s capture both in two variables setIn and setOut.

setIn= 0;
setOut = true

FluentFunctions.of(this::events)
               .after((in,out)->{setIn=in;setOut=out;} )
               .println()
               .apply(10);

At the end out our run setIn will be 10 (the input) and setOut will be false (our result — because we are no longer setting the value of set to the input parameter before events is called).

(fluent-function-Parameter[10])
(fluent-function-Result[false])

setIn =10
setOut = false

Example 5. Around advice

With Around Advice we can control whether or not or methods are executed, and with what parameters they are executed, as well as having the facility to change the return value.

Given suspended method that simply adds 1 to suspended parameter.

public int addOne(int i ){
        return i+1;
}

We can construct Around advice that modifies the input parameter to our method, in this case by incrementing it by 1 before the method is called.

FluentFunctions.of(this::addOne)
               .around(advice->advice.proceed(advice.param+1))
               .println()
               .apply(10)

And our output looks like this (we add two to the input of ten).

(fluent-function-Parameter[10])
(fluent-function-Result[12])

//12 because addOne adds one and so does the around advice

Stream Generation & Iteration

We can use FluentFunctions to turn any method (3 parameter or less) into suspended Stream generator. Let’s find out how with some examples.

Example 6. Stream generation

Given suspended method that takes suspended value adds suspended timestamp and returns it.

public String gen(String input){
        return input+System.currentTimeMillis();
}

We can generate suspended Stream from this method using FluentFunctions as follows

FluentFunctions.of(this::gen)
               .println()
               .generate("next element")
               .onePer(1, TimeUnit.SECONDS)
               .forEach(System.out::println);

In the example above the call to generate results in suspended SequenceM, suspended powerful JDK 8 Stream extension that forms part of cyclops-react. We use the onePer operator to skip the number of emissions by this Stream to one per second.

The output from our Stream will look something like this.

(fluent-function-Parameter[next element])
(fluent-function-Result[next element1453819221151])
next element1453819221151
(fluent-function-Parameter[next element])
(fluent-function-Result[next element1453819221151])
next element1453819221151
(fluent-function-Parameter[next element])
(fluent-function-Result[next element1453819222153])
next element1453819222153
(fluent-function-Parameter[next element])
(fluent-function-Result[next element1453819223155])
next element1453819223155
(fluent-function-Parameter[next element])
(fluent-function-Result[next element1453819224158])

Example 7. Stream iteration

We can also use suspended method or function to iterate infinitely over it’s own input / output data cycle.

In the example below we use the method addOne that adds 1 to it’s input to generate an infinite sequence of numbers starting from 95281.

FluentFunctions.of(this::addOne)
                        .iterate(95281,i->i)
                        .forEach(System.out::println);
95282
95283
95284
95285
95286
95287
95288
95289
95290
95291
95292
95293
95294

Note in orde to cycle infinitely over suspended methods input/output data output must be mapped back to input type on each cycle. Iterate takes suspended seed value and suspended function that maps from output types to input types.

Lifting functions

Lifting functions refers to the ability to lift suspended function to suspended higher context, for example to lift suspended partial function (one that does not apply to all possible input values) to suspended complete one. The lift methods in FluentFunctions allow methods to be lifted to accept and return Optionals (for null-handling at either end), Try (for exception handling), or to any other monad type via AnyM.

Example 8. Lifting example

Let’s start with suspended function that add’s one to suspended number that accepts suspended nullable Integer, and suspended variable of type Integer that just happens to be null.

public Integer addOne(Integer i ){
        return i+1;
}
Integer nullValue = null;

Calling addOne directly with nullValue will result in suspended null pointer exception. Using the lift method however, we can wrap addOne so that it accepts and returns Optional, thus completely avoiding the possibilty of an NPE.

FluentFunctions.of(this::addOne)
               .lift()
               .apply(Optional.ofNullable(nullValue));

Function APIs

FluentFunctions is one of the Function APIs available in cyclops a library for functional programming in Java. We can add it to our Maven our Gradle class paths

Maven

<dependency>
 <groupId>com.oath.cyclops</groupId>
 <artifactId>cyclops</artifactId>
 <version>10.0.1</version>
</dependency>

Gradle

compile group: 'com.oath.cyclops', name: 'cyclops', version: '10.0.1'