How to tell Java to apply a lambda expressions for a custom functional interface instead for the one from the method’s contract?

The lambdas are without any doubt one of the most intriguing and attractive features in Java 8, but sometimes instead of helping us writing a better and boilerplateless code, they can get us into trouble. And still, they are the better alternative to the anonymous classes for lots of reasons. The anonymous classes were a […]

by Konstantin Yovkov

August 6, 2014

2 min read

Kocko Blog Cover Pic - How to tell Java to apply a lambda expressions for a custom functional interface instead for the one from the method's contract?

The lambdas are without any doubt one of the most intriguing and attractive features in Java 8, but sometimes instead of helping us writing a better and boilerplateless code, they can get us into trouble. And still, they are the better alternative to the anonymous classes for lots of reasons.

The anonymous classes were a nice way to achieve clojures in Java, but it was something natural to write a lot of boilerplate code to achieve something atomic. Let take a look on the following code snippet:

clojures in Java

It does a single thing – writing a message on the standard output, but in order to have it implemented, we wrote five lines of code. Which is not really cool and is a sign for a boilerplate code.

The same statement, but written with the terms of lambdas, would look like:

written with the terms of lambdas

This looks pretty neat and more readable, isn’t it ? ūüôā

But, there is, however, a problem with the lambda approach! Let’s first get back to the anonymous class and write our own implementation of the¬†java.awt.event.ActionListener¬†interface, which has a member variable within:

 implemnetation of the java.awt.event.ActionListener interface

Using anonymous classes, it won’t be a problem to create an anonymous implementation of¬†MyActionListener¬†and even to refer the nester member within the implementation:

anonymous implementation of MyActionListener

Now the question that stands is how to achieve the same functionality using lambdas?

The following snippet doesn’t compile:

following snippet doesn't compile

because the lambda expression we’re using is actually the implementation of the¬†ActionListener#actionPerformed(ActionEvent e)¬†method, not the¬†MyActionListener#actionPerformed(ActionEvent e)¬†method and this is why it fails to compile – the compiler doesn’t know about the variable¬†fourtyTwo¬†since it’s not defined in the¬†ActionListener¬†interface.

Now the problem is how to tell the JVM that the lambda we’re using is actual implementation of the¬†MyActionListener#actionPerformed(ActionEvent e)? And the answer is the following:

In Java 8 the abstract classes¬†are not functional interfaces, even if they contain a single abstract method! This is why, we can’t cast the lambda to¬†MyActionListener¬†when passing and to expect to have our hands on the variable named¬†fourtyTwo. On the other hand, however, functional interfaces can be extended and so we can create functional interfaces of our own.

we can create functional interfaces of our own

This is enough to say that our interface is functional, because

  • MyActionListener¬†is an interface and not an abstract class
  • MyActionListener¬†has a single abstract method and this is the derived¬†ActionListener#actionPerformed(ActionEvent e)

Now we can write the lambda expression, which would be an implementation of MyActionListener#actionPerformed(ActionEvent e) and pass it to the myButton.addActionListener() method:

 lambda expression, which would be an implementation of MyActionListener#actionPerformed(ActionEvent e) and pass it to the myButton.addActionListener() method

it compiles and successfully accesses the member variable and therefore the problem is solved.

Cheers!

Categories