Are function objects in Java

Is Java 8 a functional programming language?

Java 8 won't be ready until 2014, but the first trial version has recently been available as an Early Access download.

For a long time it has also been known where the content focus of the new Java version is: In Project Lambda, which finally integrates functional features in Java. In doing so, Oracle takes into account the fact that modern multicore architectures in Java can only be persuaded to top performance with great difficulty; more on this in a future article. First of all, the primary feature of functional programming languages ​​should be discussed: the support of functions as first-class objects.

Actually, it has always been possible in Java to treat functions as objects. A classic higher order function as we can e.g. write like this:

This function accepts a function and a list, applies the function to each element of the list, and returns a list of the results.

Unfortunately, the example is not yet complete because the type is not supplied with Java. Here is its definition:

The function is not much more difficult to implement than in functional languages. However, the use a problem is visible, at least in Java before version 8: There is no direct notation there to write functions-as-objects. Instead, the most space-saving way to create functional objects is to use the anonymous inner class:

This notation is an improvement over Java 1.0, where there were no inner classes. However, this notation is much too cumbersome and difficult to read for everyday use to the extent that it is common in functional languages. (And there are other problems as well.) Typical programming patterns from functional programming can in principle be implemented, but not really practicable.

Java 8 "Project Lambda" now offers a shorter notation for functions-than-objects via so-called Lambda expressionswhich allow to drastically shorten the call of:

This is a great thing and makes many programming techniques from functional programming in Java not only acceptable but also practicable.

It is particularly nice that the definition of does not have to be changed in order to benefit from the lambda expressions: The Java compiler automatically transforms the lambda expression into the anonymous inner class, which we still have to write in Java before version 8. The compiler does this via so-called Target typing: The context of a lambda expression determines the exact type, and the compiler inferences the code to be generated from this.

However, this feature is also a shortcoming, since lambda expressions do not have an independent existence. For example, the following does not work:

The compiler complains with:

In other words: functions that are generated by lambdas must always have a predefined interface as a type in Java. There are so-called single-method interfaces in question, i.e. those interfaces that have exactly one method. This is in contrast to functional languages ​​(more precisely, the statically typed functional languages), in which functional types of the form are built in beforehand. In particular, this means that every arity (i.e. every possible number of parameters) requires its own interface: The interface from above only works for single-digit functions. The distinction between primitive types and reference types also requires further overloading. Accordingly, Java 8 comes with a whole zoo of specially defined function types that can be viewed here. The 42 interfaces listed there include melodious names like, or. (There aren't even functions with more than two parameters.)

These many specialized interfaces mean that many higher-order functions are still not as useful as they are in functional languages. For example, it is easy to write a composition function:

This works - as - only for, but not for the other interfaces for single-digit functions that are defined in. That alone is,,,,,,,,, ,,,,, and.

In other words: Java 8 now has lambda expressions and function objects, but no function types - the answer to the question in the title is therefore a clear “yes and no”.

This restriction is bitter for functional programmers, but understandable from the point of view of the Java makers: They want to develop Java further without changing the core. The introduction of the correct types of functions would, however, require massive changes in the JVM, which Oracle has so far avoided. Let's hope it still happens one day.