Solve the Internal Server Error problem with the use the all-one-word “run time”! Notice all the instances below are the word “run time”.
Generics are a facility of generic programming that were added to the Java programming language in 2004 within version J2SE 5.0. They were designed to extend Java's type system to allow "a type or method to operate on objects of various types while providing compile-time type safety". The aspect compile-time type safety required that parametrically polymorphic functions are not implemented in the Java virtual machine, since type safety is impossible in this case.
The Java collections framework supports generics to specify the type of objects stored in a collection instance.
In 1998, Gilad Bracha, Martin Odersky, David Stoutamire and Philip Wadler created Generic Java, an extension to the Java language to support generic types. Generic Java was incorporated in Java with the addition of wildcards.
Short description: Form of abstraction for a type or method to allow them to be functions of a type parameter
Generics are a facility of generic programming that were added to the Java programming language in 2004 within version J2SE 5.0. They were designed to extend Java's type system to allow “a type or method to operate on objects of various types while providing compile-time type safety”.<ref>Java Programming Language</ref> The aspect compile-time type safety was not fully achieved, since it was shown in 2016 that it is not guaranteed in all cases.<ref>A ClassCastException can be thrown even in the absence of casts or nulls.
</ref>
The Java collections framework supports generics to specify the type of objects stored in a collection instance.
In 1998, Gilad Bracha, Martin Odersky, David Stoutamire and Philip Wadler created Generic Java, an extension to the Java language to support generic types.<ref>GJ: Generic Java</ref> Generic Java was incorporated in Java with the addition of wildcards.
According to Java Language Specification:<ref>Java Language Specification, Third Edition by James Gosling, Bill Joy, Guy Steele, Gilad Bracha – Prentice Hall PTR 2005</ref>
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
—an error in logic, as it is not generally possible to cast an arbitrary string to an integer.
<syntaxhighlight lang=“Java”> List v = new ArrayList(); v.add(“test”); // A String that cannot be cast to an Integer Integer i = (Integer)v.get(0); // Run time error </syntaxhighlight>
Although the code is compiled without error, it throws a run time exception (
java.lang.ClassCastException
) when executing the third line of code. This type of logic error can be detected during compile time by using generics and is the primary motivation for using them.
The above code fragment can be rewritten using generics as follows:
<syntaxhighlight lang=“Java”> List<String> v = new ArrayList<String>(); v.add(“test”); Integer i = (Integer)v.get(0); // (type error) compilation-time error </syntaxhighlight>
The type parameter
String
within the angle brackets declares the
ArrayList
to be constituted of
String
(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.
The logical flaw in the third line of this fragment will be detected as a compile-time error (with J2SE 5.0 or later) because the compiler will detect that
v.get(0)
returns
String
instead of
Integer
. For a more elaborate example, see reference.<ref>
</ref>
Here is a small excerpt from the definition of the interfaces
List
and
Iterator
in package
:
<syntaxhighlight lang=“Java”> public interface List<E> {
void add(E x); Iterator}iterator();
public interface Iterator<E> {
E next(); boolean hasNext();} </syntaxhighlight>
A type argument for a parameterized type is not limited to a concrete class or interface. Java allows the use of type wildcards to serve as type arguments for parameterized types. Wildcards are type arguments in the form “
<?>
”; optionally with an upper or lower bound. Given that the exact type represented by a wildcard is unknown, restrictions are placed on the type of methods that may be called on an object that uses parameterized types.
Here is an example where the element type of a
Collection<E>
is parameterized by a wildcard:
<syntaxhighlight lang=“java”> Collection<?> c = new ArrayList<String>(); c.add(new Object()); // compile-time error c.add(null); // allowed</syntaxhighlight>
Since we don’t know what the element type of
c
stands for, we cannot add objects to it. The
add()
method takes arguments of type
E
, the element type of the
Collection<E>
generic interface. When the actual type argument is
?
, it stands for some unknown type. Any method argument value we pass to the
add()
method would have to be a subtype of this unknown type. Since we don't know what type that is, we cannot pass anything in. The sole exception is null; which is a member of every type.<ref>
</ref>
To specify the upper bound of a type wildcard, the
extends
keyword is used to indicate that the type argument is a subtype 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
. Adding null elements is, again, also allowed.<ref>
</ref>
The use of wildcards above adds flexibility since there is not any inheritance relationship between any two parameterized types with concrete type as type argument. Neither
List<Number>
nor
List<Integer>
is a subtype of the other; even though
Integer
is a subtype of
Number
. So, any method that takes
List<Number>
as a parameter does not accept an argument of
List<Integer>
. If it did, it would be possible to insert a
Number
that is not an
Integer
into it; which violates type safety. Here is an example that demonstrates how type safety would be violated if
List<Integer>
were a subtype of
List<Number>
:
<syntaxhighlight lang=“java”> List<Integer> ints = new ArrayList<Integer>(); ints.add(2); List<Number> nums = ints; // valid if List<Integer> were a subtype 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! </syntaxhighlight>
The solution with wildcards works because it disallows operations that would violate type safety:
<syntaxhighlight lang=“java”> List<? extends Number> nums = ints; // OK nums.add(3.14); // compile-time error nums.add(null); // allowed </syntaxhighlight>
To specify the lower bounding class of a type wildcard, the
super
keyword is used. This keyword indicates that the type argument is a supertype of the 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
. Adding to such a list requires either elements of type
Number
, any subtype of
Number
or null (which is a member of every type).
The mnemonic PECS (Producer Extends, Consumer Super) from the book Effective Java by Joshua Bloch gives an easy way to remember when to use wildcards (corresponding to covariance and contravariance) in Java.
Here is an example of a generic Java class, which can be used to represent individual entries (key to value mappings) in a map:
<syntaxhighlight lang=“Java”> public class Entry<KeyType, ValueType> {
private final KeyType key; private final ValueType value;
public Entry(KeyType key, ValueType value) {
this.key = key;
this.value = value;
}
public KeyType getKey() {
return key;
}
public ValueType getValue() {
return value;
}
public String toString() {
return "(" + key + ", " + value + ")";
}
} </syntaxhighlight>
This generic class could be used in the following ways, for example:
<syntaxhighlight lang=“Java”> Entry<String, String> grade = new Entry<String, String>(“Mike”, “A”); Entry<String, Integer> mark = new Entry<String, Integer>(“Mike”, 100); System.out.println(“grade: ” + grade); System.out.println(“mark: ” + mark);
Entry<Integer, Boolean> prime = new Entry<Integer, Boolean>(13, true); if (prime.getValue()) System.out.println(prime.getKey() + “ is prime.”); else System.out.println(prime.getKey() + “ is not prime.”); </syntaxhighlight>
It outputs:
grade: (Mike, A) mark: (Mike, 100) 13 is prime.
Thanks to type inference, Java SE 7 and above allow the programmer to substitute an empty pair of angle brackets (
<>
, called the diamond operator) for a pair of angle brackets containing the one or more type parameters that a sufficiently-close context implies.<ref>http://docs.oracle.com/javase/7/docs/technotes/guides/language/type-inference-generic-instance-creation.html</ref> Thus, the above code example using
Entry
can be rewritten as:
<syntaxhighlight lang=“Java”> Entry<String, String> grade = new Entry<>(“Mike”, “A”); Entry<String, Integer> mark = new Entry<>(“Mike”, 100); System.out.println(“grade: ” + grade); System.out.println(“mark: ” + mark);
Entry<Integer, Boolean> prime = new Entry<>(13, true); if (prime.getValue()) System.out.println(prime.getKey() + “ is prime.”); else System.out.println(prime.getKey() + “ is not prime.”); </syntaxhighlight>
Here is an example of a generic method using the generic class above: <syntaxhighlight lang=“Java”> public static <Type> Entry<Type, Type> twice(Type value) {