Many parameterized modules require specification of additional semantic constraints or signature constraints on a generic parameter. The former corresponds to the expectations on the services provided by the actual argument and the latter on the requirements on the interfaces supported by the actual argument.
Languages such as SML, C++, Eiffel, Ada-95, etc all support such constrained genericity. In Java, such constraints can be expressed using class type method parameters to capture semantic constraints, and interface type method parameters to capture signature constraints in place of Object type parameters discussed earlier.
Refer to the Java classes/interfaces such as java.util.Enumeration, java.util.Iterator, java.awt.Container, java.awt.event.MouseListener, etc for more examples.
The Java approach has one important limitation -- certain type equality constraints cannot be expressed or enforced at compile time. For example, let S be a subclass of C. Then, a collection of instances of C may potentially contain a mix of ``direct'' instances of C and ``direct'' instances of S. However it is not possible to specify and verify statically (that is, without resorting to type tests and casts) a collection class that is made up entirely of either ``direct'' instances of C or ``direct'' instances of S, but not a mix of the two. See [9,29] for proposals to extend Java language to incorporate such constrained polymorphism.
The language GJ, which is a conservative extension of Java 2, supports generics including covariant overriding [4]. The translator for GJ into Java incorporates generalization of the examples sketched above.