When generics were introduced to Java in JDK 5, many developers reacted with ambivalent feelings. While introducing generic types to the language seemed at first to solve many lacks in Java's type system, the way generified code appeared caused developers to think that generics were not a well-designed addition to Java.

Since JDK 5, many libraries and APIs have been generified, allowing developers to have first-hand experience with Java generics. One of the more interesting aspects of that experience is illustrated in Brian Goetz's latest IBM developerWorks article, Going Wild With Generics:

Bounded wildcards are extremely useful in making generic APIs more flexible. The biggest impediment to using bounded wildcards correctly is the perception that we don't need to use them! Some situations will call for lower-bounded wildcards, and some for upper-bounded ones...

It turns out some libraries did not at first specify wildcards correctly, making generified versions of those APIs hard to use. The main issue had to do with the fact that Java generics are not covariant, unlike arrays, for instance. Thus, while an array of Integers is also an array of Numbers, a generified List of Integers is not also a List of Numbers, even though Integer is a subtype of Number. Goetz explains this issue in the article:

People can argue over which choice was "right" and which was "wrong"—of course, both have pros and cons—but there is no question that having two similar mechanisms for constructing derived types with subtly different semantics is a substantial source of confusion and mistakes... Bounded wildcards (those funny "? extends T" generic type specifiers) are one of the tools the language provides for dealing with the lack of covariance—they let classes declare when method arguments or return values are covariant (or the opposite, contravariant).

The rest of Goetz's article describes how to use wildcards correctly, including how to specify upper and lower bounds for generic method parameters:

Things get ... complicated ... when we want the API to deal not only in variables of type T, but in types generified over T... Let's say we want to add a new method to [a] Box that allows us to fetch the contents from another Box and put it in this one:

public interface Box<T> {
    public T get();
    public void put(T element);
    public void put(Box<T> box);
}

The problem with this extended Box is that we can only put the contents in a Box whose type parameter is exactly the same as the receiving box... So, for example, the code [below] won't compile:

Box<Number> nBox = new BoxImpl<Number>();
Box<Integer> iBox = new BoxImpl<Integer>();
nBox.put(iBox);

Goetz notes that in order to solve this problem, you can specify upper and lower bounds for the generic type parameter:

public interface Box<T> {
    public T get();
    public void put(T element);
    public void put(Box<? extends T> box);
}

However, this sort of notation can get unwieldy in certain situation, notes Goetz:

In Java 6, this signature [in java.util.concurrent.AbstractExecutorService] was changed to Collection<? extends Callable<T>> — but to illustrate how easy it is to make this mistake, the correct fix would have been to make invokeAll() take an argument of Collection<? extends Callable<? extends T>>. The latter is definitely uglier but has the benefit of not boxing in your clients...

In addition to upper bounds, it is also possible to specify a lower bound for a generic type parameter, and Goetz provides some rules about defining such limits.

What do you think of generics in Java? To what extent do you use generic type parameters when you define your own APIs?

void foo(List<Object> input)
{
  List<String> strings = (List<String>)(List)input;
 
  for (String s : strings) {  // CCE here, I think
     // do stuff with s
  }  
}