JDK-6762569 : Javac crashes with AssertionError in Types.containedBy
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: unknown,x86
  • Submitted: 2008-10-22
  • Updated: 2011-05-18
  • Resolved: 2011-05-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b40Fixed
Related Reports
Duplicate :  
JDK-6865518 - Compiler assertion failure during type checking
Relates :  
JDK-6651719 - Compiler crashes possibly during forward reference of TypeParameter
Description
Javac crashes with an assertion error in Types.contained by when compiling the following source:

import java.util.*;

class Test {
    <T> void m(T t, List<? super List<T>> list) {}
    void test(List<? super List<?>> list) {
        m("", list);
    }
}

In order to reproduce this problem the following command should be executed:

java -Xbootclasspath/p:/dist/lib/javac.jar -esa -jar dist/lib/javac.jar Test.java

or, using a JDK 7 compiler:

javac -J-esa Test.java
Comments
SUGGESTED FIX A webrev of this fix is available at the following URL http://hg.openjdk.java.net/jdk7/tl/langtools/rev/638d45788c9e
24-10-2008
EVALUATION This bug has not been seen since 6651719 has been fixed. That fix added a test case which is very similar to the one reported in this CR under test/tools/javac/generics/wildcards/.6651719/T6651719b.java. In fact, I (erroneously) thought that this failure was related to 6651719; however that's not true. The only reason that made that program compile was that something has changed in the way in which javac reports assertions (using assert keyword) when the compiler is invoked through the compiler API. In particular, assertion errors caused by assert keywords were not enabled if javac was executed in the usual way (setting -Xbootclasspath against a 6-open/7 JVM). This bug is caused by the fact that, when the following type-containment is executed: T? <= Object, where T is an UndetVar type (that is the type of a type-variable subject to type-inference), where lower(T?) = String javac raises an assertion error in this case because the undet var has a non-empty lower bound. This is a bit too harsh; we should go on and infer an instantiation for T?, an then check the instantiated type against the lower bound(s); if an uncompatible lower bound is found (that is a lower bound that is *not* a subtype of the instantiated type) the containment test should return false. In this case, since the inferred type is Object which is indeed a supertype of String, type-containment should succeed. On the other hand given the following example: class Test { <T> void m(T t, List<? super List<T>> list) {} void test(List<? super List<? extends Number>> list) { m("", list); } } This should fail, since the instantiated type Number is not compatible with the constraint String <: T (this example crashes javac as well)
22-10-2008