Learning Java, 4th Edition

Arrays of Parameterized Types

There is one place where we haven’t yet considered how generic types affect the Java language: array types. After everything we’ve seen, it would seem natural to expect that arrays of generic types would come along for the ride. But as we’ll see, Java has a schizophrenic relationship with arrays of parameterized types.

The first thing we need to do is recall how arrays work for regular Java types. An array is a kind of built-in collection of some base type of element. Furthermore, array types (including all multidimensional variations of the array) are true types in the Java language and are represented at runtime by unique class types. This is where the trouble begins. Although arrays in Java act a lot like generic collections (they change their APIs to adopt a particular type for “reading” and “writing”), they do not behave like Java generics with respect to their type relationships. As we saw in Chapter 6, arrays exist in the Java class hierarchy stemming from Object and extending down parallel branches with the plain Java objects.

Arrays are covariant subtypes of other types of arrays, which means that, unlike concrete generic types, although they change their method signatures, they are still related to their parents. This means that Strings [] in Java is a subtype of Object []. This brings up the aliasing problem that we mentioned earlier. An array of Strings can be aliased as an array of Objects and we can attempt to put things into it illegally that won’t be noticed until runtime:

    String [] strings = new String[5];
    Object [] objects = strings;
    objects[0] = new Date(); // Runtime ArrayStoreException!

To prevent disaster, Java must check every array assignment for the correct type at runtime. But recall that generic types do not have real representations at runtime; there is only the raw type. So Java would have no way to know the difference between a Trap<Mouse> and a Trap<Bear> element in an array once the array was aliased as, say, an Object []. For this reason, Java does not allow you to create arrays of generic types—at least not concrete ones. (More on that later in this chapter.)

Using Array Types

Now, because we just said that Java won’t let you make any of these arrays, you’d expect that would be pretty much the end of the story. But no! Even though we don’t have real array implementations that perform the needed runtime behavior, Java allows us to declare the array type anyway. The catch is that you must break type safety in order to use them by using an array of the raw type as their implementation:

    Trap<Mouse> [] tma = new Trap[10]; // unchecked warning
    Trap<Mouse> tm = new Trap<Mouse>();
    tma[0] = tm;
    Trap<Mouse> again = tma[0];

Here, we declared an array of a generic type, Trap<Mouse>. Assigning any value (other than null) to this variable, tma, results in an unchecked warning from the compiler at the point of the assignment.

What we are effectively telling the compiler here is to trust us to make sure that the array contains only the correct generic types and asking it to allow us to use it thereafter as if it were checked. We do not get warnings at each usage as we would with a raw type, only at the point where we assign the array. The catch is that the compiler can’t prevent us from abusing the array. The unchecked warning at the point where we assign the array is just a representative warning that reminds us that it’s possible to abuse the array later.

What Good Are Arrays of Generic Types?

Why does Java even let us declare arrays of generic types? One important usage is that it allows generic types to be used in variable-length argument methods. For example:

    void useLists( List<String> ... lists ) {
            List<String> ls0 = lists[0];
    }

Another answer is that it’s an escape hatch to preserve our ability to use arrays when necessary. You might want to do this for at least two reasons. First, arrays are faster than collections in many cases. The Java runtime is very good at optimizing array access, and sometimes it just might be worth it to you to eat the compiler warning to get the benefits. Second, there is the issue of interfacing generic code to legacy code in which only the Javadoc and your faith in the developer are your guarantees as to the contents. By assigning raw arrays to generic instantiations, we can at least ensure that in simple usage we don’t abuse the types in the new code.

Wildcards in Array Types

In general, wildcard instantiations of generics can be used as the base type for arrays in the same way that concrete instantiations can. Let’s look at an example:

    ArrayList<?>[] arrayOfArrayLists = ...;

This type declaration is an array of unbounded wildcard instantiations of ArrayList. Each element of the array can hold an instance of the wildcard type, meaning in this case that each element of the array could hold a different instantiation of ArrayList. For example:

    arrayOfArrayLists[0] = new ArrayList<Date>();
    arrayOfArrayLists[1] = new ArrayList<String>();

There is also a secret surprise that we are going to spring on you relating to wildcard types in arrays. Although we said that Java won’t let us create arrays of generic types, there is an exception to the rule. Java does allow us to create arrays of unbounded wildcard instantiations. Here are two examples:

    ArrayList<?>[] arrayOfArrayLists = new ArrayList<?>[10];
    arrayOfArrayLists[0] = new ArrayList<Date>();

    Trap<?> [] arrayOfTraps = new Trap<?>[10];
    arrayOfTraps[0] = new Trap<Mouse>();

Here, we not only declared two arrays of wildcard instantiations, but we allocated the arrays as well! The trick is that the arrays must be of the unbounded wildcard type. Why does this work? Because each element in the unbounded wildcard instantiation of the array can hold any instantiation, no runtime check of the generic portion of the type is necessary at runtime. Any instantiation of ArrayList is assignable to the element of type ArrayList<?>, so only the check of the raw type is required.

The term reifiable type is used to refer to any type that is unchanged by erasure. This includes plain Java concrete types, primitives, and unbounded wildcard instantiations. Reifiable types are kind of like the real people in The Matrix: they still exist when unplugged from the simulation.