Generics, also known as templates or parametric polymorphism, seem to be a popular feature in modern programming languages. Ada has them, so does C++, and so does Microsoft's copy of Java, C#. The overall design for Java generics was published in 1998, long before C# was launched. C# is again following Java's lead and adopting generics, although with a different design. The popularity might lead you to think that generics solve a big and important problem.
If you look at some of the written material justifying generics in Java, however, a different picture emerges. Some texts suggest that a purpose of generics is to reduce the amount of casting needed, particularly when using the Java data structure classes known as the collection classes. From JDK 1.2 (where collections were introduced) up to and including JDK 1.4, collections held Objects. Variables of any class type could be put into any collection, because all class types are compatible with the type used in a collection, Object. When you retrieved something from a collection, you had to figure out what type it really was, then cast it back to that.
The Java Collection classes
JDK 1.2 introduced some really robust data structure container classes. There are about 20 classes and a dozen interfaces kept in the package java.util.
These classes are termed the collection classes, and they do some amazing things. They maintain standard data structures, such as lists, sets, and maps (pairing of a key and value) and several subtypes of these. You can create a data structure that holds your own objects merely by instantiating one of these types.
The collection classes were updated to work with generic types in the JDK 1.5 release. Generics can work with all software libraries, not just the collection classes, but the collection classes are the main beneficiaries within the Java API. The chapter on collection classes comes right after this chapter and gives practical examples of generic use.
Usually, your collections just hold one kind of type, e.g. a given collection of yours holds String objects. A different collection holds Timestamps. A typical collection does not hold a mixed bag of String, Integer, Date, Thread, JFrame, and Timestamp objects. So figuring out what's in the collection isn't a problem. And casting something back to the right class isn't a big deal either:
String result = (String) myDict.get(i); // without generics
Using generics, the collection gives you back the right type, i.e. String, not Object. You can thus omit the cast, and that statement becomes:
String result = myDict.get(i); // with generics
Yippee! The casts aren't written in the source, but they don't vanish altogether. They are still there in the generated code. It's like autoboxing; the compiler will insert the required code for you. So what's the reason behind this apparent paradox: lots of people want generics, but all generics seem to do is save you writing a few casts?
The answer is that analyzing generics in terms of saving casts misses the big picture. The real purpose of generics is to improve type safety by moving the detection of errors earlier in the development cycle. The value of Java generics is quite a bit less than a cure for software bit-rot, but more than just a confusing new syntax to avoid a few casts.
Imagine that you have a collection class that does something with objects of some other type: It keeps a pool of them, stores them in a stack, or holds them in sorted order, for example. One instance of your class can do this magical processing on type A, another instance on type B, a third on C, and so on. Previously, you were not able to make this distinction. You had to code “all instances of that collection class process the type Object” and then keep clear in your head which of your instances dealt with type A objects, which with B, which with type C, etc.
Generics let you explicitly tell the compiler which specific type each instance of your class processes. The compiler will look at the generic information where you say “I intend this object to process only type A objects”, and it will make sure that you don't slip a few B's in.
What used to happen was that you thought you had a collection of say, Strings. But some buggy code occasionally put an Integer in there too. Everything was held as an Object so the compiler couldn't catch it. When you retrieved the Integer at run-time and tried to cast it back to a String, it would throw a class cast exception. This error could be rare enough that it wouldn't happen until after a long time after the application was deployed.
With generics the compiler has enough information to notice when you try to slip an Integer into a collection of Strings. Errors are reported at compile time, when it is much cheaper to fix problems. Remember you probably need an option on the command line to compile code with these new features:
javac -source 1.5 myGenerics.java
Let's look at the three steps involved in conveying the extra information to the compiler.