Start Concurrent: A Gentle Introduction to Concurrent Programming

Learning to use classes as we did in Chapter 9 provides us with useful tools. First, we can group related data together. Then, we can encapsulate that data so that it can only be changed in carefully controlled ways. But these ideas are only a fraction of the true power of object orientation available when we exploit relationships between different classes. Eventually, in Chapter 11, we’ll talk about hierarchical relationships, where one class can be the parent of many other child classes.

However, there’s a simpler relationship that classes can share, the ability to do some specific action or answer some specific question. If we know that several different classes can all do the same things, we want to be able to treat them in a unified way. For example, imagine that you’re writing code to do laboratory analysis of the free radical content of a number of creatures and items. For this analysis it’s necessary to sort the test subjects by weight and by age.

The subjects you’re going to sort will be objects of type Dog, Cat, Person, and Cheese. All of these subjects will have some calendar age. Naturally, the age we’re interested for a Dog is 7 times its calendar age. At the same time, because a cat has nine lives, we’ll use 1/9 of its calendar age. The age we use for Person and Cheese objects is simply their calendar age.

As we discussed in Example 6.2, sorting is one of the most fundamental tools for computer scientists. In that example, we introduced selection sort. Here we’re going to use another sort called bubble sort. We introduce bubble sort to expose you to another way to sort data. Although both are easy to understand, neither bubble sort nor selection sort are the fastest ways known to sort lists.

Bubble sort works by scanning through a list of items, a pair at a time, and swapping the elements of the pair if they’re out of order. One scan through the list is called a pass. The algorithm keeps making passes until no consecutive pair of elements is out of order. Here’s an implementation of bubble sort that sorts an array of int values in ascending order.

The only change needed to make a bubble sort work with lists of arbitrary objects (instead of just int values) is the if statement. Likewise, changing the greater than (>) to a less than (<) will change the sort from ascending to descending.

Knowing how to sort a list of items is half the problem we want to solve. The other half is designing the classes so that sorting by either age or weight is easy. And easy sorting isn’t enough: We want to follow good object-oriented design so that sorting future classes will be easy as well.

For these kinds of situations, Java has a feature called interfaces. An interface is a set of methods that an object must have in order to implement that interface. If an object implements an interface, it’s making a promise to have a version of each of the methods listed in the interface. It can choose to do anything it wants inside the body of each method, but it must have them to compile. Interfaces are also described as contracts, since a contract is a promise to do certain things. One reason that interfaces are so useful is because Java allows objects to implement any number of them.

The purpose of an interface is to guarantee that an object has the capability to do something. In the case of this sorting problem, we’ll need to sort by age and weight. Consequently, the ability to report age and weight are the two important capabilities that the objects must have.

Declaring an interface is similar to declaring a class except that interfaces can only hold abstract methods, default methods, static methods, and constants. Note that interfaces can never contain fields other than constants. Because the purpose of an interface is to ensure that an object has certain publicly available capabilities, all methods and constants listed in an interface are assumed to be public. It’s legal but clutters code to mark interface members with public, and it’s illegal to mark them with private or protected.

An abstract method is one that doesn’t have a body. Its return type, name, and parameters are given, but this information is concluded with a semicolon (;) instead of a method body.

Here’s an interface for a guitar player that defines two abstract methods.

Any object that implements this interface must have both of these methods, declared with the access modifier public, the same return types, and the same parameter types. We could create a RockGuitarist class that implements Guitarist as follows.

Or we can create a ClassicalGuitarist class. A classical guitarist is going to approach playing a chord or a melody differently from a rock guitarist. Java only requires that all the methods in the interface are implemented.

Interfaces make our code more flexible because we can use a reference with an interface type to refer to any objects that implement the interface. In the following snippet of code, we do this by creating 100 Guitarist references, each of which randomly points to either a RockGuitarist or a ClassicalGuitarist.

One benefit of using interfaces is that more mistakes can be caught at compile time instead of run time. If you implement an interface with a class you’re writing but forget (or misspell) a required method, the compiler will fail to compile that class. If you remember all of the required methods but forget to specify that your class implements a particular interface, the compiler will fail when you try to use that class in a place where that interface is required.

If you have code that takes some arbitrary object as a parameter, you can determine if that object implements a particular interface by using the instanceof keyword. For example, the following method takes a Chord object and an object of type Object. The Object type is the most basic reference type there is. All reference types in Java can be treated as an Object type. Thus, a reference of type Object could point at any object of any type. In this case, if the Object turns out to implement the Guitarist interface, we can cast it to a Guitarist and use it to strum a chord.

If you haven’t read Section 9.4, you may want to look over that material to be sure you understand what nested classes and inner classes are. Recall that a normal inner class is declared inside of another class, but it’s also legal to declare a class inside of a method. Such a class is called a local class. Under some circumstances, it’s useful to create an inner class with no name, called an anonymous class.

Both kinds of classes are inner classes. They can access fields and methods, even private ones. Like other inner classes, they’re not allowed to declare static variables other than constants. We bring up these special kinds of classes in this chapter because they’re commonly used to create a class with a narrow purpose that implements a required interface.

It’s not difficult to move from totaling the value of items as we did in Example 10.1 to sorting them. Refer to the following class diagram as we explain our solution to the sorting problem posed at the beginning of the chapter. Dotted lines are used to show the “implements” relationship.

We’ll start with the definitions of the two interfaces we’ll use to compare objects.

Classes implementing these two interfaces will be able to give their age and weight independently. The next step is to create the Dog, Cat, Person, and Cheese classes which implement them.

We’ll see in Chapter 11 that the Dog, Cat, and Person classes could inherit from a common ancestor (such as Creature or Mammal) which implements the Ageable and Weighable interfaces. That design could reduce the total amount of code needed. For now, each class will have to implement both interfaces directly.

With the classes in place, we can assume that client code will instantiate some objects and perform operations on them. All that’s necessary is to write the method that will do the sorting. We can wrap the bubble sort code given earlier in a method body with only a few changes to generalize the sort beyond int values.

In this method, the boolean age is true if we’re sorting by age and false if we’re sorting by weight. Note that the array elements and temp have the Object type. Recall that any object can be stored in a reference of type Object.

The only other change we needed was to replace the greater-than comparison (>) with the outOfOrder() method, which we define below.

Even though we’ve designed our program for objects that implement both the Ageable and Weighable interfaces, the compiler only sees Object references in the array. Thus, we must cast each object to the appropriate interface type to do the comparison. There’s a danger that a user will pass in an array with objects which do not implement both Ageable and Weighable, causing a ClassCastException. To allow for universal sorting methods, the Java API defines a Comparable interface which can be implemented by any class which requires sorting. With Java 5 and higher, the Comparable interface uses generics to be more type-safe, but we won’t discuss how to use this interface until we cover generics in Chapter 18.

As we discussed in Section 10.2, implementing an interface means promising to have public methods with the signatures specified in the interface definition. Making a promise seems only tangentially related to having multiple threads of execution. Indeed, interfaces and concurrency do not overlap a great deal, but there are two important areas where they affect one another.

The first is that a special interface called the Runnable interface can be used to create new threads of execution. Runnable is a very simple interface, containing the single signature void run(). Essentially, any object with a run() method that takes no arguments and returns no values can be used to create a thread of execution. Just as a regular program has a single starting place, the main() method, some method needs to be marked as a starting place for additional threads. For more information about using the Runnable interface, refer to Section 13.4.5.

The second connection between interfaces and concurrency is more philosophical. What can you specify in an interface? The rules for interfaces in Java are relatively limited: You can require a class to have a public instance method with specific parameters and a specific return type. Java interfaces don’t allow you to require a static method.

In Chapter 14, we will discuss a key way to make classes thread-safe by using the synchronized keyword. Like static, Java does not allow an interface to specify whether a method is synchronized. Thus, it’s impossible to use an interface to guarantee that a method will be thread-safe.

As with all interface usage, this restriction cuts both ways: If you’re designing an interface, there’s no way to guarantee that implementing classes use synchronized methods. On the other hand, if you’re implementing an interface, the designer may hope that your class uses synchronized (or otherwise thread-safe) methods, but the interface cannot force you to do so. Whenever thread-safety is an issue, make sure you read (or write) the documentation carefully. Since there’s no way to force programmers to use the synchronized keyword, the documentation may be the only guide.

Conceptual Problems

Programming Practice

Experiments