Java Generics for Dummies

Generics for Dummies
...or how to shoot an elephant
from five feet, and miss!
Knut Mork – 22.2.2005

"The increase in complexity is increasing,
in part because of the natural, inevitable trend of technology
to put together ever-more powerful solutions
to problems we never realized we had.”
Donald Norman

Traditional example
List myIntList = new ArrayList();
myIntList.add(new Integer(0));
Integer x = (Integer) myIntList.iterator().next();
Same example using generics
List<Integer> myIntList = new ArrayList<Integer>();
myIntList.add(new Integer(0));
Integer x = myIntList.iterator().next();

Excerpt from java.util:
public interface List<E> {
void add(E x);
Iterator<E> iterator();
}
public interface Iterator<E> {
E next();
boolean hasNext();
}

• What ?
– To abstract over types
• Why ?
– Safer code, eliminate run-time checks
– Strong typing (not loose info)
– Remove (visible) down-casting
– Reduce awful, but necessary javadoc comments
– Increase the indend of your code/interface
– Others ?
• Where ?
– Collections, reflection (but problems with impl), others ?
• When ?
– Introduced in Java 1.5

No more casting ?
Basket<Fruit> basket = new Basket<Fruit>();
basket.addElement(new Apple());
Apple apple = (Apple) basket.pickElement();

“Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.”
Martin Fowler

Real example from java.util.Collections:
public static <T extends Object &
Comparable<? super T>> max(Collection<? extends T> coll)
public static Object max(Collection coll) JDK 1.5
JDK 1.4

Example - subtyping
List<String> ls = new ArrayList<String>();
List<Object> lo = ls;
lo.add(new Object());
String s = ls.get(0);

Example - subtyping
List<String> ls = new ArrayList<String>();
List<Object> lo = ls; // compile-time error
lo.add(new Object());
String s = ls.get(0);

Traditional example2
void printCollection(Collection c) {
Iterator i = c.iterator();
for(k = 0; k < c.size(); k++) {
System.out.println(i.next());
}
}
Same example2 using generics
void printCollection(Collection<Object> c) {
for(Object e : c) {
System.out.println(e);
}
}

Traditional example2
void printCollection(Collection c) {
Iterator i = c.iterator();
for(k = 0; k < c.size(); k++) {
System.out.println(i.next());
}
}
Same example2 using generics
void printCollection(Collection<?> c) {
for(Object e : c) {
System.out.println(e);
}
}

But, on the other hand...
Collection<?> c = new ArrayList<String>();
c.add(new Object()); // compile-time error

It gets worse...
”The single biggest enemy of reliability
(and perhaps software quality in general)
is complexity.”
Bertrand Meyer

Bounded Wildcards
public void eatAll (List<Fruit> fruites) {
for (Fruit f: fruites) {
f.eat(this);
}
}
public void eatAll(List<? extends Fruit> fruites) {
...
}

Bounded Wildcards
public void addBanana(List<? extends Fruit> fruites) {
fruites.add(0, new Banana());
}

Bounded Wildcards
public void addBanana(List<? extends Fruit> fruites) {
fruites.add(0, new Banana()); // compile-time error
}

...a lot worse...
"Once a satisfactory product has been achieved,
further change may be counterproductive,
especially if the product is successful.
You have to know when to stop.”
Donald Norman

Example 3
static void fromArrayToCollection(Object[] a, Collection c) {
for (Object o : a) {
c.add(o);
}
}

Example 3
c.add(o);
}
}
Generic version:
static void fromArrayToCollection(Object[] a, Collection<?> c) {
c.add(o);
}
}

Example 3
c.add(o);
}
}
Generic version:
static void fromArrayToCollection(Object[] a, Collection<?> c) {
c.add(o); // compile-time error
}
}

Example 3
c.add(o);
}
}
Generic working version:
static <T> void fromArrayToCollection(T[] a, Collection<T> c) {
for (T o : a) {
c.add(o);
}
}

”Under the hood”
”When simple things need instruction,
it is a certain sign of poor design.”
Donald Norman

List <String> l1 = new ArrayList<String>();
List<Integer> l2 = new ArrayList<Integer>();
System.out.println(l1.getClass() == l2.getClass());
Output result ?

Collection cs = new ArrayList<String>();
if(cs instanceof Collection<String>) {...}
Output result ?

Legacy code interoperability
"You must not give the world what it asks for,
but what it needs.”
Edsger Dijkstra

Using legacy code in 1.5
List fruitList1 = new ArrayList<Fruit>();
fruitList1.add(new Apple()); // warning
List fruitList2 = new ArrayList();
fruitList2 = juggle(fruitList2); // warning
List<Fruit> fruitList3 = new ArrayList<Fruit>();
fruitList3 = eat(fruitList3); // warning
public List eat(List fruits) {...}
public List<Fruit> juggle(List<Fruit> fruits) {...}

Using legacy code in 1.5
public String loophole(Integer x) {
List<String> ys = new ArrayList<String>();
List xs = ys;
xs.add(x); // compile-time unchecked warning
return ys.iterator().next();
}

Example of warnings given:
Unsafe type operation:
Should not assign expression of raw type List to type List<Foo>.
References to generic type List<E> should be parameterized.
Unsafe type operation:
The method bar(List<Foo>) in the type SimpleExample should not
be applied for the arguments (List). References to generic types
should be parameterized.

...and even worse...
"Once a satisfactory product has been achieved,
further change may be counterproductive,
especially if the product is successful.
You have to know when to stop.”
Donald Norman

• A type parameter cannot be referenced in a static context
• Runtime type check with instanceof and casting on generic types have no meaning
• Arrays of generic types are not permitted
• For overloading, it is not enough to use wildcards for formal parameter types
• Generic classes can be extended
– The subclass provides the actual type parameters for the superclass
• For overriding, the return type of the method in the subclass can now be identical or
a subtype of the return type of the method in the superclass
• A generic class cannot be a subclass of Throwable
• Type parameters are allowed in the throws clause, but not for the parameter of the
catch block
• Varargs with a parameterized type are not legal

Introduction of characters with new special meaning
<, > ? T, E, ...
super &
”Programs must be written for people to read,
and only incidentally for machines to execute.”
Abelson and Sussman

Which ones will compile ?
a) Basket b = new Basket();
b) Basket b1 = new Basket<Fruit>();
c) Basket<Fruit> b2 = new Basket<Fruit>();
d) Basket<Apple> b3 = new Basket<Fruit>();
e) Basket<Fruit> b4 = new Basket<Apple>();
f) Basket<?> b5 = new Basket<Apple>();
g) Basket<Apple> b6 = new Basket<?>();

Thoughts and comments
Anyone ?
Is this a good thing or not ?
Is it an important feature of the language ?
What if this was included in the first version ?
Would the design be different/easier ?
Would users use it differently ?
When should we use it ? If we should, that is!
Why can’t we find other good examples, but the collection ones ?

Still interested ?
• Intro paper:
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
• Angelika’s F.A.Q.
http://www.langer.camelot.de/GenericsFAQ/JavaGenericsFAQ.html

”There are two ways of constructing a software design:
One way is to make it so simple
that there are obviously no deficiencies,
and the other way is to make it so complicated
that there are no obvious deficiencies.
The first method is far more difficult.”
C. A. R. Hoare

Java Generics for Dummies

More Related Content

What's hot (19)

Viewers also liked (12)

Similar to Java Generics for Dummies (20)

Recently uploaded (20)

Java Generics for Dummies

Editor's Notes