Chapter 6. Interfaces, Lambda Expressions, and Inner Classes

You have now seen all the basic tools for object-oriented programming in Java. This chapter shows you several advanced techniques that are commonly used. Despite their less obvious nature, you will need to master them to complete your Java tool chest.

The first technique, called interfaces, is a way of describing what classes should do, without specifying how they should do it. A class can implement one or more interfaces. You can then use objects of these implementing classes whenever conformance to the interface is required. After we cover interfaces, we move on to lambda expressions, a concise way for expressing a block of code that can be executed at a later point in time. Using lambda expressions, you can express code that uses callbacks or variable behavior in an elegant and concise fashion.

Click here to view code image

public interface Comparable
{
   int compareTo(Object other);
}

This means that any class that implements the Comparable interface is required to have a compareTo method, and the method must take an Object parameter and return an integer.

All methods of an interface are automatically public. For that reason, it is not necessary to supply the keyword public when declaring a method in an interface.

Of course, there is an additional requirement that the interface cannot spell out: When calling x.compareTo(y), the compareTo method must actually be able to compare the two objects and return an indication whether x or y is larger. The method is supposed to return a negative number if x is smaller than y, zero if they are equal, and a positive number otherwise.

This particular interface has a single method. Some interfaces have multiple methods. As you will see later, interfaces can also define constants. What is more important, however, is what interfaces cannot supply. Interfaces never have instance fields. Before Java SE 8, methods were never implemented in interfaces. (As you will see in Section 6.1.4, “Static Methods,” on p. 298 and Section 6.1.5, “Default Methods,” on p. 298, it is now possible to supply simple methods in interfaces. Of course, those methods cannot refer to instance fields—interfaces don’t have any.)

Supplying instance fields and methods that operate on them is the job of the classes that implement the interface. You can think of an interface as being similar to an abstract class with no instance fields. However, there are some differences between these two concepts—we look at them later in some detail.

Now suppose we want to use the sort method of the Arrays class to sort an array of Employee objects. Then the Employee class must implement the Comparable interface.

Click here to view code image

class Employee implements Comparable

Of course, now the Employee class needs to supply the compareTo method. Let’s suppose that we want to compare employees by their salary. Here is an implementation of the compareTo method:

Click here to view code image

public int compareTo(Object otherObject)
{
   Employee other = (Employee) otherObject;
   return Double.compare(salary, other.salary);
}

Here, we use the static Double.compare method that returns a negative if the first argument is less than the second argument, 0 if they are equal, and a positive value otherwise.

We can do a little better by supplying a type parameter for the generic Comparable interface:

Click here to view code image

class Employee implements Comparable<Employee>
{
   public int compareTo(Employee other)
   {
      return Double.compare(salary, other.salary);
   }
   ...
}

Note that the unsightly cast of the Object parameter has gone away.

Listing 6.1 presents the full code for sorting an array of instances of the class Employee (Listing 6.2) for sorting an employee array.

Listing 6.1 interfaces/EmployeeSortTest.java

Click here to view code image

 1   package interfaces;
 2
 3   import java.util.*;
 4
 5   /**
 6    * This program demonstrates the use of the Comparable interface.
 7    * @version 1.30 2004-02-27
 8    * @author Cay Horstmann
 9    */
10   public class EmployeeSortTest
11   {
12      public static void main(String[] args)
13      {
14         Employee[] staff = new Employee[3];
15
16         staff[0] = new Employee("Harry Hacker", 35000);
17         staff[1] = new Employee("Carl Cracker", 75000);
18         staff[2] = new Employee("Tony Tester", 38000);
19
20         Arrays.sort(staff);
21
22         // print out information about all Employee objects
23         for (Employee e : staff)
24            System.out.println("name=" + e.getName() + ",salary=" + e.getSalary());
25      }
26   }

Listing 6.2 interfaces/Employee.java

Click here to view code image

 1   package interfaces;
 2
 3   public class Employee implements Comparable<Employee>
 4   {
 5      private String name;
 6      private double salary;
 7
 8      public Employee(String name, double salary)
 9      {
10        this.name = name;
11        this.salary = salary;
12      }
13
14      public String getName()
15      {
16         return name;
17      }
18
19      public double getSalary()
20      {
21         return salary;
22      }
23
24      public void raiseSalary(double byPercent)
25      {
26         double raise = salary * byPercent / 100;
27         salary += raise;
28      }
29
30      /**
31       * Compares employees by salary
32       * @param other another Employee object
33       * @return a negative value if this employee has a lower salary than
34       * otherObject, 0 if the salaries are the same, a positive value otherwise
35       */
36      public int compareTo(Employee other)
37      {
38         return Double.compare(salary, other.salary);
39      }
40   }

Click here to view code image

x = new Comparable(. . .); // ERROR

However, even though you can’t construct interface objects, you can still declare interface variables.

Comparable x; // OK

An interface variable must refer to an object of a class that implements the interface:

Click here to view code image

x = new Employee(. . .); // OK provided Employee implements Comparable

Next, just as you use instanceof to check whether an object is of a specific class, you can use instanceof to check whether an object implements an interface:

Click here to view code image

if (anObject instanceof Comparable) { . . . }

Just as you can build hierarchies of classes, you can extend interfaces. This allows for multiple chains of interfaces that go from a greater degree of generality to a greater degree of specialization. For example, suppose you had an interface called Moveable.

Click here to view code image

public interface Moveable
{
   void move(double x, double y);
}

Then, you could imagine an interface called Powered that extends it:

Click here to view code image

public interface Powered extends Moveable
{
   double milesPerGallon();
}

Although you cannot put instance fields or static methods in an interface, you can supply constants in them. For example:

Click here to view code image

public interface Powered extends Moveable
{
   double milesPerGallon();
   double SPEED_LIMIT = 95; // a public static final constant
}

Just as methods in an interface are automatically public, fields are always public static final.

Some interfaces define just constants and no methods. For example, the standard library contains an interface SwingConstants that defines constants NORTH, SOUTH, HORIZONTAL, and so on. Any class that chooses to implement the SwingConstants interface automatically inherits these constants. Its methods can simply refer to NORTH rather than the more cumbersome SwingConstants.NORTH. However, this use of interfaces seems rather degenerate, and we do not recommend it.

While each class can have only one superclass, classes can implement multiple interfaces. This gives you the maximum amount of flexibility in defining a class’s behavior. For example, the Java programming language has an important interface built into it, called Cloneable. (We will discuss this interface in detail in Section 6.2.3, “Object Cloning,” on p. 306.) If your class implements Cloneable, the clone method in the Object class will make an exact copy of your class’s objects. If you want both cloneability and comparability, simply implement both interfaces. Use commas to separate the interfaces that you want to implement:

Click here to view code image

class Employee implements Cloneable, Comparable

Click here to view code image

abstract class Comparable // why not?
{
   public abstract int compareTo(Object other);
}

The Employee class would then simply extend this abstract class and supply the compareTo method:

Click here to view code image

class Employee extends Comparable // why not?
{
   public int compareTo(Object other) { . . . }
}

There is, unfortunately, a major problem with using an abstract base class to express a generic property. A class can only extend a single class. Suppose the Employee class already extends a different class, say, Person. Then it can’t extend a second class.

Click here to view code image

class Employee extends Person, Comparable // Error

But each class can implement as many interfaces as it likes:

Click here to view code image

class Employee extends Person implements Comparable // OK

Other programming languages, in particular C++, allow a class to have more than one superclass. This feature is called multiple inheritance. The designers of Java chose not to support multiple inheritance, because it makes the language either very complex (as in C++) or less efficient (as in Eiffel).

Instead, interfaces afford most of the benefits of multiple inheritance while avoiding the complexities and inefficiencies.

Click here to view code image

public interface Path
{
   public static Path get(String first, String... more) {
      return FileSystems.getDefault().getPath(first, more);
   }
   ...
}

Then the Paths class is no longer necessary.

It is unlikely that the Java library will be refactored in this way, but when you implement your own interfaces, there is no longer a reason to provide a separate companion class for utility methods.

Click here to view code image

public interface Comparable<T>
{
   default int compareTo(T other) { return 0; }
       // By default, all elements are the same
}

Of course, that is not very useful since every realistic implementation of Comparable would override this method. But there are other situations where default methods can be useful. For example, as you will see in Chapter 11, if you want to be notified when a mouse click happens, you are supposed to implement an interface that has five methods:

Click here to view code image

public interface MouseListener
{
   void mouseClicked(MouseEvent event);
   void mousePressed(MouseEvent event);
   void mouseReleased(MouseEvent event);
   void mouseEntered(MouseEvent event);
   void mouseExited(MouseEvent event);
}

Most of the time, you only care about one or two of these event types. As of Java SE 8, you can declare all of the methods as default methods that do nothing.

Click here to view code image

public interface MouseListener
{
   default void mouseClicked(MouseEvent event) {}
   default void mousePressed(MouseEvent event) {}
   default void mouseReleased(MouseEvent event) {}
   default void mouseEntered(MouseEvent event) {}
   default void mouseExited(MouseEvent event) {}
}

Then programmers who implement this interface only need to override the listeners for the events they actually care about.

A default method can call other methods. For example, a Collection interface can define a convenience method

Click here to view code image

public interface Collection
{
   int size(); // An abstract method
   default boolean isEmpty()
   {
        return size() == 0;
   }
   ...
}

Then a programmer implementing Collection doesn’t have to worry about implementing an isEmpty method.

An important use for default methods is interface evolution. Consider for example the Collection interface that has been a part of Java for many years. Suppose that a long time ago, you provided a class

Click here to view code image

public class Bag implements Collection

Later, in Java SE 8, a stream method was added to the interface.

Suppose the stream method was not a default method. Then the Bag class no longer compiles since it doesn’t implement the new method. Adding a nondefault method to an interface is not source compatible.

But suppose you don’t recompile the class and simply use an old JAR file containing it. The class will still load, even with the missing method. Programs can still construct Bag instances, and nothing bad will happen. (Adding a method to an interface is binary compatible.) However, if a program calls the stream method on a Bag instance, an AbstractMethodError occurs.

Making the method a default method solves both problems. The Bag class will again compile. And if the class is loaded without being recompiled and the stream method is invoked on a Bag instance, the Collection.stream method is called.

1. Superclasses win. If a superclass provides a concrete method, default methods with the same name and parameter types are simply ignored.

2. Interfaces clash. If a superinterface provides a default method, and another interface supplies a method with the same name and parameter types (default or not), then you must resolve the conflict by overriding that method.

Let’s look at the second rule. Consider another interface with a getName method:

Click here to view code image

interface Named
{
   default String getName() { return getClass().getName() + "_" + hashCode(); }
}

What happens if you form a class that implements both of them?

Click here to view code image

class Student implements Person, Named
{
   ...
}

The class inherits two inconsistent getName methods provided by the Person and Named interfaces. Instead of choosing one over the other, the Java compiler reports an error and leaves it up to the programmer to resolve the ambiguity. Simply provide a getName method in the Student class. In that method, you can choose one of the two conflicting methods, like this:

Click here to view code image

class Student implements Person, Named
{
   public String getName() { return Person.super.getName(); }
   ...
}

Now assume that the Named interface does not provide a default implementation for getName:

interface Named
{
   String getName();
}

Can the Student class inherit the default method from the Person interface? This might be reasonable, but the Java designers decided in favor of uniformity. It doesn’t matter how two interfaces conflict. If at least one interface provides an implementation, the compiler reports an error, and the programmer must resolve the ambiguity.

We just discussed name clashes between two interfaces. Now consider a class that extends a superclass and implements an interface, inheriting the same method from both. For example, suppose that Person is a class and Student is defined as

Click here to view code image

class Student extends Person implements Named { ... }

In that case, only the superclass method matters, and any default method from the interface is simply ignored. In our example, Student inherits the getName method from Person, and it doesn’t make any difference whether the Named interface provides a default for getName or not. This is the “class wins” rule.

The “class wins” rule ensures compatibility with Java SE 7. If you add default methods to an interface, it has no effect on code that worked before there were default methods.

Click here to view code image

public interface ActionListener
{
   void actionPerformed(ActionEvent event);
}

The timer calls the actionPerformed method when the time interval has expired.

Suppose you want to print a message “At the tone, the time is ...”, followed by a beep, once every 10 seconds. You would define a class that implements the ActionListener interface. You would then place whatever statements you want to have executed inside the actionPerformed method.

Click here to view code image

class TimePrinter implements ActionListener
{
   public void actionPerformed(ActionEvent event)
   {
      System.out.println("At the tone, the time is " + new Date());
      Toolkit.getDefaultToolkit().beep();
   }
}

Note the ActionEvent parameter of the actionPerformed method. This parameter gives information about the event, such as the source object that generated it—see Chapter 11 for more information. However, detailed information about the event is not important in this program, and you can safely ignore the parameter.

Next, you construct an object of this class and pass it to the Timer constructor.

Click here to view code image

ActionListener listener = new TimePrinter();
Timer t = new Timer(10000, listener);

The first parameter of the Timer constructor is the time interval that must elapse between notifications, measured in milliseconds. We want to be notified every 10 seconds. The second parameter is the listener object.

Finally, you start the timer.

t.start();

Every 10 seconds, a message like

Click here to view code image

At the tone, the time is Wed Apr 13 23:29:08 PDT 2016

is displayed, followed by a beep.

Listing 6.3 puts the timer and its action listener to work. After the timer is started, the program puts up a message dialog and waits for the user to click the OK button to stop. While the program waits for the user, the current time is displayed at 10-second intervals.

Be patient when running the program. The “Quit program?” dialog box appears right away, but the first timer message is displayed after 10 seconds.

Note that the program imports the javax.swing.Timer class by name, in addition to importing javax.swing.* and java.util.*. This breaks the ambiguity between javax.swing.Timer and java.util.Timer, an unrelated class for scheduling background tasks.

Listing 6.3 timer/TimerTest.java

Click here to view code image

 1   package timer;
 2
 3   /**
 4      @version 1.01 2015-05-12
 5      @author Cay Horstmann
 6   */
 7
 8   import java.awt.*;
 9   import java.awt.event.*;
10   import java.util.*;
11   import javax.swing.*;
12   import javax.swing.Timer;
13   // to resolve conflict with java.util.Timer
14
15   public class TimerTest
16   {
17      public static void main(String[] args)
18      {
19         ActionListener listener = new TimePrinter();
20
21         // construct a timer that calls the listener
22         // once every 10 seconds
23         Timer t = new Timer(10000, listener);
24         t.start();
25
26         JOptionPane.showMessageDialog(null, "Quit program?");
27         System.exit(0);
28      }
29   }
30
31   class TimePrinter implements ActionListener
32   {
33      public void actionPerformed(ActionEvent event)
34      {
35         System.out.println("At the tone, the time is " + new Date());
36         Toolkit.getDefaultToolkit().beep();
37      }
38   }

Now suppose we want to sort strings by increasing length, not in dictionary order. We can’t have the String class implement the compareTo method in two ways—and at any rate, the String class isn’t ours to modify.

To deal with this situation, there is a second version of the Arrays.sort method whose parameters are an array and a comparator—an instance of a class that implements the Comparator interface.

Click here to view code image

public interface Comparator<T>
{
   int compare(T first, T second);
}

To compare strings by length, define a class that implements Comparator<String>:

Click here to view code image

class LengthComparator implements Comparator<String>
{
   public int compare(String first, String second) {
       return first.length() - second.length();
   }
}

Click here to view code image

Comparator<String> comp = new LengthComparator();
if (comp.compare(words[i], words[j]) > 0) ...

Contrast this call with words[i].compareTo(words[j]). The compare method is called on the comparator object, not the string itself.

To sort an array, pass a LengthComparator object to the Arrays.sort method:

Click here to view code image

String[] friends = { "Peter", "Paul", "Mary" };
Arrays.sort(friends, new LengthComparator());

Now the array is either ["Paul", "Mary", "Peter"] or ["Mary", "Paul", "Peter"].

You will see in Section 6.3, “Lambda Expressions,” on p. 314 how to use a Comparator much more easily with a lambda expression.

To understand what cloning means, recall what happens when you make a copy of a variable holding an object reference. The original and the copy are references to the same object (see Figure 6.1). This means a change to either variable also affects the other.

Click here to view code image

Employee original = new Employee("John Public", 50000);
Employee copy = original;
copy.raiseSalary(10); // oops--also changed original

Figure 6.1 Copying and cloning

Click here to view code image

Employee copy = original.clone();
copy.raiseSalary(10); // OK--original unchanged

To visualize that, consider the Employee class that was introduced in Chapter 4. Figure 6.2 shows what happens when you use the clone method of the Object class to clone such an Employee object. As you can see, the default cloning operation is “shallow”—it doesn’t clone objects that are referenced inside other objects. (The figure shows a shared Date object. For reasons that will become clear shortly, this example uses a version of the Employee class in which the hire day is represented as a Date.)

Figure 6.2 A shallow copy

For every class, you need to decide whether

In this case, the appearance of the Cloneable interface has nothing to do with the normal use of interfaces. In particular, it does not specify the clone method—that method is inherited from the Object class. The interface merely serves as a tag, indicating that the class designer understands the cloning process. Objects are so paranoid about cloning that they generate a checked exception if an object requests cloning but does not implement that interface.

Even if the default (shallow copy) implementation of clone is adequate, you still need to implement the Cloneable interface, redefine clone to be public, and call super.clone(). Here is an example:

Click here to view code image

class Employee implements Cloneable
{
   // raise visibility level to public, change return type
   public Employee clone() throws CloneNotSupportedException
   {
      return (Employee) super.clone();
   }
   ...
}

The clone method that you just saw adds no functionality to the shallow copy provided by Object.clone. It merely makes the method public. To make a deep copy, you have to work harder and clone the mutable instance fields.

Here is an example of a clone method that creates a deep copy:

Click here to view code image

class Employee implements Cloneable
{
   ...
   public Employee clone() throws CloneNotSupportedException
   {
      // call Object.clone()
      Employee cloned = (Employee) super.clone();

      // clone mutable fields
      cloned.hireDay = (Date) hireDay.clone();

      return cloned;
   }
}

The clone method of the Object class threatens to throw a CloneNotSupportedException—it does that whenever clone is invoked on an object whose class does not implement the Cloneable interface. Of course, the Employee and Date classes implement the Cloneable interface, so the exception won’t be thrown. However, the compiler does not know that. Therefore, we declared the exception:

Click here to view code image

public Employee clone() throws CloneNotSupportedException

Would it be better to catch the exception instead?

Click here to view code image

public Employee clone()
{
   try
   {
      Employee cloned = (Employee) super.clone();
      ...
   }
   catch (CloneNotSupportedException e) { return null; }
   // this won't happen, since we are Cloneable
}

This is appropriate for final classes. Otherwise, it is a good idea to leave the throws specifier in place. That gives subclasses the option of throwing a CloneNotSupportedException if they can’t support cloning.

You have to be careful about cloning of subclasses. For example, once you have defined the clone method for the Employee class, anyone can use it to clone Manager objects. Can the Employee clone method do the job? It depends on the fields of the Manager class. In our case, there is no problem because the bonus field has primitive type. But Manager might have acquired fields that require a deep copy or are not cloneable. There is no guarantee that the implementor of the subclass has fixed clone to do the right thing. For that reason, the clone method is declared as protected in the Object class. But you don’t have that luxury if you want users of your classes to invoke clone.

Should you implement clone in your own classes? If your clients need to make deep copies, then you probably should. Some authors feel that you should avoid clone altogether and instead implement another method for the same purpose. We agree that clone is rather awkward, but you’ll run into the same issues if you shift the responsibility to another method. At any rate, cloning is less common than you may think. Less than 5 percent of the classes in the standard library implement clone.

The program in Listing 6.4 clones an instance of the class Employee (Listing 6.5), then invokes two mutators. The raiseSalary method changes the value of the salary field, whereas the setHireDay method changes the state of the hireDay field. Neither mutation affects the original object because clone has been defined to make a deep copy.

Listing 6.4 clone/CloneTest.java

Click here to view code image

 1   package clone;
 2
 3   /**
 4    * This program demonstrates cloning.
 5    * @version 1.10 2002-07-01
 6    * @author Cay Horstmann
 7    */
 8   public class CloneTest
 9   {
10      public static void main(String[] args)
11      {
12         try
13         {
14            Employee original = new Employee("John Q. Public", 50000);
15            original.setHireDay(2000, 1, 1);
16            Employee copy = original.clone();
17            copy.raiseSalary(10);
18            copy.setHireDay(2002, 12, 31);
19            System.out.println("original=" + original);
20            System.out.println("copy=" + copy);
21         }
22         catch (CloneNotSupportedException e)
23         {
24            e.printStackTrace();
25         }
26      }
27   }

Listing 6.5 clone/Employee.java

Click here to view code image

 1   package clone;
 2
 3   import java.util.Date;
 4   import java.util.GregorianCalendar;
 5
 6   public class Employee implements Cloneable
 7   {
 8      private String name;
 9      private double salary;
10      private Date hireDay;
11
12      public Employee(String name, double salary)
13      {
14         this.name = name;
15         this.salary = salary;
16         hireDay = new Date();
17      }
18
19      public Employee clone() throws CloneNotSupportedException
20      {
21         // call Object.clone()
22         Employee cloned = (Employee) super.clone();
23
24         // clone mutable fields
25         cloned.hireDay = (Date) hireDay.clone();
26
27         return cloned;
28      }
29
30      /**
31       * Set the hire day to a given date.
32       * @param year the year of the hire day
33       * @param month the month of the hire day
34       * @param day the day of the hire day
35       */
36      public void setHireDay(int year, int month, int day)
37      {
38         Date newHireDay = new GregorianCalendar(year, month - 1, day).getTime();
39
40         // Example of instance field mutation
41         hireDay.setTime(newHireDay.getTime());
42      }
43
44      public void raiseSalary(double byPercent)
45      {
46         double raise = salary * byPercent / 100;
47         salary += raise;
48      }
49
50      public String toString()
51      {
52         return "Employee[name=" + name + ",salary=" + salary + ",hireDay=" + hireDay + "]";
53      }
54   }

In Section 6.2.1, “Interfaces and Callbacks,” on p. 302, you saw how to do work in timed intervals. Put the work into the actionPerformed method of an ActionListener:

Click here to view code image

class Worker implements ActionListener
{
   public void actionPerformed(ActionEvent event)
   {
      // do some work
   }
}

Then, when you want to repeatedly execute this code, you construct an instance of the Worker class. You then submit the instance to a Timer object.

The key point is that the actionPerformed method contains code that you want to execute later.

Or consider sorting with a custom comparator. If you want to sort strings by length instead of the default dictionary order, you can pass a Comparator object to the sort method:

Click here to view code image

class LengthComparator implements Comparator<String>
{
   public int compare(String first, String second)
   {
      return first.length() - second.length();
   }
}
...
Arrays.sort(strings, new LengthComparator());

The compare method isn’t called right away. Instead, the sort method keeps calling the compare method, rearranging the elements if they are out of order, until the array is sorted. You give the sort method a snippet of code needed to compare elements, and that code is integrated into the rest of the sorting logic, which you’d probably not care to reimplement.

Click here to view code image

first.length() - second.length()

What are first and second? They are both strings. Java is a strongly typed language, and we must specify that as well:

Click here to view code image

(String first, String second)
   -> first.length() - second.length()

You have just seen your first lambda expression. Such an expression is simply a block of code, together with the specification of any variables that must be passed to the code.

Why the name? Many years ago, before there were any computers, the logician Alonzo Church wanted to formalize what it means for a mathematical function to be effectively computable. (Curiously, there are functions that are known to exist, but nobody knows how to compute their values.) He used the Greek letter lambda (λ) to mark parameters. Had he known about the Java API, he would have written

Click here to view code image

λfirst.λsecond.first.length() - second.length()

You have just seen one form of lambda expressions in Java: parameters, the -> arrow, and an expression. If the code carries out a computation that doesn’t fit in a single expression, write it exactly like you would have written a method: enclosed in {} and with explicit return statements. For example,

Click here to view code image

(String first, String second) ->
   {
      if (first.length() < second.length()) return -1;
      else if (first.length() > second.length()) return 1;
      else return 0;
   }

If a lambda expression has no parameters, you still supply empty parentheses, just as with a parameterless method:

Click here to view code image

() -> { for (int i = 100; i >= 0; i--) System.out.println(i); }

If the parameter types of a lambda expression can be inferred, you can omit them. For example,

Click here to view code image

Comparator<String> comp
   = (first, second) // Same as (String first, String second)
      -> first.length() - second.length();

Here, the compiler can deduce that first and second must be strings because the lambda expression is assigned to a string comparator. (We will have a closer look at this assignment in the next section.)

If a method has a single parameter with inferred type, you can even omit the parentheses:

Click here to view code image

ActionListener listener = event ->
   System.out.println("The time is " + new Date()");
      // Instead of (event) -> ... or (ActionEvent event) -> ...

You never specify the result type of a lambda expression. It is always inferred from context. For example, the expression

Click here to view code image

(String first, String second) -> first.length() - second.length()

can be used in a context where a result of type int is expected.

The program in Listing 6.6 shows how to use lambda expressions for a comparator and an action listener.

Listing 6.6 lambda/LambdaTest.java

Click here to view code image

 1   package lambda;
 2
 3   import java.util.*;
 4
 5   import javax.swing.*;
 6   import javax.swing.Timer;
 7
 8   /**
 9    * This program demonstrates the use of lambda expressions.
10    * @version 1.0 2015-05-12
11    * @author Cay Horstmann
12    */
13   public class LambdaTest
14   {
15      public static void main(String[] args)
16      {
17         String[] planets = new String[] { "Mercury", "Venus", "Earth", "Mars",
18               "Jupiter", "Saturn", "Uranus", "Neptune" };
19         System.out.println(Arrays.toString(planets));
20         System.out.println("Sorted in dictionary order:");
21         Arrays.sort(planets);
22         System.out.println(Arrays.toString(planets));
23         System.out.println("Sorted by length:");
24         Arrays.sort(planets, (first, second) -> first.length() - second.length());
25         System.out.println(Arrays.toString(planets));
26
27         Timer t = new Timer(1000, event ->
28            System.out.println("The time is " + new Date()));
29         t.start();
30
31         // keep program running until user selects "Ok"
32         JOptionPane.showMessageDialog(null, "Quit program?");
33         System.exit(0);
34      }
35   }

To demonstrate the conversion to a functional interface, consider the Arrays.sort method. Its second parameter requires an instance of Comparator, an interface with a single method. Simply supply a lambda:

Click here to view code image

Arrays.sort(words,
   (first, second) -> first.length() - second.length());

Behind the scenes, the Arrays.sort method receives an object of some class that implements Comparator<String>. Invoking the compare method on that object executes the body of the lambda expression. The management of these objects and classes is completely implementation dependent, and it can be much more efficient than using traditional inner classes. It is best to think of a lambda expression as a function, not an object, and to accept that it can be passed to a functional interface.

This conversion to interfaces is what makes lambda expressions so compelling. The syntax is short and simple. Here is another example:

Click here to view code image

Timer t = new Timer(1000, event ->
   {
      System.out.println("At the tone, the time is " + new Date());
      Toolkit.getDefaultToolkit().beep();
   });

That’s a lot easier to read than the alternative with a class that implements the ActionListener interface.

In fact, conversion to a functional interface is the only thing that you can do with a lambda expression in Java. In other programming languages that support function literals, you can declare function types such as (String, String) -> int, declare variables of those types, and use the variables to save function expressions. However, the Java designers decided to stick with the familiar concept of interfaces instead of adding function types to the language.

Click here to view code image

BiFunction<String, String, Integer> comp
   = (first, second) -> first.length() - second.length();

However, that does not help you with sorting. There is no Arrays.sort method that wants a BiFunction. If you have used a functional programming language before, you may find this curious. But for Java programmers, it’s pretty natural. An interface such as Comparator has a specific purpose, not just a method with given parameter and return types. Java SE 8 retains this flavor. When you want to do something with lambda expressions, you still want to keep the purpose of the expression in mind, and have a specific functional interface for it.

A particularly useful interface in the java.util.function package is Predicate:

Click here to view code image

public interface Predicate<T>
{
   boolean test(T t);
   // Additional default and static methods
}

The ArrayList class has a removeIf method whose parameter is a Predicate. It is specifically designed to pass a lambda expression. For example, the following statement removes all null values from an array list:

Click here to view code image

list.removeIf(e -> e == null);

Click here to view code image

Timer t = new Timer(1000, event -> System.out.println(event));

Click here to view code image

Timer t = new Timer(1000, System.out::println);

The expression System.out::println is a method reference that is equivalent to the lambda expression x -> System.out.println(x).

As another example, suppose you want to sort strings regardless of letter case. You can pass this method expression:

Click here to view code image

Arrays.sort(strings, String::compareToIgnoreCase)

As you can see from these examples, the :: operator separates the method name from the name of an object or class. There are three principal cases:

• object::instanceMethod

• Class::staticMethod

• Class::instanceMethod

In the first two cases, the method reference is equivalent to a lambda expression that supplies the parameters of the method. As already mentioned, System.out::println is equivalent to x -> System.out.println(x). Similarly, Math::pow is equivalent to (x, y) -> Math.pow(x, y).

In the third case, the first parameter becomes the target of the method. For example, String::compareToIgnoreCase is the same as (x, y) -> x.compareToIgnoreCase(y).

You can capture the this parameter in a method reference. For example, this::equals is the same as x -> this.equals(x). It is also valid to use super. The method expression

super::instanceMethod

uses this as the target and invokes the superclass version of the given method. Here is an artificial example that shows the mechanics:

Click here to view code image

class Greeter
{
   public void greet()
   {
      System.out.println("Hello, world!");
   }
}

class TimedGreeter extends Greeter
{
   public void greet()
   {
      Timer t = new Timer(1000, super::greet);
      t.start();
   }
}

Click here to view code image

ArrayList<String> names = ...;
Stream<Person> stream = names.stream().map(Person::new);
List<Person> people = stream.collect(Collectors.toList());

We will discuss the details of the stream, map, and collect methods in Chapter 1 of Volume II. For now, what’s important is that the map method calls the Person(String) constructor for each list element. If there are multiple Person constructors, the compiler picks the one with a String parameter because it infers from the context that the constructor is called with a string.

You can form constructor references with array types. For example, int[]::new is a constructor reference with one parameter: the length of the array. It is equivalent to the lambda expression x -> new int[x].

Array constructor references are useful to overcome a limitation of Java. It is not possible to construct an array of a generic type T. The expression new T[n] is an error since it would be erased to new Object[n]. That is a problem for library authors. For example, suppose we want to have an array of Person objects. The Stream interface has a toArray method that returns an Object array:

Click here to view code image

Object[] people = stream.toArray();

But that is unsatisfactory. The user wants an array of references to Person, not references to Object. The stream library solves that problem with constructor references. Pass Person[]::new to the toArray method:

Click here to view code image

Person[] people = stream.toArray(Person[]::new);

The toArray method invokes this constructor to obtain an array of the correct type. Then it fills and returns the array.

Click here to view code image

public static void repeatMessage(String text, int delay)
{
   ActionListener listener = event ->
      {
         System.out.println(text);
         Toolkit.getDefaultToolkit().beep();
      };
   new Timer(delay, listener).start();
}

Consider a call

Click here to view code image

repeatMessage("Hello", 1000); // Prints Hello every 1,000 milliseconds

Now look at the variable text inside the lambda expression. Note that this variable is not defined in the lambda expression. Instead, it is a parameter variable of the repeatMessage method.

If you think about it, something nonobvious is going on here. The code of the lambda expression may run long after the call to repeatMessage has returned and the parameter variables are gone. How does the text variable stay around?

To understand what is happening, we need to refine our understanding of a lambda expression. A lambda expression has three ingredients:

1. A block of code

2. Parameters

3. Values for the free variables, that is, the variables that are not parameters and not defined inside the code

In our example, the lambda expression has one free variable, text. The data structure representing the lambda expression must store the values for the free variables, in our case, the string "Hello". We say that such values have been captured by the lambda expression. (It’s an implementation detail how that is done. For example, one can translate a lambda expression into an object with a single method, so that the values of the free variables are copied into instance variables of that object.)

Click here to view code image

public static void countDown(int start, int delay)
{
   ActionListener listener = event ->
      {
         start--; // Error: Can't mutate captured variable
         System.out.println(start);
      };
   new Timer(delay, listener).start();
}

There is a reason for this restriction. Mutating variables in a lambda expression is not safe when multiple actions are executed concurrently. This won’t happen for the kinds of actions that we have seen so far, but in general, it is a serious problem. See Chapter 14 for more information on this important issue.

It is also illegal to refer to variable in a lambda expression that is mutated outside. For example, the following is illegal:

Click here to view code image

public static void repeat(String text, int count)
{
   for (int i = 1; i <= count; i++)
   {
      ActionListener listener = event ->
         {
            System.out.println(i + ": " + text);
               // Error: Cannot refer to changing i
         };
      new Timer(1000, listener).start();
   }
}

The rule is that any captured variable in a lambda expression must be effectively final. An effectively final variable is a variable that is never assigned a new value after it has been initialized. In our case, text always refers to the same String object, and it is OK to capture it. However, the value of i is mutated, and therefore i cannot be captured.

Click here to view code image

Path first = Paths.get("/usr/bin");
Comparator<String> comp =
   (first, second) -> first.length() - second.length();
   // Error: Variable first already defined

Inside a method, you can’t have two local variables with the same name, and therefore, you can’t introduce such variables in a lambda expression either.

When you use the this keyword in a lambda expression, you refer to the this parameter of the method that creates the lambda. For example, consider

Click here to view code image

public class Application()
{
   public void init()
   {
      ActionListener listener = event ->
         {
            System.out.println(this.toString());
            . . .
         }
      . . .
   }
}

The expression this.toString() calls the toString method of the Application object, not the ActionListener instance. There is nothing special about the use of this in a lambda expression. The scope of the lambda expression is nested inside the init method, and this has the same meaning anywhere in that method.

The point of using lambdas is deferred execution. After all, if you wanted to execute some code right now, you’d do that, without wrapping it inside a lambda. There are many reasons for executing code later, such as:

Click here to view code image

repeat(10, () -> System.out.println("Hello, World!"));

To accept the lambda, we need to pick (or, in rare cases, provide) a functional interface. Table 6.1 lists the most important functional interfaces that are provided in the Java API. In this case, we can use the Runnable interface:

Click here to view code image

public static void repeat(int n, Runnable action)
{
    for (int i = 0; i < n; i++) action.run();
}

Table 6.1 Common Functional Interfaces

Click here to view code image

public static void repeat(int n, IntConsumer action)
{
    for (int i = 0; i < n; i++) action.accept(i);
}

And here is how you call it:

Click here to view code image

repeat(10, i -> System.out.println("Countdown: " + (9 - i)));

Table 6.2 lists the 34 available specializations for primitive types int, long, and double. It is a good idea to use these specializations to reduce autoboxing. For that reason, I used an IntConsumer instead of a Consumer<Integer> in the example of the preceding section.

Table 6.2 Functional Interfaces for Primitive Types p, q is int, long, double; P, Q is Int, Long, Double

Click here to view code image

Arrays.sort(people, Comparator.comparing(Person::getName));

This is certainly much easier than implementing a Comparator by hand. Moreover, the code is clearer since it is obvious that we want to compare people by name.

You can chain comparators with the thenComparing method for breaking ties. For example,

Click here to view code image

Arrays.sort(people,
   Comparator.comparing(Person::getLastName)
   .thenComparing(Person::getFirstName));

If two people have the same last name, then the second comparator is used.

There are a few variations of these methods. You can specify a comparator to be used for the keys that the comparing and thenComparing methods extract. For example, here we sort people by the length of their names:

Click here to view code image

Arrays.sort(people, Comparator.comparing(Person::getName,
   (s, t) -> Integer.compare(s.length(), t.length())));

Moreover, both the comparing and thenComparing methods have variants that avoid boxing of int, long, or double values. An easier way of producing the preceding operation would be

Click here to view code image

Arrays.sort(people, Comparator.comparingInt(p -> p.getName().length()));

If your key function can return null, you will like the nullsFirst and nullsLast adapters. These static methods take an existing comparator and modify it so that it doesn’t throw an exception when encountering null values but ranks them as smaller or larger than regular values. For example, suppose getMiddleName returns a null when a person has no middle name. Then you can use Comparator.comparing(Person::getMiddleName(), Comparator.nullsFirst(...)).

Click here to view code image

Arrays.sort(people, comparing(Person::getMiddleName, nullsFirst(naturalOrder())));

The static reverseOrder method gives the reverse of the natural order. To reverse any comparator, use the reversed instance method. For example, naturalOrder().reversed() is the same as reverseOrder().

• Inner class methods can access the data from the scope in which they are defined—including the data that would otherwise be private.

• Inner classes can be hidden from other classes in the same package.

• Anonymous inner classes are handy when you want to define callbacks without writing a lot of code.

We will break up this rather complex topic into several steps.

1. Starting on page 331, you will see a simple inner class that accesses an instance field of its outer class.

2. On page 334, we cover the special syntax rules for inner classes.

3. Starting on page 335, we peek inside inner classes to see how they are translated into regular classes. Squeamish readers may want to skip that section.

4. Starting on page 339, we discuss local inner classes that can access local variables of the enclosing scope.

5. Starting on page 342, we introduce anonymous inner classes and show how they were commonly used to implement callbacks before Java had lambda expressions.

6. Finally, starting on page 346, you will see how static inner classes can be used for nested helper classes.

Click here to view code image

public class TalkingClock
{
   private int interval;
   private boolean beep;

   public TalkingClock(int interval, boolean beep) { ... }
   public void start() { ... }

   public class TimePrinter implements ActionListener
      // an inner class
   {
      ...
   }
}

Note that the TimePrinter class is now located inside the TalkingClock class. This does not mean that every TalkingClock has a TimePrinter instance field. As you will see, the TimePrinter objects are constructed by methods of the TalkingClock class.

Here is the TimePrinter class in greater detail. Note that the actionPerformed method checks the beep flag before emitting a beep.

Click here to view code image

public class TimePrinter implements ActionListener
{
   public void actionPerformed(ActionEvent event)
   {
      System.out.println("At the tone, the time is " + new Date());
      if (beep) Toolkit.getDefaultToolkit().beep();
   }
}

Something surprising is going on. The TimePrinter class has no instance field or variable named beep. Instead, beep refers to the field of the TalkingClock object that created this TimePrinter. This is quite innovative. Traditionally, a method could refer to the data fields of the object invoking the method. An inner class method gets to access both its own data fields and those of the outer object creating it.

For this to work, an object of an inner class always gets an implicit reference to the object that created it (see Figure 6.3).

Figure 6.3 An inner class object has a reference to an outer class object

Click here to view code image

public void actionPerformed(ActionEvent event)
{
   System.out.println("At the tone, the time is " + new Date());
   if (outer.beep) Toolkit.getDefaultToolkit().beep();
}

The outer class reference is set in the constructor. The compiler modifies all inner class constructors, adding a parameter for the outer class reference. The TimePrinter class defines no constructors; therefore, the compiler synthesizes a no-argument constructor, generating code like this:

Click here to view code image

public TimePrinter(TalkingClock clock) // automatically generated code
{
   outer = clock;
}

Again, please note that outer is not a Java keyword. We just use it to illustrate the mechanism involved in an inner class.

When a TimePrinter object is constructed in the start method, the compiler passes the this reference to the current talking clock into the constructor:

Click here to view code image

ActionListener listener = new TimePrinter(this); // parameter automatically added

Listing 6.7 shows the complete program that tests the inner class. Have another look at the access control. Had the TimePrinter class been a regular class, it would have needed to access the beep flag through a public method of the TalkingClock class. Using an inner class is an improvement. There is no need to provide accessors that are of interest only to one other class.

Listing 6.7 innerClass/InnerClassTest.java

Click here to view code image

 1   package innerClass;
 2
 3   import java.awt.*;
 4   import java.awt.event.*;
 5   import java.util.*;
 6   import javax.swing.*;
 7   import javax.swing.Timer;
 8
 9   /**
10    * This program demonstrates the use of inner classes.
11    * @version 1.11 2015-05-12
12    * @author Cay Horstmann
13    */
14   public class InnerClassTest
15   {
16      public static void main(String[] args)
17      {
18         TalkingClock clock = new TalkingClock(1000, true);
19         clock.start();
20
21         // keep program running until user selects "Ok"
22         JOptionPane.showMessageDialog(null, "Quit program?");
23         System.exit(0);
24      }
25   }
26
27   /**
28    * A clock that prints the time in regular intervals.
29    */
30   class TalkingClock
31   {
32      private int interval;
33      private boolean beep;
34
35      /**
36       * Constructs a talking clock
37       * @param interval the interval between messages (in milliseconds)
38       * @param beep true if the clock should beep
39       */
40      public TalkingClock(int interval, boolean beep)
41      {
42         this.interval = interval;
43         this.beep = beep;
44      }
45
46      /**
47       * Starts the clock.
48       */
49      public void start()
50      {
51         ActionListener listener = new TimePrinter();
52         Timer t = new Timer(interval, listener);
53         t.start();
54      }
55
56      public class TimePrinter implements ActionListener
57      {
58         public void actionPerformed(ActionEvent event)
59         {
60            System.out.println("At the tone, the time is " + new Date());
61            if (beep) Toolkit.getDefaultToolkit().beep();
62         }
63      }
64   }

Click here to view code image

public void actionPerformed(ActionEvent event)
{
   ...
   if (TalkingClock.this.beep) Toolkit.getDefaultToolkit().beep();
}

Conversely, you can write the inner object constructor more explicitly, using the syntax

outerObject.new InnerClass(construction parameters)

For example:

Click here to view code image

ActionListener listener = this.new TimePrinter();

Here, the outer class reference of the newly constructed TimePrinter object is set to the this reference of the method that creates the inner class object. This is the most common case. As always, the this. qualifier is redundant. However, it is also possible to set the outer class reference to another object by explicitly naming it. For example, since TimePrinter is a public inner class, you can construct a TimePrinter for any talking clock:

Click here to view code image

TalkingClock jabberer = new TalkingClock(1000, true);
TalkingClock.TimePrinter listener = jabberer.new TimePrinter();

Note that you refer to an inner class as

OuterClass.InnerClass

when it occurs outside the scope of the outer class.

For example, the TimePrinter class inside the TalkingClock class is translated to a class file TalkingClock$TimePrinter.class. To see this at work, try the following experiment: run the ReflectionTest program of Chapter 5, and give it the class TalkingClock$TimePrinter to reflect upon. Alternatively, simply use the javap utility:

javap -private ClassName

You will get the following printout:

Click here to view code image

public class TalkingClock$TimePrinter
{
   public TalkingClock$TimePrinter(TalkingClock);

   public void actionPerformed(java.awt.event.ActionEvent);

   final TalkingClock this$0;
}

You can plainly see that the compiler has generated an additional instance field, this$0, for the reference to the outer class. (The name this$0 is synthesized by the compiler—you cannot refer to it in your code.) You can also see the TalkingClock parameter for the constructor.

If the compiler can automatically do this transformation, couldn’t you simply program the same mechanism by hand? Let’s try it. We would make TimePrinter a regular class, outside the TalkingClock class. When constructing a TimePrinter object, we pass it the this reference of the object that is creating it.

Click here to view code image

class TalkingClock
{
   ...
   public void start()
   {
      ActionListener listener = new TimePrinter(this);
      Timer t = new Timer(interval, listener);
      t.start();
   }
}

class TimePrinter implements ActionListener
{
   private TalkingClock outer;
   ...
   public TimePrinter(TalkingClock clock)
   {
       outer = clock;
   }
}

Now let us look at the actionPerformed method. It needs to access outer.beep.

Click here to view code image

if (outer.beep) ... // Error

Here we run into a problem. The inner class can access the private data of the outer class, but our external TimePrinter class cannot.

Thus, inner classes are genuinely more powerful than regular classes because they have more access privileges.

You may well wonder how inner classes manage to acquire those added access privileges, if they are translated to regular classes with funny names—the virtual machine knows nothing at all about them. To solve this mystery, let’s again use the ReflectionTest program to spy on the TalkingClock class:

Click here to view code image

class TalkingClock
{
   private int interval;
   private boolean beep;
   public TalkingClock(int, boolean);

   static boolean access$0(TalkingClock);
   public void start();
}

Notice the static access$0 method that the compiler added to the outer class. It returns the beep field of the object that is passed as a parameter. (The method name might be slightly different, such as access$000, depending on your compiler.)

Click here to view code image

if (TalkingClock.access$0(outer))

Is this a security risk? You bet it is. It is an easy matter for someone else to invoke the access$0 method to read the private beep field. Of course, access$0 is not a legal name for a Java method. However, hackers who are familiar with the structure of class files can easily produce a class file with virtual machine instructions to call that method, for example, by using a hex editor. Since the secret access methods have package visibility, the attack code would need to be placed inside the same package as the class under attack.

To summarize, if an inner class accesses a private data field, then it is possible to access that data field through other classes added to the package of the outer class, but to do so requires skill and determination. A programmer cannot accidentally obtain access but must intentionally build or modify a class file for that purpose.

Click here to view code image

public void start()
{
   class TimePrinter implements ActionListener
   {
      public void actionPerformed(ActionEvent event)
      {
         System.out.println("At the tone, the time is " + new Date());
         if (beep) Toolkit.getDefaultToolkit().beep();
      }
   }

   ActionListener listener = new TimePrinter();
   Timer t = new Timer(interval, listener);
   t.start();
}

Local classes are never declared with an access specifier (that is, public or private). Their scope is always restricted to the block in which they are declared.

Local classes have one great advantage: They are completely hidden from the outside world—not even other code in the TalkingClock class can access them. No method except start has any knowledge of the TimePrinter class.

Here is a typical example. Let’s move the interval and beep parameters from the TalkingClock constructor to the start method.

Click here to view code image

public void start(int interval, boolean beep)
{
   class TimePrinter implements ActionListener
   {
      public void actionPerformed(ActionEvent event)
      {
         System.out.println("At the tone, the time is " + new Date());
               if (beep) Toolkit.getDefaultToolkit().beep();
      }
   }

   ActionListener listener = new TimePrinter();
   Timer t = new Timer(interval, listener);
   t.start();
}

Click here to view code image

class TalkingClock$1TimePrinter
{
   TalkingClock$1TimePrinter(TalkingClock, boolean);

   public void actionPerformed(java.awt.event.ActionEvent);

   final boolean val$beep;
   final TalkingClock this$0;
}

Note the boolean parameter to the constructor and the val$beep instance variable. When an object is created, the value beep is passed into the constructor and stored in the val$beep field. The compiler detects access of local variables, makes matching instance fields for each one, and copies the local variables into the constructor so that the instance fields can be initialized.

The “effectively final” restriction is sometimes inconvenient. Suppose, for example, that you want to update a counter in the enclosing scope. Here, we want to count how often the compareTo method is called during sorting:

Click here to view code image

int counter = 0;
Date[] dates = new Date[100];
for (int i = 0; i < dates.length; i++)
   dates[i] = new Date()
      {
         public int compareTo(Date other)
         {
            counter++; // Error
            return super.compareTo(other);
         }
      };
Arrays.sort(dates);
System.out.println(counter + " comparisons.");

You can’t declare counter as final because you clearly need to update it. You can’t replace it with an Integer because Integer objects are immutable. A remedy is to use an array of length 1:

Click here to view code image

int[] counter = new int[1];
for (int i = 0; i < dates.length; i++)
   dates[i] = new Date()
      {
         public int compareTo(Date other)
         {
            counter[0]++;
            return super.compareTo(other);
         }
      };

When inner classes were first invented, a prototype version of the compiler automatically made this transformation for all local variables that were modified in the inner class. However, this was later abandoned. After all, there is a danger. When the code in the inner class is executed at the same time in multiple threads, the concurrent updates can lead to race conditions—see Chapter 14.

Click here to view code image

public void start(int interval, boolean beep)
{
   ActionListener listener = new ActionListener()
   {
      public void actionPerformed(ActionEvent event)
      {
         System.out.println("At the tone, the time is " + new Date());
         if (beep) Toolkit.getDefaultToolkit().beep();
      }
   };
   Timer t = new Timer(interval, listener);
   t.start();
}

This syntax is very cryptic indeed. What it means is this: Create a new object of a class that implements the ActionListener interface, where the required method actionPerformed is the one defined inside the braces { }.

In general, the syntax is

Click here to view code image

new SuperType(construction parameters)
   {
     inner class methods and data
   }

Here, SuperType can be an interface, such as ActionListener; then, the inner class implements that interface. SuperType can also be a class; then, the inner class extends that class.

Click here to view code image

Person queen = new Person("Mary");
   // a Person object
Person count = new Person("Dracula") { ...};
   // an object of an inner class extending Person

If the closing parenthesis of the construction parameter list is followed by an opening brace, then an anonymous inner class is being defined.

Listing 6.8 contains the complete source code for the talking clock program with an anonymous inner class. If you compare this program with Listing 6.7, you will see that in this case, the solution with the anonymous inner class is quite a bit shorter and, hopefully, with some practice, as easy to comprehend.

For many years, Java programmers routinely used anonymous inner classes for event listeners and other callbacks. Nowadays, you are better off using a lambda expression. For example, the start method from the beginning of this section can be written much more concisely with a lambda expression like this:

Click here to view code image

public void start(int interval, boolean beep)
{
   Timer t = new Timer(interval, event ->
      {
         System.out.println("At the tone, the time is " + new Date());
         if (beep) Toolkit.getDefaultToolkit().beep();
      });
   t.start();
}

Listing 6.8 anonymousInnerClass/AnonymousInnerClassTest.java

Click here to view code image

 1   package anonymousInnerClass;
 2
 3   import java.awt.*;
 4   import java.awt.event.*;
 5   import java.util.*;
 6   import javax.swing.*;
 7   import javax.swing.Timer;
 8
 9   /**
10    * This program demonstrates anonymous inner classes.
11    * @version 1.11 2015-05-12
12    * @author Cay Horstmann
13    */
14   public class AnonymousInnerClassTest
15   {
16      public static void main(String[] args)
17      {
18         TalkingClock clock = new TalkingClock();
19         clock.start(1000, true);
20
21         // keep program running until user selects "Ok"
22         JOptionPane.showMessageDialog(null, "Quit program?");
23         System.exit(0);
24      }
25   }
26
27   /**
28    * A clock that prints the time in regular intervals.
29    */
30   class TalkingClock
31   {
32      /**
33       * Starts the clock.
34       * @param interval the interval between messages (in milliseconds)
35       * @param beep true if the clock should beep
36       */
37      public void start(int interval, boolean beep)
38      {
39         ActionListener listener = new ActionListener()
40            {
41               public void actionPerformed(ActionEvent event)
42               {
43                  System.out.println("At the tone, the time is " + new Date());
44                  if (beep) Toolkit.getDefaultToolkit().beep();
45               }
46            };
47         Timer t = new Timer(interval, listener);
48         t.start();
49      }
50   }

Click here to view code image

double min = Double.POSITIVE_INFINITY;
double max = Double.NEGATIVE_INFINITY;
for (double v : values)
{
   if (min > v) min = v;
   if (max < v) max = v;
}

However, the method must return two numbers. We can achieve that by defining a class Pair that holds two values:

Click here to view code image

class Pair
{
   private double first;
   private double second;
   public Pair(double f, double s)
   {
      first = f;
      second = s;
   }
   public double getFirst() { return first; }
   public double getSecond() { return second; }
}

The minmax method can then return an object of type Pair.

Click here to view code image

class ArrayAlg
{
   public static Pair minmax(double[] values)
   {
      ...
      return new Pair(min, max);
   }
}

The caller of the method uses the getFirst and getSecond methods to retrieve the answers:

Click here to view code image

Pair p = ArrayAlg.minmax(d);
System.out.println("min = " + p.getFirst());
System.out.println("max = " + p.getSecond());

Of course, the name Pair is an exceedingly common name, and in a large project, it is quite possible that some other programmer had the same bright idea—but made a Pair class that contains a pair of strings. We can solve this potential name clash by making Pair a public inner class inside ArrayAlg. Then the class will be known to the public as ArrayAlg.Pair:

Click here to view code image

ArrayAlg.Pair p = ArrayAlg.minmax(d);

However, unlike the inner classes that we used in previous examples, we do not want to have a reference to any other object inside a Pair object. That reference can be suppressed by declaring the inner class static:

class ArrayAlg
{
   public static class Pair
   {
      ...
   }
   ...
}

Of course, only inner classes can be declared static. A static inner class is exactly like any other inner class, except that an object of a static inner class does not have a reference to the outer class object that generated it. In our example, we must use a static inner class because the inner class object is constructed inside a static method:

Click here to view code image

public static Pair minmax(double[] d)
{
    ...
    return new Pair(min, max);
}

Had the Pair class not been declared as static, the compiler would have complained that there was no implicit object of type ArrayAlg available to initialize the inner class object.

Listing 6.9 contains the complete source code of the ArrayAlg class and the nested Pair class.

Listing 6.9 staticInnerClass/StaticInnerClassTest.java

Click here to view code image

 1   package staticInnerClass;
 2
 3   /**
 4    * This program demonstrates the use of static inner classes.
 5    * @version 1.02 2015-05-12
 6    * @author Cay Horstmann
 7    */
 8   public class StaticInnerClassTest
 9   {
10     public static void main(String[] args)
11     {
12        double[] d = new double[20];
13        for (int i = 0; i < d.length; i++)
14           d[i] = 100 * Math.random();
15         ArrayAlg.Pair p = ArrayAlg.minmax(d);
16         System.out.println("min = " + p.getFirst());
17         System.out.println("max = " + p.getSecond());
18      }
19   }
20
21   class ArrayAlg
22   {
23      /**
24       * A pair of floating-point numbers
25       */
26      public static class Pair
27      {
28         private double first;
29         private double second;
30
31           /**
32            * Constructs a pair from two floating-point numbers
33            * @param f the first number
34            * @param s the second number
35            */
36           public Pair(double f, double s)
37           {
38              first = f;
39              second = s;
40           }
41
42           /**
43            * Returns the first number of the pair
44            * @return the first number
45            */
46           public double getFirst()
47           {
48              return first;
49           }
50
51           /**
52            * Returns the second number of the pair
53            * @return the second number
54            */
55           public double getSecond()
56           {
57              return second;
58           }
59       }
60
61       /**
62        * Computes both the minimum and the maximum of an array
63        * @param values an array of floating-point numbers
64        * @return a pair whose first element is the minimum and whose second element
65        * is the maximum
66        */
67       public static Pair minmax(double[] values)
68       {
69          double min = Double.POSITIVE_INFINITY;
70          double max = Double.NEGATIVE_INFINITY;
71          for (double v : values)
72          {
73             if (min > v) min = v;
74             if (max < v) max = v;
75          }
76          return new Pair(min, max);
77       }
78   }

Click here to view code image

Object invoke(Object proxy, Method method, Object[] args)

Whenever a method is called on the proxy object, the invoke method of the invocation handler gets called, with the Method object and parameters of the original call. The invocation handler must then figure out how to handle the call.

• A class loader. As part of the Java security model, different class loaders can be used for system classes, classes that are downloaded from the Internet, and so on. We will discuss class loaders in Chapter 9 of Volume II. For now, we specify null to use the default class loader.

• An array of Class objects, one for each interface to be implemented.

• An invocation handler.

There are two remaining questions. How do we define the handler? And what can we do with the resulting proxy object? The answers depend, of course, on the problem that we want to solve with the proxy mechanism. Proxies can be used for many purposes, such as

• Routing method calls to remote servers

• Associating user interface events with actions in a running program

• Tracing method calls for debugging purposes

In our example program, we use proxies and invocation handlers to trace method calls. We define a TraceHandler wrapper class that stores a wrapped object. Its invoke method simply prints the name and parameters of the method to be called and then calls the method with the wrapped object as the implicit parameter.

Click here to view code image

class TraceHandler implements InvocationHandler
{
   private Object target;

   public TraceHandler(Object t)
   {
      target = t;
   }

   public Object invoke(Object proxy, Method m, Object[] args)
      throws Throwable
   {
      // print method name and parameters
      ...
      // invoke actual method
      return m.invoke(target, args);
   }
}

Here is how you construct a proxy object that causes the tracing behavior whenever one of its methods is called:

Click here to view code image

Object value = ...;
// construct wrapper
InvocationHandler handler = new TraceHandler(value);
// construct proxy for one or more interfaces
Class[] interfaces = new Class[] { Comparable.class};
Object proxy = Proxy.newProxyInstance(null, interfaces, handler);

In the program shown in Listing 6.10, we use proxy objects to trace a binary search. We fill an array with proxies to the integers 1 ... 1000. Then we invoke the binarySearch method of the Arrays class to search for a random integer in the array. Finally, we print the matching element.

Click here to view code image

Object[] elements = new Object[1000];
// fill elements with proxies for the integers 1 . . . 1000
for (int i = 0; i < elements.length; i++)
{
   Integer value = i + 1;
   elements[i] = Proxy.newProxyInstance(. . .); // proxy for value;
}

// construct a random integer
Integer key = new Random().nextInt(elements.length) + 1;

// search for the key
int result = Arrays.binarySearch(elements, key);

// print match if found
if (result >= 0) System.out.println(elements[result]);

The Integer class implements the Comparable interface. The proxy objects belong to a class that is defined at runtime. (It has a name such as $Proxy0.) That class also implements the Comparable interface. However, its compareTo method calls the invoke method of the proxy object’s handler.

The binarySearch method makes calls like this:

Click here to view code image

if (elements[i].compareTo(key) < 0) . . .

Since we filled the array with proxy objects, the compareTo calls call the invoke method of the TraceHandler class. That method prints the method name and parameters and then invokes compareTo on the wrapped Integer object.

Finally, at the end of the sample program, we call

Click here to view code image

System.out.println(elements[result]);

The println method calls toString on the proxy object, and that call is also redirected to the invocation handler.

Listing 6.10 proxy/ProxyTest.java

Click here to view code image

 1   package proxy;
 2
 3   import java.lang.reflect.*;
 4   import java.util.*;
 5
 6   /**
 7    * This program demonstrates the use of proxies.
 8    * @version 1.00 2000-04-13
 9    * @author Cay Horstmann
10    */
11   public class ProxyTest
12   {
13      public static void main(String[] args)
14      {
15         Object[] elements = new Object[1000];
16
17         // fill elements with proxies for the integers 1 ... 1000
18         for (int i = 0; i < elements.length; i++)
19         {
20             Integer value = i + 1;
21             InvocationHandler handler = new TraceHandler(value);
22             Object proxy = Proxy.newProxyInstance(null, new Class[] { Comparable.class } , handler);
23             elements[i] = proxy;
24         }
25
26         // construct a random integer
27         Integer key = new Random().nextInt(elements.length) + 1;
28
29         // search for the key
30         int result = Arrays.binarySearch(elements, key);
31
32         // print match if found
33         if (result >= 0) System.out.println(elements[result]);
34      }
35   }
36
37   /**
38    * An invocation handler that prints out the method name and parameters, then
39    * invokes the original method
40    */
41   class TraceHandler implements InvocationHandler
42   {
43      private Object target;
44
45      /**
46       * Constructs a TraceHandler
47       * @param t the implicit parameter of the method call
48       */
49      public TraceHandler(Object t)
50      {
51         target = t;
52      }
53
54      public Object invoke(Object proxy, Method m, Object[] args) throws Throwable
55      {
56          // print implicit argument
57          System.out.print(target);
58          // print method name
59          System.out.print("." + m.getName() + "(");
60          // print explicit arguments
61          if (args != null)
62          {
63             for (int i = 0; i < args.length; i++)
64             {
65                System.out.print(args[i]);
66                if (i < args.length - 1) System.out.print(", ");
67             }
68          }
69          System.out.println(")");
70
71          // invoke actual method
72          return m.invoke(target, args);
73       }
74   }

All proxy classes extend the class Proxy. A proxy class has only one instance field—the invocation handler, which is defined in the Proxy superclass. Any additional data required to carry out the proxy objects’ tasks must be stored in the invocation handler. For example, when we proxied Comparable objects in the program shown in Listing 6.10, the TraceHandler wrapped the actual objects.

All proxy classes override the toString, equals, and hashCode methods of the Object class. Like all proxy methods, these methods simply call invoke on the invocation handler. The other methods of the Object class (such as clone and getClass) are not redefined.

The names of proxy classes are not defined. The Proxy class in Oracle’s virtual machine generates class names that begin with the string $Proxy.

There is only one proxy class for a particular class loader and ordered set of interfaces. That is, if you call the newProxyInstance method twice with the same class loader and interface array, you get two objects of the same class. You can also obtain that class with the getProxyClass method:

Click here to view code image

Class proxyClass = Proxy.getProxyClass(null, interfaces);

A proxy class is always public and final. If all interfaces that the proxy class implements are public, the proxy class does not belong to any particular package. Otherwise, all non-public interfaces must belong to the same package, and the proxy class will also belong to that package.

You can test whether a particular Class object represents a proxy class by calling the isProxyClass method of the Proxy class.

This ends our final chapter on the fundamentals of the Java programming language. Interfaces, lambda expressions, and inner classes are concepts that you will encounter frequently. However, as we already mentioned, cloning and proxies are advanced techniques that are of interest mainly to library designers and tool builders, not application programmers. You are now ready to learn how to deal with exceptional situations in your programs in Chapter 7.