Java Reference
In-Depth Information
11.5.1. Erasure at Runtime
The runtime impact of erasure is simple to state: Nothing that needs to
know the value of a type argument at runtime is allowed. This has the
following consequences, some of which we have already discussed:
•
You cannot instantiate a type represented only as a type para-
meter, nor can you create an array of such a type. So for a type
variable
T
you can't do
newT()
or
newT[n]
.
•
You cannot create an array whose element type is a parameter-
ized type, with the exception of a parameterized type for which
all the type arguments are unbounded wildcards. For example,
"
newList<String>[1]
" is invalid, whereas "
newList<?>[1]
" is okay.
•
You cannot use
instanceof
to see if an object is an instance of a
parameterized type, again with the exception of a parameterized
type whose type arguments are all unbounded wildcards. The
in-
stanceof
test is a runtime test, and at runtime the parameterized
type has been replaced by its erasure. Since this is unlikely to
perform the test you expected, the compiler rejects it. You can
replace the parameterized type by its erasure if that is what you
really wanted to test.
•
Casts involving type parameters or parameterized types are re-
placed with casts to the erasure of that type (see discussion be-
low).
•
A catch clause cannot declare that it catches an exception repres-
ented by a type variableeven if the bound on that type variable
is an exception type. The exact type of the exception must be
known at compile time. (You can throw an exception so referen-
ced, however, and you can declare the type variable in a meth-
od's
throw
clause.)
•
A generic class is not allowed to directly or indirectly extend
Throwable
. Given that you can't catch generic exceptions there is
little point in being able to declare them.
