Generics in Java

Generics are a facility of generic programming that were added to the Java programming language in 2004 within the official 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.”[1] This was not achieved though, since it was shown in 2016 that compile-time safety is not guaranteed.[2] 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.[3] Generic Java was incorporated in Java with the addition of wildcards.

Hierarchy and classification

According to Java Language Specification:[4]

Motivation

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); // Run time error

Although the code is compiled 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<>();
v.add("test");
Integer i = v.get(0); // (type error)  compilation-time error

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.

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 reference.[5]

Here is a small excerpt from the definition of the interfaces List and Iterator in package java.util:

public interface List<E> { 
    void add(E x);
    Iterator<E> iterator();
}

public interface Iterator<E> { 
    E next();
    boolean hasNext();
}

Type wildcards

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 "?", possibly 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 which uses parameterized types.

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

To specify the upper bound of a type wildcard, the extends keyword is used, which indicates 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 extend 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 adding non-null elements is once again not allowed.

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 sample code that explains the contradiction it brings if List<Integer> were a subtype of List<Number>:

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!

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

List<? extends Number> nums = ints;  // it is OK
nums.add(3.14); // it is prohibited

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 elements of type Number or any super type of Number.

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.

Generic class definitions

Here is an example of a generic Java class, which can be used to represent individual entries (key to value mappings) in a map:

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 + ")";  
    }

}

This generic class could be used in the following ways, for example:

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.");

It outputs:

grade: (Mike, A)
mark: (Mike, 100)
13 is prime.

Diamond operator

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.[6] Thus, the above code example using Entry can be rewritten as:

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.");

Generic method definitions

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

public static <Type> Entry<Type, Type> twice(Type value) {
    return new Entry<Type, Type>(value, value);
}

Note: If we remove the first <Type> in the above method, we will get compilation error (cannot find symbol 'Type') since it represents the declaration of the symbol.

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

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

The parameters can be explicitly added if needed:

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

The use of primitive types is not allowed, and boxed versions must be used instead:

Entry<int, int> pair; // Fails compilation. Use Integer instead.

There is also the possibility to create generic methods based on given parameters.

public <Type> Type[] toArray(Type... elements) {
    return elements;
}

In such cases you can't use primitive types either, e.g.:

Integer[] array = toArray(1, 2, 3, 4, 5, 6);

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;
    }
}

Problems with 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 ordinarily contains arbitrary objects. The compile-time check guarantees that the resulting code is type-correct.

Because 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.[7] 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 may have been parameterized with Integer (however, it may have been parameterized with any parent of Integer, such as Number or Object).

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");
}

Another effect of type erasure is that a generic class cannot extend the Throwable class in any way, directly or indirectly:[8]

public class GenericException<T> extends Exception

The reason why this is not supported is due to type erasure:

try {
    throw new GenericException<Integer>();
}
catch(GenericException<Integer> e) {
    System.err.println("Integer");
}
catch(GenericException<String> e) {
    System.err.println("String");
}

Due to type erasure, the runtime will not know which catch block to execute, so this is prohibited by the compiler.

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 cannot be compiled:

<T> 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. Consequently, the type parameter cannot be used in the declaration of static variables or in static methods.

Project Valhalla

Project Valhalla is an experimental project to incubate improved Java generics and language features, for future versions potentially from Java 10 onwards. Potential enhancements include:[9]

See also

References

  1. ↑ Java Programming Language
  2. ↑ A ClassCastException can be thrown even in the absence of casts or nulls."Java and Scala’s Type Systems are Unsound" (PDF).
  3. ↑ GJ: Generic Java
  4. ↑ Java Language Specification, Third Edition by James Gosling, Bill Joy, Guy Steele, Gilad Bracha – Prentice Hall PTR 2005
  5. ↑ Gilad Bracha (July 5, 2004). "Generics in the Java Programming Language" (PDF). www.oracle.com.
  6. ↑ http://docs.oracle.com/javase/7/docs/technotes/guides/language/type-inference-generic-instance-creation.html
  7. ↑ Gafter, Neal (2006-11-05). "Reified Generics for Java". Retrieved 2010-04-20.
  8. ↑ "Java Language Specification, Section 8.1.2". Oracle. Retrieved 24 October 2015.
  9. ↑ Goetz, Brian. "Welcome to Valhalla!". OpenJDK mail archive. OpenJDK. Retrieved 12 August 2014.


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.