The biggest, most far-reaching new feature to come into Java with the JDK 1.5 release is “type genericity”—the ability to pass types as arguments, just the way we can pass values as arguments. In this chapter we'll take a close look at generic types, see what software problem they solve, and describe how they were retro-fitted into the language and run-time system (not an easy thing).
We'll start with a reminder on terminology—if we don't keep the terminology straight here, we're lost! We'll finish with a look at some advanced features of generics, features really intended for library designers, but also useful for everyone else to know how to read. There's a small corner of generics (specifically, generic methods rather than classes) that we'll defer to the next chapter.
Generics are based on an idea that seems simple—code can be parameterized with types as well as variables. However, the topic quickly moves into compiler theory and challenging intellectual rigor. We'll surely see entire books on Java generics in due course, just like there are entire books on C pointers. To help things along, this chapter sometimes introduces new concepts that depend on previous concepts and previous examples. To get a clear picture you'll need to read the sections in sequence.
Everyone is familiar with the concept of methods having parameters. When you write the method, you write the parameters in a comma-separated list. Here's the declaration of the power() function in Java.lang.Math:
static double pow(double a, double b) { /*more*/ }
The method returns the value of a raised to the power b. The variables a and b are parameters to the method. Here's the point: The method will calculate that value for any a and b. Parameters let us write that method once, use it on any pairs of numbers, and refer to the different numbers coming into the method by unchanging names in the method body.
Arguments are the converse. At the place where we invoke the method, we write the method name and supply the specific variables or values that we want the method to work on, in this particular case:
import static java.lang.Math.*;
double result = pow(10.0, PI );
The literal 10.0 and the constant Math.PI (the closest approximation to PI that a double can hold) are the arguments for this call. Other calls may have different arguments.
result = pow(x, y);
The compiler plants code to do a parameter = argument assignment for each parameter on every call. This takes place right before the call, in a method prolog that you don't see.
In a single sentence, the concept of generics is “We want to have a parameter that represents a type, not a value. We'll instantiate objects-of-the-generic-class using different types (Integer, Timestamp, Double, Thread) as the type argument. Each object will be specialized to do work on that specific actual type argument.” OK, three sentences. We indicate that something is a type parameter by enclosing it in angle brackets, e.g. <String>. The type parameters come right after the name of the class being parameterized. e.g. class List <String>. That is read as List specialized for String, abbreviated to “List of String”.
Let's motivate the feature by looking at the problem.