Java泛型

2.1 Introduction
Java's generics implementation was based on a project originally called Pizza, which was done by Martin Odersky and others. Pizza was renamed GJ, then it turned into a JSR and ended up being adopted into the Java language. And this particular generics proposal had as a key design goal that it could run on an unmodified VM [Virtual Machine]. It is, of course, great that you don't have to modify your VM, but it also brings about a whole bunch of odd limitations. The limitations are not necessarily directly apparent, but you very quickly go, "Hmm, that's strange."

When you take an element out of a Collection, you must cast it to the type of element that is stored in the collection. Besides being inconvenient, this is unsafe. The compiler does not check that your cast is the same as the collection's type, so the cast can fail at run time.
Generics provide a way for you to communicate the type of a collection to the compiler, so that it can be checked. Once the compiler knows the element type of the collection, the compiler can check that you have used the collection consistently and can insert the correct casts on values being taken out of the collection.

List<T> pronounced List of T


2.2 Defining Simple generic



2.3 Java Generic Mechanism-Type Erasure
Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler. The main advantage of this approach is that it provides total interoperability between generic code and legacy code that uses non-parameterized types (which are technically known as raw types). The main disadvantages are that parameter type information is not available at run time, and that automatically generated casts may fail when interoperating with ill-behaved legacy code. There is, however, a way to achieve guaranteed run-time type safety for generic collections even when interoperating with ill-behaved legacy code (reference to section Dynamic Type Safety).

Generic type parameter will be erased to its first bound.

e.g. 1
import java.util.ArrayList;

public class TestErasure1 {
public static void main(String[] args) throws InstantiationException,
IllegalAccessException {
Class<?> c1 = new ArrayList().getClass();
Class<?> c2 = new ArrayList<String>().getClass();
Class<?> c3 = new ArrayList<Integer>().getClass();
System.out.println(c1 == c2);
System.out.println(c1 == c3);
}

}
Output: true true
you can declare ArrayList.class, but you can not declare ArrayList<String>.class

e.g. 2
public class SimpleHolder {

private Object obj;

public Object getObj() {
return obj;
}

public void setObj(Object obj) {
this.obj = obj;
}


public static void main(String[] args) {
SimpleHolder holder=new SimpleHolder();
holder.setObj("Item");
String s=(String) holder.getObj();
}

}

public class GenericHolder<T> {
private T obj;

public T getObj() {
return obj;
}

public void setObj(T obj) {
this.obj = obj;
}

public static void main(String[] args) {
GenericHolder<String> holder=new GenericHolder<String>();
holder.setObj("Item");
String s=holder.getObj();
}

}

Use
javap –c SimpleHolder>>SimpleHolder.txt
javap –c GenericHolder>>GenericHolder.txt

They have same generated byte codes, there is no necessary to do type check with set method, compiler will check it for you, but still necessary to do type cast with the returned value from get method. Actually compiler does the same thing for you when you don’t use generic instead of using Object.

Because of erasure, you can not do the following:

class Erasure<T>{
public void T(Object arg){
if(arg instanceof T){} //error
T t=new T(); //error
T[] array1=new T[10]; //error
T[] array2=(T[])new Object[10];//Unchecked warning
}
}

You can do this way?
class Building{}
class House extends Building{}

class ClassTypeCapture<T>{
Class<T> kind;
public ClassTypeCapture(Class<T> kind) throws InstantiationException, IllegalAccessException{
this.kind=kind;

}
public T getObject() throws InstantiationException, IllegalAccessException{
T temp=(T) kind.newInstance();
System.out.println("className of returned object:"+temp.getClass().getSimpleName());
return temp;
}
public boolean checkClassType(Object arg){
return kind.isInstance(arg);
}

public static void main(String[] args) throws InstantiationException,
IllegalAccessException {
System.out.println("\n***********separator********************");
ClassTypeCapture<Building> ctc1=new ClassTypeCapture<Building>(Building.class);
System.out.println(ctc1.checkClassType(new Building()));
System.out.println(ctc1.checkClassType(new House()));

ClassTypeCapture<House> ctc2=new
ClassTypeCapture<House>(House.class);
System.out.println(ctc2.checkClassType(new Building()));
System.out.println(ctc2.checkClassType(new House()));

House temp=ctc2.getObject();
}
2.4 Subtype and Covariant
Are the following assignments valid?
class Building{}
class House extends Building{}

Building b=new Building();
House h = new House();
b=h;

Building[] arrayB=new Building[10];
House[] arrayH=new House[10];
arrayB=arrayH;

List<Building> lb=new ArrayList<Building>();
List<House> lh=new ArrayList<House>();
lb=lh;

In general, if Foo is a subtype (subclass or subinterface) of Bar, and G is some generic type declaration, it is not the case that G<Foo> is a subtype of G<Bar>.
2.5 Generic methods

2.6 Wildcards
2.6.1 Wildcards with an UpBound: <? Extend T> - get method
The syntax ? extend T denotes an unknown type that is a subtype of T
2.6.2 Wildcards with a LowerBound: <? Super T> - set method
The syntax ? super T denotes an unknown type that is a supertype of T, note T may have many supertypes(interfaces)
2.6.3 Unbounded wildcard: <?>
List<?> vs. List
After the compiler erasure, it seems List<?> and List are all erased to List<Object>, are they equal? no, there are different.
List<?> is a non raw type which holds object from a special unknown type, the type is a reify type and we just don’t know right now,
List is a raw type list which holds objects from any types,

2.7 Self Bounded Type


2.8 Dynamic Type Safety
Java.util.Collectinos provide a group of static methods to support dynamic type safety:
checkedCollection(), checkedList(), checkedMap(), checkedSet(), checkedSortedMap(), checkedSortedSet()


2.9 Generics in C#, C++ and Java
How C# generics work?
In C# without generics, you are basically able to say class List {...}. In C# with generics, you can say class List<T> {...}, where T is the type parameter. Within List<T> you can use T as if it were a type. When it actually comes time to create a List object, you say List<int> or List<Customer>. You construct new types from that List<T>, and it is truly as if your type arguments get substituted for the type parameter. All of the Ts become ints or Customers, you don't have to downcast, and there is strong type checking everywhere.

In the CLR [Common Language Runtime], when you compile List<T>, or any other generic type, it compiles down to IL [Intermediate Language] and metadata just like any normal type. The IL and metadata contains additional information that knows there's a type parameter, of course, but in principle, a generic type compiles just the way that any other type would compile. At runtime, when your application makes its first reference to List<int>, the system looks to see if anyone already asked for List<int>. If not, it feeds into the JIT the IL and metadata for List<T> and the type argument int. The JITer, in the process of JITing the IL, also substitutes the type parameter.

It's exactly instantiating at runtime. It's producing native code specifically for that type at the point it is needed. And literally when you say List<int>, you will get a List of int. If the code in the generic type uses an array of T, that becomes an array of int.


Comparing C# and Java Generics
Bruce Eckel: How do C# generics compare with Java generics?
Anders Hejlsberg: Java's generics implementation was based on a project originally called Pizza, which was done by Martin Odersky and others. Pizza was renamed GJ, then it turned into a JSR and ended up being adopted into the Java language. And this particular generics proposal had as a key design goal that it could run on an unmodified VM [Virtual Machine]. It is, of course, great that you don't have to modify your VM, but it also brings about a whole bunch of odd limitations. The limitations are not necessarily directly apparent, but you very quickly go, "Hmm, that's strange."
For example, with Java generics, you don't actually get any of the execution efficiency that I talked about, because when you compile a generic class in Java, the compiler takes away the type parameter and substitutes Object everywhere. So the compiled image for List<T> is like a List where you use the type Object everywhere. Of course, if you now try to make a List<int>, you get boxing of all the ints. So there's a bunch of overhead there. Furthermore, to keep the VM happy, the compiler actually has to insert all of the type casts you didn't write. If it's a List of Object and you're trying to treat those Objects as Customers, at some point the Objects must be cast to Customers to keep the verifier happy. And really all they're doing in their implementation is automatically inserting those type casts for you. So you get the syntactic sugar, or some of it at least, but you don't get any of the execution efficiency. So that's issue number one I have with Java's solution.
Issue number two, and I think this is probably an even bigger issue, is that because Java's generics implementation relies on erasure of the type parameter, when you get to runtime, you don't actually have a faithful representation of what you had at compile time. When you apply reflection to a generic List in Java, you can't tell what the List is a List of. It's just a List. Because you've lost the type information, any type of dynamic code-generation scenario, or reflection-based scenario, simply doesn't work. If there's one trend that's pretty clear to me, it's that there's more and more of that. And it just doesn't work, because you've lost the type information. Whereas in our implementation, all of that information is available. You can use reflection to get the System.Type for object List<T>. You cannot actually create an instance of it yet, because you don't know what T is. But then you can use reflection to get the System.Type for int. You can then ask reflection to please put these two together and create a List<int>, and you get another System.Type for List<int>. So representationally, anything you can do at compile time you can also do at runtime.
Comparing C# Generics to C++ Templates
Bruce Eckel: How do C# generics compare with C++ templates?
Anders Hejlsberg: To me the best way to understand the distinction between C# generics and C++ templates is this: C# generics are really just like classes, except they have a type parameter. C++ templates are really just like macros, except they look like classes.
The big difference between C# generics and C++ templates shows up in when the type checking occurs and how the instantiation occurs. First of all, C# does the instantiation at runtime. C++ does it at compile time, or perhaps at link time. But regardless, the instantiation happens in C++ before the program runs. That's difference number one. Difference number two is C# does strong type checking when you compile the generic type. For an unconstrained type parameter, like List<T>, the only methods available on values of type T are those that are found on type Object, because those are the only methods we can generally guarantee will exist. So in C# generics, we guarantee that any operation you do on a type parameter will succeed.
C++ is the opposite. In C++, you can do anything you damn well please on a variable of a type parameter type. But then once you instantiate it, it may not work, and you'll get some cryptic error messages. For example, if you have a type parameter T, and variables x and y of type T, and you say x + y, well you had better have an operator+ defined for + of two Ts, or you'll get some cryptic error message. So in a sense, C++ templates are actually untyped, or loosely typed. Whereas C# generics are strongly typed.