Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6790039

overhaul cast-conversion (umbrella)


    • Type: Bug
    • Status: Closed
    • Priority: P3
    • Resolution: Cannot Reproduce
    • Affects Version/s: 7
    • Fix Version/s: 7
    • Component/s: tools
    • Subcomponent:
    • CPU:
    • OS:


      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.


          Issue Links



              • Assignee:
                mcimadamore Maurizio Cimadamore
                mcimadamore Maurizio Cimadamore
              • Votes:
                0 Vote for this issue
                0 Start watching this issue


                • Created: