Diagnosing Java code: Easily mastering Java generics

J2SE 1.5-code-named Tiger-is scheduled for release at the end of 2003. I've always been interested in collecting as much information about upcoming new technologies as possible, so I'm going to write a series of articles about the new and restructured features available from V1.5, the first of these. I particularly want to talk about generic types and focus on the changes and adjustments that are made in Tiger to support them.

In many ways, Tiger is certainly the greatest improvement in Java programming to date, including a significant expansion of the source language syntax. The most notable change planned in Tiger is the addition of generic types, as shown in advance in the JSR-14 prototype compiler (you can download the compiler for free immediately; see resources).

Let's start by describing what generic types are and what features are added to support them.

Data type conversions and errors

To understand why generic types are so useful, we need to turn our attention to one of the most error-prone elements in the Java language-the need to constantly convert expression down type (downcast) to a more specific data type than its static type (see Resources for "the Double Descent bug pattern "to understand some aspects of the trouble you might encounter when converting data types."

Every downward-type conversion in a program is a potential hazard for classcastexception and should be avoided as much as possible. But they are often unavoidable in the Java language, even in well-designed programs.

The most common reason for downcast type conversions in the Java language is that classes are often used in a private way, which limits the possible run-time types of parameters returned by a method call. For example, suppose you add an element to the Hashtable and retrieve it from it. In a given program, the element type used as a key and the type of value stored in the hash table cannot be any object. Typically, all keys are instances of a particular type. Similarly, stored values will have common types that are more specific than Object.

However, in the current version of the Java language, it is not possible to declare specific keys and elements of a hash table to be more specific than Object type. The type signature that performs the insert and retrieve operations on the hash tells us that you can only insert and delete any object. For example, the description of the put and get operations looks like this:

Listing 1. The Insert/Retrieve type description indicates that it can only be any object

class Hashtable {
　 Object put(Object key, Object value) {...}
　 Object get(Object key) {...}
　 ...
}

So when we retrieve elements from instances of class Hashtable, for example, even if we know that only String is placed in Hashtable, the type system only knows that the retrieved value is of type Object. Before any string-specific action is made on the retrieved value, it must be cast to string, even if the retrieved element is added to the same block of code!

Listing 2. Cast a retrieved value to a String

import java.util.Hashtable;
class Test {
　 public static void main(String[] args) {
　　 Hashtable h = new Hashtable();
　　 h.put(new Integer(0), "value");
　　 String s = (String)h.get(new Integer(0));
　　 System.out.println(s);
　 }
}

Note The data type conversions that are required in the third row of the Main method body section. Because the Java type system is fairly weak, the code is riddled with data type conversions like the above. These data type conversions not only make Java code more verbose, but they also reduce the value of static type checking (since each data type conversion is a pseudo directive that chooses to ignore static type checking). How do we extend the type system so that we don't have to avoid it?