Bounded Wildcards: Java Generics

Imagine that you have a class that looks like this:

class Handler {
  private List list;

  public Handler(List list) {
    this.list = list;
  }

  public void add(Object o) {
    list.add(o);
  }

  public void handle() {
    for (int i = 0; i < list.size(); i++) {
      Shape s = (Shape) list.get(i);
      /*..*/
    }
  }
}

This is about as un-type-safe as you can get. You can call add with any type at all. And yet, if you look at the handle method it's easy to see that we are really expecting to be dealing with Shape instances. Of course we can fix this by adding a little bit of type safety to the add method as follows:

  public void add(Shape s) {
    list.add(s);
  }

However, since the list is passed as an argument into the constructor, it might have been loaded with things that weren't Shapes prior to construction. What we really want is a way to insist that the list contain shapes, and nothing but shapes. We can do this by adding generics as follows:

class Handler {
  private List<Shape> list;

  public Handler(List<Shape> list) {
    this.list = list;
  }

  public void add(Shape s) {
    list.add(s);
  }

  public void handle() {
    for (Shape s : list) {
      /*..*/
    }
  }
}

Now Handler can only take lists of Shapes. (Note the new iteration syntax too.)

This works OK until someone wants to pass a list of Squares into the handler as in the following:

  public void handleSquares() {
    List<Square> ls = new ArrayList<Square>();
    /* get a bunch of squares */
    Handler h = new Handler(ls); // <---Error
    h.handle();
  }

The compiler complains that you cannot pass a List<Square> to an argument that expects a List<Shape>. Remember from my previous blog that lists of derivatives are not derivatives of lists of bases. That previous blog also told us how to solve this by using the <? extends Shape> syntax, as shown below:

class Handler {
  private List<? extends Shape> list; //......... <--- Modified

  public Handler(List<? extends Shape> list) { // <--- Modified
    this.list = list;
  }

  public void add(Shape s) {
    list.add(s); //.............................. <--- Error!!
  }

  public void handle() {
    for (Shape s : list) {
      /*..*/
    }
  }
}

This resolves the previous error, but at the expense of a new one. The call to add won't compile because you can't add a known type into a list that holds an unknown type. Somehow, when we are adding, we have to be dealing with a known type. We can do that by using the <? super Shape> syntax as follows:

class Handler {
  private List<? super Shape> list; //............ <--- Modified

  public Handler(List<? extends Shape> list) {
    this.list = list;
  }

  public void add(Shape s) {
    list.add(s);
  }

  public void handle() {
    for (int i = 0; i < list.size(); i++) { //.....<--- Modified
      Shape shape = (Shape) list.get(i);
      /*...*/
    }
  }
}

You may not have seen this syntax before. It's a little difficult to understand at first. A List<? super Shape> is a list into which you may add Shapes. Another way to think of this is that the type <? super T> is an unknown type that T can substitute for. You may have to read that several times before you understand it. I certainly did. So here's yet another way to think about it. The type <? super T> is a type that T is derived from. It is a base class of T. Clearly if D is derived from B then you can put D instances into a List<B>. Likewise, since T derives from <? super T>, you can put T instances into a List<? super T>. Follow? No? Neither did I for awhile. It takes a bit of getting used to.

One more thing to get used to is the assignment this.list = list. Can you reliably assign a List<? extends T> to a List<? super T>? The compiler says you can. It also makes a certain amount of sense. After all if I have a list of things derived from Shape (e.g. List<? extends Shape>) then that is substitutable for a list of some base type that Shape derives from (e.g. List<? super Shape>). In other words List<? super Shape> is more generic than List<? extends Shape>. In some very strange sense List<? extends Shape> is a subtype of List<? super Shape>.

One last factoid: A List<Shape> can be passed to both List<? extends Shape> and List<? super Shape>.

Unfortunately, by weakining the type of the list instance variable; we had to put the cast back into the handle method. That's a shame. But there are worse problems.

Our original intent was to pass in a List<Square> to the Handler. We've done this, and it works. But now there is nothing to stop us from adding a Circle instance to the Handler.

  public void handleSquares() {
    List<Square> ls = new ArrayList<Square>();
    /* get a bunch of squares */
    Handler h = new Handler(ls);
    h.add(new Circle());// .............<--- THIS IS TERRIBLE!!!!!
    h.handle();
  }

This is no good. We need a way to make sure that if we pass a List<Square> to the handler, then nothing but Squares can be added to the Handler. Luckily the new language features allow us to create generics of our own. This is really simple to do.

class Handler<T> { //.....................<-- A new generic.
  private List<? super T> list;

  public Handler(List<? extends T> list) {
    this.list = list;
  }

  public void add(T t) {
    list.add(t);
  }

  public void handle() {
    for (int i = 0; i < list.size(); i++) {
      Shape s = (Shape) list.get(i);
      /*...*/
    }
  }
}

This class can be used as follows:

  public void handleSquares() {
    List<Square> ls = new ArrayList<Square>();
    /* get a bunch of squares */
    Handler<Square> h = new Handler<Square>(ls); //....<<--- Cool!
    h.handle();
  }

This compiles, and solves the problem. We can not add Circle instances to a Handler<Square>. But there is a significant problem. The handle method expects Shape instances. But nothing else enforces that. For example, there is nothing to stop us from creating a Handler<Dog>, where Dog does not derive from Shape.

We can resolve this by constraining the type argument of Handler to be a derivative of Shape as follows:

class Handler<T extends Shape> {

This prevents Handler<Dog> from being created. Whatever T is, it must derive from Shape.

Now let's get rid of that ugly loop. I want to be able to use the new typesafe looping syntax. Consider the following:

class Handler<T extends Shape> {
  private List<? super T> inlist;
  private List<? extends Shape> outlist;  //...<--- Two list references.

  public Handler(List<? extends T> list) {
    inlist = outlist = list; //................<--- Both list variables refer to the same list.
  }

  public void add(T t) {
    inlist.add(t);
  }

  public void handle() {
    for (Shape s : outlist) { //...............<--- Just what we wanted.
      /*...*/
    }
  }
}

This solution is ironic. C++ templates did not have bounded wildcards. There was no way to pass a List<Square> to a List<Shape>. One common technique in C++ was to create one list for each derivative. So we'd have a List<Square> and a List<Circle> and keep all the subtypes seperate. Using Bounded Wildcards in Java we can keep the objects in the same list; but we may want to have two different list variables, one for adding, and one for getting. Both variables refer to the same list. Isn't that wierd?

---