}
// Show type of ob.
void showType() {
System.out.println("Type of ob is " +
ob.getClass().getName());
}
}
// Demonstrate the non-generic class.
class NonGenDemo {
public static void main(String args[]) {
NonGen iOb;
// Create NonGen Object and store
// an Integer in it. Autoboxing still occurs.
iOb = new NonGen(88);
// Show the type of data used by iOb.
iOb.showType();
// Get the value of iOb.
// This time, a cast is necessary.
int v = (Integer) iOb.getob();
System.out.println("value: " + v);
System.out.println();
// Create another NonGen object and
// store a String in it.
NonGen strOb = new NonGen("Non-Generics Test");
// Show the type of data used by strOb.
strOb.showType();
// Get the value of strOb.
// Again, notice that a cast is necessary.
String str = (String) strOb.getob();
System.out.println("value: " + str);
// This compiles, but is conceptually wrong!
iOb = strOb;
v = (Integer) iOb.getob(); // run-time error!
}
}
There are several things of interest in this version. First, notice that NonGen replaces all
uses of T with Object. This makes NonGen able to store any type of object, as can the generic
version. However, it also prevents the Java compiler from having any real knowledge about
the type of data actually stored in NonGen, which is bad for two reasons. First, explicit casts
must be employed to retrieve the stored data. Second, many kinds of type mismatch errors
cannot be found until run time. Let's look closely at each problem.
Search WWH :
