Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
Cast-conversion impl has several problems when it comes to generic types; most of them have to do with the fact that javac tries to be smarter than the JLS, in order to detect an illegal generic cast at compile-time rather than at runtime. Though this is desirable, the underlying impl is not reliable, meaning that a lot of valid cast are rejected by the compiler because of some failures in the 'provable distinct' test. Note also, that javac implements a stricter version of such a test than the JLS does - this is because we want to be able to detect more illegal cast than the JLS does. Here's an example: List<? extends Number> ln = ... Object o = (List<String>)ln; //error: inconvertible types The JLS require an unchecked warning here - because ? extends Number and String are not provably distinct; on the other hand, javac exploits the type info regarding the wildcard upper bound in order to reject that cast as illegal. Problem arise when either the target or the source type is *) a type variable with a recursive bound (fbound) - T extends Comparable<T> *) a captured type variable whose upper bound is recursive In such a setting, the enhanced type-disjointness test fails, that is, it is possible for javac to consider that two such types are distinct when they are not - the result is an unwanted complilation error where the user would have expected an unchecked warning.
|