Generic Types
A generic type is a generic class or interface that is parameterized over types. The following Box class will be modified to demonstrate the concept.
A Simple Box Class
Begin by examining a non-generic Box class that operates on objects of any type. It needs only to provide two methods: set, which adds an object to the box, and get, which retrieves it:
public class Box < private Object object; public void set(Object object) < this.object = object; >public Object get() < return object; >>
Since its methods accept or return an Object, you are free to pass in whatever you want, provided that it is not one of the primitive types. There is no way to verify, at compile time, how the class is used. One part of the code may place an Integer in the box and expect to get Integers out of it, while another part of the code may mistakenly pass in a String, resulting in a runtime error.
A Generic Version of the Box Class
A generic class is defined with the following format:
The type parameter section, delimited by angle brackets (<>), follows the class name. It specifies the type parameters (also called type variables) T1, T2, . and Tn.
To update the Box class to use generics, you create a generic type declaration by changing the code «public class Box» to «public class Box ". This introduces the type variable, T, that can be used anywhere inside the class.
With this change, the Box class becomes:
/** * Generic version of the Box class. * @param the type of the value being boxed */ public class Box < // T stands for "Type" private T t; public void set(T t) < this.t = t; >public T get() < return t; >>
As you can see, all occurrences of Object are replaced by T. A type variable can be any non-primitive type you specify: any class type, any interface type, any array type, or even another type variable.
This same technique can be applied to create generic interfaces.
Type Parameter Naming Conventions
By convention, type parameter names are single, uppercase letters. This stands in sharp contrast to the variable naming conventions that you already know about, and with good reason: Without this convention, it would be difficult to tell the difference between a type variable and an ordinary class or interface name.
The most commonly used type parameter names are:
- E - Element (used extensively by the Java Collections Framework)
- K - Key
- N - Number
- T - Type
- V - Value
- S,U,V etc. - 2nd, 3rd, 4th types
You'll see these names used throughout the Java SE API and the rest of this lesson.
Invoking and Instantiating a Generic Type
To reference the generic Box class from within your code, you must perform a generic type invocation, which replaces T with some concrete value, such as Integer:
You can think of a generic type invocation as being similar to an ordinary method invocation, but instead of passing an argument to a method, you are passing a type argument — Integer in this case — to the Box class itself.
Type Parameter and Type Argument Terminology: Many developers use the terms "type parameter" and "type argument" interchangeably, but these terms are not the same. When coding, one provides type arguments in order to create a parameterized type. Therefore, the T in Foo is a type parameter and the String in Foo f is a type argument. This lesson observes this definition when using these terms.
Like any other variable declaration, this code does not actually create a new Box object. It simply declares that integerBox will hold a reference to a "Box of Integer", which is how Box is read.
An invocation of a generic type is generally known as a parameterized type.
To instantiate this class, use the new keyword, as usual, but place between the class name and the parenthesis:
The Diamond
In Java SE 7 and later, you can replace the type arguments required to invoke the constructor of a generic class with an empty set of type arguments (<>) as long as the compiler can determine, or infer, the type arguments from the context. This pair of angle brackets, <>, is informally called the diamond. For example, you can create an instance of Box with the following statement:
For more information on diamond notation and type inference, see Type Inference.
Multiple Type Parameters
As mentioned previously, a generic class can have multiple type parameters. For example, the generic OrderedPair class, which implements the generic Pair interface:
public interface Pair < public K getKey(); public V getValue(); >public class OrderedPair implements Pair < private K key; private V value; public OrderedPair(K key, V value) < this.key = key; this.value = value; >public K getKey() < return key; >public V getValue() < return value; >>
The following statements create two instantiations of the OrderedPair class:
Pair p1 = new OrderedPair("Even", 8); Pair p2 = new OrderedPair("hello", "world"); The code, new OrderedPair , instantiates K as a String and V as an Integer. Therefore, the parameter types of OrderedPair's constructor are String and Integer, respectively. Due to autoboxing, it is valid to pass a String and an int to the class.
As mentioned in The Diamond, because a Java compiler can infer the K and V types from the declaration OrderedPair , these statements can be shortened using diamond notation:
OrderedPair p1 = new OrderedPair<>("Even", 8); OrderedPair p2 = new OrderedPair<>("hello", "world"); To create a generic interface, follow the same conventions as for creating a generic class.
Parameterized Types
You can also substitute a type parameter (that is, K or V) with a parameterized type (that is, List ). For example, using the OrderedPair example:
OrderedPairBox > p = new OrderedPair<>("primes", new Box(. )); Generic Methods
Generic methods are methods that introduce their own type parameters. This is similar to declaring a generic type, but the type parameter's scope is limited to the method where it is declared. Static and non-static generic methods are allowed, as well as generic class constructors.
The syntax for a generic method includes a list of type parameters, inside angle brackets, which appears before the method's return type. For static generic methods, the type parameter section must appear before the method's return type.
The Util class includes a generic method, compare, which compares two Pair objects:
public class Util < public static boolean compare(Pair p1, Pair p2) < return p1.getKey().equals(p2.getKey()) && p1.getValue().equals(p2.getValue()); >> public class Pair < private K key; private V value; public Pair(K key, V value) < this.key = key; this.value = value; >public void setKey(K key) < this.key = key; >public void setValue(V value) < this.value = value; >public K getKey() < return key; >public V getValue() < return value; >>
The complete syntax for invoking this method would be:
Pair p1 = new Pair<>(1, "apple"); Pair p2 = new Pair<>(2, "pear"); boolean same = Util. compare(p1, p2);
The type has been explicitly provided, as shown in bold. Generally, this can be left out and the compiler will infer the type that is needed:
Pair p1 = new Pair<>(1, "apple"); Pair p2 = new Pair<>(2, "pear"); boolean same = Util.compare(p1, p2);
This feature, known as type inference, allows you to invoke a generic method as an ordinary method, without specifying a type between angle brackets. This topic is further discussed in the following section, Type Inference.
Generic Methods
Consider writing a method that takes an array of objects and a collection and puts all objects in the array into the collection. Here's a first attempt:
static void fromArrayToCollection(Object[] a, Collection c) < for (Object o : a) < c.add(o); // compile-time error > >
By now, you will have learned to avoid the beginner's mistake of trying to use Collection as the type of the collection parameter. You may or may not have recognized that using Collection isn't going to work either. Recall that you cannot just shove objects into a collection of unknown type.
The way to do deal with these problems is to use generic methods. Just like type declarations, method declarations can be genericthat is, parameterized by one or more type parameters.
static void fromArrayToCollection(T[] a, Collection c) < for (T o : a) < c.add(o); // Correct > >
We can call this method with any kind of collection whose element type is a supertype of the element type of the array.
Object[] oa = new Object[100]; Collection co = new ArrayList(); // T inferred to be Object fromArrayToCollection(oa, co); String[] sa = new String[100]; Collection cs = new ArrayList(); // T inferred to be String fromArrayToCollection(sa, cs); // T inferred to be Object fromArrayToCollection(sa, co); Integer[] ia = new Integer[100]; Float[] fa = new Float[100]; Number[] na = new Number[100]; Collection cn = new ArrayList(); // T inferred to be Number fromArrayToCollection(ia, cn); // T inferred to be Number fromArrayToCollection(fa, cn); // T inferred to be Number fromArrayToCollection(na, cn); // T inferred to be Object fromArrayToCollection(na, co); // compile-time error fromArrayToCollection(na, cs);
Notice that we don't have to pass an actual type argument to a generic method. The compiler infers the type argument for us, based on the types of the actual arguments. It will generally infer the most specific type argument that will make the call type-correct.
One question that arises is: when should I use generic methods, and when should I use wildcard types? To understand the answer, let's examine a few methods from the Collection libraries.
interface Collection < public boolean containsAll(Collection c); public boolean addAll(Collectionextends E> c); >
We could have used generic methods here instead:
interface Collection < public boolean containsAll(Collection c); public extends E> boolean addAll(Collection c); // Hey, type variables can have bounds too! >
However, in both containsAll and addAll , the type parameter T is used only once. The return type doesn't depend on the type parameter, nor does any other argument to the method (in this case, there simply is only one argument). This tells us that the type argument is being used for polymorphism; its only effect is to allow a variety of actual argument types to be used at different invocation sites. If that is the case, one should use wildcards. Wildcards are designed to support flexible subtyping, which is what we're trying to express here.
Generic methods allow type parameters to be used to express dependencies among the types of one or more arguments to a method and/or its return type. If there isn't such a dependency, a generic method should not be used.
It is possible to use both generic methods and wildcards in tandem. Here is the method Collections.copy() :
class Collections < public static void copy(List dest, Listextends T> src)
Note the dependency between the types of the two parameters. Any object copied from the source list, src , must be assignable to the element type T of the destination list, dst . So the element type of src can be any subtype of T we don't care which. The signature of copy expresses the dependency using a type parameter, but uses a wildcard for the element type of the second parameter.
We could have written the signature for this method another way, without using wildcards at all:
class Collections < public static extends T> void copy(List dest, List src)
This is fine, but while the first type parameter is used both in the type of dst and in the bound of the second type parameter, S , S itself is only used once, in the type of src nothing else depends on it. This is a sign that we can replace S with a wildcard. Using wildcards is clearer and more concise than declaring explicit type parameters, and should therefore be preferred whenever possible.
Wildcards also have the advantage that they can be used outside of method signatures, as the types of fields, local variables and arrays. Here is an example.
Returning to our shape drawing problem, suppose we want to keep a history of drawing requests. We can maintain the history in a static variable inside class Shape , and have drawAll() store its incoming argument into the history field.
static List> history = new ArrayList>(); public void drawAll(Listextends Shape> shapes) < history.addLast(shapes); for (Shape s: shapes) < s.draw(this); > >
Finally, again let's take note of the naming convention used for the type parameters. We use T for type, whenever there isn't anything more specific about the type to distinguish it. This is often the case in generic methods. If there are multiple type parameters, we might use letters that neighbor T in the alphabet, such as S . If a generic method appears inside a generic class, it's a good idea to avoid using the same names for the type parameters of the method and class, to avoid confusion. The same applies to nested generic classes.