Functional Interfaces

Imagine you want to call a subroutine that someone else wrote. Before you write the call, you have to answer a few questions. What is the subroutine called? How many values does it expect you to pass in, and what type is each one? What type of value does it send back? If any of these answers is wrong, the call cannot be made correctly. The information that answers these questions is the subroutine's specification.

A functional interface is one way to write that specification down in a Java file. It is a file that holds a specification for exactly one subroutine, and it is defined in a .java file just as a class is. This article works through two short functional interface declarations taken from a Java source. Your goal is to learn what makes an interface count as functional, how to read its declaration, and how to check a use of the subroutine against the declaration.

The definition has two parts, and you should check them separately. The first check is that the type is an interface. A declaration that begins with the word interface, rather than class, passes this check. The second check is that the interface contains exactly one abstract method. Counting the methods inside the braces is how you apply it. If there is exactly one method, the declaration passes the second check.

The first example in the source is a whole functional interface squeezed onto one line. It is saved in a file named FunctionR2R.java, which matches the name of the interface, as with any Java class. The declaration reads as follows.

Read the declaration from left to right. The word public makes the interface visible, and the word interface tells you this is an interface rather than a class. FunctionR2R is the interface name. Inside the braces there is one line that names a subroutine, valueAt. The first word before the method name is the return type, which here is double, so the subroutine gives back a double. The items inside the parentheses are the parameters. Here there is one parameter, of type double, named x. Put together, the declaration says: there is a subroutine called valueAt, it takes one double, and it returns a double. The source describes FunctionR2R as a functional interface representing a function that takes a double and returns a double.

The parameter name x is written in the declaration, but it is not really part of the specification. What matters to a caller is how many parameters there are and what type each one has. The name is a label that helps a reader, and it does not change what a valid call looks like.

Before you look at the file's contents, make a prediction. Look at the one-line declaration again and ask yourself how much of the file is about how valueAt actually computes its answer, and how much is only about the shape of the call. Commit to an answer before you read the next block.

Your prediction is checked by reading the declaration itself. The trace attached to this lesson runs the real Java declaration so you can watch the structure as it is read. If the file did contain computation, you would expect to find it inside the braces. You do not find it there, so the file records a specification and nothing more.

The source gives a second example with a different shape. It describes a subroutine that does not return anything and takes two parameters, an array of strings and an int. The source does not name the array parameter in the excerpt, so this article uses items as an illustrative name. The declaration is shown below.

The two declarations share one structure even though their contents differ. Each one names a single subroutine and then states its parameters and its return type. The difference is in the types. The return type of ArrayProcessor is void, which means the process method does not hand a value back to the caller. A void return type is still a return type, and it tells the caller that no value comes back. The count parameter tells the processor how many entries to work with, which contrasts with FunctionR2R, where the single input is one double.

The specification records three facts about one subroutine. The first is the subroutine's name. The second is its parameters, meaning how many there are and their types. The third is its return type. Each fact has a fixed place in the declaration. In FunctionR2R, the name is valueAt, the parameter is one double, and the return type is double. In ArrayProcessor, the name is process, the parameters are a String array and an int, and the return type is void.

The word one matters here. A single functional interface is about a single subroutine. If you need to describe two different subroutines, you write two interfaces. This is what the source means when it describes the interface as a specification for a single subroutine.

Once you know the three facts, you can debug a broken use of a subroutine by asking where the use departs from the specification. You do not need to guess. You compare the call against the declaration line by line, starting with the name, then the parameters, then the return type.

The before-and-after pair shows the fix. The first call passes two numbers, so it diverges from the one-double parameter list. The corrected call passes a single double, which matches the declaration. The return type is unchanged by this fix because the declaration already says the method returns a double.