Feature Research

With any new feature, you’ll first need to understand what the feature itself encompasses. That might be as simple as a small syntax change or as complex as a new way to build Java binaries. Our lambda expressions fall somewhere in between. Let’s look at a very simple expression and then use it in a bit of code.

So where would we begin with lambda expressions? If you have some programming experience from a functional language like LISP, perhaps you already know what lambdas are and where they might be used. If you don’t know much about the term, you could search online. If the feature has been available for some time (like lambda expressions in Java as we write this edition of the book at the dawn of 2020) you will likely turn up some good tutorials. If it’s a very new feature or your initial searches are not turning up useful results, you can go back to the JSR. For lambda expressions, again that’s JSR 335. Section 2 of a JSR is the Request section and usually contains some helpful hints. Here’s the opening paragraph from section 2.7 providing a short description of the feature:

We propose extending the Java Language to support compact lambda expressions (otherwise known as closures or anonymous methods.) Additionally, we will extend the language to support a conversion known as “SAM conversion” to allow lambda expressions to be used where a single-abstract-method interface or class is expected, enabling forward compatibility of existing libraries.

JSR 335 Section 2.7

There are several keywords in just those few sentences that could help you search for more background material. What are “closures”? What is “SAM conversion” The last sentence even gives you clue about where lambda expressions would be used: wherever a particular type of interface or class is allowed. That paragraph is certainly not enough to fully grasp lambda expressions on their own, but again, it has some hints about the right topics to research.

The rest of the JSR should give you more documentation you can read. It may include content that is immediately useful, but more often you’ll find links to supporting material, design documents by members of the team working on the JSR, or even earlier drafts of the request itself so you can see its evolution. You should also be able to find more concrete information in the Java documentation for the version containing your feature (Java 8 in our lambda example). Even the early access builds will have some official documentation available.

You should feel free to do some of that research on lambda expressions right now. Read some of the supporting documents from the JSR. Check out the Oracle tutorials on lambdas in Java 8. Try searching online at sites like Stack Overflow. You’ll want to become comfortable finding examples you understand from sources you trust. New releases of Java are now rolling out every six months. It will pay to know how you can best stay up-to-date!

Basic Lambda Expressions

While we hope you do some of that research homework, we do want to show you some examples of how compact and powerful lambda expressions can be. The basic syntax of a lambda expression is simple:

(params) -> expression or block

The “params” are zero or more named (and possibly typed) parameters that are passed to the expression on the right side of the new → operator. The expression (or block of statements inside the usual pair of curly braces) can return a value or execute some code. For example, here’s a common “increment” lambda expression for a single input parameter:

(n) -> n + 1

It’s important to note that this lambda expression does not alter the value of the parameter n. It just performs a calculation. You could think of this particular example as a “next” operation for integers. If you had some other context that used a next() method to do some work, you could supply this lambda expression. That becomes more powerful when you want to use that same context to work with other types of objects like strings or dates. What is the “next” date? Is it the next day? the next year? With a lambda expression, you can provide a tailored version of “next” right where you need it.

You can pass more than one parameter to your function. Or you can pass none. In the wild, you will see all these variations including a popular shortcut: if you have exactly one parameter, you do not need to use parentheses on the left side of the expression. The following expressions are all valid:

// 1 parameter
(n) -> n + 1

n -> n + 1

n -> System.out.println("Working on " + n)

// No parameters
() -> System.out.println("Done working")

// Multiple parameters
(a, b, c) -> (a + b + c) / 3

Consider sorting lists. If we have a list of numbers (we’ll use the Integer wrapper class in this example), sorting is straightforward:

jshell> ArrayList<Integer> numbers = new ArrayList<>();
numbers ==> []

jshell> numbers.add(19)
$5 ==> true

jshell> numbers.add(6)
$6 ==> true

jshell> numbers.add(12)
$7 ==> true

jshell> numbers.add(7)
$8 ==> true

jshell> numbers
numbers ==> [19, 6, 12, 7]

jshell> Collections.sort(numbers)

jshell> numbers
numbers ==> [6, 7, 12, 19]

But what if we wanted the numbers in reverse order? Previously, we would have to write a special class that implements the Comparator interface or provide an anonymous inner class:

jshell> Collections.sort(numbers, new Comparator<Integer>() {
   ...>   public int compare(Integer a, Integer b) {
   ...>     return b.compareTo(a);
   ...>   }
   ...> })

jshell> numbers
numbers ==> [19, 12, 7, 6]

Fair enough, the anonymous inner class worked, but it was a little bulky. We could use a lambda expression instead to write a more compact version:

jshell> Collections.sort(numbers) // put the array back in ascending order

jshell> numbers
numbers ==> [6, 7, 12, 19]

jshell> Collections.sort(numbers, (a, b) -> b.compareTo(a))

jshell> numbers
numbers ==> [19, 12, 7, 6]

Wow! That is much cleaner. You have to understand what the Collections.sort() method is expecting as arguments and know that the Comparator interface has only one abstract method (i.e. it is a single-abstract-method—or SAM—interface; remember the JSR description?). But when you do have the right environment, a lambda expression can be quite efficient.

We could take these techniques and rewrite several of our “list generating” examples from throughout the book. Let’s take the snippet from “File operations” using java.io.File objects. We could sort and list the names using the actual File objects with the help of the Arrays.asList() method (to get an Iterable) and then use a lambda expression with the forEach() method like so:

File tmpDir = new File("/tmp" );
File [] files = tmpDir.listFiles();

Arrays.sort(files, (a,b) -> a.getName().compareTo(b.getName()))
Arrays.asList(files).forEach(n -> System.out.println(n.getName()))

We were able to get file names before without lambdas, but in many cases we can write more concise code with them. You have to get comfortable with the lambda syntax, of course, but that’s what all this practice is for!

Method References

That process of sorting complex objects using one of their attributes is so common, in fact, there’s a Java helper method that creates the right function already in the API. The Comparator.comparing() static method can help write something similar to our lambda expression that uses compareTo() in the previous section. It takes advantage of method references, a simplified type of lambda expression that uses existing methods from other classes.

There are many details and use cases for method references that we won’t go into here, but the basic syntax and usage is straightforward. You place the :: separator between a class name and a method name. The Comparator.comparing() method is expecting a reference to a method that can be used on the objects being sorted (i.e. you should still call appropriate methods). When sorting our File objects, we can use any of the getter methods that return sort-friendly information like the name or size of the file.

Arrays.sort(files, Comparator.comparing(File::getName));

That is pretty clean! And we can see exactly what is intended: we are going to sort a bunch of files by comparing their names. Which, of course, is exactly what we did with lambdas in the previous section. Remember, it’s not that using method references is better—they can always be replaced by a lambda expression—it’s that many times method references can provide more readable code once you get used to the new syntax (just like with lambda expressions themselves).²

Eventful Lambdas

We have seen a few other code examples that have similarly constrained environments. Think back to the many event handlers in Chapter 10. Several listeners were exactly the single-abstract-method variety like the ActionListener interface used by JButton or JMenuItem. Where appropriate, we can use a lambda expression to simplify our event handling code. We often have simple, temporary handlers to check the basic ability to click a button like so:

    JButton okButton = new JButton("OK");
    okButton.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent ae) {
            System.out.println("OK pressed!");
        }
    });

We can now use a lambda expression to shorten that up quite a bit. It makes writing such quick proof-of-concept code for several buttons much easier:

    JButton okButton = new JButton("OK");
    okButton.addActionListener(ae -> System.out.println("OK pressed"));
    JButton noButton = new JButton("Cancel");
    noButton.addActionListener(ae -> System.out.println("Cancel pressed"));

Great! Lambda expressions can provide a nice way to tackle situations where a little dynamic code is needed. Not every event handler will lend itself to this type of conversion, or course. But many will and the more compact notation can help make your code more readable, too.

Replacing Runnable

Another popular interace that fits this model is the Runnable interface introduced in Chapter 9 and used again in Chapter 10. We saw examples of using both inner classes and anonymous inner classes to create new Thread objects. The SwingUtilities.invokeLater() method also needed a Runnable instance as an argument. We can use a lambda expression in these cases as well. Recall the ProgressPretender example from “SwingUtilities and component updates”. We were already inside the run() method of a class that implements the Runnable interface when we had to create a second, anonymous instance of Runnable to update a label:

    public void run() {
        while (progress <= 100) {
            SwingUtilities.invokeLater(new Runnable() {
                public void run() {
                    label.setText(progress + "%");
                }
            });
        // ...

But now we can use a lambda expression to keep the focus on the real work the thread is doing:

    public void run() {
        while (progress <= 100) {
            SwingUtilities.invokeLater(() -> label.setText(progress + "%"));
        // ...

Again, a much more compact—and hopefully readable—bit of code. It is not a required change, nor does it improve performace of the application, but if you (and any members of your team in a work setting) understand lambda expressions, this code can increase maintainability and leave you more time to work on other problems.