Bounding Generics with the Contravariant 'Super' Keyword
In Java generics, the 'super' keyword plays a vital role in establishing subtypes for type parameters. However, it can only be used with wildcards and not with named type parameters. This presents a common question: why?
Why Not with Type Parameters?
The reason 'super' cannot be used with type parameters is that such a constraint would be ineffective in preventing unexpected behavior. Object, the ultimate superclass of all reference types, would render any hypothetical 'super' bound meaningless in practice.
For example, consider the following hypothetical method in the Collection interface:
<code class="java"><S super T> S[] toArray(S[] a);</code>
Attempting to declare such a method would fail at compile-time. Even if it were allowed, it wouldn't achieve its intended purpose. Since all reference type arrays are Object arrays, any array type could be used as an argument, rendering the 'super' bound ineffective.
Consequences for Arrays
Generics and arrays have a complex relationship, and the lack of 'super' bounds for named type parameters reflects this. While it might seem desirable to restrict parameter arrays to only those with superclasses of the parameterized type, that's not possible for arrays.
For instance, a 'List
Conclusion
Ultimately, the 'super' keyword's exclusion from named type parameters in Java generics is due to the inherent limitations of arrays in the context of generics. By prohibiting such bounds, Java prevents developers from creating potentially misleading constraints that would ultimately fail to provide the desired safety guarantees.
The above is the detailed content of Why Can\'t We Use the \'Super\' Keyword with Named Type Parameters in Java Generics?. For more information, please follow other related articles on the PHP Chinese website!