System, but they may not be reproduced for publication

warnings when a raw type is used in a way that might jeopardize type safety. In the
preceding program, these lines generate unchecked warnings:
In the first line, it is the use of Gen without a type argument that causes the warning.
In the second line, it is the assignment of a raw reference to a generic variable that
generates the warning.
At first, you might think that this line should also generate an unchecked warning, but
it does not:
No compiler warning is issued because the assignment does not cause any further loss
of type safety than had already occurred when raw was created.
One final point: You should limit the use of raw types to those cases in which you must
mix legacy code with modern, generic code. Raw types are simply a transitional feature
and not something that should be used for new code.
TYPE INFERENCE WITH THE DIAMOND
OPERATOR
Beginning with JDK 7, it is possible to shorten the syntax used to create an instance of a
generic type. To begin, think back to the TwoGen class shown earlier in this chapter. A
portion is shown here for convenience. Notice that it uses two generic types.

---

For versions of Java prior to JDK 7, to create an instance of TwoGen, you must use a
statement similar to the following:
Here, the type arguments (which are Integer and String) are specified twice: first,
when tgOb is declared, and second, when a TwoGen instance is created via new.
While there is nothing wrong, per se, with this form, it is a bit more verbose than it
needs to be. Since, in the new clause, the type of the type arguments can be readily
inferred, there is really no reason that they need to be specified a second time. To
address this situation, JDK 7 added a syntactic element that lets you avoid the second
specification.
Today, the preceding declaration can be rewritten as shown here:
Notice that the instance creation portion simply uses < >, which is an empty type
argument list. This is referred to as the diamond operator. It tells the compiler to infer
the type arguments needed by the constructor in the new expression. The principal
advantage of this type­inference syntax is that it shortens what are sometimes quite
long declaration statements. This is especially helpful for generic types that specify
bounds.
The preceding example can be generalized. When type inference is used, the declaration
syntax for a generic reference and instance creation has this general form:

---

Here, the type argument list of the new clause is empty.
Although mostly for use in declaration statements, type inference can also be applied to
parameter passing. For example, if the following method is added to TwoGen:
then the following call is legal:
In this case, the type arguments for the arguments passed to isSame( ) can be inferred
from the parameters’ types. They don’t need to be specified again.
Although the diamond operator offers convenience, in general, the remaining examples
of generics in this book will continue to use the full syntax when declaring instances of
generic classes. There are two reasons for this. First, using the full­length syntax makes
it very clear precisely what is being created, which is helpful when example code is
shown. Second, the code will work in environments that are using an older compiler. Of
course, in your own code, the use of the type inference syntax will streamline your
declarations.
LOCAL VARIABLE TYPE INFERENCE AND
GENERICS
As just explained, type inference is already supported for generics through the use of
the diamond operator. However, you can also use the new local variable type inference
feature added by JDK 10 with a generic class. For example, again assuming the
TwoGen class, this declaration:
can be rewritten like this using local variable type inference:
In this case, the type of tgOb is inferred to be TwoGen because

---

that is the type of its initializer. Also notice that the use of var results in a shorter
declaration than would be the case otherwise. In general, generic type names can often
be quite long and (in some cases) complicated. The use of var is another way to
substantially shorten such declarations. For the same reasons as just explained for the
diamond operator, the remaining examples in this book will continue to use the full
generic syntax, but in your own code the use of local variable type inference can be
quite helpful.
ERASURE
Usually, it is not necessary for the programmer to know the details about how the Java
compiler transforms your source code into object code. However, in the case of
generics, some general understanding of the process is important because it explains
why the generic features work as they do—and why their behavior is sometimes a bit
surprising. For this reason, a brief discussion of how generics are implemented in Java
is in order.
An important constraint that governed the way generics were added to Java was the
need for compatibility with previous versions of Java. Simply put: generic code had to
be compatible with preexisting, nongeneric code. Thus, any changes to the syntax of the
Java language, or to the JVM, had to avoid breaking older code. The way Java
implements generics while satisfying this constraint is through the use of erasure.
In general, here is how erasure works. When your Java code is compiled, all generic
type information is removed (erased). This means replacing type parameters with their
bound type, which is Object if no explicit bound is specified, and then applying the
appropriate casts (as determined by the type arguments) to maintain type compatibility
with the types specified by the type arguments. The compiler also enforces this type
compatibility. This approach to generics means that no type parameters exist at run
time. They are simply a source­code mechanism.
AMBIGUITY ERRORS
The inclusion of generics gives rise to a new type of error that you must guard against: