Introduction

All the Java Collection classes, e.g. HashMap, ArrayList, TreeList can contain only generic Objects. The problem with this is you must keep track manually what sorts of object are really in each Collection. The compiler won’t warn you if you add a Cat to a Collection of Dogs.

Without genericity, in Java, you must, at run time, cast objects on the way into a Collection to make sure they are the right type, and cast them back again on the way out before you can use their methods. It is totally up to you as application programmer to enforce your rules about what sort of objects you want in each Collection. You can’t simply declare that a Collection will contain only Dog objects, and have attempts put anything else in flagged at compile time.

Java 1.5 has generics implemented with high overhead, requiring implicit casts both on the way into the collection and on the way out. The compiler automatically casts all objects going into your collection to Dog, and will automatically cast them back to Dog on the way out. Inside the collection, they are treated as generic Objects.

In theory, neither of these two time consuming casts are necessary. However, removing them would create a vulnerability in the JVM that could be exploited maliciously. The saving grace of the design in that Sun did not need to change the JVM or class file structure to implement it.

You can try out the JDK 1.5+ compiler with generics.

Why The New Syntax?

Further, types passed to a static method define the types of the parameters in the call, something quite different from passing a class as a parameter, which could only have an effect once the call had been made. e.g.

The Ugly

• The syntax for generics is butt ugly. Here is a class that has two replaceable types D and C. D must implement both Comparable, and Serializable.
  & is used where you would expect to use comma. extends is used where you would expect to use implements. < > is used where you would expect to use ( ). I can hardly believe Sun chose such disgusting inconsistent syntax. But that’s what we are stuck with.
• To avoid creating new keywords, generics recycles extends, super and & with meanings quite unrelated to the original meanings.
• Generics are fundamentally incompatible with arrays. You cannot allocate a generically typed array e.g.

  // You MAY NOT write code like this:
  
  HashMap<String,Integer>[] hs = new HashMap<String,Integer>[1000];

  This is nuts since all the Collection classes fundamentally depend on internally typed arrays. You can’t write code that involves arrays and generics without generating (or suppressing) unchecked conversion warnings. The excuse Sun gives is this goofiness is necessary because of type erasure — that all generic type information is checked then discarded at compile time. The excuse they give for type erasure was they wanted to make code with generics usable by older Java object code that knew nothing of genericity. You can’t actually do this, so the benefit was never realised.

  To understand why type erasure forced this monstrous kludge, read up on ArrayStoreException. Even without generics, Java cannot tell purely at compile time when inserting a given Object into an array is legal. Since the type erasure means there is no generic information around at run time, Java cannot enforce generic type safety when Objects are stored in arrays.

  I think the real reason they did it was political. They did not want to force the licenced vendors to make major changes to their JVMs. To kludge around the problem, look at how Sun implemented ArrayList.

• Again because of type erasure, Java cannot enforce generic type information in casts at run time. Happily casts are rarely required when working with generics.

How To Use Generics

javac.exe -source 1.5 -target 1.5 *.java

To create an ArrayList that can only hold Dog Objects. If you attempt to put anything else in there, (except subclasses like Dalmatians), you will find out at compile time. This is a great improvement on the old days when you sometimes found out about your errors when you partly exercised the code at run time.

// this il not legal
java.util.Vector<Dog> dogs = new java.util.Vector<Dalmatian>();

Comparator/Comparable

Iterator

Generics and Static Methods

Generics and Static Factories

// naive and unsuccessful attempt to create a new object of generic type T
T thing = new T();

// What that code compiles to at run time:
Object thing = new Object();

Static Inference

// How the sort method is defined in Collections.sort
// Quite a bit more complex that using it, eh?
public static
  <T extends Comparable<? super T>>
  void sort( List<T> list )

You would expect to invoke it then with:

// Short form of sort invocation
// relying on compiler static type inference
Collections.sort( listOfDogs );

So when is Java smart enough to figure out the types on its own via inferring? It sometimes feels as if it depends on the phases of the moon. Inferring has even the cleverest programmers scratching their heads. Nobody can figure out for certain why sometimes the compiler can infer the generic types and sometimes it cannot. So what can you do?

If you have Eclipse, you can rapidly experiment, removing the explicit types one by one and putting them back if Eclipse complains. If you don’t have Eclipse, you can do the same thing more slowly with a compile cycle.

The problem with removing type tags is if you remove one too many tags, you are flying without a net. You have effectively turned off type checking. It is difficult to tell the difference between allowing inference to check types and turning off type checking altogether. This is a serious flaw in the design of Java generics.

Generic type tags are useful documentation to let others know what your code is up to. That is an argument for leaving them in.

If you burn the generic types into your code in 100 places, it will be hard to modify later if you change that type. Ideally you should specify the type of a variable in only one place — where it is declared. That is an argument for removing the type tags wherever you can.

Generics and Serialised Objects

// generates type mismatch error
ArrayList<Thing> things = ois.readObject();

// generates cast warning
ArrayList<Thing>things = (ArrayList<Thing>)ois.readObject();

// suppress unchecked warning
@SuppressWarnings( "unchecked" )
void restore()
   {
   // Java cannot check that the object is actually an ArrayList<Thing>.
   // It will just trust that it is.
   ArrayList<Thing> things = (ArrayList<Thing>) ois.readObject();
   ...
   }

// copy with a temporary array, generates no warning
final ArrayList<Thing> things = new ArrayList<Thing>( INITIAL_SIZE );
...
final ArrayList<Object> temp = (ArrayList<Object>)ois.readObject();
things.clear();
for ( Object item : temp )
   {
   things.add( (Thing)item );
   }

Syntactic Soup: <?> vs <Dog> vs <? extends Dog> vs <E extends Dog> vs <? super T>

ArrayList<Dog> is a collection permitted to contain Dogs or any subclass of Dog. An ArrayList< Dog> that incidentally contained only Dalmatians is a quite different beast from an ArrayList<Dalmatian> which can’t contain anything but Dalmatians (or their subclasses).

Collection<Object> is a heterogenous Collection, while Collection<?> is a homogenous Collection of elements of the same unknown type, e.g. Dog and its subclasses.

Consider the wildcard form of a type specification:

• Collection<Dog> potentially contains both Dog and Dalmatian objects. Collection<Dog> matches both types of specifier.
• Collection<Dalmatian>, on the other paw, may not contain any Dog objects, other than Dalmatians. Collection< Dalmatian> matches the wildcard [Collection <? extends T >] but not the simple form [ Collection < T >].

The wildcard form restricts our ability to put raw Dog objects into the Collection, but on the other hand it lets us deal with Collection< Dalmatian>, where we could not otherwise.

You will need to read Sun’s tutorial many times. It is as subtle as a Buddhist sutra. It makes me wonder if generics were a big mistake, introducing something so very difficult to solve a simple problem. Angelika Langer’s Generics FAQ is somewhat more accessible. Just keep reading and experimenting and more and more of what you read will make sense little by little. Unfortunately, I find the understanding does not stick and you have to keep going back to the well to have it continue to make sense.

Here is a complex example. If you understand this, you will be well on your way to understanding the fine points:

public static
<D extends Dog & Comparable<? super D>>
D selectSuitableDog( Collection<? extends D> );

This static method above is designed to be used with class D that has the following properties:

• It must either be a Dog or a subclass of Dog
• D must implement Comparable on two Dog objects, or on two superclass of Dog objects such as Object. A Comparable for two Dalmatians will not do.

You must pass a Collection to the method where the Collection contains Dog objects (where the Dog objects may be subclasses of Dog), or a more limited Collection of some subclass of Dog objects, e.g. a Collection<Dalmatian> of pure Dalmatian objects. Note that a Collection< Dog> where all elements happen to be Dalmatian is quite a different animal from a Collection< Dalmatian>where all elements are coerced to be Dalmatians (or subsets of Dalmatian).

Compared with the gobbledegook to define the method, your call to the method is very simple:

Under the Hood

Tips

• My usual tactic to solve difficult generics problems is to scan the code in src.zip for source code similar to what I am trying to do, then puzzle why the Sun code works, then copy the technique. Sometimes you discover there is no solution that does not generate a warning message.

Learning More