Generic Implementation and Limitation

In the Generic Common Usage, we introduced some common usage about java generic: extends, ? super T, wildcard usage.

Now, we come to how generic is implemented and what this implementation brings to us.

The implementation of generic – erase

We all hear that Java generic is implemented by erase, but what does that mean? More specific, how erase affect the byte code, and Java run time environment.

Byte code

In order to achieve the back-compatibility, Java use erase to implement generic.

This is what we commonly heard, and how erase makes it?
It’s simple. Making all byte code same, whether it uses generic or not. In this way, you can invoke old library without generic and they can invoke new generic code without worry. Just because the byte code makes no difference.

we can see from following snippet that the byte code use generic is almost the same with code not using generic.

// pre Java5 generic code
public static void swapAgain(Object[] ts, int i, int j) {
    Object tmp = ts[i];
    ts[i] = ts[j];
    ts[j] = tmp;
}

// Java5 and later generic code
public static <T> void swap(T[] ts, int i, int j) {
    T tmp = ts[i];
    ts[i] = ts[j];
    ts[j] = tmp;
}
// the result de-compiled from byte code
public static <T> void swap(T[] ts, int i, int j) {
    Object tmp = ts[i];
    ts[i] = ts[j];
    ts[j] = tmp;
}

If we look at upper code closely, we may argue that there actually exist some differences: the declaration of method are different. OK, it’s not different actually in byte code. Let’s view the byte code directly:

public static swapAgain([Ljava/lang/Object;II)V

// signature <T:Ljava/lang/Object;>([TT;II)V
// declaration: void swap<T>(T[], int, int)
public static swap([Ljava/lang/Object;II)V

Now we can see, they are same except some comments. Actually, if you name them with same name, the compiler will complain:

Error:(90, 28) java: name clash: swap(T[],int,int) and swap(java.lang.Object[],int,int) have the same erasure

Is this all what compiler do for us? No, we need more. Compiler erase our generic type to Object(more precisely, its bounds), so it should recover type back when we need generic type.

public static void main(String[] args) {
    Container<Integer> integerContainer = new Container<>();
    integerContainer.add(1);
    Integer integer = integerContainer.get(0);
}

// the result de-compiled from byte code
public static void main(String[] args) {
    Container integerContainer = new Container();
    integerContainer.add(Integer.valueOf(1));
    Integer integer = (Integer)integerContainer.get(0);
}

From the above comparison, we can see that the effect of erase:

• compile code into its bound type, make it no differences with common code
• add cast when we need explicit type

What should be noticed is that all compiler changed is the type of reference, not affect the object in the heap, which store its real type, class etc.

Runtime

At run time, things is almost the same. JVM load the same byte code and run it like original code. Let it runs as before means we don’t know which type any more, because it has already lost in compilation.

Just one thing is different: the array. Because array’s implementation is not exposed, it can change to suit the generic, which make array can store the exact type information. This is called ‘Array is reified’ which we will explain it later using example.

Limitations

No primitive

Primitives can’t be erased, so it can’t be used in generic.

Array vs Collection

Array is covariant, Collection is invariant;

Object[] s = new Integer[1]; // fine
ArrayList<Object> sl = new ArrayList<Integer>(); // compiler error: Incompatible types

Array is reified, Collection is erased – this lead to upper compilation result, which is explained more clearly by following code:

Object[] s = new Integer[4]; // fine, an array expect 4 integer
s[0] = new String(); // compile fine, but throw Runtime Exception because array know what itself stores -- array is reified

// if compiler let the code's compilation fine
ArrayList<Object> sl = new ArrayList<Integer>(); 
// then because list actually store a list of object -- Collection is ersed, no error when adding a string (erased into ref of object, which suit the requirement of list)
sl.add(new String()); 
// 100...00 lines code
// finally it throw exception when we try to cast this string to a integer -- it would be horrible to find where this bug stems from!

Lacking Runtime Behavior

Because we just have a bounded type (usually, it is Object), we don’t know what the exact type reference is and can’t use with type parameter:

• new
• instanceof
• T.class
• …

// all the following is invalid

// construction is static dispatched, so have to decided in compiling time, which is erased
T a = new T();

// array is reified, which needs specific type info to create, which is erased
T[] aa = new T[1];

// T is erased, so can't test
if (a instanceof T) {
}
// but this one can work, because this relies on object, not reference
b.getClass().isInstance(a)

More

Java uses erase to implement generic, while c++ uses template to produce a new copy of code for different type.
Do you have any other ideas about how to implement generic? Glad to hear your opinion.

Ref

• Thinking in Java 4th Edition, Generics
• code example

Written with StackEdit.