Collections

To

summarize what we’ve seen so far, your first, most efficient choice to

hold a group of objects should be an array, and you’re forced into this

choice if you want to hold a group of primitives. In the remainder of the

chapter we’ll look at the more general case, when you don’t know at

the time you’re writing the program how many objects you’re going

to need, or if you need a more sophisticated way to store your objects. Java

provides four types of

Among

their other characteristics –

,

for example, implements a LIFO (last-in, first-out) sequence, and

is an

Disadvantage:
unknown type

The

“disadvantage” to using the Java collections is that you lose type

information when you put an object into a collection. This happens because,

when the collection was written, the programmer of that collection had no idea

what specific type you wanted to put in the collection, and making the

collection hold only your type would prevent it from being a general-purpose

tool. So instead, the collection holds handles to objects of type

,

which is of course every object in Java, since it’s the root of all the

classes. (Of course, this doesn’t include primitive types, since they

aren’t inherited from anything.) This is a great solution, except for

these reasons:

1. Since
   the type information is thrown away when you put an object handle into a
   collection,
   any
   type of object can be put into your collection, even if you mean it to hold
   only, say, cats. Someone could just as easily put a dog into the collection.
2. Since
   the type information is lost, the only thing the collection knows it holds is a
   handle to an
   Object.
   You must perform a cast
   to the correct type before you use it.

On

the up side, Java won’t let you

the objects that you put into a collection. If you throw a dog into a

collection of cats, then go through and try to treat everything in the

collection as a cat, you’ll get an exception when you get to the dog. In

the same vein, if you try to cast the dog handle that you pull out of the cat

collection into a cat, you’ll get an exception at run-time.

Here’s

an example:

//: CatsAndDogs.java
// Simple collection example (Vector)
import java.util.*;
 
class Cat {
  private int catNumber;
  Cat(int i) {
    catNumber = i;
  }
  void print() {
    System.out.println("Cat #" + catNumber);
  }
}
 
class Dog {
  private int dogNumber;
  Dog(int i) {
    dogNumber = i;
  }
  void print() {
    System.out.println("Dog #" + dogNumber);
  }
}
 
public class CatsAndDogs {
  public static void main(String[] args) {
    Vector cats = new Vector();
    for(int i = 0; i < 7; i++)
      cats.addElement(new Cat(i));
    // Not a problem to add a dog to cats:
    cats.addElement(new Dog(7));
    for(int i = 0; i < cats.size(); i++)
      ((Cat)cats.elementAt(i)).print();
    // Dog is detected only at run-time
  }
} ///:~ 

You

can see that using a

is straightforward: create one, put objects in using

The

classes

and

are distinct – they have nothing in common except that they are

s.

(If you don’t explicitly say what class you’re inheriting from, you

automatically inherit from

)

The

class, which comes from

,

holds

s,

so not only can you put

objects into this collection using the

method

,

but you can also add

objects without complaint at either compile-time or run-time. When you go to

fetch out what you think are

objects using the

method

,

you get back a handle to an

that you must cast to a

.

Then you need to surround the entire expression with parentheses to force the

evaluation of the cast before calling the

method for

,

otherwise you’ll get a syntax error. Then, at run-time, when you try to

cast the

object to a

,

you’ll get an exception.

This

is more than just an annoyance. It’s something that can create some

difficult-to-find bugs. If one part (or several parts) of a program inserts

objects into a collection, and you discover only in a separate part of the

program through an exception that a bad object was placed in the collection,

then you must find out where the bad insert occurred. You do this by code

inspection, which is about the worst debugging tool you have. On the upside,

it’s convenient to start with some standardized collection classes for

programming, despite the scarcity and awkwardness.

Sometimes
it works right anyway

It

turns out that in some cases things seem to work correctly without casting back

to your original type. The first case is quite special: the

class has some extra help from the compiler to make it work smoothly. Whenever

the compiler expects a

object and it hasn’t got one, it will automatically call the

Thus,

all you need to do to make objects of your class print out is to override the

method, as shown in the following example:

//: WorksAnyway.java
// In special cases, things just seem
// to work correctly.
import java.util.*;
 
class Mouse {
  private int mouseNumber;
  Mouse(int i) {
    mouseNumber = i;
  }
  // Magic method:
  public String toString() {
    return "This is Mouse #" + mouseNumber;
  }
  void print(String msg) {
    if(msg != null) System.out.println(msg);
    System.out.println(
      "Mouse number " + mouseNumber);
  }
}
 
class MouseTrap {
  static void caughtYa(Object m) {
    Mouse mouse = (Mouse)m; // Cast from Object
    mouse.print("Caught one!");
  }
}
 
public class WorksAnyway {
  public static void main(String[] args) {
    Vector mice = new Vector();
    for(int i = 0; i < 3; i++)
      mice.addElement(new Mouse(i));
    for(int i = 0; i < mice.size(); i++) {
      // No cast necessary, automatic call
      // to Object.toString():
      System.out.println(
        "Free mouse: " + mice.elementAt(i));
      MouseTrap.caughtYa(mice.elementAt(i));
    }
  }
} ///:~ 

You

can see the redefinition of

in

.

In the second

loop in

you find the statement:

After

the ‘

’

sign the compiler expects to see a

A

second approach to hiding the cast has been placed inside

.

The

method accepts not a

,

but an

which it then casts to a

.

This is quite presumptuous, of course, since by accepting an

anything could be passed to the method. However, if the cast is incorrect

– if you passed the wrong type – you’ll get an exception at

run-time. This is not as good as compile-time checking but it’s still

robust. Note that in the use of this method:

no

cast is necessary.

Making
a type-conscious Vector

You

might not want to give up on this issue just yet. A more ironclad solution is

to create a new class using the

,

such that it will accept only your type and produce only your type:

//: GopherVector.java
// A type-conscious Vector
import java.util.*;
 
class Gopher {
  private int gopherNumber;
  Gopher(int i) {
    gopherNumber = i;
  }
  void print(String msg) {
    if(msg != null) System.out.println(msg);
    System.out.println(
      "Gopher number " + gopherNumber);
  }
}
 
class GopherTrap {
  static void caughtYa(Gopher g) {
    g.print("Caught one!");
  }
}
 
class GopherVector {
  private Vector v = new Vector();
  public void addElement(Gopher m) {
    v.addElement(m);
  }
  public Gopher elementAt(int index) {
    return (Gopher)v.elementAt(index);
  }
  public int size() { return v.size(); }
  public static void main(String[] args) {
    GopherVector gophers = new GopherVector();
    for(int i = 0; i < 3; i++)
      gophers.addElement(new Gopher(i));
    for(int i = 0; i < gophers.size(); i++)
      GopherTrap.caughtYa(gophers.elementAt(i));
  }
} ///:~ 

This

is similar to the previous example, except that the new

class has a

member

of type

(inheriting from

tends to be frustrating, for reasons you’ll see later), and methods just

like

.

However, it doesn’t accept and produce generic

s,

only

objects.

Because

a

will accept only a

,

if you were to say:

you

would get an error message

.

This approach, while more tedious from a coding standpoint, will tell you

immediately if you’re using a type improperly.

Note

that no cast is necessary when using

– it’s always a

.

Parameterized
types

This

kind of problem isn’t isolated – there are numerous cases in which

you need to create new types based on other types, and in which it is useful to

have specific type information at compile-time. This is the concept of a

|

|