Diagnosing Java code: Easily mastering Java Generic types, part 2nd

J2SE 1.5―, code-named Tiger, is scheduled to be released by the end of 2003 and will include generic types (as shown in advance in the JSR-14 prototype compiler, which is now available for download). In part 1th, we discussed the basics of generic types and why they are an important and urgently needed complement to the Java language. We also explained how the implementation of a generic type for Tiger would contain several "bugs" that limit the context in which a generic type can be used.

To help new programmers effectively use generic types, I'll explain in detail which usages of the generic type are prohibited in Tiger and JSR-14, and will explain why these restrictions are JSR-14 (and, of course, Tiger) in order to The inevitable result of implementing policies that are used by a generic type on a compatible way.

Limitations of generic types

Let's look at the usage restrictions for generic types in Tiger and JSR-14:

Enclosing type parameters should not be referenced in static members.

You cannot instantiate a generic type parameter with a base type.

You cannot use an "exposed" type parameter in a data type conversion or instanceof operation.

The "exposed" type parameter cannot be used in the new operation.

You cannot use an "exposed" type parameter in a implements or extends clause of a class definition.

Why is there such a limit? This is due to the mechanism used by Tiger and JSR-14 to implement generic types on the JVM. Because the JVM does not support generic types at all, so these compilers "play tricks" that seem to have support for generic types--they examine all code with generic type information, but then "erase" all generic types and generate class files that contain only ordinary types.

For example, you would erase a generic type like list<t> with only a List. An "exposed" type parameter-a type parameter (such as a type parameter T in a class list<t>) that appears separately rather than in a type-is simply erased to their upper bounds (in the case of T, the upper bound is Object).

This technology is extremely powerful: we can increase the precision of almost any generic type, but remain compatible with the JVM. In fact, we can even alternately use old, non-generic classes (such as List) and their corresponding generic classes (list<t>), which look the same at runtime.

Unfortunately, as the above restrictions show, there is a cost to getting this functionality. Erasing in this manner introduces defects in the type system that limit our use of the security of the generic type.

To help illustrate each limitation, we look up an example of these limitations. In this article, we'll discuss the first three limitations. The problems associated with the latter two constraints are too complex to be considered and need to be studied in more depth for the next article.

Enclosing type parameters in static members

The compiler completely prohibits referencing enclosing type parameters in static methods and static inner classes. So, for example, the following code is illegal in Tiger:

Listing 1. Illegal reference of enclosing type parameters in a static context

class C<T> {
　 static void m() {
　　 T t;
　 }
　 static class D {
　　 C<T> t;
　 }
}