What are functional interfaces used for in Java 8?

Question

I came across a new term in Java 8: "functional interface". I could only find one use of it while working with lambda expressions.

Java 8 provides some built-in functional interfaces and if we want to define any functional interface then we can make use of the @FunctionalInterface annotation. It will allow us to declare only a single method in the interface.

For example:

@FunctionalInterface
interface MathOperation {
    int operation(int a, int b);
}

How useful it is in Java 8 other than just working with lambda expressions?

(The question here is different from the one I asked. It is asking why we need functional interfaces while working with lambda expressions. My question is: What are the other uses of functional interfaces besides use with lambda expressions?)

Solution 1

@FunctionalInterface annotation is useful for compilation time checking of your code. You cannot have more than one method besides static, default and abstract methods that override methods in Object in your @FunctionalInterface or any other interface used as a functional interface.

But you can use lambdas without this annotation as well as you can override methods without @Override annotation.

From docs

a functional interface has exactly one abstract method. Since default methods have an implementation, they are not abstract. If an interface declares an abstract method overriding one of the public methods of java.lang.Object, that also does not count toward the interface's abstract method count since any implementation of the interface will have an implementation from java.lang.Object or elsewhere

This can be used in lambda expression:

public interface Foo {
  public void doSomething();
}

This cannot be used in lambda expression:

public interface Foo {
  public void doSomething();
  public void doSomethingElse();
}

But this will give compilation error:

@FunctionalInterface
public interface Foo {
  public void doSomething();
  public void doSomethingElse();
}

Invalid '@FunctionalInterface' annotation; Foo is not a functional interface

Solution 2

The documentation makes indeed a difference between the purpose

An informative annotation type used to indicate that an interface type declaration is intended to be a functional interface as defined by the Java Language Specification.

and the use case

Note that instances of functional interfaces can be created with lambda expressions, method references, or constructor references.

whose wording does not preclude other use cases in general. Since the primary purpose is to indicate a functional interface, your actual question boils down to “Are there other use cases for functional interfaces other than lambda expressions and method/constructor references?”

Since functional interface is a Java language construct defined by the Java Language Specification, only that specification can answer that question:

JLS §9.8. Functional Interfaces:

…

In addition to the usual process of creating an interface instance by declaring and instantiating a class (§15.9), instances of functional interfaces can be created with method reference expressions and lambda expressions (§15.13, §15.27).

So the Java Language Specification doesn’t say otherwise, the only use case mentioned in that section is that of creating interface instances with method reference expressions and lambda expressions. (This includes constructor references as they are noted as one form of method reference expression in the specification).

So in one sentence, no, there is no other use case for it in Java 8.

Solution 3

As others have said, a functional interface is an interface which exposes one method. It may have more than one method, but all of the others must have a default implementation. The reason it's called a "functional interface" is because it effectively acts as a function. Since you can pass interfaces as parameters, it means that functions are now "first-class citizens" like in functional programming languages. This has many benefits, and you'll see them quite a lot when using the Stream API. Of course, lambda expressions are the main obvious use for them.

Solution 4

Not at all. Lambda expressions are the one and only point of that annotation.

Solution 5

A lambda expression can be assigned to a functional interface type, but so can method references, and anonymous classes.

One nice thing about the specific functional interfaces in java.util.function is that they can be composed to create new functions (like Function.andThen and Function.compose, Predicate.and, etc.) due to the handy default methods they contain.

View more solutions

Comments

[Kulbhushan Singh]

It looks duplcate to this link. They also talk about why there should be only one method in Functional Interface. stackoverflow.com/questions/33010594/…

[Madhusudan]

@KulbhushanSingh I saw this question before posting... Both questions sense difference...

[hansvb]

Well, lamdbas work without the annotation as well. It's an assertion just like @Override to let the compiler know that you intended to write something that was "functional" (and get an error if you slipped).

[Holger]

To be more precise, you have to have exactly one abstract method that doesn’t override a method in java.lang.Object in a functional interface.

[Holger]

…and it’s slightly different to “not have more than one public method besides static and default”…

[Holger]

Straight to the point and the correct answer, though a bit short. I took the time to add a more elaborated answer saying the same thing with more words…

[Sergii Bishyr]

@lwpro2 a typo. Sure it was about obj -> obj.doSomething(anyObj). Thanks for noticing!

[Sergii Bishyr]

@lwpro2 but even with this I'm unable to reproduce the issue in most recent versions of java

[Pr0methean]

What if a method overridden from Object is redeclared in a manner incompatible with Object's implementation -- e.g. narrowing the return type of clone()?

[saran3h]

Still don't understand any point of having it. Why would anyone on earth bothers checking how many methods does his/her interface has. Marker interfaces still have a point and a specific purpose. The documentation and the answer only explain what it does, not how is it of any use at all. And "use" is exactly what the OP asked. So I wouldn't recommend this answer.

[Sergii Bishyr]

@saran3h thanks for your comment. The concept of the functional interface is completely different question. The point of having this annotation on top of your interface is to make it clear to the client of this interface how it is used, and make sure no one add more methods consequently breaking the clients of your interface.

[K.Nicholas]

You should elaborate on this comment more. What about method references and new functions?

[VNT]

@Sergii Bishyr But without declaring FunctionalInterface annotation on the interface, we have got the compilation errors if we declare more than one method in the interface and using lambda expressions. Then what is the use of FunctionalInterface annotation?

[Sergii Bishyr]

@VNT the compilation error get the clients of this interface, but not the interface itself can change. With this annotation the compilation error is on the interface, so you make sure that nobody will break the clients of your interface.

[sofs1]

Should your first two examples have 'abstract' keyword to it?

[Ketan]

@sofs1 Methods declared in interfaces are by default both public and abstract. You have to use abstract keyword in case of methods in abstract class. However it is fine to use abstract keyword for methods in interface also. They have permitted it for compatibility of older java version but it is discouraged.

[sheikh]

This shows how to use them but doesn't explain why we need them though.

[Naman]

Might just be asking for a little too much or irrelevant(you can choose not to answer), but what would you suggest when someone created a utility public static String generateTaskId() versus to make it more "functional" someone else chose to write it as public class TaskIdSupplier implements Supplier<String> with the get method using the existing generation implementation. Is that a misuse of functional interfaces, especially reusing the Supplier from the JDK built-in? PS: I couldn't find a better place/Q&A to ask this. Happy to migrate if you could suggest.

[Holger]

@Naman you are not making the utility method more functional when you create a named class TaskIdSupplier. Now, the question is why you created the named class. There are scenarios where such a named type is needed, e.g. when you want to support finding the implementation via ServiceLoader. There is nothing wrong with letting it implement Supplier then. But when you don’t need it, don’t create it. When you only need a Supplier<String>, it’s already sufficient to use DeclaringClass::generateTaskId and eliminating the need for an explicit class is the point of this language feature.

[Naman]

To be honest, I was looking towards a justification for a recommendation that I was passing on. For some reason at work I didn't really felt that the TaskIdSupplier implementation was worth the effort, but then the concept of ServiceLoader totally skipped off my mind. Encountered a few questions during these discussions we were having such as What is the use of Supplier's public existence when one can go ahead and develop their own interfaces? and Why not have public static Supplier<String> TASK_ID_SUPPLIER = () ->... as a global constant?. (1/2)

[Naman]

All of that seems to be simple and basic, while in the course of implementation to make a decision or while designing the services, it seems tough to provide justifications over such questions and that certainly needs a hands-on with a variety of language features.

[Holger]

@Naman the idiomatic way to represent functions in Java are methods and evaluating those functions is identical to invoking them. Never should a developer be forced to do variable.genericMethodName(args) instead of meaningfulMethodName(args). Using a class type to represent a function, whether via lambda expression/ method reference or a manually created class, is only a vehicle to pass the function around (in the absence of true function types in Java). This should only be done when needed.

[Holger]

When you have a small code fragment only being passed around, you may create a lambda expression encapsulating it. Whenever there’s also a need to invoke it like a method (this includes scenarios with a need for testing, when the code fragment is not trivial), create a named method that can be invoked and use a method reference or a lambda expression/ explicit class encapsulating a call, to pass it around when needed. Constants are only useful when you don’t trust the efficiency of lambda expressions or method references embedded in your code, in other words, they are almost never needed.

[surajs1n]

Don't you think, the compiler will anyways throw an error in case of the interface is not compliant. Then why even we should use @FunctionalInterface? Just wondering...

[Sergii Bishyr]

It’s true for the case when you are the client of your own interface. But not for the case when it’s part of a library. Also, usually the software projects is written by many people, so this is a way to tell other developers that this interface is can be used as a lambda, so it’s better not to add another abstract method