Java Reference
In-Depth Information
• It is an array type (§
10.1
) whose element type is reifiable.
• It is a nested type where, for each type
T
separated by a “
.
”,
T
itself is reifiable.
For example, if a generic class
X
<
T
>
has a generic member class
Y
<
U
>
, then
the type
X
<?>.
Y
<?>
is reifiable because
X
<?>
is reifiable and
Y
<?>
is reifiable.
The type
X
<?>.
Y
<Object>
is not reifiable because
Y
<Object>
is not reifiable.
An intersection type is not reifiable.
The decision not to make all generic types reifiable is one of the most crucial, and
controversial design decisions involving the type system of the Java programming
language.
Ultimately, the most important motivation for this decision is compatibility with ex-
isting code. In a naive sense, the addition of new constructs such as generics has no
implications for pre-existing code. The Java programming language, per se, is com-
patible with earlier versions as long as every program written in the previous versions
retains its meaning in the new version. However, this notion, which may be termed
language compatibility, is of purely theoretical interest. Real programs (even trivi-
al ones, such as “Hello World”) are composed of several compilation units, some of
which are provided by the Java SE platform (such as elements of
java.lang
or
java.util
).
In practice, then, the minimum requirement is platform compatibility - that any pro-
gram written for the prior version of the Java SE platform continues to function un-
changed in the new version.
One way to provide platform compatibility is to leave existing platform functionality
unchanged, only adding new functionality. For example, rather than modify the exist-
ing Collections hierarchy in
java.util
, one might introduce a new library utilizing gen-
erics.
The disadvantages of such a scheme is that it is extremely difficult for pre-existing cli-
ents of the Collection library to migrate to the new library. Collections are used to ex-
change data between independently developed modules; if a vendor decides to switch
to the new, generic, library, that vendor must also distribute two versions of their code,
to be compatible with their clients. Libraries that are dependent on other vendors code
cannot be modified to use generics until the supplier's library is updated. If two mod-
ules are mutually dependent, the changes must be made simultaneously.
Clearly, platform compatibility, as outlined above, does not provide a realistic path
for adoption of a pervasive new feature such as generics. Therefore, the design of the
