Generics

Ordinary classes and methods work with specific types: either

primitives or class types. If you are writing code that might be used across more types, this rigidity can be overconstraining.

One way that object-oriented languages allow generalization is through polymorphism. You can write (for example) a method that takes a base class object as an argument, and then use that method with any class derived from that base class. Now your method is a little more general and can be used in more places. The same is true within classes—anyplace you use a specific type, a base type provides more flexibility. Of course, anything but a

final

class can be extended(Or a class with all

private

constructors.), so this flexibility is automatic much of the time.

Sometimes, being constrained to a single hierarchy is too limiting. If a method argument is an

interface

instead of a class, the limitations are loosened to include anything that

implements the

interface

—including classes that haven’t been created yet. This gives the client programmer the option of implementing an

interface

in order to conform to your class

or method. So interfaces allow you to cut across class hierarchies, as long as you have the option to create a new class in order to do so.

Sometimes even an interface is too restrictive. An interface still requires that your code work with that particular interface. You could write even more general code if you could say that your code works with “some unspecified type,” rather than a specific interface or class.

This is the concept of generics, one of the more significant changes in Java SE5. Generics implement the concept of parameterized types, which allow multiple types. The term

“generic” means “pertaining(适合; 关于，有关; 附属，从属) or appropriate to large groups of classes.” The original intent of

generics in programming languages was to allow the programmer the greatest amount of expressiveness possible when writing classes or methods, by loosening the constraints on the

types that those classes or methods work with. As you will see in this chapter, the Java implementation of generics is not that broad reaching—indeed, you may question whether the term “generic” is even appropriate for this feature.

If you’ve never seen any kind of parameterized type mechanism before, Java generics will probably seem like a convenient addition to the language. When you create an instance of a parameterized type, casts will be taken care of for you and the type correctness will be ensured at compile time. This seems like an improvement.

However, if you’ve had experience with a parameterized type mechanism, in C++, for example, you will find that you can’t do everything that you might expect when using Java

generics. While using someone else’s generic type is fairly easy, when creating your own you will encounter a number of surprises. One of the things I shall try to explain is how the

feature came to be like it is.

This is not to say that Java generics are useless. In many cases they make code more straightforward and even elegant. But if you’re coming from a language that has implemented a more pure version of generics, you may be disappointed. In this chapter, we will examine both the strengths and the limitations of Java generics so that you can use this new feature more effectively.

Comparison with C++

The Java designers stated that much of the inspiration for the language came as a reaction to C++. Despite this, it is possible to teach Java largely without reference to C++, and I have

endeavored(尝试，试图) to do so except when the comparison will give you greater depth of understanding.

Generics require more comparison with C++ for two reasons. First, understanding certain aspects of C++ templates (the main inspiration for generics, including the basic syntax) will

help you understand the foundations of the concept, as well as—and this is very important— the limitations of what you can do with Java generics and why. The ultimate goal is to give

you a clear understanding of where the boundaries lie, because my experience is that by understanding the boundaries, you become a more powerful programmer. By knowing what you can’t do, you can make better use of what you can do (partly because you don’t waste time bumping up against walls).

The second reason is that there is significant misunderstanding in the Java community about C++ templates, and this misunderstanding may further confuse you about the intent of

generics.

So although I will introduce a few C++ template examples in this chapter, I will keep them to a minimum.

Simple generics

One of the most compelling initial motivations for generics is to create container classes,which you saw in the Holding Your Objects chapter (you’ll learn more about these in the

Containers in Depth chapter). A container is a place to hold objects while you’re working with them. Although this is also true of arrays, containers tend to be more flexible and have

different characteristics than simple arrays. Virtually all programs require that you hold a group of objects while you use them, so containers are one of the most reusable of class

libraries.

Let’s look at a class that holds a single object. Of course, the class could specify the exact type of the object, like this:

//: generics/Holder1.java

class Automobile {}

public class Holder1 {
private Automobile a;
public Holder1(Automobile a) { this.a = a; }
Automobile get() { return a; }
} ///:~

But this is not a very reusable tool, since it can’t be used to hold anything else. We would prefer not to write a new one of these for every type we encounter.

Before Java SE5, we would simply make it hold an

Object

:

//: generics/Holder2.java

public class Holder2 {
private Object a;
public Holder2(Object a) { this.a = a; }
public void set(Object a) { this.a = a; }
public Object get() { return a; }
public static void main(String[] args) {
Holder2 h2 = new Holder2(new Automobile());
Automobile a = (Automobile)h2.get();
h2.set("Not an Automobile");
String s = (String)h2.get();
h2.set(1); // Autoboxes to Integer
Integer x = (Integer)h2.get();
}
} ///:~

Now a

Holder2

can hold anything—and in this example, a single

Holder2

holds three different types of objects.

There are some cases where you want a container to hold multiple types of objects, but typically you only put one type of object into a container. **One of the primary motivations for generics is to specify what type of object a container holds, and to have that specification backed up by the compiler.

So instead of

Object

, we’d like to use an unspecified type, which can be decided at a later time. To do this, you put a type parameter inside angle brackets after the class name, and then substitute an actual
4000
type when you use the class. For the “holder” class, it looks like this,where

T

is the type parameter:

//: generics/Holder3.java

public class Holder3<T> {
private T a;
public Holder3(T a) { this.a = a; }
public void set(T a) { this.a = a; }
public T get() { return a; }
public static void main(String[] args) {
Holder3<Automobile> h3 =
new Holder3<Automobile>(new Automobile());
Automobile a = h3.get(); // No cast needed
// h3.set("Not an Automobile"); // Error
// h3.set(1); // Error
}
} ///:~

Now when you create a

Holders

, you must specify what type you want to put into it using the same angle-bracket syntax, as you can see in

main()

. You are only allowed to put objects

of that type (or a subtype, since the substitution principle still works with generics) into the holder. And when you get a value out, it is automatically the right type.

That’s the core idea of Java generics: You tell it what type you want to use, and it takes care of the details.

In general, you can treat generics as if they are any other type—they just happen to have type parameters. But as you’ll see, you can use generics just by naming them along with their type

argument list.

A tuple library

One of the things you often want to do is return multiple objects from a method call. The return statement only allows you to specify a single object, so the answer is to create an

object that holds the multiple objects that you want to return. Of course, you can write a special class every time you encounter the situation, but with generics it’s possible to solve the problem once and save yourself the effort in the future. At the same time, you are ensuring compile-time type safety.

This concept is called a tuple, and it is simply a group of objects wrapped together into a single object. The recipient(接受者; 容器; 容纳者;) of the object is allowed to read the elements but not put new ones in. (This concept is also called a Data Transfer Object (or Messenger.)

Tuples can typically be any length, but each object in the tuple can be of a different type.However, we want to specify the type of each object and ensure that when the recipient reads

the value, they get the right type. To deal with the problem of multiple lengths, we create multiple different tuples. Here’s one that holds two objects:

//: net/mindview/util/TwoTuple.java
package net.mindview.util;

public class TwoTuple<A,B> {
public final A first;
public final B second;
public TwoTuple(A a, B b) { first = a; second = b; }
public String toString() {
return "(" + first + ", " + second + ")";
}
} ///:~

The constructor captures the object to be stored, and

toString( )

is a convenience function to display the values in a list. Note that a tuple implicitly keeps its elements in order.

Upon first reading, you may think that this could violate common safety principles of Java programming. Shouldn’t

first

and

second

be private, and only accessed with methods named

getFirst()

and

getSecond()

? Consider the safety that you would get in that case:Clients could still read the objects and do whatever they want with them, but they could not assign

first

or

second

to anything else. The

final

declaration buys you the same safety, but the above form is shorter and simpler.

Another design observation is that you might want to allow a client programmer to point

first

or

second

to another object. However, it’s safer to leave it in the above form, and just force the user to create a new

TwoTuple

if they want one that has different elements.

The longer-length tuples can be created with inheritance. You can see that adding more type parameters is a simple matter:

//: net/mindview/util/ThreeTuple.java
package net.mindview.util;

public class ThreeTuple<A,B,C> extends TwoTuple<A,B> {
public final C third;
public ThreeTuple(A a, B b, C c) {
super(a, b);
third = c;
}
public String toString() {
return "(" + first + ", " + second + ", " + third +")";
}
} ///:~

//: net/mindview/util/FourTuple.java
package net.mindview.util;

public class FourTuple<A,B,C,D> extends ThreeTuple<A,B,C> {
public final D fourth;
public FourTuple(A a, B b, C c, D d) {
super(a, b, c);
fourth = d;
}
public String toString() {
return "(" + first + ", " + second + ", " +
third + ", " + fourth + ")";
}
} ///:~

//: net/mindview/util/FiveTuple.java
package net.mindview.util;

public class FiveTuple<A,B,C,D,E>
extends FourTuple<A,B,C,D> {
public final E fifth;
public FiveTuple(A a, B b, C c, D d, E e) {
super(a, b, c, d);
fifth = e;
}
public String toString() {
return "(" + first + ", " + second + ", " +
third + ", " + fourth + ", " + fifth + ")";
}
} ///:~

To use a tuple, you simply define the appropriate-length tuple as the return value for your function, and then create and return it in your return statement: