Chapter 6. Interfaces and Inner Classes
• PROXIES
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, called an interface, 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 anytime that conformance to the interface is required. After we cover interfaces, we take up cloning an object (or deep copying, as it is sometimes called). A clone of an object is a new object that has the same state as the original. In particular, you can modify the clone without affecting the original.
Next, we move on to the mechanism of inner classes. Inner classes are technically somewhat complex—they are defined inside other classes, and their methods can access the fields of the surrounding class. Inner classes are useful when you design collections of cooperating classes. In particular, inner classes enable you to write concise, professional-looking code to handle GUI events.
This chapter concludes with a discussion of proxies, objects that implement arbitrary interfaces. A proxy is a very specialized construct that is useful for building system-level tools. You can safely skip that section on first reading.
Interfaces
In the Java programming language, an interface is not a class but a set of requirements for classes that want to conform to the interface.
Typically, the supplier of some service states: “If your class conforms to a particular interface, then I’ll perform the service.” Let’s look at a concrete example. The sort method of the Arrays class promises to sort an array of objects, but under one condition: The objects must belong to classes that implement the Comparable interface.
Here is what the Comparable interface looks like:
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.
NoteAs of Java SE 5.0, the Comparable interface has been enhanced to be a generic type.
For example, a class that implements Comparable<Employee> must supply a method
int compareTo(Employee other)
You can still use the “raw” Comparable type without a type parameter, but then you have to manually cast the parameter of the compareTo method to the desired type.
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 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 more than one method. 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, and the methods are never implemented in the interface. Supplying instance fields and method implementations 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.
To make a class implement an interface, you carry out two steps:
1. You declare that your class intends to implement the given interface.
2. You supply definitions for all methods in the interface.
To declare that a class implements an interface, use the implements keyword:
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 a compareTo method that returns –1 if the first employee’s salary is less than the second employee’s salary, 0 if they are equal, and 1 otherwise.
CautionIn the interface declaration, the compareTo method was not declared public because all methods in an interface are automatically public. However, when implementing the interface, you must declare the method as public. Otherwise, the compiler assumes that the method has package visibility—the default for a class. Then the compiler complains that you try to supply a weaker access privilege.
As of Java SE 5.0, we can do a little better. We’ll decide to implement the Comparable<Employee> interface type instead.
Note that the unsightly cast of the Object parameter has gone away.
TipThe compareTo method of the Comparable interface returns an integer. If the objects are not equal, it does not matter what negative or positive value you return. This flexibility can be useful when you are comparing integer fields. For example, suppose each employee has a unique integer id and you want to sort by employee ID number. Then you can simply return id - other.id. That value will be some negative value if the first ID number is less than the other, 0 if they are the same ID, and some positive value otherwise. However, there is one caveat: The range of the integers must be small enough that the subtraction does not overflow. If you know that the IDs are not negative or that their absolute value is at most (Integer.MAX_VALUE - 1) / 2, you are safe.
Of course, the subtraction trick doesn’t work for floating-point numbers. The difference salary - other.salary can round to 0 if the salaries are close together but not identical.
Now you saw what a class must do to avail itself of the sorting service—it must implement a compareTo method. That’s eminently reasonable. There needs to be some way for the sort method to compare objects. But why can’t the Employee class simply provide a compareTo method without implementing the Comparable interface?
The reason for interfaces is that the Java programming language is strongly typed. When making a method call, the compiler needs to be able to check that the method actually exists. Somewhere in the sort method will be statements like this:
The compiler must know that a[i] actually has a compareTo method. If a is an array of Comparable objects, then the existence of the method is assured because every class that implements the Comparable interface must supply the method.
You would expect that the sort method in the Arrays class is defined to accept a Comparable[] array so that the compiler can complain if anyone ever calls sort with an array whose element type doesn’t implement the Comparable interface. Sadly, that is not the case. Instead, the sort method accepts an Object[] array and uses a clumsy cast:
If a[i] does not belong to a class that implements the Comparable interface, then the virtual machine throws an exception.
Listing 6–1 presents the full code for sorting an employee array.
Listing 6–1. EmployeeSortTest.java
• int compareTo(T other)
• static void sort(Object[] a)
According to the language standard: “The implementor must ensure sgn(x.compareTo(y)) = –sgn(y.compareTo(x)) for all x and y. (This implies that x.compareTo(y) must throw an exception if y.compareTo(x) throws an exception.)” Here, “sgn” is the sign of a number: sgn(n) is –1 if n is negative, 0 if n equals 0, and 1 if n is positive. In plain English, if you flip the parameters of compareTo, the sign (but not necessarily the actual value) of the result must also flip.
As with the equals method, problems can arise when inheritance comes into play.
Because Manager extends Employee, it implements Comparable<Employee> and not Comparable<Manager>. If Manager chooses to override compareTo, it must be prepared to compare managers to employees. It can’t simply cast the employee to a manager:
That violates the “antisymmetry” rule. If x is an Employee and y is a Manager, then the call x.compareTo(y) doesn’t throw an exception—it simply compares x and y as employees. But the reverse, y.compareTo(x), throws a ClassCastException.
This is the same situation as with the equals method that we discussed in Chapter 5, and the remedy is the same. There are two distinct scenarios.
If subclasses have different notions of comparison, then you should outlaw comparison of objects that belong to different classes. Each compareTo method should start out with the test
if (getClass() != other.getClass()) throw new ClassCastException();
If there is a common algorithm for comparing subclass objects, simply provide a single compareTo method in the superclass and declare it as final.
For example, suppose that you want managers to be better than regular employees, regardless of the salary. What about other subclasses such as Executive and Secretary? If you need to establish a pecking order, supply a method such as rank in the Employee class. Have each subclass override rank, and implement a single compareTo method that takes the rank values into account.
Properties of Interfaces
Interfaces are not classes. In particular, you can never use the new operator to instantiate an interface:
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:
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:
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.
Then, you could imagine an interface called Powered that extends it:
Although you cannot put instance fields or static methods in an interface, you can supply constants in them. For example:
Just as methods in an interface are automatically public, fields are always public static final.
It is legal to tag interface methods as public, and fields as public static final. Some programmers do that, either out of habit or for greater clarity. However, the Java Language Specification recommends that the redundant keywords not be supplied, and we follow that recommendation.
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 discuss this interface in detail in the next section.) If your class implements Cloneable, the clone method in the Object class will make an exact copy of your class’s objects. Suppose, therefore, you want cloneability and comparability. Then you simply implement both interfaces.
class Employee implements Cloneable, Comparable
Use commas to separate the interfaces that describe the characteristics that you want to supply.
Interfaces and Abstract Classes
If you read the section about abstract classes in Chapter 5, you may wonder why the designers of the Java programming language bothered with introducing the concept of interfaces. Why can’t Comparable simply be an abstract class:
The Employee class would then simply extend this abstract class and supply the compareTo method:
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 that the Employee class already extends a different class, say, Person. Then it can’t extend a second class.
class Employee extends Person, Comparable // ERROR
But each class can implement as many interfaces as it likes:
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.
C++ NoteC++ has multiple inheritance and all the complications that come with it, such as virtual base classes, dominance rules, and transverse pointer casts. Few C++ programmers use multiple inheritance, and some say it should never be used. Other programmers recommend using multiple inheritance only for “mix in” style inheritance. In the mix-in style, a primary base class describes the parent object, and additional base classes (the so-called mix-ins) may supply auxiliary characteristics. That style is similar to a Java class with a single base class and additional interfaces. However, in C++, mix-ins can add default behavior, whereas Java interfaces cannot.
Object Cloning
When you make a copy of a variable, 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.
Employee original = new Employee("John Public", 50000);
Employee copy = original;
copy.raiseSalary(10); // oops--also changed original
Figure 6–1. Copying and cloning
If you would like copy to be a new object that begins its life being identical to original but whose state can diverge over time, then you use the clone method.
Employee copy = original.clone();
copy.raiseSalary(10); // OK--original unchanged
But it isn’t quite so simple. The clone method is a protected method of Object, which means that your code cannot simply call it. Only the Employee class can clone Employee objects. There is a reason for this restriction. Think about the way in which the Object class can implement clone. It knows nothing about the object at all, so it can make only a field-by-field copy. If all data fields in the object are numbers or other basic types, copying the fields is just fine. But if the object contains references to subobjects, then copying the field gives you another reference to the subobject, so the original and the cloned objects still share some information.
To visualize that phenomenon, let’s 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.
Does it matter if the copy is shallow? It depends. If the subobject that is shared between the original and the shallow clone is immutable, then the sharing is safe. This certainly happens if the subobject belongs to an immutable class, such as String. Alternatively, the subobject may simply remain constant throughout the lifetime of the object, with no mutators touching it and no methods yielding a reference to it.
Quite frequently, however, subobjects are mutable, and you must redefine the clone method to make a deep copy that clones the subobjects as well. In our example, the hireDay field is a Date, which is mutable.
For every class, you need to decide whether
1. The default clone method is good enough;
2. The default clone method can be patched up by calling clone on the mutable subobjects; and
3. clone should not be attempted.
The third option is actually the default. To choose either the first or the second option, a class must
1. Implement the Cloneable interface; and
2. Redefine the clone method with the public access modifier.
The clone method is declared protected in the Object class so that your code can’t simply call anObject.clone(). But aren’t protected methods accessible from any subclass, and isn’t every class a subclass of Object? Fortunately, the rules for protected access are more subtle (see Chapter 5). A subclass can call a protected clone method only to clone its own objects. You must redefine clone to be public to allow objects to be cloned by any method.
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.
The Cloneable interface is one of a handful of tagging interfaces that Java provides. (Some programmers call them marker interfaces.) Recall that the usual purpose of an interface such as Comparable is to ensure that a class implements a particular method or set of methods. A tagging interface has no methods; its only purpose is to allow the use of instanceof in a type inquiry:
if (obj instanceof Cloneable) . . .
We recommend that you do not use tagging interfaces in your own programs.
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:
Before Java SE 5.0, the clone method always had return type Object. The covariant return types of Java SE 5.0 let you specify the correct return type for your clone methods.
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:
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 class implements the Cloneable interface, so the exception won’t be thrown. However, the compiler does not know that. Therefore, we declared the exception:
public Employee clone() throws CloneNotSupportedException
Would it be better to catch the exception instead?
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 that 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–2 clones an Employee object, 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.
All array types have a clone method that is public, not protected. You can use it to make a new array that contains copies of all elements. For example:
int[] luckyNumbers = { 2, 3, 5, 7, 11, 13 };
int[] cloned = (int[]) luckyNumbers.clone();
cloned[5] = 12; // doesn't change luckyNumbers[5]
Chapter 1 of Volume II shows an alternate mechanism for cloning objects, using the object serialization feature of Java. That mechanism is easy to implement and safe, but it is not very efficient.
Interfaces and Callbacks
A common pattern in programming is the callback pattern. In this pattern, you want to specify the action that should occur whenever a particular event happens. For example, you may want a particular action to occur when a button is clicked or a menu item is selected. However, because you have not yet seen how to implement user interfaces, we consider a similar but simpler situation.
The javax.swing package contains a Timer class that is useful if you want to be notified whenever a time interval has elapsed. For example, if a part of your program contains a clock, then you can ask to be notified every second so that you can update the clock face.
When you construct a timer, you set the time interval and you tell it what it should do whenever the time interval has elapsed.
How do you tell the timer what it should do? In many programming languages, you supply the name of a function that the timer should call periodically. However, the classes in the Java standard library take an object-oriented approach. You pass an object of some class. The timer then calls one of the methods on that object. Passing an object is more flexible than passing a function because the object can carry additional information.
Of course, the timer needs to know what method to call. The timer requires that you specify an object of a class that implements the ActionListener interface of the java.awt.event package. Here is that interface:
The timer calls the actionPerformed method when the time interval has expired.
As you saw in Chapter 5, Java does have the equivalent of function pointers, namely, Method objects. However, they are difficult to use, slower, and cannot be checked for type safety at compile time. Whenever you would use a function pointer in C++, you should consider using an interface in Java.
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.
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 8 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.
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
At the tone, the time is Thu Apr 13 23:29:08 PDT 2000
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 in 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.
• static void showMessageDialog(Component parent, Object message)
• Timer(int interval, ActionListener listener)
• void start()
• void stop()
• static Toolkit getDefaultToolkit()
• void beep()
Inner Classes
An inner class is a class that is defined inside another class. Why would you want to do that? There are three reasons:
• Inner class methods can access the data from the scope in which they are defined—including 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.
• Starting on page 260, you will see a simple inner class that accesses an instance field of its outer class.
• On page 263, we cover the special syntax rules for inner classes.
• Starting on page 264, we peek inside inner classes to see how they are translated into regular classes. Squeamish readers may want to skip that section.
• Starting on page 266, we discuss local inner classes that can access local variables of the enclosing scope.
• Starting on page 269, we introduce anonymous inner classes and show how they are commonly used to implement callbacks.
• Finally, starting on page 271, you will see how static inner classes can be used for nested helper classes.
C++ has nested classes. A nested class is contained inside the scope of the enclosing class. Here is a typical example: a linked list class defines a class to hold the links, and a class to define an iterator position.
The nesting is a relationship between classes, not objects. A LinkedList object does not have subobjects of type Iterator or Link.
There are two benefits: name control and access control. Because the name Iterator is nested inside the LinkedList class, it is externally known as LinkedList::Iterator and cannot conflict with another class called Iterator. In Java, this benefit is not as important because Java packages give the same kind of name control. Note that the Link class is in the private part of the LinkedList class. It is completely hidden from all other code. For that reason, it is safe to make its data fields public. They can be accessed by the methods of the LinkedList class (which has a legitimate need to access them), and they are not visible elsewhere. In Java, this kind of control was not possible until inner classes were introduced.
However, the Java inner classes have an additional feature that makes them richer and more useful than nested classes in C++. An object that comes from an inner class has an implicit reference to the outer class object that instantiated it. Through this pointer, it gains access to the total state of the outer object. You will see the details of the Java mechanism later in this chapter.
In Java, static inner classes do not have this added pointer. They are the Java analog to nested classes in C++.
Use of an Inner Class to Access Object State
The syntax for inner classes is rather complex. For that reason, we use a simple but somewhat artificial example to demonstrate the use of inner classes. We refactor the TimerTest example and extract a TalkingClock class. A talking clock is constructed with two parameters: the interval between announcements and a flag to turn beeps on or off.
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.
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
This reference is invisible in the definition of the inner class. However, to illuminate the concept, let us call the reference to the outer object outer. Then, the actionPerformed method is equivalent to the following:
The outer class reference is set in the constructor. The compiler modifies all inner class constructors, adding a parameter for the outer class reference. Because the TimePrinter class defines no constructors, the compiler synthesizes a default constructor, generating code like this:
Again, please note, 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:
ActionListener listener = new TimePrinter(this); // parameter automatically added
Listing 6–4 shows the complete program that tests the inner class. Have another look at the access control. Had the TimePrinter class been a regular class, then 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.
We could have declared the TimePrinter class as private. Then only TalkingClock methods would be able to construct TimePrinter objects. Only inner classes can be private. Regular classes always have either package or public visibility.
Listing 6–4. InnerClassTest.java
Special Syntax Rules for Inner Classes
In the preceding section, we explained the outer class reference of an inner class by calling it outer. Actually, the proper syntax for the outer reference is a bit more complex. The expression
OuterClass.this
denotes the outer class reference. For example, you can write the actionPerformed method of the TimePrinter inner class as
Conversely, you can write the inner object constructor more explicitly, using the syntax
outerObject.new InnerClass(construction parameters)
For example:
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, because TimePrinter is a public inner class, you can construct a TimePrinter for any talking clock:
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.
Are Inner Classes Useful? Actually Necessary? Secure?
When inner classes were added to the Java language in Java 1.1, many programmers considered them a major new feature that was out of character with the Java philosophy of being simpler than C++. The inner class syntax is undeniably complex. (It gets more complex as we study anonymous inner classes later in this chapter.) It is not obvious how inner classes interact with other features of the language, such as access control and security.
By adding a feature that was elegant and interesting rather than needed, has Java started down the road to ruin that has afflicted so many other languages?
While we won’t try to answer this question completely, it is worth noting that inner classes are a phenomenon of the compiler, not the virtual machine. Inner classes are translated into regular class files with $ (dollar signs) delimiting outer and inner class names, and the virtual machine does not have any special knowledge about them.
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
If you use UNIX, remember to escape the $ character if you supply the class name on the command line. That is, run the ReflectionTest or javap program as
java ReflectionTest TalkingClock$TimePrinter
or
javap -private TalkingClock$TimePrinter
You will get the following printout:
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.
Now let us look at the actionPerformed method. It needs to access outer.beep.
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, because inner classes 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:
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 inner class methods call that method. The statement
if (beep)
in the actionPerformed method of the TimePrinter class effectively makes the following call:
if (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. Because 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 that are 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.
The synthesized constructors and methods can get quite convoluted. (Skip this note if you are squeamish.) Suppose we turn TimePrinter into a private inner class. There are no private classes in the virtual machine, so the compiler produces the next best thing, a package-visible class with a private constructor
private TalkingClock$TimePrinter(TalkingClock);
Of course, nobody can call that constructor, so there is a second package-visible constructor
TalkingClock$TimePrinter(TalkingClock, TalkingClock$1);
that calls the first one.
The complier translates the constructor call in the start method of the TalkingClock class to
new TalkingClock$TimePrinter(this, null)
Local Inner Classes
If you look carefully at the code of the TalkingClock example, you will find that you need the name of the type TimePrinter only once: when you create an object of that type in the start method.
When you have a situation like this, you can define the class locally in a single method.
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 a 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.
Accessing final Variables from Outer Methods
Local classes have another advantage over other inner classes. Not only can they access the fields of their outer classes, they can even access local variables! However, those local variables must be declared final. Here is a typical example. Let’s move the interval and beep parameters from the TalkingClock constructor to the start method.
Note that the TalkingClock class no longer needs to store a beep instance field. It simply refers to the beep parameter variable of the start method.
Maybe this should not be so surprising. The line
if (beep) . . .
is, after all, ultimately inside the start method, so why shouldn’t it have access to the value of the beep variable?
To see why there is a subtle issue here, let’s consider the flow of control more closely.
1. The start method is called.
2. The object variable listener is initialized by a call to the constructor of the inner class TimePrinter.
3. The listener reference is passed to the Timer constructor, the timer is started, and the start method exits. At this point, the beep parameter variable of the start method no longer exists.
4. A second later, the actionPerformed method executes if (beep) . . ..
For the code in the actionPerformed method to work, the TimePrinter class must have copied the beep field, as a local variable of the start method, before the beep parameter value went away. That is indeed exactly what happens. In our example, the compiler synthesizes the name TalkingClock$1TimePrinter for the local inner class. If you use the ReflectionTest program again to spy on the TalkingClock$1TimePrinter class, you get the following output:
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 of them, and copies the local variables into the constructor so that the instance fields can be initialized.
From the programmer’s point of view, local variable access is quite pleasant. It makes your inner classes simpler by reducing the instance fields that you need to program explicitly.
As we already mentioned, the methods of a local class can refer only to local variables that are declared final. For that reason, the beep parameter was declared final in our example. A local variable that is declared final cannot be modified after it has been initialized. Thus, it is guaranteed that the local variable and the copy that is made inside the local class always have the same value.
You have seen final variables used for constants, such as
public static final double SPEED_LIMIT = 55;
The final keyword can be applied to local variables, instance variables, and static variables. In all cases it means the same thing: You can assign to this variable once after it has been created. Afterwards, you cannot change the value—it is final.
However, you don’t have to initialize a final variable when you define it. For example, the final parameter variable beep is initialized once after its creation, when the start method is called. (If the method is called multiple times, each call has its own newly created beep parameter.) The val$beep instance variable that you can see in the TalkingClock$1TimePrinter inner class is set once, in the inner class constructor. A final variable that isn’t initialized when it is defined is often called a blank final variable.
The final restriction is somewhat inconvenient. Suppose, for example, you want to update a counter in the enclosing scope. Here, we want to count how often the compareTo method is called during sorting.
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. The remedy is to use an array of length 1:
(The array variable is still declared as final, but that merely means that you can’t have it refer to a different array. You are free to mutate the array elements.)
When inner classes were first invented, the prototype compiler automatically made this transformation for all local variables that were modified in the inner class. However, some programmers were fearful of having the compiler produce heap objects behind their backs, and the final restriction was adopted instead. It is possible that a future version of the Java language will revise this decision.
Anonymous Inner Classes
When using local inner classes, you can often go a step further. If you want to make only a single object of this class, you don’t even need to give the class a name. Such a class is called an anonymous inner class.
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 { }.
Here, SuperType can be an interface, such as ActionListener; then, the inner class implements that interface. Or SuperType can be a class; then, the inner class extends that class.
An anonymous inner class cannot have constructors because the name of a constructor must be the same as the name of a class, and the class has no name. Instead, the construction parameters are given to the superclass constructor. In particular, whenever an inner class implements an interface, it cannot have any construction parameters. Nevertheless, you must supply a set of parentheses as in
You have to look carefully to see the difference between the construction of a new object of a class and the construction of an object of an anonymous inner class extending that class.
If the closing parenthesis of the construction parameter list is followed by an opening brace, then an anonymous inner class is being defined.
Are anonymous inner classes a great idea or are they a great way of writing obfuscated code? Probably a bit of both. When the code for an inner class is short, just a few lines of simple code, then anonymous inner classes can save typing time, but it is exactly time-saving features like this that lead you down the slippery slope to “Obfuscated Java Code Contests.”
Listing 6–5 contains the complete source code for the talking clock program with an anonymous inner class. If you compare this program with Listing 6–4, you will find that in this case the solution with the anonymous inner class is quite a bit shorter, and, hopefully, with a bit of practice, as easy to comprehend.
Listing 6–5. AnonymousInnerClassTest.java
Static Inner Classes
Occasionally, you want to use an inner class simply to hide one class inside another, but you don’t need the inner class to have a reference to the outer class object. You can suppress the generation of that reference by declaring the inner class static.
Here is a typical example of where you would want to do this. Consider the task of computing the minimum and maximum value in an array. Of course, you write one method to compute the minimum and another method to compute the maximum. When you call both methods, then the array is traversed twice. It would be more efficient to traverse the array only once, computing both the minimum and the maximum simultaneously.
However, the method must return two numbers. We can achieve that by defining a class Pair that holds two values:
The minmax function can then return an object of type Pair.
The caller of the function uses the getFirst and getSecond methods to retrieve the answers:
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, except that the other programmer 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:
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:
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:
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.
You use a static inner class whenever the inner class does not need to access an outer class object. Some programmers use the term nested class to describe static inner classes.
Inner classes that are declared inside an interface are automatically static and public.
Listing 6–6 contains the complete source code of the ArrayAlg class and the nested Pair class.
Listing 6–6. StaticInnerClassTest.java
Proxies
In the final section of this chapter, we discuss proxies, a feature that became available with Java SE 1.3. You use a proxy to create at runtime new classes that implement a given set of interfaces. Proxies are only necessary when you don’t yet know at compile time which interfaces you need to implement. This is not a common situation for application programmers, and you should feel free to skip this section if you are not interested in advanced wizardry. However, for certain system programming applications, the flexibility that proxies offer can be very important.
Suppose you want to construct an object of a class that implements one or more interfaces whose exact nature you may not know at compile time. This is a difficult problem. To construct an actual class, you can simply use the newInstance method or use reflection to find a constructor. But you can’t instantiate an interface. You need to define a new class in a running program.
To overcome this problem, some programs generate code, place it into a file, invoke the compiler, and then load the resulting class file. Naturally, this is slow, and it also requires deployment of the compiler together with the program. The proxy mechanism is a better solution. The proxy class can create brand-new classes at runtime. Such a proxy class implements the interfaces that you specify. In particular, the proxy class has the following methods:
• All methods required by the specified interfaces; and
• All methods defined in the Object class (toString, equals, and so on).
However, you cannot define new code for these methods at runtime. Instead, you must supply an invocation handler. An invocation handler is an object of any class that implements the InvocationHandler interface. That interface has a single method:
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.
To create a proxy object, you use the newProxyInstance method of the Proxy class. The method has three parameters:
• A class loader. As part of the Java security model, different class loaders for system classes, classes that are downloaded from the Internet, and so on, can be used. We 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; and
• 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.
Here is how you construct a proxy object that causes the tracing behavior whenever one of its methods is called:
Now, whenever a method from one of the interfaces is called on proxy, the method name and parameters are printed out and the method is then invoked on value.
In the program shown in Listing 6–7, 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.
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.
As you saw earlier in this chapter, as of Java SE 5.0, the Integer class actually implements Comparable<Integer>. However, at runtime, all generic types are erased and the proxy is constructed with the class object for the raw Comparable class.
The binarySearch method makes calls like this:
if (elements[i].compareTo(key) < 0) . . .
Because 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
System.out.println(elements[result]);
The println method calls toString on the proxy object, and that call is also redirected to the invocation handler.
Here is the complete trace of a program run:
500.compareTo(288)
250.compareTo(288)
375.compareTo(288)
312.compareTo(288)
281.compareTo(288)
296.compareTo(288)
288.compareTo(288)
288.toString()
You can see how the binary search algorithm homes in on the key by cutting the search interval in half in every step. Note that the toString method is proxied even though it does not belong to the Comparable interface—as you will see in the next section, certain Object methods are always proxied.
Properties of Proxy Classes
Now that you have seen proxy classes in action, we want to go over some of their properties. Remember that proxy classes are created on the fly in a running program. However, once they are created, they are regular classes, just like any other classes in the virtual machine.
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 that are 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–7, 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 Sun’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, then you get two objects of the same class. You can also obtain that class with the getProxyClass method:
Class proxyClass = Proxy.getProxyClass(null, interfaces);
A proxy class is always public and final. If all interfaces that the proxy class implements are public, then the proxy class does not belong to any particular package. Otherwise, all non-public interfaces must belong to the same package, and then the proxy class also belongs to that package.
You can test whether a particular Class object represents a proxy class by calling the isProxyClass method of the Proxy class.
java.lang.reflect.InvocationHandler 1.3
• Object invoke(Object proxy, Method method, Object[] args)
• static Class getProxyClass(ClassLoader loader, Class[] interfaces)
• static Object newProxyInstance(ClassLoader loader, Class[] interfaces, InvocationHandler handler)
• static boolean isProxyClass(Class c)
This ends our final chapter on the fundamentals of the Java programming language. Interfaces and inner classes are concepts that you will encounter frequently. However, as we already mentioned, proxies are an advanced technique that is of interest mainly to tool builders, not application programmers. You are now ready to go on to learn about graphics and user interfaces, starting with Chapter 7.