Java Reference
In-Depth Information
A.3. Generics: Reification, Erasure, and Raw Types
The generic type system was added to the Java programming language
for the 5.0 release. The design was strongly constrained by the need to
maintain compatibility between independently developed code modules
that may or may not include the use of generics. The key design decision
was that generic types could not be reified at runtime. Rather, for each
generic type declaration there would be a single type that was defined
in terms of the erasure of its type variables. As we discussed in
Chapter
11
, in simple terms the type is defined such that each type variable is re-
placed by its boundcommonly
Object
. The reasoning behind this decision
is beyond the scope of this topic, but to quote
JLS
4.7 (
The Java
™
Lan-
guage Specification
,
Third Edition
, Section 4.7):
…the design of the generic type system seeks to support migration
compatibility. Migration compatibility allows the evolution of existing
code to take advantage of generics without imposing dependencies
between independently developed software modules. The price of
migration compatibility is that full reification of the generic type sys-
tem is not possible, at least while the migration is taking place.
Note that in the future, this design decision might be changed.
A.3.1.
Raw
Types,
"Unchecked"
Warnings,
and
Bridge
Methods
A consequence of the reification design decision is the existence and use
of raw types. Raw types represent the erasure of a specific generic type.
They exist so that code that was written to use a non-generic version of
a class or interface can execute in a virtual machine that uses a generic
version of that class or interface. Some of these uses may cause
"un-
checked" warnings
to be issued by the compiler, but the uses are still
permitted. "Unchecked" warnings are emitted in the following circum-
stances:
