Re: Java type-casting -- Q3
And I also now start to suspect that "generics" is
kind of a "poor man's solution to polymorphism"
I mentioned this in a previous post, but maybe you missed it.
Generics in Java are *not* polymorphic. They aren't designed to be.
Yes, they are.
It's important to note that the OP does not mean the same kind of polymorphism
that you do here. He means "type-polymorphism" and we mean
"object-polymorphism". The former is what we mean by "parameterized types".
The latter is "polymorphism" in the sense that Grady Booch defined in his
seminal works on object-oriented programming.
They're something else. Arguably, generics are better than
polymorphism, because they prevent you from doing broken things with
types. But I don't think most folks have adjusted their thinking in
that direction yet.
Generics are not a substitute for (object-) polymorphism, so it's meaningless
to say they're "better" than (object-) polymorphism. (Unless the context
changes, I'll just say "polymorphism" for the object-oriented one now.)
That's like saying "static access is better than methods". You are correct
that generics can lock out broken things with types, but they don't stop the
programmer from doing broken things with types through the abuse of generics.
Generics in Java are a kind of type calculus. They embody a set of
declarations and constraints about type relationships in a program, so that
the programmer can prove at compile time that certain type relationships and
constraints will pertain at run time without fear of ClassCastExceptions and
the like. In a way they're like compile-time assertions, only about types
rather than program state.
There are definitely subtype relationships one can express in generics,
through the use of bounded wildcards.
Note further that there is nothing in the use of generics that eliminates the
need for or value of polymorphism, and actually generics are a part of the
Consider the 'Comparable<T>' interface. An implementing class such as
'String' polymorphically (in both senses) invokes its 'compareTo(T o )' method
as 'compareTo( String o )' (before erasure). Object polymorphism ensures
dispatch to the 'String#compareTo' method, and type polymorphism ensures that
the argument is a 'String'.
For a deeper example, that is, more deeply polymorphic, consider the hierarchy
from 'java.util.Stack<E>' on up to 'java.util.AbstractList<E>' and beyond,
including to 'java.util.List<E>'. You can declare a variable
Vector <Foo> foos = new Stack <Foo> ();
If you call 'foos.firstElement()' you will polymorphically (in both senses)
call 'Stack<E>#firstElement()' and if it isn't 'null', obtain an instance of
To show that generics are object-polymorphic:
public class Quisp <E extends Comparable<? super E>>
Vector <E> stuff = new Stack <E> ();
// constructors, initialization, populate stuff
public E findLessThan( E query )
for( Enumeration <E> nume = stuff.elements();
E compar = nume.nextElement();
if ( compar.compareTo( query ) < 0 )
Here we see an example of object-polymorphism on the parameterized type 'E'.