What is the concept of erasure in generics in java?
It's basically the way that generics are implemented in Java via compiler trickery. The compiled generic code actually just uses
When you compile some code against a generic type or method, the compiler works out what you really mean (i.e. what the type argument for
Compare this with, say, C#, where the information is retained at execution time, allowing code to contain expressions such as
To complete the already very complete Jon Skeet's answer, you have to realize the concept of type erasure derives from a need of compatibility with previous versions of java.
Initially presented at EclipseCon 2007 (no longer available), the compatibility included those points:
There are propositions for a greater reification. Reify being "Regard an abstract concept as real", where Language constructs should be concepts, not just syntactic sugar.
I should also mention the
The generics mechanism in the language provides compile-time (static) type checking, but it is possible to defeat this mechanism with unchecked casts.
Usually this is not a problem, as the compiler issues warnings on all such unchecked operations.
There are, however, times when static type checking alone is not sufficient, like:
Update July 2012, almost 4 years later:
It is now (2012) detailed in "API Migration Compatibility Rules (Signature Test)"
Just as a side-note, it is an interesting exercise to actually see what the compiler is doing when it performs erasure -- makes the whole concept a little easier to grasp. There is a special flag you can pass the compiler to output java files that have had the generics erased and casts inserted. An example:
This, of course, does more than just erasure; all of the automatic stuff the compiler does gets done here. For example, default constructors are also inserted, the new foreach-style
Complementing the already-complemented Jon Skeet answer...
It has been mentioned that implementing generics through erasure leads to some annoying limitations (e.g. no
The more interesting point (which has not been raised) is that implementing generics using erasure offers quite a bit more flexibility in what the high-level type system can accomplish. A good example of this would be Scala's JVM implementation vs CLR. On the JVM, it is possible to implement higher-kinds directly due to the fact that the JVM itself imposes no restrictions on generic types (since these "types" are effectively absent). This contrasts with the CLR, which has runtime knowledge of parameter instantiations. Because of this, the CLR itself must have some concept of how generics should be used, nullifying attempts to extend the system with unanticipated rules. As a result, Scala's higher-kinds on the CLR are implemented using a weird form of erasure emulated within the compiler itself, making them not-entirely-compatible with plain-old .NET generics.
Erasure may be inconvenient when you want to do naughty things at runtime, but it does offer the most flexibility to the compiler writers. I'm guessing that's part of why it's not going away any time soon.
Erasure, literally means that the type information which is present in the source code is erased from the compiled bytecode. Let us understand this with some code.
If you compile this code and then decompile it with a decompiler such as JAD , you will get something like this. Notice that the decompiled code contains no trace of the type information present in the original source code.
As I understand it (being a .net guy) the jvm has no concept of generics so the compiler replaces type parameters with Object and performs all the casting for you.
This means that java generics are nothing but syntax sugar and don't offer any performance improvement for value types that require boxing/unboxing when passed by reference.
protected by sᴜʀᴇsʜ ᴀᴛᴛᴀ Nov 3 '14 at 7:11
Thank you for your interest in this question.
Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.
Would you like to answer one of these unanswered questions instead?