Type Erasure

[Lil_Aziz1]

I started reading about Generics again and I thought I was almost done with it until the last section: Type Erasure ( Type Erasure (The Java™ Tutorials > Learning the Java Language > Generics) )

So it states:

For instance, Box<String> is translated to type Box, which is called the raw type — a raw type is a generic class or interface name without any type arguments. This means that you can't find out what type of Object a generic class is using at runtime. The following operations are not possible:

    public class MyClass<E> {
        public static void myMethod(Object item) {
            if (item instanceof E) {  //Compiler error
                ...
            }
            E item2 = new E();   //Compiler error
            E[] iArray = new E[10]; //Compiler error
            E obj = (E)new Object(); //Unchecked cast warning
        }
    }

The operations shown in bold are meaningless at runtime because the compiler removes all information about the actual type argument (represented by the type parameter E) at compile time.

Okay that kind of make sense. The E in Box<E> is removed as String in Box<String> is removed. But then, how does the compiler know what to return?

public class Example<T> {
     private T value;
     
     public Example(T value) {
          this.value = value;
          //When the type erasure removes the Ts, what does it replace it with? If it replaces it with Object, shouldn't item instanceOf E work then?
     }
     //works
     public Object getValue() {
	  return value;
     }
     //compile-time error. 
     public Number getValue() {
	  return value;
     }

Any help is appreciated. Thanks in advance!

[Norm]

Would this do it:

public T getValue() {
return value;
}

[Lil_Aziz1]

Well yes, but the question is: if type erasure removes all information about a generic variable (private T t), how does it know what it is? If it replaces it with Object, why can't we do

if (item instanceof E)

[JosAH]

Generics have to cooperate with legacy code; Generics only exist during compile time and constructs such as E item= new E() would force the compiler to call a constructor of an actual (raw) class; the compiler knows what constructor from which class it should call but it can't call it because you might fill in another real class for <E> at a new compilation and that would change the entire generated code (that's what C++ does and it results in the much hated 'code bloat').

When an E is returned from, say, a Collection<E> the compiler knows that and can check it and let the JVM simply return an Object; the compiler knew during compile time that it was a E because it checked it. (if it wasn't an E the compiler would've whined and stopped the compilation process).

kind regards,

Jos