Generics 101, Part 1: What Are Generics?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Java 2 Standard Edition 5.0 introduced generics to Java developers. Many developers have been put off by this suite of language features because they’ve found generics difficult to grasp. However, learning generics doesn’t need to be difficult, as this article and its two successors prove.
This article initiates a three-part series that helps you master generics fundamentals. Part 1 focuses on the "What are generics?" question and the rationale for using them. Part 2 explores generics features in the context of a generic stack type, and Part 3 explores generics features in the context of a generic copy method.
What Are Generics?
Generics are language features that promote type safety (discussed later in this article). Chief among these features is the generic type, which is a class or interface whose name is followed by a formal type parameter list (an angle-bracketed and comma-separated list of type parameters—parameters that accept type names, such as String or Employee, as arguments).
Generic types are syntactically expressed as follows:
class identifier<formal_type_parameter_list> {}
interface identifier<formal_type_parameter_list> {}
Java's collections framework offers many examples of generic types. For instance, the java.util package includes Set<E>, which consists of the Set interface and type parameter E (identifying the set's element type). Also, this package includes Map<K, V>, which consists of the Map interface and type parameters K and V (identifying the map's key and value types, respectively).
Although the collections framework is the prime beneficiary for generics, this suite of language features isn't exclusive to this framework. For example, each of the java.lang.Class, java.lang.ThreadLocal, and java.lang.ref.WeakReference classes has been generified to support generics: Class<T>, ThreadLocal<T>, and WeakReference<T> are the results.
A parameterized type is an instance of a generic type where the type parameters in the formal type parameter list are replaced with type names. Examples include Set<Country> (Set of Country), where Country replaces E in Set<E>; and Map<String, Part> (Map of String keys and Part values), where String and Part replace K and V in Map<K, V>.
A type name that replaces a type parameter is referred to as an actual type argument. For example, Country is an actual type argument in Set<Country>, and String and Part are actual type arguments in Map<String, Part>. Generics support five kinds of actual type arguments:
- Concrete type: The type parameter is passed the name of a class or interface. For example, Set<Country> countries; specifies that the set's elements are Country instances.
- Concrete parameterized type: The type parameter is passed the name of a parameterized type. For example, List<List<Employee>> empLists; specifies that the list's elements are lists of Employee instances.
- Array type: The type parameter is passed an array. For example, List<String[]> solarSystems; specifies that the list's elements are arrays of Strings, possibly the names of planets occupying each solar system.
- Type parameter: The type parameter is passed a type parameter. For example, given class declaration class ToDoList<E> { List<E> items; /* ... */ }, ToDoList's E type parameter is passed to List's E type parameter.
- Wildcard: The type parameter is passed a question mark symbol (?), indicating an unknown actual type argument. For example, Set<?> indicates that that the set's elements are unknown. (I'll have more to say about wildcards later in this article.)
Generic types imply the existence of raw types, which are generic types without formal type parameter lists. For example, Set<Country>'s raw type is Set. Raw types aren't generic and (as far as collections are concerned) their instances can store elements of Object or any subtype. Java lets you mix raw types with generic types to support the large base of nongeneric legacy code written before generics.
The Rationale for Using Generics
Java developers strive to create Java programs that work correctly for their clients—no developer wants code to fail and then be faced with an angry client. Failure is typically indicated through thrown exceptions; ClassCastExceptions (resulting from improper casting) are among the worst because they usually are not expected (and are not logged so that their causes can be found). Take a look at Listing 1.
Listing 1—BeforeGenerics.java
// BeforeGenerics.java
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
public class BeforeGenerics
{
public static void main(String[] args)
{
List l = new ArrayList();
l.add(new Double(101.0));
l.add(new Double(89.0));
l.add(new Double(33.0));
double avg = calculateAverage(l);
System.out.println("Average = "+avg);
l.add("Average");
avg = calculateAverage(l);
System.out.println("Average = "+avg);
}
static double calculateAverage(List l)
{
double sum = 0.0;
Iterator iter = l.iterator();
while (iter.hasNext())
sum += ((Double) iter.next()).doubleValue();
return sum/l.size();
}
}
Listing 1 averages the floating-point values in a List-referenced ArrayList of Double objects. Somewhere in this source code lurks a bug that leads to a thrown ClassCastException. If you compile BeforeGenerics.java with a pre-J2SE 5.0 compiler, no error/warning message outputs. Instead, you only discover this bug when you run the program:
Average = 74.33333333333333
Exception in thread "main" java.lang.ClassCastException: java.lang.String
at BeforeGenerics.calculateAverage(BeforeGenerics.java:30)
at BeforeGenerics.main(BeforeGenerics.java:21)
The thrown ClassCastException is caused indirectly by l.add("Average"); and directly by sum += ((Double) iter.next()).doubleValue();. This exception is thrown when iter.next() returns the previously added String and the cast from String to Double is attempted.
This exception indicates that the program is not type-safe; it arises from assuming that collections are homogeneous—they store objects of a specific type or of a family of related types. In reality, these collections are heterogeneous—they are capable of storing any type of object because the element type of collections is Object.
Although ClassCastExceptions can occur from many sources, they frequently result from violating the integrity of a collection considered to be homogeneous. Solving collection-oriented type safety problems motivated the inclusion of generics in the Java language (and an overhaul of the collections framework to support generics). With generics, the compiler can now detect type-safety violations. Examine Listing 2.
Listing 2—AfterGenerics.java
// AfterGenerics.java
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
public class AfterGenerics
{
public static void main(String[] args)
{
List<Double> l = new ArrayList<Double>();
l.add(101.0);
l.add(89.0);
l.add(33.0);
double avg = calculateAverage(l);
System.out.println("Average = "+avg);
l.add("Average");
avg = calculateAverage(l);
System.out.println("Average = "+avg);
}
static double calculateAverage(List<Double> l)
{
double sum = 0.0;
Iterator<Double> iter = l.iterator();
while (iter.hasNext())
sum += iter.next();
return sum/l.size();
}
}
Although Listing 2 is similar to Listing 1, there are fundamental differences. For example, List<Double> l = new ArrayList<Double>(); replaces List l = new ArrayList();. Specifying Double between angle brackets tells the compiler that l references a homogeneous list of Double objects—Double is the element type.
It's necessary to specify <Double> after both List and ArrayList to prevent non-Double objects from being stored in the list, in calculateAverage()'s parameter list to prevent this method from being able to store non-Doubles in the list, and after Iterator to eliminate a (Double) cast when retrieving objects from the list.
Along with four instances of <Double> that provide type information to the compiler, Listing 2 also relies on autoboxing to simplify the code. For example, the compiler uses autoboxing with this type information to expand l.add(101.0); to l.add(new Double(101.0));, and to expand sum += iter.next(); to sum += ((Double) iter.next()).doubleValue();.
Because the compiler uses the extra type information provided by <Double> to verify that the list can only contain Doubles, the (Double) cast is no longer needed (although it can be specified). Eliminating this cast reduces source code clutter. Furthermore, this type information aids the compiler in detecting attempts to store non-Double objects in the list:
AfterGenerics.java:20: cannot find symbol
symbol : method add(java.lang.String)
location: interface java.util.List<java.lang.Double>
l.add ("Average");
^
1 error