Functional Programming in Java

Stream and Optional classes - added to Java 8 - allow you to have some fun with functional programming. The problem is Java still misses quite a lot to be taken as a serious FP language. Lambda notation and two monads (Optional and Stream) are just the tip of the iceberg. This leads to arising of libraries like vavr or functionaljava - both deriving from purely functional language Haskell.

One of the first things you need to get rid of when trying to be more functional, is the attempt to unwrap the monad too early. It usually involves using methods like Optional.get() or Stream.collect() where there is yet no need. Sometimes though, Java doesn't help with that, so let me give you some custom code for the rescue. This article will bring you closer to the concept of method lifting. 

Calculations on Optionals

Suppose we have some nice API we would like to use to calculate numbers:

1
2
3
4
5
6
7
8
    public interface Math {

        int multiply(int a, int b);

        double divide(int a, int b);

        ..
    }

We would like to use it to do some calculations on numbers wrapped with Optional:


1
2
3
4
5
    public interface NumberProvider {

        Optional<Integer> getNumber();

    }

Let's say we want to write a method, which returns the result of the division of two numbers wrapped with Optional, or empty Optional if any one of them is empty (we skip the 0 divisor case here). It may look something like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
public Optional<Double> divideFirstTwo(NumberProvider numberProvider, Math math) {
        Optional<Integer> first = numberProvider.getNumber();
        Optional<Integer> second = numberProvider.getNumber();
        if(first.isPresent() && second.isPresent()) {
            double result = math.divide(first.get(), second.get());
            return Optional.of(result);
        } else {
            return Optional.empty();
        }
    }

That's rather nasty. It involves a lot of code which the only purpose is to wrap and unwrap the Optional. Let's try to make it more functional:


1
2
3
4
5
  public Optional<Double> divideFirstTwo(NumberProvider numberProvider, Math math) {
        return numberProvider.getNumber()
                .flatMap(first -> numberProvider.getNumber()
                                         .map(second -> math.divide(first, second)));
    }

That's much better. It turns out that invoking flatMap on the first monad and map on the second one inside the lambda, can be extracted even further to the method called lift:


1
2
3
4
5
6
public interface Optionals {

    static <R, T, Z> BiFunction<Optional<T>, Optional<R>, Optional<Z>> lift(BiFunction<? super T, ? super R, ? extends Z> function) {
        return (left, right) -> left.flatMap(leftVal -> right.map(rightVal -> function.apply(leftVal, rightVal)));
    }
}

Lift is able to promote any function, which takes two arguments, to the function with the arguments and the result type wrapped with Optional. It actually adds Optional behavior to the function in such a way that if one of the arguments is empty, then the result will also be empty. If JDK extracted flatMap and map methods to some common interface, for example Monad, then we could write one lift function for every instance of Java monad (Stream, Optional, custom classes). Unfortunately, we need to do this copy pasting for every instance. The final code for divideFirstTwo becomes:


1
2
3
4
5
6
import static com.ps.functional.monad.optional.Optionals.lift;
...

    public Optional<Double> divideFirstTwo(NumberProvider numberProvider, Math math) {
        return lift(math::divide).apply(numberProvider.getNumber(), numberProvider.getNumber());
    }


Summary 

I hope this article encouraged you to play with functional style in Java. JDK needs to be greatly improved for the language to be called functional in the future. Unfortunately, Java 9 doesn't promise any major improvements besides just a few additional methods. Source code can be found here.
0

Add a comment

I have recently started implementing different distributed system protocols to get some understanding how they work. I think that using Akka Actors to simulate hosts is a good choice because they are easy to set up. What is more you can kill actors on demand to test some failure scenarios.

When I started working as a Java Developer, me and my teammate got a first task to repair all broken tests (great task for new starters!) in some old project. Replacing some old configuration and upgrading a few libraries helped making the tests status green but there was another problem.

In this article I am going to share some cool features I stumbled upon while coding with Intellij. These are not the most popular/productivity improving ones - for these you should watch this video. 

1.

I have recently pushed very simple Map Reduce concept implementation on my Github account (click). My idea was to focus on the concept and mock the rest.

In this article I will try to map methods of Java’s Optional to Kotlin’ssimilar scattered language features and built-in functions. The code in the examples is written in Kotlin, because the language has all the JDK classes available.

Representation

Let’s start with the representation.

Have you ever scrolled someone’s code and bumped into this weird method called flatMap, not knowing what it actually does from the context? Or maybe you compared it with method map but didn’t really see much difference? If that is the case then this article is for you.

Fact - End-to-end  tests are critical if you want to make sure your software works as it should. To be 100% sure that you covered every (or almost every) possible branch in your business code, it is worth to check what code has been invoked after your E2E suite finished successfully.

Functional Programming in Java

Stream and Optional classes - added to Java 8 - allow you to have some fun with functional programming. The problem is Java still misses quite a lot to be taken as a serious FP language.

In this article, I am going to present you a simple trick that will make using java.util.function.Function.andThen() more useful.

1

Checked exceptions & Java 8

Defining custom exceptions (both checked and unchecked) is a common approach to handling errors in Java applications. It usually leads to creating a new class for every different type of error, marking methods with throws keyword or wrapping code with try-catch blocks.

1
Popular Posts
Popular Posts
About Me
About Me
Labels
Blog Archive
Loading
Dynamic Views theme. Powered by Blogger. Report Abuse.