Jump to content

Generics in Java: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
→‎Wildcards: retarget link
→‎Type erasure: Clarified, rewrote some, and merged criticism from Criticism of Java.
Line 136: Line 136:


==Type erasure==
==Type erasure==
Generics are checked at compile-time for type correctness. The generic type information is then removed via a process called '''type erasure'''. For example, <code>List&lt;Integer&gt;</code> will be converted to the '''raw type''' (non-generic type) <code>List</code>, which can contain arbitrary objects. However, due to the compile-time check, the resulting code is guaranteed to be type correct, as long as the code generated no unchecked compiler warnings.
Generics are checked at compile-time for type-correctness. The generic type information is then removed in a process called '''type erasure'''. For example, <code>List&lt;Integer&gt;</code> will be converted to the non-generic type <code>List</code>, which can contain arbitrary objects. The compile-time check guarantee that the resulting code is type-correct.


As a result, there is no way to tell at runtime which type parameter is used on an object. For example, when an <code>ArrayList</code> is examined at runtime, there is no general way to tell whether it was an <code>ArrayList&lt;Integer&gt;</code> or an <code>ArrayList&lt;Float&gt;</code>. (There are partial approaches — for example, individual elements may be examined to see what type they belong to, since an <code>ArrayList&lt;Float&gt;</code> should never contain an <code>Integer</code> and vice versa; and it can be determined using [[Reflection (computer science)|reflection]] if the <code>ArrayList</code> actually belongs to a non-parameterized subtype of a specific <code>ArrayList</code> type, such as an <code>ArrayListOfFloats</code> that's declared to extend <code>ArrayList&lt;Float&gt;</code> — but no approach will work in all cases.)
As a result of type erasure, type parameters cannot be determined at run-time. For example, when an <code>ArrayList</code> is examined at runtime, there is no general way to determine whether, before type erasure, it was an <code>ArrayList&lt;Integer&gt;</code> or an <code>ArrayList&lt;Float&gt;</code>. Many people are dissatisfied with this restriction <ref>{{cite web|first=Neal|last=Gafter|title=Reified Generics for Java|date=2006-11-05|accessdate=2010-04-20}}</ref>. There are partial approaches. For example, individual elements may be examined to determine the type they belong to; for example, if an <code>ArrayList</code> contains an <code>Integer</code>, that ArrayList was presumably parameterized with <code>Integer</code>. [[Reflection (computer science)|reflection]] can also determine the type parameter. However, no approach works in all cases.

The following code demonstrates that the Class objects appear the same:


Demonstrating this point, the following code outputs "Equal":
<source lang="java">
<source lang="java">
ArrayList<Integer> li = new ArrayList<Integer>();
ArrayList<Integer> li = new ArrayList<Integer>();
Line 149: Line 148:
</source>
</source>


Java generics differ from [[C++]] templates. Java generics generate only one compiled version of a generic class or function regardless of the number of types used. Furthermore, the Java run-time environment does not need to know which parameterized type is used because the type information is validated at compile-time and erased from the compiled code. Consequently, one cannot instantiate a Java class of a parameterized type because instantiation requires a call to a constructor, which is not possible when the type is unknown at both compile-time and runtime.
Java generics differ from [[C++ templates]]. Java generics generate only one compiled version of a generic class or function regardless of the number of parameterizing types used. Furthermore, the Java run-time environment does not need to know which parameterized type is used because the type information is validated at compile-time and is not included in the compiled code. Consequently, instantiating a Java class of a parameterized type is impossible because instantiation requires a call to a constructor, which is unavailable if the type is unknown.


For example, the following code will not compile:
<source lang="java">
<source lang="java">
T instantiateElementType(List<T> arg)
T instantiateElementType(List<T> arg)
Line 158: Line 158:
</source>
</source>


Because there is only one copy of a generic class, static variables are shared among all the instances of the class, regardless of their type parameter. As a result, the type parameter cannot be used in the declaration of static variables or in static methods. Static variables and static methods are "outside" of the scope of the class's parameterized types.
Because there is only one copy per generic class at runtime, static variables are shared among all the instances of the class, regardless of their type parameter. As a result, the type parameter cannot be used in the declaration of static variables or in static methods. Static variables and static methods are "outside" of the scope of the class's parameterized types.


==See also==
==See also==

Revision as of 01:37, 21 April 2010

Generics are a facility of generic programming that was added to the Java programming language in 2004 as part of J2SE 5.0. They allow "a type or method to operate on objects of various types while providing compile-time type safety."[1]

Hierarchy and classification

As per Java Language Specification[2]:

  • A type variable is an unqualified identifier. Type variables are introduced by generic class declarations, generic interface declarations, generic method declarations, and by generic constructor declarations.
  • A class is generic if it declares one or more type variables. These type variables are known as the type parameters of the class. It defines one or more type variables that act as parameters. A generic class declaration defines a set of parameterized types, one for each possible invocation of the type parameter section. All of these parameterized types share the same class at runtime.
  • An interface is generic if it declares one or more type variables. These type variables are known as the type parameters of the interface. It defines one or more type variables that act as parameters. A generic interface declaration defines a set of types, one for each possible invocation of the type parameter section. All parameterized types share the same interface at runtime.
  • A method is generic if it declares one or more type variables. These type variables are known as the formal type parameters of the method. The form of the formal type parameter list is identical to a type parameter list of a class or interface.
  • A constructor can be declared as generic, independently of whether the class the constructor is declared in is itself generic. A constructor is generic if it declares one or more type variables. These type variables are known as the formal type parameters of the constructor. The form of the formal type parameter list is identical to a type parameter list of a generic class or interface.

Motivation for generics

The following block of Java code illustrates a problem that exists when not using generics. First, it declares an ArrayList of type Object. Then, it adds a String to the ArrayList. Finally, it attempts to retrieve the added String and cast it to an Integer.

  List v = new ArrayList();
  v.add("test");
  Integer i = (Integer)v.get(0);

Although the code compiles without error, it throws a runtime exception (java.lang.ClassCastException) when executing the third line of code. This type of problem can be avoided by using generics and is the primary motivation for using generics.

Using generics, the above code fragment can be rewritten as follows:

  List<String> v = new ArrayList<String>();
  v.add("test");
  Integer i = v.get(0); // (type error)

The type parameter String within the angle brackets declares the ArrayList to be constituted of Strings (a descendant of the ArrayList's generic Object constituents). With generics, it is no longer necessary to cast the third line to any particular type, because the result of v.get(0) is defined as String by the code generated by the compiler.

Compiling the third line of this fragment with J2SE 5.0 (or later) will yield a compile-time error because the compiler will detect that v.get(0) returns String instead of Integer. For a more elaborate example, see [3].

Wildcards

Generic type parameters in Java are not limited to specific classes. Java allows the use of wildcards to specify bounds on the type of parameters a given generic object may have. Wildcards are type parameters of the form "?", possibly annotated with a bound. Given that the exact element type of an object with a wildcard is unknown, restrictions are placed on the type of methods that may be called on the object.

As an example of an unbounded wildcard, List<?> indicates a list which has an unknown object type. Methods which take such a list as an argument can take any type of list, regardless of parameter type. Reading from the list will return objects of type Object, and writing non-null elements to the list is not allowed, since the parameter type is not known.

To specify the upper bound of a generic element, the extends keyword is used, which indicates that the generic type is a subtype of the bounding class. Thus it must either extend the class, or implement the interface of the bounding class. So List<? extends Number> means that the given list contains objects of some unknown type which extends the Number class. For example, the list could be List<Float> or List<Number>. Reading an element from the list will return a Number, while writing non-null elements is once again not allowed.

The use of wildcards above are necessary since objects of one type parameter cannot be converted to objects of another parameter. Neither List<Number> nor List<Integer> is a subtype of the other, even though Integer is a subtype of Number. So, code that deals with List<Number> does not work with List<Integer>. If it did, it would be possible to insert a Number that is not a Integer into it, which violates type safety. Here is a sample code that explains the contradiction it brings if List<Integer> is a subtype of List<Number>:

List<Integer> ints = new ArrayList<Integer>();
ints.add(2);
List<Number> nums = ints;  //valid if List<Integer> is a supertype of List<Number> according to substitution rule. 
nums.add(3.14);  
Integer x=ints.get(1); // now 3.14 is assigned to an Integer variable!


The solution with wildcards works because it disallows operations that would violate type safety.

To specify the lower bounding class of a generic element, the super keyword is used. This keyword indicates that the aforementioned generic type is a super-type of said bounding class. So, List<? super Number> could represent List<Number> or List<Object>. Reading from a list defined as List<? super Number> returns elements of type Object. Writing to such a list requires elements of type Number or its subclasses.

Generic class definitions

Here is an example of a generic class:

public class Pair<T, S>{
  public Pair(T f, S s){ 
    first = f;
    second = s;   
  }

  public T getFirst(){
    return first;
  }

  public S getSecond()   {
    return second;
  }

  public String toString()  { 
    return "(" + first.toString() + ", " + second.toString() + ")"; 
  }

  private final T first;
  private final S second;
}

Note that the above class is for illustration of java generics only. A better implementation of Pair can be found in this stackoverflow.com discussion.

This generic class can be used in the following way:

Pair<String, String> grade440 = new Pair<String, String>("mike", "A");
Pair<String, Integer> marks440 = new Pair<String, Integer>("mike", 100);
System.out.println("grade: " + grade440.toString());
System.out.println("marks: " + marks440.toString());

Generic method definitions

Here is an example of a generic method using the generic class above:

public <T> Pair<T,T> twice(T value)
{
   return new Pair<T,T>(value,value);
}

In many cases the user of the method need not indicate the type parameters, as they can be inferred:

Pair<String, String> pair = twice("Hello");

The parameters can be explicitly added if needed:

Pair<String, String> pair = this.<String>twice("Hello");

Note that you cannot use native types, ex:

Pair<int, int> pair; // this fails. You have to use Integer instead.

Generics in throws clause

Although exceptions themselves cannot be generic, generic parameters can appear in a throws clause:

public <T extends Throwable> void throwMeConditional
      (boolean conditional, T exception) throws T
{
   if(conditional)
     throw exception;
}

Type erasure

Generics are checked at compile-time for type-correctness. The generic type information is then removed in a process called type erasure. For example, List<Integer> will be converted to the non-generic type List, which can contain arbitrary objects. The compile-time check guarantee that the resulting code is type-correct.

As a result of type erasure, type parameters cannot be determined at run-time. For example, when an ArrayList is examined at runtime, there is no general way to determine whether, before type erasure, it was an ArrayList<Integer> or an ArrayList<Float>. Many people are dissatisfied with this restriction [4]. There are partial approaches. For example, individual elements may be examined to determine the type they belong to; for example, if an ArrayList contains an Integer, that ArrayList was presumably parameterized with Integer. reflection can also determine the type parameter. However, no approach works in all cases.

Demonstrating this point, the following code outputs "Equal":

ArrayList<Integer> li = new ArrayList<Integer>();
ArrayList<Float> lf = new ArrayList<Float>();
if (li.getClass() == lf.getClass()) // evaluates to true
  System.out.println("Equal");

Java generics differ from C++ templates. Java generics generate only one compiled version of a generic class or function regardless of the number of parameterizing types used. Furthermore, the Java run-time environment does not need to know which parameterized type is used because the type information is validated at compile-time and is not included in the compiled code. Consequently, instantiating a Java class of a parameterized type is impossible because instantiation requires a call to a constructor, which is unavailable if the type is unknown.

For example, the following code will not compile:

T instantiateElementType(List<T> arg)
{
  return new T(); //causes a compile error
}

Because there is only one copy per generic class at runtime, static variables are shared among all the instances of the class, regardless of their type parameter. As a result, the type parameter cannot be used in the declaration of static variables or in static methods. Static variables and static methods are "outside" of the scope of the class's parameterized types.

See also

References

  1. ^ Java Programming Language
  2. ^ Java Language Specification, Third Edition by James Gosling, Bill Joy, Guy Steele, Gilad Bracha - Prentice Hall PTR 2005
  3. ^ http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf - Generics in the Java Programming Language
  4. ^ Gafter, Neal (2006-11-05). "Reified Generics for Java". {{cite web}}: |access-date= requires |url= (help); Missing or empty |url= (help)

External links