• 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?
• Is there a correspondence between type inference for method invocation and type inference for instance creation?
• What is the "diamond" operator?
• What is type argument inference for instance creation expressions?
• Why does the type inference for an instance creation expression fail?
• What is type argument inference for generic methods?
• 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?

• 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?

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> otherWrapper = (Wrapper<T>) other; // warning; unchecked cast
    return (this.wrapped.equals(otherWrapper.wrapped));
  }
}

Example (implementation of equals ): 

class Wrapper<T> {
  private T wrapped;
    ...
  public boolean equals (Object other) {
    ...
    Wrapper<?> otherWrapper = (Wrapper<?>) other;
    return (this.wrapped.equals(otherWrapper.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 Technicalities.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'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 Triple copy() { ... }
  public Object 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

Examples: 

 

parameterized type	type erasure
List<String>	List
Map.Entry<String,Long>	Map.Entry
Pair<Long,Long>[]	Pair[]
Comparable<? super Number>	Comparable

Examples: 

 

type parameters	type erasure
<T>	Object
<T extends Number>	Number
<T extends Comparable<T>>	Comparable
<T extends Cloneable & Comparable<T>>	Cloneable
<T extends Object & Comparable<T>>	Object
<S, T extends S>	Object,Object

Examples: 

 

parameterized method	type erasure
Iterator<E> iterator()	Iterator iterator()
<T> T[] toArray(T[] a)	Object[] toArray(Object[] a)
<U> AtomicLongFieldUpdater<U>  newUpdater(Class<U> tclass, String fieldName)	AtomicLongFieldUpdater newUpdater(Class tclass,String fieldName)

The short answer is: it is likely that one will find neither a substantial difference in runtime performance nor any consistent trend.  However, this has not yet been verified by any benchmarks I know of.  Nevertheless, let us take a look at the various overlapping effects that might explain such a statement. 
 

Implicit casts.

The casts added by the compiler are exactly the casts that would appear in non-generic code.  Hence the implicit casts do not add any overhead. 
 

Example (generic code):  List <String> list = new List <String> (); list.add("abc"); String s = list.get(0); Example (after type erasure):  List list = new LinkedList(); list.add("abc"); String s = (String) list.get(0);

Example (non-generic code):  List list = new LinkedList(); list.add("abc"); String s = (String) list.get(0);

The non-generic code is exactly what the compiler generates in the process of type erasure, hence there is no difference in performance.
 

Bridge methods.

The compiler adds bridge methods. These synthetic methods cause an additional method invocation at runtime, they are represented in the byte code and increase its volume, and they add to the memory footprint of the program. 
 

Example (generic code):  final class Byte implements Comparable <Byte> {   priva te byte value;    public  Byte(byte value) {      this.value = value;    }   public  byte byteValue() { return value; }    public  int compareTo( Byte t hat) {      return this.value - that.value;    } } Example (after type erasure):  final class Byte implements Comparable {   priva te byte value;    public  Byte(byte value) {      this.value = value;    }    public  byte byteValue() { return value; }    public  int compareTo(Byte t hat)   {      return this.value - that.value;    }   public  int compareTo(Object that) {      return this.compareTo((Byte)that);    } }

Example (non-generic code): final class Byte implements Comparable {   priva te byte value;    public  Byte(byte value) {      this.value = value;    }    public  byte byteValue() { return value; }    public  int compareTo( Object that) {      return this.value - ( (Byte) that).value;    } }

It is likely that there is a slight performance penalty for the bridge method that affects runtime execution and class loading.  However, only new (i.e. 5.0) source code is affected.  If we compile legacy (i.e. 1.4-compatible) source code, there are no additional bridge methods and the byte code should be identical, more or less, to the way it was before. Most likely the slight performance penalty is compensated for by improvements in Hotspot. 
 

Runtime type information.

Static information about type parameters and their bounds is made available via reflection.  This runtime type information adds to the size of the byte code and the memory footprint, because the information must be loaded into memory at runtime.  Again, this only affects new (i.e. 5.0) source code.  On the other hand, there are some enhancements to reflection that apply even to existing language features, and those do require slightly larger class files, too. At the same time, the representation of runtime type information has been improved. For example, there is now an access bit for "synthetic" rather than a class file attribute, and class literals now generate only a single instruction. These things often balance out.  For any particular program you might notice a very slight degradation in startup time due to slightly larger class files, or you might find improved running time because of shorter code sequences.  Yet it is unlikely that one will find any large or consistent trends. 
 

Compilation time.

Compiler performance might decrease because translating generic source code is more work than translating non-generic source code.  Just think of all the static type checks the compiler must perform for generic types and methods.  On the other hand, the performance of a compiler is often more dominated by its implementation techniques rather than the features of the language being compiled.  Again,  it is unlikely that one will find any perceivable or measurable trends. 

The type system of a programming language determines which types are convertible to which other types.  These conversion rules have an impact on various areas of a programming language.  One area where conversion rules and type relationships play role is casts and instanceof expressions.  Other area is assignment compatibility and method invocation, where argument and return value passing relies on convertibility of the involved types. 

The type conversion rules determine which casts are accepted and which ones are rejected.  For example, the types String and Integer have no relationship and for this reason the compiler rejects the attempt of a cast from String to Integer , or vice versa.  In contrast, the types Number and Integer have a super-subtype relationship; Integer is a subtype of Number and Number is a supertype of Integer . Thanks to this relationship, the compiler accepts the cast from Number to Integer , or vice versa.  The cast from Integer to Number is not even necessary, because the conversion from a subtype to a supertype is considered an implicit type conversion, which need not be expressed explicitly in terms of a cast; this conversion is automatically performed by the compiler whenever necessary.  The same rules apply to  instanceof expressions. 

The conversion rules define which types are assignment compatible.  Using the examples from above, we see that a String cannot be assigned to an Integer variable, or vice versa, due to the lack of a type relationship.  In contrast, an Integer can be assigned to a Number variable, but not vice versa.  A side effect of the super-subtype relationship is that we can assign a subtype object to a supertype variable, without an explicit cast anywhere.  This is the so-called widening reference conversion ; it is an implicit conversion that the compiler performs automatically whenever it is needed.  The converse, namely assignment of a supertype object to a subtype variable, is not permitted.  This is because the so-called narrowing reference conversion is not an implicit conversion.  It can only be triggered by an explicit cast. 

The rules for assignment compatibility also define which objects can be passed to which method.  An argument can be passed to a method if its type is assignment compatible to the declared type of the method parameter. For instance, we cannot pass an Integer   to a method that asks for String , but we can pass an Integer to a method that asks for a Number .  The same rules apply to the return value of a method. 
 

Super-subtype relationships of parameterized types.

In order to understand how objects of parameterized types can be used in assignments, method invocations and casts, we need an understanding of the relationship that parameterized types have among each other and with non-parameterized types. And we need to know the related conversion rules. 

We already mentioned super-subtype relationships and the related narrowing and  widening reference conversions .  They exist since Java was invented, that is, among non-generic types.  The super-subtype relationship has been extended to include parameterized types.  In the Java 5.0 type system super-subtype relationships and the related narrowing/widening reference conversions exist among parameterized types, too.  We will explain the details in separate FAQ entries.  Here are some initial examples to get a first impression of the impact that type relationships and conversion rules have on method invocation. 

Consider a method whose declared parameter type is a wildcard parameterized type.  A wildcard parameterized type acts as supertype of all members of the type family that the wildcard type denotes. 

Example (of widening reference conversion from concrete instantiation to wildcard instantiation): 

void printAll( LinkedList<? extends Number> c) { ... }

LinkedList<Long> l = new LinkedList<Long>();
...
printAll(l);  // widening reference conversion

Note that this super-subtype relationship between a wildcard instantiation and a member of the type family that the wildcard denotes is different from inheritance. Inheritance implies a super-subtype relationship as well, but it is a special case of the more general super-subtype relationship that involves wildcard instantiations. 

We know inheritance relationships from non-generic Java.  It is the relationship between a superclass and its derived subclasses, or a super-interface and its sub-interfaces, or the relationship between an interface and its implementing classes.  Equivalent inheritance relationships exists among instantiations of different generic types.  The prerequisite is that the instantiations must have the same type arguments.  Note that this situation differs from the super-subtype relationship mentioned above, where we discussed the relationship between wildcard instantiations and concrete instantiations of the same generic type, whereas we now talk of the relationship between instantiations of different generic types with identical type arguments. 

Example (of widening reference conversion from one concrete parameterized type to another concrete parameterized type): 

void printAll( Collection<Long> c) { ... }

LinkedList<Long> l = new LinkedList<Long>();
...
printAll(l);  // widening reference conversion

It is common that programmers believe that the super-subtype relationship among type arguments would  extend into the respective parameterized type.  This is not true. Concrete instantiations of the same generic type for different type arguments have no type relationship. For instance, Number is a supertype of Integer , but List<Number> is not a supertype of List<Integer> .  A type relationship among different instantiations of the same generic type exists only among wildcard instantiations and concrete instantiations, but never among concrete instantiations. 

Example (of illegal attempt to convert between different concrete instantiations of the same generic type): 

void printAll( LinkedList<Number> c) { ... }

LinkedList<Long> l = new LinkedList<Long>();
...
printAll(l);  // error; no conversion

Unchecked conversion of parameterized types.

With the advent of parameterized types a novel category of type relationship was added to the Java type system: the relationship between a parameterized type and the corresponding raw type. The conversion from a parameterized type to the corresponding raw type is a widening reference conversion like the conversion from a subtype to the supertype. It is an implicit conversion.  An example of such a conversion is the conversion from a parameterized type such as List<String> or List<? extends Number> to the raw type List .  The counterpart, namely the conversion from the raw type to an instantiation of the respective generic type, is the so-called  unchecked conversion . It is an automatic conversion, too, but the compiler reports an "unchecked conversion" warning.   Details are explained in separate FAQ entries.  Here are some initial examples to get a first impression of usefulness of unchecked conversions.  They are mainly permitted for compatibility between generic and non-generic source code. 

Below is an example of a method whose declared parameter type is a raw type. The method might be a pre-Java-5.0 method that was defined before generic and parameterized types had been available in Java.  For this reason it declares List as the argument type.  Now, in Java 5.0, List is a raw type. 

Example (of a widening reference conversion from parameterized type to raw type): 

void printAll( List c) { ... }

List<String> l = new LinkedList<String>();
...
printAll(l);  // widening reference conversion

Below is an example of the conversion in the opposite direction.  We consider a method has a declared parameter type that is a parameterized type.  We pass a raw type argument to the method and rely on an unchecked conversion to make it work. 

Example (of an unchecked conversion from raw type to parameterized type): 

void printAll( List<Long> c) { ... }

List l = new LinkedList();
...
printAll(l);  // unchecked conversion

The subsequent FAQ entries discuss details of the various type relationships and conversions among raw types, concrete parameterized types, bounded and unbounded wildcard parameterized types. 
 

The diagram illustrates the super-subtype relationship among instantiations that have the same type argument.  The type argument can be a concrete type, but also a bounded or unbounded wildcard.  For instance, Collection<Number> is the supertype of List<Number> and LinkedList<Number> , Collection<? extends Number> is the supertype of List<? extends Number> and LinkedList<? extends Number> , Collection<?> is the supertype of List<?> and LinkedList<?> , and so on. 

Type relationships to other concrete instantiations do not exist.  In particular, the supertype-subtype relationship among the type arguments does not extend to the instantiations.  For example, Collection<Number> is NOT a supertype of Collection<Long> . 

Regarding conversions, the usual reference widening conversion from subtype to supertype is allowed. The reverse is not permitted.

At the same, an unbounded wildcard instantiation is supertype of all unbounded instantiations of any generic subtypes.  For instance, the unbounded wildcard instantiation Collection<?> is supertype of List<?> , LinkedList<?> , and so on. Both type relationships combined, an unbounded wildcard instantiation is supertype of all instantiations of the same generic type and of all instantiations of all its generic subtypes. 

Regarding conversions, the usual reference widening conversion from subtype to supertype is allowed. The reverse is not permitted. 

There is one special rules for unbounded wildcard instantiations: the conversion from a raw type to the unbounded wildcard instantiation is not an "unchecked" conversion, that is, the conversion from Collection   to Collection<?> does not lead to an "unchecked" warning.  This is different for concrete and bounded instantiations, where the conversion from the raw type to the concrete and bounded wildcard instantiation leads to an "unchecked" warning. 

At the same time, a wildcard instantiation with an upper bound is supertype of all generic subtypes that are instantiated on the same upper bound wildcard.  For instance, Collection<? extends Number> is supertype of Set<? extends Number> and ArrayList<? extends Number> . 

The upper bound wildcard instantiation is also supertype of other upper bound wildcard instantiation with an upper bound that is a subtype of the own upper bound.  For instance, Collection<? extends Number> is supertype of Collection<? extends Long> and Collection<? extend Short> , because Long and Short are subtypes of Number . 

Similarly, Collection<? extends Comparable<?>> is supertype of Collection<? extends Number> and Collection<? extends Delayed> , because Number is a subtype of Comparable<Number> , which is a subtype of Comparable<?> , and Delayed   (see java.util.concurrent.Delayed ) is a subtype of Comparable<Delayed> , which is a subtype of Comparable<?> . The idea is that if the upper bound of one wildcard is a supertype of the upper bound of another wildcard then the type family with the supertype bound includes the type family with the subtype bound.  If one family of types (e.g. ? extends Comparable<?>) includes the other (e.g. ? extends Number> and ? extends Delayed ) then the wildcard instantiation on the larger family (e.g. Collection<? extends Comparable<?>> ) is supertype of the wildcard instantiation of the included family (e.g. Collection<? extends Number> ). 

All these type relationships combined make a bounded wildcard instantiation supertype of a quite a number of instantiations of the same generic type and subtypes thereof. 

Regarding conversions, the usual reference widening conversion from subtype to supertype is allowed. The reverse is not permitted. 

At the same time, a wildcard instantiation with a lower bound is supertype of parameterized subtypes that are instantiated on the same lower bound wildcard.  For instance, Collection<? super Number> is supertype of Set<? super Number> and ArrayList<? super Number> . 

The lower bound wildcard instantiation is also supertype of other lower bound wildcard instantiation with a lower bound bound that is a supertype of the own lower bound.  For instance, Collection<? super Number> is supertype of Collection<? super Serializable> , because Serializable is a supertype of Number .   The idea is that if the lower bound of one wildcard is a subtype of the lower bound of another wildcard then the type family with the subtype bound includes the type family with the supertype bound.  If one family of types (e.g. ? super Number) includes the other (e.g. ? super Serializable ) then the wildcard instantiation on the larger family (e.g. Collection<? super Number> ) is supertype of the wildcard instantiation of the included family (e.g. Collection<? super Serializable> ). 

Regarding conversions, the usual reference widening conversion from subtype to supertype is allowed. The reverse is not permitted. 

On the one hand, there is the inheritance relationship between a supertype and a subtype. This is the usual notion of inheritance as we know it from non-generic Java.  For instance, the interface Collection is a supertype of the interface List .  This inheritance relationship is extended in analogy to instantiations of generic types, i.e. to parameterized types.  The prerequisite is that the instantiations must have identical type arguments.  An example is the supertype Collection<Long> and its subtype List<Long> . The rule is: as long as the type arguments are identical, the inheritance relationship among generic types leads to a super-subtype relationship among corresponding parameterized types. 

On the other hand, there is a relationship based on the type arguments. The prerequisite is that at least one of the involved type arguments is a wildcard. For example, Collection<? extends Number> is a supertype of Collection<Long> , because the type Long is a member of the type family that the wildcard " ? extends Number " denotes. 

This kind of type relationship also exists between two wildcard instantiations of the same generic type with different wildcards as type arguments. The prerequisite is that the type family denoted by one wildcard is a superset of the type family denoted by the other wildcard. For example, Collection<?> is a supertype of Collection<? extends Number> , because the family of types denoted by the wildcard " ? " is a superset of the family of types denoted by the wildcard " ? extends Number ".  The super-sub set relationship among the type arguments leads to a super-sub type relationship among corresponding instantiations of the same parameterized type.  The type relationship mentioned above, between a wildcard instantiation and a concrete instantiation of the same generic type, is a special case of this rule; you just interpret the concrete type argument as a type family with only one member, namely the concrete type itself. 

Both effects - the super-subtype relationship due to inheritance and the super-subtype relationship due to type arguments - are combined and lead to a two-dimensional super-subtype relationship table.  The tables below use examples for illustration. 

The vertical axis of the table lists parameterized types according to their inheritance relationship, starting with the supertype on the top to a subtype on the bottom. The horizontal axis lists type arguments according to their super-subset relationship of the type families they denote, starting with the largest type set on the lefthand side to the smallest type set on the righthand side. 
 

		?	? extends Serializable	? extends Number	Long
	Collection	Collection<?>	Collection<? extends Serializable>	Collection<? extends Number>	Collection<Long>
	List	List<?>	List<? extends Serializable>	List<? extends Number>	List<Long>
	ArrayList	ArrayList<?>	ArrayList<? extends Serializable>	ArrayList<? extends Number>	ArrayList<Long>

If you pick a certain entry in the table, say List<? extends Serializable> , then the subtable to the bottom and to the right contains all subtypes of the entry. 

Below is another example that involves lower bound wildcards. Again, the horizontal axis lists type arguments according to their super-subset relationship of the type families they denote, starting with largest set of types denoted by the unbounded wildcard " ? " over type families of decreasing size to a type set consisting of one concrete type. The difficulty with lower bound wildcards is that the super-subset relationship of the type families denoted by lower bound wildcards is slightly counter-intuitive to determine.  Details are discussed in a separate FAQ entry. 
 

		?	? super Long	? super Number	Object
	Collection	Collection<?>	Collection<? super Long>	Collection<? super Number>	Collection<Object>
	List	List<?>	List<? super Long>	List<? super Number>	List<Object>
	ArrayList	ArrayList<?>	ArrayList<? super Long>	ArrayList<? super Number>	ArrayList<Object>

If you pick a certain entry in the table, say List<? super Long> , then the subtable to the bottom and to the right contains all subtypes of the entry and you would find information such as: ArrayList<? super Number> is a subtype of List<? super Long> .

Generic Types With More Than One Type Parameter

We have been setting up tables to determine the super-subtype relationships among different instantiations of different, yet related parameterized types.  These tables were two-dimensional because we took into account inheritance on the one hand and various values for a type argument on the other hand.  A similar technique can be applied to parameterized types with more than one type parameter. 

The example below uses a generic class Pair with two type parameters.  The vertical axis lists the first type arguments order by their super-subset relationship from the largest type set to the smallest type set.  The horizontal axis does the same for the second type argument. 
 

		?	? super Long	? super Number	Object
	?	Pair<?,?>	Pair<?,? super Long>	Pair<?,? super Number>	Pair<?,Object>
	? extends Serializable	Pair<? extends Serializable,?>	Pair<? extends Serializable,? super Long>	Pair<? extends Serializable ,? super Number>	Pair<? extends Serializable,Object>
	? extends Number	Pair<? extends Number,?>	Pair<? extends Number,? super Long>	Pair<? extends Number,? super Number>	Pair<? extends Number,Object>
	Long	Pair<Long,?>	Pair<Long,? super Long>	Pair<Long,? super Number>	Pair<Long,Object>

Tables with more than two dimensions can be set up in analogy.  The key point is that you list generic types from supertype to subtype and type arguments from superset to subset. For this purpose you need to interpret type arguments as sets of types and determine their super-subtype relationships.  Note that the latter can be rather counter-intuitive in case of multi-level wildcards involving lower bounds.  Details are discussed in a separate FAQ entry.

Here are the rules:

• The unbounded wildcard "?" denotes the set of all types and is the superset of all sets denoted by bounded wildcards.
• A wildcard with an upper bound A denotes a superset of another wildcard with an upper bound B, if A is a super type of B.
• A wildcard with a lower bound A denotes a superset of another wildcard with a lower bound B, if A is a sub type of B.
• A concrete type denotes a set with only one element, namely the type itself.

	upper bound wildcards	lower bound wildcards
	?	?
	? extends SuperType	? super SubType
	? extends SubType	? super SuperType
	concrete type*  *either SubType or a subtype thereof	concrete type*  *either SuperType or a supertype thereof

Here are some examples illustrating the rules: 
 

	upper bound wildcards	lower bound wildcards
	?	?
	? extends Serializable	? super Long
	? extends Number	? super Number
	Long	Serializable

The wildcard " ? " denotes the largest possible type set, namely the set of all types.  It is the superset of all type sets. 

Upper bound wildcards are fairly easy to understand, compared to lower bound wildcards.  The wildcard " ? extends Serializable "  denotes the family of types that are subtypes of Serializable , the type Serializable itself being included. Naturally, this type family is a subset of the type set denoted by the wildcard " ? ". 

The wildcard " ? extends Number "  denotes the family of types that are subtypes of Number , the type Number itself being included. Since Number is a subtype of Serializable , the type family " ? extends Number " is a subset of the type family " ? extends Serializable ".  In other words, the super-sub type relationship between the upper bounds leads to a super-sub set   relationship between the resulting type sets. 

The concrete type Long denotes a single-member type set, which is a subset of the type family " ? extends Number " because Long is a subtype of Number . 

Among the lower bound wildcards, the wildcard " ? super Long "  denotes the family of types that are supertypes of Long , the type Long itself being included.  The wildcard " ? super Number "  denotes the family of types that are supertypes of Number , the type Number itself being included.  Number is a supertype of Long , and for this reason the type family " ? super Number " is smaller than the type family " ? super Long "; the latter includes type Long as member, while the former excludes it.  In other words, the super-sub type relationship between the lower bounds leads to the opposite relationship between the resulting type sets, namely  a sub-super set   relationship. 

Multi-Level Wildcards

Matters are more complicated when it comes to multi-level wildcards.  In principle, the rules outlined above are extended to multi-level wildcards in analogy.  However, the resulting super-subset relationships tend to be everything but intuitive to understand, so that in practice you will probably want to refrain from overly complex multi-level wildcards.  Nonetheless, we discuss in the following the rules for super-subset relationships among two-level wildcards. 

For multi-level wildcards we apply the same rules as before. The only difference is that the bounds are wildcards instead of concrete types. As a result we do not consider type relationships among the bounds, but set relationships. 

• A wildcard with an upper bound A denotes a superset of another wildcard with an upper bound B, if A denotes a super set of B.
• A wildcard with a lower bound A denotes a superset of another wildcard with a lower bound B, if A denotes a sub set of B.

	upper-upper bound wildcards	upper-lower bound wildcards
	?	?
	? extends ParType< ? >	? extends ParType< ? >
	? extends ParType < ? extends SuperType >	? extends ParType< ? super SubType >
	? extends ParType < ? extends SubType >	? extends ParType< ? super SuperType >
	? extends ParType< concrete type * > *either SubType or a subtype thereof	? extends ParType < concrete type * > *either SuperType or a supertype thereof
	concrete type* < concrete type** > *either ParType or a subtype thereof **either SubType or a subtype thereof	concrete type* < concrete type** > *either ParType or a subtype thereof **either SuperType or a supertype thereof

	lower-upper bound wildcards	lower-lower bound wildcards
	?	?
	? super ParType < concrete type * > *either SubType or a subtype thereof	? super ParType < concrete type * > *either SuperType or a supertype thereof
	? super ParType< ? extends SubType >	? super ParType< ? super SuperType >
	? super ParType < ? extends SuperType >	? super ParType< ? super SubType >
	? super ParType< ? >	? super ParType< ? >
	concrete type* <?> *either ParType or a supertype thereof	concrete type* <?> *either ParType or a supertype thereof

The rules look fairly complex, but basically it is a recursive process.  For instance: the type set denoted by " ? extends ParType <? extends SuperType> " is a superset of the type set denoted by " ? extends ParTyp e <? extends SubType > " because the upper bound " ? extends SuperType " is a superset of the upper bound " ? extends SubType ", and this is because the inner upper bound SuperType is a supertype of  the inner upper bound SubType .  In this recursive way, the super-subset relationships of multi-level wildcards can be made plausible.  Here are some concrete examples: 

Examples: 
 

	upper-upper bound wildcards	upper-lower bound wildcards
	?	?
	? extends List<?>	? extends List<?>
	? extends List<? extends Serializable>	? extends List<? super Long>
	? extends List<? extends Number>	? extends List<? super Number>
	? extends List<Long>	? extends List<Serializable>
	ArrayList<Long>	LinkedList<Serializable>

	lower-upper bound wildcards	lower-lower bound wildcards
	?	?
	? super List<Long>	? super List<Object>
	? super List<? extends Number>	? super List<? super Serializable>
	? super List<? extends Serializable>	? super List<? super Number>
	? super List<?>	? super List<?>
	Collection<?>	Collection<?>

• in the definition of a class
• in the definition of an interface
• in the definition of type parameter bounds
• in the definition of wildcard bounds

Definition of classes and interfaces

Example ( extends in the definition of a class): 

public class Quadruple<T> extends Triple<T> {
  private T fth;
  public Triple(T t1, T t2, T t3, T t4) {
    super(T1, t2, t3);
    fth = t4;
  }
  ...
}

Example ( extends in the definition of an interface): 

public interface SortedSet<E> extends Set<E> {
  ...
}

Definition of type parameter bounds

Example ( extends in the definition of type parameter bounds): 

public class Caller<V, T extends Callable<V>> {
    public Caller(T task) {
      FutureTask<V> future = new FutureTask<V>(task);
      Thread thread = new Thread(future);
      thread.setDaemon(false);
      thread.start();
      try { System.out.println ("result: " + future.get()); }
      catch (Exception e) { e.printStackTrace(); }
    }
}

In our example, we can supply a sub-interface of Callable<V> as a type argument, that is, an interface that extends the bound.  But we can also supply a class type that implements the bound.  In other words, extends in conjunction with type parameter bounds does not strictly mean inheritance, but it also includes the implements -relationship that exists between classes and interfaces. 

In conjunction with type parameter bounds the extends keyword refers to an even broader notion of subtyping.  It includes relationships that cannot be expressed in terms of extends or implements as we know them from non-generic Java. Consider the following example. 

Example ( extends in the definition of a type parameter bound that is a final class): 

public class SomeClass<T extends String> {
  ...
}

Let us consider another example that demonstrates that extends in conjunction with type parameter bounds means more than inheritance. 

Example ( extends in the definition of a type parameter bound that is a wildcard parameterized type): 

public class SomeClass<T extends Collection<?>> {
  ...
}

Definition of wildcard bounds

Example ( extends in the definition of a wildcard bound): 

List<? extends Number> ref = new ArrayList<Number>();

If the bound is a wildcard parameterized type, then extends refers to the subtype relationship that exists among wildcard parameterized types and concrete parameterized types. 

Example ( extends in the definition of a wildcard bound): 

Triple<? extends Collection<?>> q = new Triple<List<? extends Number>>();

Example (of illegal generic exception type): 

class IllegalArgumentException<T> extends Exception {   // illegal
  private T info;
  public IllegalArgumentException(T arg) { info = arg; }
  public T getInfo() { return info; }
}

Example (of illegal  use of illegal parameterized exception type): 

void method_1() {
  try { method_2(); }
  catch (IllegalArgumentException<String> e) { ... } // illegal
  catch (IllegalArgumentException<Long> e) { ... } // illegal
  catch (Throwable e) { ... }
}

Other problems occur when we define methods that throw instantiations of an (illegal) generic exception type. 

Example (of illegal  use of illegal parameterized exception type): 

void method_1() 
  throws IllegalArgumentException<String>, IllegalArgumentException<Long> { // illegal
  ... do something ...
  throw new IllegalArgumentException<String>("argument missing");
  ... do something  else ...
  throw new IllegalArgumentException<Long>(timeout);
}

Example (before type erasure): 

< E extends Exception > void someMethod() {
  try { &hellip; do something that might raise an exception &hellip;
  } catch ( E e) { &hellip; do something special for this particular exception type &hellip;
  } catch (IllegalStateException e) { &hellip; handle illegal state &hellip;
  } catch (Exception e) { &hellip; handle all remaining exceptions &hellip;
  }
}

void someMethod() {
  try { &hellip; do something that might raise an exception &hellip;
  } catch ( Exception e) { &hellip; do something special for this particular exception type &hellip;
  } catch (IllegalStateException e) { &hellip; handle illegal state &hellip;
  } catch (Exception e) { &hellip; handle all remaining exceptions &hellip;
  }
}

In other words, there never is a catch clause for the particular unknown exception type that the type argument stands for. Instead of catching a particular exception type we end up catching the bound of the unknown exception type, which changes the meaning of the sequence of catch clauses substantially and is almost always undesired.  For this reason, the use of type parameters in catch clauses is illegal.

Example (before type erasure): 

public interface Action<E extends Exception> {
  void run() throws E ;
}
public final class Executor {
  public static <E extends Exception>
    void execute(Action<E> action) throws E { 
      &hellip;
      action.run();
      &hellip;
  }
}
public final class Test {
  private static class TestAction implements Action<java.io.FileNotFoundException> {
    public void run() throws java.io.FileNotFoundException {
      &hellip;
      throw new java.io.FileNotFoundException() ; 
      &hellip;
  }
  public static void main(String[] args) {
    try { 
      Executor.execute(new TestAction()) ;
    } catch (java.io.FileNotFoundException f) { &hellip; }
  }
} 

Even after type erasure the code snippet above still captures the intent. 

Example (after type erasure): 

public interface Action {
  void run() throws Exception ;
}
public final class Executor {
  public static void execute(Action action) throws Exception { 
      &hellip;
      action.run();
      &hellip;
  }
}
public final class Test {
  private static class TestAction implements Action {
    public void run() throws java.io.FileNotFoundException {
      &hellip;
      throw new java.io.FileNotFoundException() ; 
      &hellip;
  }
  public static void main(String[] args) {
    try {
      Executor.execute(new TestAction()) ;
    } catch (java.io.FileNotFoundException f) { &hellip; }
  }
} 

Example (of method with type parameter in throws clause): 

interface Task< E extends Exception > {
  void run() throws E ;
}

• create a new exception (or error) and throw it
• catch the exception (or error) of an invoked operation and re-throw it
• propagate the exception (or error) of an invoked operation

Example (throwing an object of unknown type): 

final class CleanUp< E extends Exception , T extends Task<E>> {
  public void cleanup(T task) throws E {
    task.run();
  }
}
final class DisconnectTask implements Task<IllegalAccessException> {
  public void run() throws IllegalAccessException {
    ...
    throw new IllegalAccessException();
    ...
  }
}
class Test {
  public static void main(String[] args) {
    CleanUp<IllegalAccessException,DisconnectTask> cleaner 
       = new CleanUp<IllegalAccessException,DisconnectTask>();
    try { cleaner.cleanup(new DisconnectTask()); }
    catch (IllegalAccessException e) { e.printStackTrace(); }
  }
}

The rule is that no instantiation can be used.  The scope is qualified using the raw type.  This is because there is only one instance of a static member per type. 

Example (of a generic type with static members): 

public final class Counted<T> {
  public  static final int MAX = 1024;
  public  static class BeyondThresholdException extends Exception {}

  private static int count;
  public  static int getCount() { return count; }

  private final T value;
  public Counted(T arg) throws BeyondThresholdException { 
    value = arg; 
    count++; 
    if (count >= 1024)  throw new BeyondThresholdException();
  }
  public void finalize() { count--; }
  public T getValue() { return value; }
}

---

int m = Counted .MAX;      // ok
int k = Counted <Long> .MAX; // error
int n = Counted <?> .MAX; // error

try {
  Counted<?>[] array = null;
  array[0] = new Counted<Long>(10L);
  array[1] = new Counted<String>("abc");
}
catch ( Counted .BeyondThresholdException e) {
  e.printStackTrace();
}
System.out.println( Counted .getCount());   // ok
System.out.println( Counted <Long> .getCount()); // error
System.out.println( Counted <?> .getCount()); // error
 

In sum, it is illegal to refer to a static member using an instantiation of the generic enclosing type.  This is true for all categories of static members, including static fields, static methods, and static nested types, because each of these members exists only once per type.

Like a static nested type, an inner class exists only once, in the sense that there is only one .class file that represents the inner class.  Different from a static nested type, an inner class depends on the type argument of its outer class type.  This is because each object of an inner class type has a hidden reference to an object of the outer class type.  The type of this hidden reference is an instantiation of the generic enclosing type.  As a result, the inner class type is not independent of the enclosing class's type arguments. 

Example (of an inner class nested into a generic outer class): 

 class Sequence <E> {
        private E[] theSequence;
        private int idx;

        // static classes
        public static class NoMoreElementsException extends Exception {}
        public static class NoElementsException extends Exception {} 

        // (non-static) inner class
        public class Iterator { 
            boolean hasNext() {
                return (theSequence != null && idx < theSequence.length);
            }
           E getNext() throws NoElementsException, 
                               NoMoreElementsException, 
                               java.lang.IllegalStateException {
                if (theSequence == null)
                    throw new NoElementsException();
                if (idx < 0)
                    throw new java.lang.IllegalStateException();
                if (idx >= theSequence.length)
                    throw new NoMoreElementsException();
                else
                    return theSequence[idx++];
            }
        }
        public Iterator getIterator() {
            return this.new Iterator();
        }
}

class Test {
    private static <T> void print(Sequence<T> seq) 
      throws Sequence.NoElementsException , 
             Sequence.NoMoreElementsException {
        Sequence <T> .Iterator iter = seq.new Iterator();
        while (iter.hasNext())
            System.out.println(iter.getNext()); 
    }
   public static void main(String[] args) {
        try {
            Sequence<String> seq1 = new Sequence<String>();
            ... fill the sequence ...
            print(seq1);
            Sequence<Long> seq2 = new Sequence<Long>();
            ... fill the sequence ...
            print(seq2);
        } catch (Exception e) { e.printStackTrace();
        }
    }
}

In contrast, the nested exception types are static classes and do not depend on the outer class's type parameter. (Static nested types never depend on their enclosing type's type parameters, because the type parameters must not appear in any static context of a generic class. Details are explained in a separate FAQ entry.) Static nested classes must be referred to using the raw type as the scope qualifier, that is, as Sequence.NoElementsException ;  use of an instantiation as the scope, such as Sequence<T>.NoElementsException , is illegal. 

Example (of a nested interface): 

class Controller <E extends Executor > {
  private E executor;
  public Controller(E e) { executor = e; }
  ... 
  public interface Command { void  doIt(Runnable task); } 

  public Command command() {
    return new Command() {
      public void  doIt(Runnable task) { executor.execute(task); }
    };
  }
}
class Test
  public static void test(Controller<ThreadPoolExecutor> c) {
    Controller<ExecutorService> controller 
      = new Controller<ExecutorService>(Executors.newCachedThreadPool());
    Controller.Command command = controller.command(); 
    ...
  }
}

Below is another example of a nested interface taken from the java.util package.  The generic Map interface has a nested Entry interface. 

Example (of a nested interface taken from package java.util ): 

public interface Map <K,V> {
  public interface Entry<K,V> {
    public K getKey();
    public V getValue();
    ...
  }
  public Set< Map.Entry<K, V> > entrySet();
  ...
}

When the inner interface Entry is used it must be referred to using the raw type Map as the scope qualifier, that is, as Map.Entry<String,Long> for instance. A qualification such as  Map<String,Long>.Entry<String,Long> is illegal.

Example (of a nested enum type): 

class Controller <E extends Executor > {
  private State state;
  ... 
  public enum State { VALID, INVALID; } 
  public State getState() { return state; }
}
class Test
  public static void test(Controller<ThreadPoolExecutor> c) {
    Controller<ExecutorService> controller 
      = new Controller<ExecutorService>(Executors.newCachedThreadPool());
    Controller.State state = controller.getState();
    switch (state)) {
      case INVALID: ... ;
      case VALID:   ... ;
    } 
    ...
  }
}

Example (of a generic type with static members): 

package com.sap.util;

public final class Counted <T> {
  public  static final int MAX = 1024;
  public  static class BeyondThresholdException extends Exception {}

  private static int count;
  public  static int getCount() { return count; }

  private final T value;
  public Counted(T arg) throws BeyondThresholdException { 
    value = arg; 
    count++; 
    if (count >= 1024)  throw new BeyondThresholdException();
  }
  public void finalize() { count--; }
  public T getValue() { return value; }
}

---

import com.sap.util. * ;      // ok
import com.sap.util. Counted ;     // ok
import com.sap.util. Counted <String> ; // error

import static com.sap. Counted . * ;   // ok
import static com.sap. Counted <String> . * ; // error
import static cam.sap. Counted .BeyondThresholdException; // ok
import static com.sap. Counted <String> .BeyondThresholdException; // error

Example (of an illegal generic enum type): 

public enum Tag<T> {  // illegal, but assume we could do this
  good, bad;

  private T attribute;
  public void setAttribute(T arg) { attribute = arg; }
  public T getAttribute() { return attribute; }
}

public class Tag<T> extends Enum<Tag<T>> {
  public static final Tag< ??? > good;
  public static final Tag< ??? > bad;
  private static final Tag $VALUES[];
  private T attribute;

  private Tag(String s, int i) { super(s, i); }

  static {
    good   = new Tag("good", 0);
    bad    = new Tag("bad" , 1);
    $VALUES = (new Tag[] { good, bad });
  }

  public void setAttribute(T arg) { attribute = arg; }
  public T getAttribute() { return attribute; }
}

On the other hand, if we wanted that the type of the enum values is a particular instantiation of the generic enum type, how would we tell the compiler?  There is no syntax for specifying the type of an enum value. 

Also, when we refer to the enum values we must qualify their name by the name of their defining class, that is, Tag.good and Tag.bad .  Although Tag is a parameterized type, we cannot say Tag<String>.good or Tag<Long>.bad .  This is because static members of a generic type must be referred to via the raw type name.  In other words, we would not even be capable of expressing that we intend to refer to an enum value belonging to a particular instantiation of the generic enum type. 

No matter how we put it: generic enum types do not make sense.

There are two situations in which type inference is attempted:

• when an object of a generic type is created , and
• when a generic method is invoked.

class ArrayList<E> {
   ...
}
List<String> list1 = new ArrayList <String> ();  // type parameter specified     => E:=String
List<String> list2 = new ArrayList <> ();        // type parameter inferred      => E:=String 
List<String> list3 = new ArrayList();          // type parameter omitted       => using raw type

[Note: Type inference for new -expressions was introduced in Java 7 and did not exist in Java 5 and 6.]

Example (of automatic type inference on method invocation): 

class Collections {
   ...
   public static <T> void copy(List<? super T> dest, List<? extends T> src) { ... }
   ...
}

List<String> src = new ArrayList<>();
List<Object> dst = new ArrayList<>();

Collections. <CharSequence> copy(dst,src);  // type parameter specified     => T:=CharSequence
Collections. <> copy(dst,src);              // error: illegal syntax
Collections.copy(dst,src);                // type parameter inferred      => T:=String

class SomeClass<T> {
    SomeClass(T arg) { ... }
}

SomeClass<Long> ref = new SomeClass<>(0L);

class SomeClass<T> {
    SomeClass(T arg) { ... }
    static <E> SomeClass<E> make(E arg) { return new SomeClass<E>(arg); }
}

SomeClass<Long> ref = new SomeClass<>(0L);
SomeClass<Long> ref = SomeClass.make(0L);

Example (of diamond operator): 

List<String> list1 = new ArrayList <String> (); 
List<String> list2 = new ArrayList <> (); 

Until Java 9 the diamond operator was not permitted in anonymous inner class definitions.

Here is an example:

Callable<Long> task = new Callable <> () {        // error in Java 7/8; fine since Java 9
    public Long call() { return 0L; }
};

Type inference takes into account the context in which the new -expression appears and what the new -expression looks like.  The type inference process works in two separate steps:

• First, the compiler takes a look at the static types of the constructor arguments in the new -expression.
• Second, if any of the missing type parameters cannot be resolved from the constructor arguments, then the compiler uses information from the context in which the new -expression appears.

Since Java 8, an additional inference context is permitted, namely the method invocation context .  If the new -expression is the argument to a method invocation, then the compiler deduces the missing type parameter information from the method's declared argument type, if possible.

Examples (of type inference for an  instance creation expression without constructor arguments): 

List<String> list1 = new ArrayList <String> (); 
List<String> list2 = new ArrayList <> ();        // type inference

Map<Callable<String>, List<Future<String>>> tasks1 
= new HashMap <Callable<String>, List<Future<String>>> (); 
Map<Callable<String>, List<Future<String>>> tasks2 
= new HashMap <> ();                             // type inference

Examples (of improved type inference in Java 8): 

List<String> list1 = new ArrayList<> ();                                // fine since Java 7
List<String> list2 = Collections.synchronizedList( new ArrayList<> () );  // error in Java 7 ; fine in Java 8

---

error: incompatible types
        List<String> list3 = Collections.synchronizedList(new ArrayList<>()); 
                                                         ^
  required: List<String>
  found:    List<Object>

The inference is different if constructor arguments are provided.  In such a context the compiler takes a look at the static types of the constructor arguments and ignores the lefthand side of the assignment.

Examples (of type inference for an  instance creation expression with constructor arguments): 

Set<Long>   s1 = new HashSet<>();
Set< Long >   s2 = new HashSet<>(Arrays.asList(0L,0L));
Set< Number > s3 = new HashSet<>(Arrays.asList(0L,0L));   // error in Java 7 ; fine since Java 8
Set<Number> s4 = new HashSet<Number>(Arrays.asList(0L,0L)); 

---

error: incompatible types
        Set<Number> s3 = new HashSet<>(Arrays.asList(0L,0L)); 
                         ^
  required: Set<Number>
  found:    HashSet<Long>

- The second new -expression has constructor arguments; the missing type parameter is inferred from the constructor argument. The constructor argument is of type List<Long> and the compiler again concludes that the missing type parameter must be Long .  Note, the lefthand side of the assignment is ignored because the constructor argument provides enough information for the type inference to complete successfully.

- The third new -expression demonstrates that the lefthand side of the assignment is indeed ignored (in Java 7). The compiler again infers from the constructors argument, i.e., the result of the asList method, that the missing type parameter for the new HashSet must be Long .  This leads to a type mismatch and an according error message.  The compiler does not conclude that the missing type parameter should be Number because it ignores the lefthand side of the assignment.  In Java 8, the type inference was modified and improved.  Since then,  compiler infers Number as the type parameter form the new HashSet on the right-hand side of the compiler and from that deduces Number as the type parameter for the asList method.  In Java 8, this compiles just fine.

- The fourth new -expression does not rely on type inference and simply specifies the intended type parameter explicitly.
 

There is yet a different result of type inference if the context of the new -expression has neither constructor arguments nor a lefthand side of an assignment.  Here is an example.

Examples (of type inference for an  instance creation expression in a method invocation context):

void method(Set<Long> arg) { ... }

method(new HashSet<>());                       // error in Java 7 ; fine in Java 8
method(new HashSet<>(Arrays.asList(0L,1L,2L)));

---

error: method method in class TypeInference cannot be applied to given types
        method(new HashSet<>()); 
        ^
  required: Set<Long>
  found: HashSet<Object>

The result of type inference can be surprising for a new -expression that appears in a context other than an assignment. 

Example (of surprising type inference): 

String s = new ArrayList<>().iterator().next(); // error

---

error: incompatible types: Object cannot be converted to String
        String s = new ArrayList<>().iterator().next();
                                                    ^

Hence the compiler has no information for type inference and concludes that the missing type parameter of the ArrayList is type Object . The iterator's next method then returns an Object instead of the expected String and the compiler accordingly reports a type mismatch.

• Explicit type argument specification .  The type arguments are explicitly specified in a type argument list.
• Automatic type argument inference. The method is invoked like regular non-generic methods, that is, without specification of the type arguments.  In this case the compiler automatically infers the type arguments from the invocation context. 

class Collections {
  public static <A extends Comparable<? super 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<Long> list = new LinkedList<Long>();
    list.add(0L); 
    list.add(1L);
    Long y = Collections.max(list) ;
  }
}

Example (of surprising type argument inference): 

public final class Utilities {
  ...
  public static <T> void fill( T [] array, T elem) {
    for (int i=0; i<array.length; ++i) { array[i] = elem; }
  }
}

public final class Test {
  public static void main(String[] args) {
    Utilities.fill(new String [5], new String ("XYZ"));  // T:=String
    Utilities.fill(new String [5], new Integer (100));   // T:=Object&Serializable&Comparable
  }
}

However, the compiler does not reject this method call.  Instead it performs type inference and infers the common supertypes of String and Integer as type argument.  To be precise the compiler infers 

T := Object & Serializable & Comparable<? extends Object&Serializable&Comparable<?>>

Whether the result of this successful type inference is desired or not depends on the circumstances.  In this example the source code compiles, but the method invocation in question will fail at runtime with an ArrayStoreException , because the method would try to store integers in an array of strings. 

In Java 5, 6, and 7 it was possible to prevent the perhaps undesired type argument inference by a minor modification of the fill method. 

Example (modified, in Java 5, 6, and 7): 

public final class Utilities {
  ...
  public static < T , S extends T > void fill( T [] array, S elem) { 
    for (int i=0; i<array.length; ++i) { array[i] = elem; }
  }
}

public final class Test {
  public static void main(String[] args) {
    Utilities.fill(new String [5], new String ("XYZ"));  // T:=String and S:=String
    Utilities.fill(new String [5], new Integer (100));   // T:=String and S:=Integer => error (in Java 5,6,7)
  }
}

Since Java 8 the compiler does no longer issue an error message and you will observe the same behavior as in the initial example without the additional type variable " S extends T ".  The fact that the type inference process  in Java 5, 6, and 7 could not find a common super type and issued an error message was just an accident.  The glitch was fixed in Java 8 and nowadays the compiler exploits the covariance of arrays in this example, too. 

Example (same as above, but in Java 8): 

public final class Utilities {
  ...
  public static < T , S extends T > void fill( T [] array, S elem) { 
    for (int i=0; i<array.length; ++i) { array[i] = elem; }
  }
}

public final class Test {
  public static void main(String[] args) {
    Utilities.fill(new String [5], new String ("XYZ"));  // T:=Object&Serializable&Comparable and S:=String  => fine
    Utilities.fill(new String [5], new Integer (100));   // T:=Object&Serializable&Comparable and S:=Integer => fine (in Java 8)
  }
}

f(x).g();

tmp=f(x); 
tmp.g();

Example:

public final class Utilities {
  ...
  public static <T> HashSet<T> create(int size) {
    return new HashSet<T>(size);
  }
}

HashSet<Integer>  tmp   = Utilities.create(5);
Iterator<Integer> iter = tmp .iterator();

Iterator<Integer> iter = Utilities.create(5).iterator();

In the two-step invocation the result of the create method appears in an assignment, and assignment is a context that the compiler considers for type inference. In the one-step invocation the result of the create method is used to invoke another method, and method chains are not considered for type inference. 

Here is what the compiler infers for the two-step call:

HashSet<Integer>  tmp   = Utilities.create(5);               // T:=Integer
Iterator<Integer> iter = tmp .iterator();                   // T:=Integer

The one-step call, in contrast, does not compile because the type argument inference works differently in this case:

Iterator<Integer> iter = Utilities.create(5).iterator();

---

error: incompatible types
        Iterator<Integer> iter = Utilities.create(5).iterator();
                                                             ^
  required: Iterator<Integer>
  found:    Iterator<Object>

The example demonstrates, that in rare cases there can be a difference between a one-step nested method call such as f(x).g(); and a two-step call using a temporary variable such as tmp=f(x); tmp.g(); . The difference stems from the fact that an assignment context is considered for the type argument inference, while other situations are not.
 

Example (of a wildcard in a method signature): 

public static void reverse(List<?> list) {
  // ...  the implementation ...
}

The wildcard capture can be imagined as an anonymous type variable that the compiler generates internally and uses as the static type of the method parameter.  A type variable is like a type parameter of a generic type or method; it stands for a particular unknown type. Changing the method parameter's type from the instantiation using a wildcard to an instantiation using the capture is known as capture conversion . The translation of our method can be imagined as though the compiler had re-implemented the method to use a synthetic generic method that has the wildcard capture as it type parameter. 

Example (pseudo code showing the wildcard capture): 

private static <T_?001> void reverse_?001(List<T_?001> list) {
  // ...  the implementation ...
}
public static void reverse(List<?> list) {
  reverse_?001(list);
}

For illustration, let us consider a conceivable implementation of the reverse method using a generic helper method rev for which the compiler must infer the type arguments from the wildcard. 

Example (implementation of the reverse method): 

private static <T> void rev(List<T> list) {
  ListIterator<T> fwd = list.listIterator();
  ListIterator<T> rev = list.listIterator(list.size());
  for (int i = 0, mid = list.size() >> 1; i < mid; i++) {
    T tmp = fwd.next();
    fwd.set(rev.previous());
    rev.set(tmp);
  }
}
public static void reverse(List<?> list) {
  rev(list);
}

Example (pseudo code showing the wildcard capture): 

private static <T> void rev(List<T> list) {
  ListIterator<T> fwd = list.listIterator();
  ListIterator<T> rev = list.listIterator(list.size());
  for (int i = 0, mid = list.size() >> 1; i < mid; i++) {
    T tmp = fwd.next();
    fwd.set(rev.previous());
    rev.set(tmp);
  }
}
private static <T_?001> void reverse_?001(List<T_?001> list) {
  rev(list);
}
public static void reverse(List<?> list) {
  reverse_?001(list);
}

Example (implementation of assignment of wildcard instantiation): 

private static void method( List<?> list) {
  List <String>            ll1 = list;     // error
  List <? extends String> ll2 = list;     // error
  List <? super String>    ll3 = list;     // error
  List <?>                 ll4 = list;     // fine
}

---

error: incompatible types
found   : java.util.List <capture of ? >
required: java.util.List<java.lang.String>
        List<String> ll1 = list;
                           ^
error : incompatible types
found   : java.util.List <capture of ?
required: java.util.List<? extends java.lang.String>
        List<? extends String> ll2 = list;
                                     ^
error : incompatible types
found   : java.util.List <capture of ?
required: java.util.List<? super java.lang.String>
        List<? super String> ll3 = list;
                                   ^

For illustration we use the getClass method, which is defined in class Object (see java.lang.Object.getClass ). The result of the getClass method is of type Class<? extends X> , where X is the erasure of the static type of the expression on which getClass is called. 

Example (with bounded wildcard):

Number n = new Integer(5);
Class<Number> c = n.getClass();  // error

---

error: incompatible types
found   : java.lang.Class<capture of ? extends java.lang.Number>
required: java.lang.Class<java.lang.Number>
        Class<Number> c = n.getClass(); 
                                    ^

Example (corrected): 

Number n = new Integer(5);
Class<?>                c1 = n.getClass(); 
Class<? extends Number> c2 = n.getClass();

Interestingly, the capture of a bounded wildcard, whose upper bound is a final class, is still incompatible to the bounds type, although the set of types that the bounded wildcard denotes contains only one type, namely the bounds type itself. 

Example (using final class as bound): 

String s = new String("abc");
Class<String>           c0 = s.getClass();  // error
Class<?>                c1 = s.getClass();  // fine
Class<? extends String> c2 = s.getClass();  // fine

---

error: incompatible types
found   : java.lang.Class<capture of ? extends java.lang.String>
required: java.lang.Class<java.lang.String>
        Class<String>           c0 = s.getClass(); 
                                               ^

Example ( of a parameterized class): 

class Box<T> {
  private T t;
  public Box(T t) { this.t = t; }
  public void put(T t) { this.t = t;}
  public T take() { return t; }
  public boolean equalTo(Box<T> other) { return this.t.equals(other.t); }
  public Box<T> copy() { return new Box<T>(t); }
}