Quickly writing Java lambdas and method references

Simply speaking, lambda expressions in Java are methods implemented without an enclosing class body. But wait, not all methods can be implemented as lambdas. Only those declared inside candidate functional interfaces(an interface that contains only one abstract method) are the privileged ones.

Converting method parameters based on anonymous implementations of functional interfaces into lambdas:

Any implementation of a Functional interface(as an anonymous class) can be converted to lambda expression.

If observed closely, all what needs to be done is eliminating the elements which could be implicitly available to the compiler and separating the parameters and the actual expression by ‘->’ operator.

Lets take a simple example of the following familiar code:

Tokens which can be inferred by the compiler without explicit mention.

Since the anonymous class implementation is of the interface Comparator which is a functional interface, it can be converted into a lambda expression.

Lets now remove the unnecessary things to reach our lambda expression. The following tokens(shown above in bold) are candidates for removal as they can be inferred by the compiler —

1. new Comparator<String>: because the name is implicit from the signature of method sort which accepts a Collection and a Comparator. The type String is inferred from type of the parameter list.

2. Return type int: as it is the return type declared with the method.

3. Method name compare: the name doesn’t need to be specified as it is the only method from the functional interface which needs implementation.

4. Parameter type String: inferred from signature of the method compare.

Hence, we get the following:

Further, since the given example has just a single line inside lambda expression, we may also optionally get away with —

5. Opening and closing braces.

6. return keyword as it can be inferred by method return type whether it returns a value or is void.

Thus our original familiar code becomes:

Collections.sort(list, (o1, o2) -> o1.compareTo(o2));

Next step: Method references

Can’t you make it more concise?

Why not? If the lambda expression just consists of a method call on its parameters or on some other object with its parameters, shouldn’t just the references to these methods suffice? Here we go with example transformations on all sorts —

Type 1: Static methods

n -> Math.abs(n)   =>    Math::abs

The parameters of the lambda expressions always go as arguments to the method referred.

Type 2: instance method of the object in parameter

str -> str.length()                         =>    String::length
(str, i) -> str.substring(i)                =>    String::substring
(str, s2, s3) -> str.replaceAll(s2, s3)     =>    String::replaceAll

This type is the most interesting of all. The method references impersonate the static method references from Type 1. The first parameter of the lambda expression is always the object on which the referred method will be called, and the rest of the parameters are arguments supplied to this method, in-order.

Type 3: instance method of any arbitrary object and the lambda expression’s parameters passed as argument to that method

() -> str.length()                   =>    str::length
text -> str.compareTo(text)          =>    str::compareTo
(text, i) -> str.indexOf(text, i)    =>    str::indexOf

These are similar to Type 1, except the Class name before the :: operator has been replaced with concrete instances of local or member variables. The method parameters are in-order arguments to the relevant methods as in Type 2.

Type 4: Constructors

name -> new Thread(name)    =>    Thread::new

Identical to Type 1 static method references.

Let’s go back to see how does our familiar code fairs with Type 2 transformation:

Collections.sort(list, String::compareTo);

Sweet, isn’t it? ❤

To many, this change to bring functional programming into object-oriented Java is a backward paradigm shift, but as we saw in this article, this helps us to reduce boiler-plate code and write simple logic in an uncomplicated fashion. However, Lambda expressions don’t hurt Object-oriented nature of Java as long they are simple enough not to play with states of enclosing class or attempt global mutations.

✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.