How to use Java generics to avoid ClassCastExceptions

• With one exception, the instanceof operator cannot be used with parameterized types. The exception is an unbounded wildcard. For example, you cannot specify Set<Shape> shapes = null; if (shapes instanceof ArrayList<Shape>) {}. Instead, you need to change the instanceof expression to shapes instanceof ArrayList<?>, which demonstrates an unbounded wildcard. Alternatively, you could specify shapes instanceof ArrayList, which demonstrates a raw type (and which is the preferred use).
• Some developers have pointed out that you cannot use Java Reflection to obtain generics information, which isn’t present in the class file. However, in Java Reflection: Generics developer Jakob Jenkov points out a few cases where generics information is stored in a class file, and this information can be accessed reflectively.
• You cannot use type parameters in array-creation expressions; for example elements = new E[size];. The compiler will report a generic array creation error message if you try to do so.

Given the limitations of erasure, you might wonder why generics were implemented with erasure. The reason is simple: The Java compiler was refactored to use erasure so that generic code could interoperate with legacy Java code, which isn’t generic (reference types cannot be parameterized). Without that backward compatibility, legacy Java code would fail to compile in a Java compiler supporting generics.

Generics and heap pollution

While working with generics, you may encounter heap pollution, in which a variable of a parameterized type refers to an object that isn’t of that parameterized type (for instance if a raw type has been mixed with a parameterized type). In this situation, the compiler reports an “unchecked warning” because the correctness of an operation involving a parameterized type (like a cast or method call) cannot be verified. Consider Listing 6.

Listing 6: Demonstrating heap pollution

import java.util.Iterator;
import java.util.Set;
import java.util.TreeSet;
public class HeapPollutionDemo
{
   public static void main(String[] args)
   {
      Set s = new TreeSet<Integer>();
      Set<String> ss = s;            // unchecked warning
      s.add(Integer.valueOf(42));    // another unchecked warning
      Iterator<String> iter = ss.iterator();
      while (iter.hasNext())
      {
         String str = iter.next();   // ClassCastException thrown
         System.out.println(str);
      }
   }
}

Variable ss has parameterized type Set<String>. When the Set that is referenced by s is assigned to ss, the compiler generates an unchecked warning. It does so because the compiler cannot determine that s refers to a Set<String> type (it does not). The result is heap pollution. (The compiler allows this assignment to preserve backward compatibility with legacy Java versions that don’t support generics. Furthermore, erasure transforms Set<String> into Set, which results in one Set being assigned to another Set.)

The compiler generates a second unchecked warning on the line that invokes Set’s add() method. It does so because it cannot determine if variable s refers to a Set<String> or Set<Integer> type. This is another heap pollution situation. (The compiler allows this method call because erasure transforms Set’s boolean add(E e) method to boolean add(Object o), which can add any kind of object to the set, including the Integer subtype of Object.)

Generic methods that include variable arguments (varargs) parameters can also cause heap pollution. This scenario is demonstrated in Listing 7.

Listing 7: Demonstrating heap pollution in an unsafe varargs context

import java.util.Arrays;
import java.util.List;
public class UnsafeVarargsDemo
{
   public static void main(String[] args)
   {
      unsafe(Arrays.asList("A", "B", "C"),
             Arrays.asList("D", "E", "F"));
   }
   static void unsafe(List<String>... l)
   {
      Object[] oArray = l;
      oArray[0] = Arrays.asList(Double.valueOf(3.5));
      String s = l[0].get(0);
   }
}

The Object[] oArray = l; assignment introduces the possibility of heap pollution. A value whose List type’s parameterized type doesn’t match the parameterized type (String) of the varargs parameter l can be assigned to array variable oArray. However, the compiler doesn’t generate an unchecked warning because it has already done so when translating List<String>... l to List[] l. This assignment is valid because variable l has the type List[], which subtypes Object[].

Also, the compiler doesn’t issue a warning or error when assigning a List object of any type to any of oArray’s array components; for example, oArray[0] = Arrays.asList(Double.valueOf(3.5));. This assignment assigns to the first array component of oArray a List object containing a single Double object.

The String s = l[0].get(0); assignment is problematic. The object stored in the first array component of variable l has the type List<Double>, but this assignment expects an object of type List<String>. As a result, the JVM throws ClassCastException.

Compile the Listing 7 source code (javac -Xlint:unchecked UnsafeVarargsDemo.java). You should observe the following output (slightly reformatted for readability) when compiled under Java SE 12:

UnsafeVarargsDemo.java:8: warning: [unchecked] unchecked generic array 
creation for varargs parameter of 
type List<String>[]
      unsafe(Arrays.asList("A", "B", "C"),
            ^
UnsafeVarargsDemo.java:12: warning: [unchecked] Possible heap pollution 
from parameterized vararg type 
List<String>
   static void unsafe(List<String>... l)
                                      ^
2 warnings

Earlier in this article, I stated that you cannot use type parameters in array-creation expressions. For example, you cannot specify elements = new E[size];. The compiler reports a “generic array creation error” message when you try to do so. However, it’s still possible to create a generic array, but only in a varargs context, and that is what the first warning message is reporting. Behind the scenes, the compiler transforms List<String>... l to List<String>[] l and then to List[] l.

Notice that the heap pollution warning is generated at the unsafe() method’s declaration site. This message isn’t generated at this method’s call site, which is the case with Java 5 and Java 6 compilers.

Not all varargs methods will contribute to heap pollution. However, a warning message will still be issued at the method’s declaration site. If you know that your method doesn’t contribute to heap pollution, you can suppress this warning by declaring it with the @SafeVarargs annotation — Java SE 7 introduced the java.lang.SafeVarargs annotation type. For example, because there is no way for the Arrays class’s asList() method to contribute to heap pollution, this method’s declaration has been annotated with @SafeVarargs, as follows:

@SafeVarargs
public static <T> List<T> asList(T... a)

The @SafeVarargs annotation eliminates the generic array creation and heap pollution warning messages. It is a documented part of the method’s contract and asserts that the method’s implementation will not improperly handle the varargs formal parameter.

Along with the varargs, covariant return types, static imports, annotations, and generics language features that I’ve already discussed in Java 101, Java 5 gave us typesafe enums. I focus on this topic in my next Java 101 article.

This story, "How to use Java generics to avoid ClassCastExceptions" was originally published by JavaWorld.