In java 8, an abstract class with only one abstract method is not a functional interface (JSR 335).
This interface
is a functional interface:
public interface MyFunctionalInterface { public abstract void myAbstractMethod(); public default void method() { myAbstractMethod(); } }
but this abstract class
is not:
public abstract class MyFunctionalAbstractClass { public abstract void myAbstractMethod(); public void method() { myAbstractMethod(); } }
So i can't use the abstract class as a target for a lambda expressions and method references.
public class Lambdas { public static void main(String[] args) { MyFunctionalAbstractClass functionalAbstractClass = () -> {}; } }
The compilation error is: The target type of this expression must be a functional interface
.
Why the language designers imposed this restriction ?
Abstract classes have no restrictions on field and method modifiers, while in an interface, all are public by default. We can have instance and static initialization blocks in an abstract class, whereas we can never have them in the interface.
A functional interface is an interface that has only one abstract method. It can contain any number of default and static methods but the abstract method it contains is exactly one.
Java Functional Interfaces. An Interface that contains exactly one abstract method is known as functional interface. It can have any number of default, static methods but can contain only one abstract method. It can also declare methods of object class.
A functional interface is an interface that contains only one abstract method. They can have only one functionality to exhibit. From Java 8 onwards, lambda expressions can be used to represent the instance of a functional interface. A functional interface can have any number of default methods.
This has been an important topic since the very inception of the Lambda project and has received a lot of thought. Brian Goetz, the chief Java Language architect, strongly supports the view of lambda as a function, not an object. Quote:
It is my belief that the best direction for evolving Java is to encourage a more functional style of programming. The role of Lambda is primarily to support the development and consumption of more functional-like libraries
I am optimistic about Java's future, but to move forward we sometimes have to let go of some comfortable ideas. Lambdas-are-functions opens doors. Lambdas-are-objects closes them. We prefer to see those doors left open.
Here is a link to the quote's source and here is Brian's more recent post which reiterates the same philosophical points and reaffirms them with additional, more practical arguments:
Making the model simpler opens doors to all sorts of VM optimizations. (Jettisoning identity is key here.) Functions are values. Modeling them as objects makes them heavier, and more complex, than they need to be.
Before throwing this use case under the bus, we did some corpus analysis to found how often abstract class SAMs are used compared to interface SAMs. We found that in that corpus, only 3% of the lambda candidate inner class instances had abstract classes as their target. And most of them were amenable to simple refactorings where you added a constructor/factory that accepted a lambda that was interface-targeted.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With