Generic and the erasure process

Question

I've a doubt reading this written in the Java tutorial:

In the introduction, we saw invocations of the generic type declaration List, such as List. In the invocation (usually called a parameterized type), all occurrences of the formal type parameter (E in this case) are replaced by the actual type argument (in this case, Integer).

but if there are no restrictions the formal type parameter is not replaced by Object? Why is said that E is replaced by Integer?

Also, here, in the Java tutorial is said:

To reference the generic Box class from within your code, you must perform a generic type invocation, which replaces T with some concrete value, such as Integer:

but, again, thanks to the erasure a compile time T in box class is replaced by Object and not by Integer. Integer type is written only for casting operations.

In fact, still in the same tutorial is said:

During the type erasure process, the Java compiler erases all type parameters and replaces each with its first bound if the type parameter is bounded, or Object if the type parameter is unbounded.

I'm really confused. Which is the truth? Is T replaced by Integer or by Object?

Answer 1

the formal type parameter is not replaced by Object?

Generic type represented as Object in runtime. But you can get information about <YourType> with reflection. Erasure relates to compatibility with old clases. It was a bad idea. Article about it.

Answer 2

You speak of different things.

The citations from the tutorial speak about type instantiation. This has nothing to do with type erasure, which is a IMHO misnamed concept, and simply means that the generic types are not available at runtime anymore.

But at compile time they are, and instantiation happens at compile time.

To answer your question, "at compile time" is a broad thing. THe following hapens all at compile time:

1. read source files
2. lexical analysis
3. parsing
4. ...
5. type checking
6. ...
7. code generation

The list is, by no means, complete, mind you. However, as you see, during type checking, the compiler knows your type instantiations and can check them.

Later, it emits byte code, and since byte code has no way of representing generics, the types are "erased", which means, a cast is inserted here and there.

So, your assumption that "compile time" is somehow an instant where everything happens at once is not correct.

---

Further edit:

I think you take all this (i.e. the word "replace") too literally. For sure, the compiler has some data structures where the types and names and scopes of all items in the program are held.

Look, it's quite simple in principle, if we have:

static <X> List<X> meth(X[] arr) { .... }

And later, you do:

Integer arr = new Integer[100];
List<Integer> list = meth(arr);
Integer foo = list.get(1);

then you are instantiating the type of the meth method:

static List<Integer> meth(Integer[] arr) { .... }

The point of the generics is to say that meth works for any type. This is just what the compiler checks. And it will know, that, for all X if you pass an array of X, you get back a list of X, hence, since you passed Integer[], the result must be List<Integer> and the list assignment is correct. Furthermore, the compiler knows, that ** for all X **, if you get an element from a List<X>, it will be an X.

Therefore, the compiler notes and checks that foo is an Integer. Later, on code generation, it will insert there a cast to Integer, because, due to type erasure, the return value from List.get is Object.

Note also, that "replace" does not mean that the compiler somehow alters your code. It just creates (maybe temporary) from the generic type signature a non-generic one (by substituting - if you like this better - all the type parameters with their actual types), and uses this to check the type.

It is just like in math, if I say: Please replace the a with 42 and check if the equation is true:

a + 1 = 43

then it makes no sense to ask "where exactly" this replacement takes place. Most probably in your brain.