View RSS Feed

Advanced Java

Dynamic Type Safety in Pre Java 5 Code Collections

Rate this Entry
by , 11-29-2011 at 11:40 PM (1260 Views)
Sometimes is might be necessary to pass generic containers to pre-Java5 code. In those cases, it is possible that the old-style code can corrupt your containers. In order to address this issue, there are a set of utilities in the java.util.Collections package to address the issues around type-checking. There are a number of static methods designed for this. They all take the container that you are checking as the first argument and the type you want to enforce as the second argument. They are shown below:
  • checkedCollection( )
  • checkedList( )
  • checkedMap( )
  • checkedSet( )
  • checkedSortedMap( )
  • checkedSortedSet( )


A ClassCastException exception will be thrown by a checked container at the point you try to insert an improper object. Note the difference with a raw container that will inform you of a problem when you try to pull an object out. I will show an example of this using apples and oranges and the oldStyleMethod() method which takes a raw List. The @SuppressWarnings(ďuncheckedĒ) annotation is used to suppress the resulting warning in this case.

the point you try to insert an improper object, as opposed to a pre-generic (raw) container which would inform you that there was a problem when you pulled the object out. In the latter case, you know thereís a problem but you donít know who the culprit is, but with checked containers you find out who tried to insert the bad object.
Letís look at the problem of "putting a cat in a list of dogs" using a checked container. Here, oldStyleMethod( ) represents legacy code because it takes a raw List, and the @SuppressWarnings("unchecked") annotation is necessary to suppress the resulting warning:

Java Code:
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class CheckedList {
	@SuppressWarnings("unchecked")
	static void oldStyleMethod(List probablyOranges) {
		probablyOranges.add(new Apple());
	}

	public static void main(String[] args) {
		List<Orange> oranges = new ArrayList<Orange>();
		oldStyleMethod(oranges);
		// This accepts apples
		List<Orange> oranges2 = Collections.checkedList(
				new ArrayList<Orange>(), Orange.class);
		try {
			oldStyleMethod(oranges2); // This throws an exception
		} catch (Exception e) {
			System.out.println(e);
		} // This works
		List<Fruit> fruits = 
			Collections.checkedList(new ArrayList<Fruit>(),
				Fruit.class);
		fruits.add(new Orange());
		fruits.add(new Apple());
	}
}

Running the program will show that an insertion of a Apple goes unchallenged by oranges1, but oranges2 immediately throws an exception when the incorrect type is inserted. Finally with this design itís fine to put objects subclassing Fruit into a checked container that is checking for the objects of type Fruit.

Submit "Dynamic Type Safety in Pre Java 5 Code Collections" to Facebook Submit "Dynamic Type Safety in Pre Java 5 Code Collections" to Digg Submit "Dynamic Type Safety in Pre Java 5 Code Collections" to del.icio.us Submit "Dynamic Type Safety in Pre Java 5 Code Collections" to StumbleUpon Submit "Dynamic Type Safety in Pre Java 5 Code Collections" to Google

Comments