Type Erasure

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
}
}
Why does the compiler not complain about E obj = (E)new Object();
They say that type information is removed at compile time. If its removed what will this statement look like after compilation ?

Hi,

If I'm right, the line should be like this after type erasure-



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

In LineA, LineB and LineC, it looks for a class E. So that results in an error when there's no such class.

As for LineD is concerned, the compiler was just looking for a "type" there and its pretty ok with it when it is given a "type" (E in this case)

Regards,
Vishwa

As for LineD is concerned, the compiler was just looking for a "type" there and its pretty ok with it when it is given a "type" (E in this case)

When you say "type" its nothing but a "class type" I dont understand why
we are allowed to declare
E instance;
if the compiler is looking for a class named "E"

Oops! I should've been clear... Just forget that line..

What I meant is,
1)instantiation
2)instanceof check

are special cases where you can't use a "generic-type"

because the compiler is looking for an "actual-type" there...
(by actual-type I mean theres a .java and .class file by that name)

Regards,
Vishwa

Well I accept it as rules But actually I am curious about what the compiled generic code looks like if all type info is lost at compile time.
What would
private E[] elementData;
look like after compilation and how how does java know that a class is typed if all the type info is lost due to type erasure ?

Hi Ranchers,

Correct me if I'm wrong..

I think,


would be the same as



to the compiler after compilation..

and how how does java know that a class is typed if all the type info is lost due to type erasure ?

Java doesn't. At runtime java doesn't know that a

can hold only Integers.

Would that knowledge be required at runtime to enable type-safety?
I doubt..

(I'll paste below two questions from Javabeat... related to this)

Hi,

< guess this is not reqd for the exam, as type erasure is not included>



Answer:
No, unfortunately this source code cannot be compiled. Method names can only be
overloaded if the count or the types of the methods differ.
The compiler erases the type information form the generics and so both isRipeInBasket
methods have the same signature. This is not allowed. (This is a major difference to the
templates in C++)

Hi,
<and this one too, guess its not included in the exam...>



Answer:
a
This source code is OK. The compiler converts the signatures of the insertRipe methods to
the following ones:
public static void insertRipe(Apple a, Basket b)
public static void insertRipe(Orange g, Basket b)
Those signatures are different and so the method name can be overloaded.

If public static <G extends Orange>void insertRipe(G g, Basket<? super G> b)becomes public static void insertRipe(Orange g, Basket b) in the class file then
can we call insertRipe(<Anything that extends orange>,<Basket of Anything> ?
Because the typing info of basket is lost ! this is what I meant earlier when I said how java know if the class file is generic or not ? For example a compiled ArrayList will not have any information that the class is generic , so when I write new ArrayList<String>() in my code how does the compiler validate this against ArrayList.class ?

I chanced upon something that I had been craving for...
http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#How%20do%20I%20refer%20to%20an%20interface%20type%20nested%20into%20a%20parameterized%20type?
I guess its a one stop shop all for java generics !