• What is an "unchecked" warning?
• How can I disable or enable unchecked warnings?
• What is the -Xlint:unchecked compiler option?
• What is the SuppressWarnings annotation?
• How can I avoid "unchecked cast" warnings?
• Is it possible to eliminate all "unchecked" warnings?
• Why do I get an "unchecked" warning although there is no type information missing?

• What is heap pollution?
• When does heap pollution occur?

• How does the compiler translate Java generics?
• What is type erasure?
• What is reification?
• What is a bridge method?
• Under which circumstances is a bridge method generated?
• Why does the compiler add casts when it translates generics?
• How does type erasure work when a type parameter has several bounds?
• What is a reifiable type?
• What is the type erasure of a parameterized type?
• What is the type erasure of a type parameter?
• What is the type erasure of a generic method?
• Is generic code faster or slower than non-generic code?
• How do I compile generics for use with JDK <= 1.4?

• How do parameterized types fit into the Java type system?
• How does the raw type relate to instantiations of the corresponding generic type?
• How do instantiations of a generic type relate to  instantiations of other generic types that have the same type argument?
• How do unbounded wildcard instantiations of a generic type relate to other instantiations of the same generic type?
• How do wildcard instantiations with an upper bound relate to other instantiations of the same generic type?
• How do wildcard instantiations with a lower bound relate to other instantiations of the same generic type?
• Which super-subtype relationships exist among instantiations of generic types?
• Which super-subset relationships exist among wildcards?
• Does "extends" always mean "inheritance"?

• Can I use parameterized types in exception handling?
• Why are generic exception and error types illegal?
• Can I use a type parameter in exception handling?
• Can I use a type parameter in a catch clause?
• Can I use a type parameter in in a throws clause?
• Can I throw an object whose type is a type parameter?

• How do I refer to static members of a parameterized type?
• How do I refer to a (non-static) inner class of a parameterized type?
• How do I refer to an interface type nested into a parameterized type?
• How do I refer to an enum type nested into a parameterized type?
• Can I import a particular instantiations of a generic type?
• Why are generic enum types illegal?

• What is type argument inference?
• What are the exact rules for type argument inference?
• What is explicit type argument specification?
• Can I use a wildcard as the explicit type argument of a generic method?
• What happens if a type parameter does not appear in the method parameter list?
• Why doesn't type argument inference fail when I provide inconsistent method arguments?
• Why do temporary variables matter in case of invocation of generic methods?

• What is the capture of a wildcard?
• What is the capture of an unbounded wildcard compatible to?
• Is the capture of a bounded wildcard compatible to the bound?

• Which methods and fields are accessible/inaccessible through a reference variable of a wildcard parameterized type?
• Which methods that use the type parameter in the argument or return type are accessible in an unbounded wildcard parameterized type?
• Which methods that use the type parameter in the argument or return type are accessible in an upper bound wildcard parmeterized type?
• Which methods that use the type parameter in the argument or return type are accessible in a lower bound wildcard parmeterized type?
• Which methods that use the type parameter as type argument of a parameterized argument or return type are accessible in a wildcard parameterized type?
• Which methods that use the type parameter as upper wildcard bound in a parameterized argument or return type are accessible in a wildcard parameterized type?
• Which methods that use the type parameter as lower wildcard bound in a parameterized argument or return type are accessible in a wildcard parameterized type?
• In a wildcard parameterized type, can I read and write fields whose type is the type parameter?
• Is it really impossible to create an object whose type is a wildcard parameterized type?

• Which types can or must not appear as target type in an instanceof expression?
• Which casts are permitted?
• Which casts are prohibited?

• What is method overriding?
• What is method overloading?
• What is the @Override annotation?
• What is a method signature?
• What is a subsignature?
• What are override-equivalent signatures?
• When does a method override its supertype's method?
• What are covariant-return types?
• What are substitutable return types?
• Can a method of a non-generic subtype override a method of a generic supertype?
• Can a method of a generic subtype override a method of a generic supertype?
• Can a generic method override a generic one?
• Can a non-generic method override a generic one?
• Can a generic method override a non-generic one?
• What is overload resolution?
• How does overload resolution work when generic methods are involved?

The most common source of "unchecked" warnings is the use of raw types.  "unchecked" warnings are issued when an object is accessed through a raw type variable, because the raw type does not provide enough type information to perform all necessary type checks. 

Example (of unchecked warning in conjunction with raw types): 

TreeSet se t = new TreeSet();
set.add("abc");        // unchecked warning
set.remove("abc");

---

warning: [unchecked] unchecked call to add(E) as a member of the raw type java.util.TreeSet
               set.add("abc"); 
                      ^

"unchecked" warnings are also reported when the compiler finds a cast whose target type is either a parameterized type or a type parameter. 

Example (of an unchecked warning in conjunction with a cast to a parameterized type or type variable): 

class Wrapper<T> {
  private T wrapped ;
  public Wrapper (T arg) {wrapped = arg;}
  ...
  p ublic Wrapper <T> clone() {
    Wrapper<T> clon = null;
     try { 
       clon = (Wrapper<T>) super.clone(); // unchecked warning
     } catch (CloneNotSupportedException e) { 
       throw new InternalError(); 
     }
     try { 
       Class<?> clzz = this.wrapped.getClass();
       Method   meth = clzz.getMethod("clone", new Class[0]);
       Object   dupl = meth.invoke(this.wrapped, new Object[0]);
       clon.wrapped = (T) dupl; // unchecked warning
     } catch (Exception e) {}
     return clon;
  }
}

---

warning: [unchecked] unchecked cast
found   : java.lang.Object
required: Wrapper <T>
                  clon = ( Wrapper <T>)super.clone(); 
                                                ^
warning: [unchecked] unchecked cast
found   : java.lang.Object
required: T
                  clon. wrapped = (T)dupl; 
                                    ^

In the example, the cast to Wrapper<T> would check whether the object returned from super.clone is a Wrapper , not whether it is a wrapper with a particular type of members.  Similarly, the casts to the type parameter T are cast to type Object at runtime, and probably optimized away altogether.  Due to type erasure, the runtime system is unable to perform more useful type checks at runtime. 

In a way, the source code is misleading, because it suggests that a cast to the respective target type is performed, while in fact the dynamic part of the cast only checks against the type erasure of the target type.  The "unchecked" warning is issued to draw the programmer's attention to this mismatch between the static and dynamic aspect of the cast.

Note: util/Wrapper.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

Example (of globally enabling unchecked warnings): 

javac -Xlint:unchecked util/Wrapper.java

The option -Xlint:-unchecked disables the "unchecked" warnings.  This is useful to suppress all  "unchecked" warnings, while other types of warnings remain enabled. 

Example (of globally disabling unchecked warnings): 

javac -g -source 1.5 -Xlint:all -Xlint:-unchecked util/Wrapper.java

The SuppressWarnings annotation can be used to suppress any type of labelled warning.  In particular we can use the annotation to suppress "unchecked" warnings. 

Example (of suppressing unchecked warnings): 

@SuppressWarnings("unchecked")
class Wrapper<T> {
  private T wrapped ;
  public Wrapper (T arg) {wrapped = arg;}
  ...
  p ublic Wrapper <T> clone() {
    Wrapper<T> clon = null;
     try { 
       clon = (Wrapper<T>) super.clone(); // unchecked warning supressed
     } catch (CloneNotSupportedException e) { 
       throw new InternalError();
     }
     try { 
       Class<?> clzz = this.wrapped.getClass();
       Method   meth = clzz.getMethod("clone", new Class[0]);
       Object   dupl = meth.invoke(this.wrapped, new Object[0]);
       clon.wrapped = (T) dupl; // unchecked warning supressed
     } catch (Exception e) {}
     return clon;
  }
}

We can suppress several types of annotations at a time.  In this case we must specify a list of warning labels. 

Example (of suppressing several types of warnings): 

@SuppressWarnings(value={"unchecked","deprecation"})
public static void someMethod() {
  ...
  TreeSet se t = new TreeSet();
  set.add(new Date(104,8,11));     // unchecked and deprecation warning suppressed
  ...
}

warning: [deprecation] Date(int,int,int) in java.util.Date has been deprecated
        set.add(new Date(104,8,11));
                ^
warning: [unchecked] unchecked call to add(E) as a member of the raw type java.util.TreeSet
        set.add(new Date(104,8,11));

Annotations can not be attached to statements, expressions, or blocks, only to program entities with a definition like types, variables, etc. 

Example (of illegal placement of annotation): 

public static void someMethod() {
  ...
  TreeSet se t = new TreeSet(); 
  @SuppressWarnings(value={"unchecked"}) // error
  set.add(new Date(104,8,11)); 
  ...
}

Note, in release of Java 5.0 the SuppressWarnings annotation is not yet supported by all compilers. Sun's compiler will support in in release 6.0. 

A typical example is the implementation of methods such as the equals method, that take Object reference and where a cast down to the actual type must be performed. 

Example (not recommended): 

class Wrapper<T> {
  private T wrapped;
    ...
  public boolean equals (Object other) {
    ...
    Wrapper <T> other Wrapper = (Wrapper<T>) other; // warning; unchecked cast
    return (this.wrapped.equals( other Wrapper.wrapped));
  }
}

Example (implementation of equals ): 

class Wrapper<T> {
  private T wrapped;
    ...
  public boolean equals (Object other) {
    ...
    Wrapper <?> other Wrapper = (Wrapper<?>) other;
    return (this.wrapped.equals( other Wrapper.wrapped));
  }
}

Raw types.

When source code is compiled for use in Java 5.0 that was developed before Java 5.0 and uses classes that are generic in Java 5.0, then "unchecked" warnings are inevitable.  For instance, if "legacy" code uses types such as List , which used to be a regular (non-generic) types before Java 5.0, but are generic in Java 5.0, all these uses of List are considered uses of a raw type in Java 5.0.  Use of the raw types will lead to "unchecked" warnings.  If you want to eliminate the "unchecked" warnings you must re-engineer the "legacy" code and replace all raw uses of List with appropriate instantiations of List such as List<String> , List<Object> , List<?> , etc.  All "unchecked" warnings can be eliminated this way. 

In source code developed for Java 5.0 you can prevent "unchecked" warnings in the first place by never using raw types.  Always provide type arguments when you use a generic type.  There are no situations in which you are forced to use a raw type.  In case of doubt, when you feel you have no idea which type argument would be appropriate, try the unbounded wildcard " ? ". 

In essence, "unchecked" warnings due to use of raw types can be eliminated if you have access to legacy code and are willing to re-engineer it. 

Casts.

"Unchecked" warnings as a result of cast expressions can be eliminated by eliminating the offensive casts.  Eliminating such casts is almost always possible.  There are, however, a few situations where a cast to a type parameter or a concrete or bounded wildcard parameterized type cannot be avoided. 

These are typically situations where a method returns a supertype reference to an object of a more specific type. The classic example is the clone method; it returns an Object reference to an object of the type on which it was invoked. In order to recover the returned object's actual type a cast in necessary.  If the cloned object is of a parameterized type, then the target type of the cast is an instantiation of that parameterized type, and an "unchecked" warning is inevitable.  The clone method is just one example that leads to unavoidable "unchecked" warnings. Invocation of methods via reflection has similar effects because the return value of a reflectively invoked method is returned via an Object reference.  It is likely that you will find further examples of unavoidable "unchecked" casts in practice. For a detailed discussion of an example see #FAQ502 , which explains the implementation of a clone method for a generic class. 

In sum, there are situations in which you cannot eliminate "unchecked" warnings due to a cast expression. 
 

Example (of unchecked warning in conjunction with raw types): 

class TreeSet<E> {
  boolean add(E o) { ...  }
}
TreeSet se t = new TreeSet();
set.add("abc");        // unchecked warning

---

warning: [unchecked] unchecked call to add(E) as a member of the raw type TreeSet
               set.add("abc"); 
                      ^

Curiously, an unchecked warning is also issued in situations where there is enough type information available.

Example (of a spurious unchecked warning in conjunction with raw types):
 

The reason is that the compiler computes the type erasure of a generic type when it finds an occurrence of the raw type in the source code.  Type erasure does not only elide all occurances of the type parameter  T , but also elides the type argument of the  getList method's return type. After type erasure, the  getList method returns just a  List and no longer a  List<String> .  All subsequent type checks are performed based on the type erasure; hence the "unchecked" warning.

The "unchecked" warning can easily be avoided by refraining from use of the raw type.  SomeType is a generic type and should always be used with a type argument. In general, the use of raw types will inevitably result in "unchecked" warnings; some of the warnings may be spurious, but most of them are justified. 

Example (of invoking a static method of a raw type):
 

Example (of heap pollution):
 

After the assignment of the reference variable  ln to the reference variable ls , the  List<String> variable will point to a  List<Number> object. Such a situation is called  heap pollution and is usually indicated by an unchecked warning.  A polluted heap is likely to lead to an unexpected  ClassCastException at runtime.  In the example above, it will lead to a  ClassCastException , when a object is retrieved from the  List<String> and assigned to a  String variable, because the object is a  Number , not a  String .

A compiler that must translate a generic type or method (in any language, not just Java) has in principle two choices: 

Code specialization is the approach that C++ takes for its templates:
The C++ compiler generates executable code for every instantiation of a template. The downside of code specialization of generic types is its potential for code bloat.  A list of integers and a list of strings would be represented in the executable code as two different types. Note that code bloat is not inevitable in C++ and can generally be avoided by an experienced programmer. 

Code specialization is particularly wasteful in cases where the elements in a collection are references (or pointers), because all references (or pointers) are of the same size and internally have the same representation. There is no need for generation of mostly identical code for a list of references to integers and a list of references to strings.  Both lists could internally be represented by a list of references to any type of object. The compiler just has to add a couple of casts whenever these references are passed in and out of the generic type or method. Since in Java most types are reference types, it deems natural that Java chooses code sharing as its technique for translation of generic types and methods. 

The Java compiler applies the code sharing technique and creates one unique byte code representation of each generic type (or method).  The various instantiations of the generic type (or method) are mapped onto this unique representation by a technique that is called type erasure . 

The type erasure process can be imagined as a translation from generic Java source code back into regular Java code.  In reality the compiler is more efficient and translates directly to Java byte code.  But the byte code created is equivalent to the non-generic Java code you will be seeing in the subsequent examples. 

The steps performed during type erasure include: 

Eliding type parameters.
When the compiler finds the definition of a generic type or method, it removes all occurrences of the type parameters and replaces them by their leftmost bound, or type Object if no bound had been specified. 

Eliding type arguments.
When the compiler finds a paramterized type, i.e. an instantiation of a generic type, then it removes the type arguments. For instance, the types List<String> , Set<Long> , and Map<String,?> are translated to List , Set and Map respectively. 

Example (before type erasure): 

interface Comparable <A> {
  public int compareTo( A that);
}
final class NumericValue implements Comparable <NumericValue> {
  priva te byte value; 
  public  NumericValue (byte value) { this.value = value; } 
  public  byte getValue() { return value; } 
  public  int compareTo( NumericValue t hat) { return this.value - that.value; }
}
class Collections { 
  public static <A extends Comparable<A>>A max(Collection <A> xs) {
    Iterator <A> xi = xs.iterator();
    A w = xi.next();
    while (xi.hasNext()) {
      A x = xi.next();
      if (w.compareTo(x) < 0) w = x;
    }
    return w;
  }
}
final class Test {
  public static void main (String[ ] args) {
    LinkedList <NumericValue> numberList = new LinkedList <NumericValue> ();
    numberList .add(new NumericValue((byte)0)); 
    numberList .add(new NumericValue((byte)1)); 
    NumericValue y = Collections.max( numberList ); 
  }
}

Example (after type erasure): 

interface Comparable {
  public int compareTo( Object that);
}
final class NumericValue implements Comparable {
  priva te byte value; 
  public  NumericValue (byte value) { this.value = value; } 
  public  byte getValue() { return value; } 
  public  int compareTo( NumericValue t hat)   { return this.value - that.value; }
  public  int compareTo(Object that) { return this.compareTo((NumericValue)that);  }
}
class Collections { 
  public static Comparable max(Collection xs) {
    Iterator xi = xs.iterator();
    Comparable w = (Comparable) xi.next();
    while (xi.hasNext()) {
      Comparable x = (Comparable) xi.next();
      if (w.compareTo(x) < 0) w = x;
    }
    return w;
  }
}
final class Test {
  public static void main (String[ ] args) {
    LinkedList numberList = new LinkedList();
    numberList .add(new NumericValue((byte)0)); 
    numberList .add(new NumericValue((byte)1)); 
    NumericValue y = (NumericValue) Collections.max( numberList ); 
  }
}

The NumericValue class implements the non-generic Comparable interface after type erasure, and the compiler adds a so-called bridge method . The bridge method is needed so that class NumericValue remains a class that implements the Comparable interface after type erasure. 

The generic method max is translated to a non-generic method and the bounded type parameter A is replaced by its leftmost bound, namely Comparable .  The parameterized interface Iterator<A> is translated to the raw type Iterator and the compiler adds a cast whenever an element is retrieved from the raw type Iterator . 

The uses of the parameterized type LinkedList<NumericValue> and the generic max method in the main method are translated to uses of the non-generic type and method and, again, the compiler must add a cast. 
 

In other languages, like for instance C#, type parameters and type arguments of generics types and methods do have a runtime representation. This representation allows the runtime system to perform certain checks and operations based on type arguments.  In such a language the runtime system can tell the difference between a  List<String> and a  List<Date> .

Example (before type erasure): 

interface Comparable <A> {
  public int compareTo( A that);
}
final class NumericValue implements Comparable <NumericValue> {
  priva te byte value; 
  public  NumericValue (byte value) { this.value = value; }
  public  byte getValue() { return value; } 
  public  int compareTo( NumericValue t hat) { return this.value - that.value; }
}

Example (after type erasure): 

interface Comparable {
  public int compareTo( Object that);
}
final class NumericValue implements Comparable {
  priva te byte value; 
  public  NumericValue (byte value) { this.value = value; } 
  public  byte getValue() { return value; } 
  public  int compareTo( NumericValue t hat)   { return this.value - that.value; }
  public  int compareTo(Object that) { return this.compareTo((NumericValue)that);  }
}

In order to achieve that class NumericValue remains a class that correctly implements the Comparable interface, the compiler adds a bridge method to the class.  The bridge method has the same signature as the interface&rsquo;s method after type erasure, because that's the method that must be implemented. The bridge method delegates to the orignal methods in the  implementing class. 

The existence of the bridge method does not mean that objects of arbitrary types can be passed as arguments to the compareTo method in NumericValue .  The bridge method is an implementation detail and the compiler makes sure that it normally cannot be invoked. 

Example (illegal attempt to invoke bridge method): 

NumericValue value = new NumericValue((byte)0);
value.compareTo(value);  // fine
value.compareTo("abc");  // error

You can, however, invoke the synthetic bridge message using reflection.  But, if you provide an argument of a type other than NumericValue , the method will fail with a ClassCastException thanks of the cast in the implementation of the bridge method. 

Example (failed attempt to invoke bridge method via reflection): 

int reflectiveCompareTo(NumericValue value, Object other)
  throws NoSuchMethodException, IllegalAccessException, InvocationTargetException
{
  Method meth = NumericValue.class.getMethod("compareTo", new Class[]{Object.class});
  return (Integer)meth.invoke(value, new Object[]{other}); 
}
NumericValue value = new NumericValue((byte)0);
reflectiveCompareTo(value, value);  // fine
reflectiveCompareTo(value,"abc");   // ClassCastException

Below is an example of a class that extends a parameterized superclass. 

Example (before type erasure): 

class Superclass <T extends Bound> {
  public void m1( T arg) { ... }
  public T m2() { ... }
}
class Subclass extends Superclass <SubTypeOfBound> {
   public void m1( SubTypeOfBound arg) { ... }
   public SubTypeOfBound m 2() { ... }
} 

class Superclass {
  void m1( Bound arg) { ... }
  Bound m2() { ... }
} 
class Subclass extends Superclass {
  public void m1(SubTypeOfBound arg) { ... }
  public void m1(Bound arg) { m1((SubTypeOfBound)arg); }
  public SubTypeOfBound m2() { ... }
  public Bound          m2() { return m2(); }
} 

The compiler must add bridge methods even if the subclass does not override the inherited methods. 

Example (before type erasure): 

class Superclass <T extends Bound> {
  public void m1( T arg) { ... }
  public T m2() { ... }
}
class AnotherSubclass extends Superclass <SubTypeOfBound> {
}

class Superclass {
  void m1( Bound arg) { ... }
  Bound m2() { ... }
}
class AnotherSubclass extends Superclass {
  public void  m1(Bound arg) { super.m1((SubTypeOfBound)arg); }
  public Bound m2() { return super.m2(); }
}

No bridge method is needed when type erasure does not change the signature of any of the methods of the parameterized supertype.  Also, no bridge method is needed if the signatures of methods in the sub- and supertype change in the same way.  This can occur when the subtype is generic itself. 

Example (before type erasure): 

interface Callable <V> {
  public V call();
}
class Task <T> implements Callable <T> {
  public T call() { ... }
}

interface Callable {
  public Object call();
}
class Task implements Callable {
  public Object call() { ... }
}

However, it does not suffice that the subclass is generic.  The key is that the method signatures must not match after type erasure.  Otherwise, we again need a bridge method. 

Example (before type erasure): 

interface Copyable <V> extends Cloneable {
  public V copy();
}
class Triple <T extends Copyable<T>> implements Copyable <Triple<T>> {
  public Triple<T> copy() { ... }
}

interface Copyable extends Cloneable {
  public Object copy();
}
class Triple implements Copyable {
  public Copyable copy() { ... }
  public Triple   copy() { return copy(); }
}

Example (before type erasure): 

public class Pair<X,Y> {
  private X first;
  private Y second;
  public Pair(X x, Y y) {
    first = x;
    second = y;
  }
  public X getFirst() { return first; }
  public Y getSecond() { return second; }
  public void setFirst(X x) { first = x; }
  public void setSecond(Y y) { second = y; }
}

final class Test {
  public static void main(String[] args) {
    Pair<String,Long> pair = new Pair<String,Long>("limit", 10000L);
    String s = pair.getFirst();
    Long   l = pair.getSecond();
    Object o = pair.getSecond();
  }
}

public class Pair {
  private Object first;
  private Object second;
  public Pair( Object x, Object y) {
    first = x;
    second = y;
  }
  public Object getFirst() { return first; }
  public Object getSecond() { return second; }
  public void setFirst( Object x) { first = x; }
  public void setSecond( Object y) { second = y; }
}

final class Test {
  public static void main(String[] args) {
    Pair pair = new Pair("limit", 10000L);
    String s = (String) pair.getFirst();
    Long   l = (Long)    pair.getSeond();
    Object o =          pair.getSecond();
  }
}

The inserted casts cannot fail at runtime with a ClassCastException because the compiler already made sure at compile-time that both fields are references to objects of the expected type.  The compiler would issue an error method if arguments of types other than String or Long had been passed to the constructor or the set methods.  Hence it is guarantees that these casts cannot fail. 

In general, casts silently added by the compiler are guaranteed not to raise a ClassCastException if the program was compiled without warnings.  This is the type-safety guarantee. 

Implicit casts are inserted when methods are invoked whose return type changed during type erasure. Invocation of methods whose argument type changed during type erasure do not require insertion of any casts.  For instance, after type erasure the setFirst and setSecond  methods of class Pair take Object arguments. Invoking them with arguments of a more specific type such as String and Long is possible without the need for any casts.

Example (before type erasure): 

interface Runnable { 
  void run();
}
interface Callable<V> {
  V call();
}
class X<T extends Callable<Long> & Runnable> {
  private T task1, task2;
  ...
  public void do() { 
    task1.run(); 
    Long result = task2.call();
  }
} 

interface Runnable { 
  void run();
}
interface Callable {
  Object call();
}
class X {
  private Callable task1, task2;
  ...
  public void do() { 
    ( (Runnable) task1).run(); 
    Long result = (Long) task2.call();
  }
}

 In general, casts silently added by the compiler are guaranteed not to raise a ClassCastException if the program was compiled without warnings.  This is the type-safety guarantee.

For example, types such as List<String> or Pair<? extends Number, ? extends Number> are available to and used by the compiler in their exact form, including the type argument information.  After type erasure, the virtual machine has only the raw types List and Pair available, which means that part of the type information is lost. 

In contrast, non-parameterized types such as java.util.Date or java.lang.Thread.State are not affected by type erasure.  Their type information remains exact, because they do not have type arguments. 

Among the instantiations of a generic type only the unbounded wildcard instantiations, such as Map<?,?> or Pair<?,?> , are unaffected by type erasure.  They do lose their type arguments, but since all type arguments are unbounded wildcards, no information is lost. 

Types that do NOT lose any information during type erasure are called reifiable types .  The term reifiable stems from  reification .  Reification means that type parameters and type arguments of generic types and methods are available at runtime.  Java does not have such a runtime representation for type arguments because of type erasure.  Consequently, the reifiable types in Java are only those types for which reification does not make a difference, that is, the types that do not need any runtime representation of type arguments.

The following types are reifiable: 

• primitive types
• non-generic (or non-parameterized) reference types
• unbounded wildcard instantiations
• raw types
• arrays of any of the above

• instantiations of a generic type with at least one concrete type argument
• instantiations of a generic type with at least one bounded wildcard as type argument

• as type in an instanceof expression
• as component type of an array