JDK-8034147 : javac crashes with a NullPointerException during bounds checking
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8,9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2014-02-10
  • Updated: 2014-07-29
  • Resolved: 2014-06-23
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 8 JDK 9
8u20Fixed 9 b22Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
javac 1.8.0-b128
java 1.8.0-b128

ADDITIONAL OS VERSION INFORMATION :
Linux x86/64

A DESCRIPTION OF THE PROBLEM :
javac crashes with a NullPointerException during generic bounds checking.

REGRESSION.  Last worked in version 7u51

ADDITIONAL REGRESSION INFORMATION: 
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b128)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run javac on the provided program.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Javac does not crash.
ACTUAL -
Javac crashes.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
An exception has occurred in the compiler (1.8.0-internal_bootstrap). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.  Thank you.
java.lang.NullPointerException
	at com.sun.tools.javac.code.Types.closure(Types.java:3314)
	at com.sun.tools.javac.code.Types.glb(Types.java:3637)
	at com.sun.tools.javac.code.Types.capture(Types.java:3914)
	at com.sun.tools.javac.code.Types.isSubtype(Types.java:836)
	at com.sun.tools.javac.code.Types.isSubtype(Types.java:806)
	at com.sun.tools.javac.code.Types$4.visitClassType(Types.java:258)
	at com.sun.tools.javac.code.Types$4.visitClassType(Types.java:1)
	at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:763)
	at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4400)
	at com.sun.tools.javac.code.Types.asSub(Types.java:234)
	at com.sun.tools.javac.code.Types$10.visitClassType(Types.java:1570)
	at com.sun.tools.javac.code.Types$10.visitClassType(Types.java:1)
	at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:763)
	at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4400)
	at com.sun.tools.javac.code.Types.isCastable(Types.java:1490)
	at com.sun.tools.javac.code.Types.notSoftSubtype(Types.java:1805)
	at com.sun.tools.javac.comp.Check.checkExtends(Check.java:619)
	at com.sun.tools.javac.comp.Check.firstIncompatibleTypeArg(Check.java:972)
	at com.sun.tools.javac.comp.Check.access$4(Check.java:935)
	at com.sun.tools.javac.comp.Check$Validator.visitTypeApply(Check.java:1254)
	at com.sun.tools.javac.tree.JCTree$JCTypeApply.accept(JCTree.java:2129)
	at com.sun.tools.javac.comp.Check$Validator.validateTree(Check.java:1350)
	at com.sun.tools.javac.comp.Check$Validator.validateTrees(Check.java:1363)
	at com.sun.tools.javac.comp.Check$Validator.visitTypeParameter(Check.java:1289)
	at com.sun.tools.javac.tree.JCTree$JCTypeParameter.accept(JCTree.java:2218)
	at com.sun.tools.javac.comp.Check$Validator.validateTree(Check.java:1350)
	at com.sun.tools.javac.comp.Check.validate(Check.java:1221)
	at com.sun.tools.javac.comp.Check.validate(Check.java:1218)
	at com.sun.tools.javac.comp.Check.validate(Check.java:1228)
	at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:4242)
	at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4215)
	at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4149)
	at com.sun.tools.javac.comp.Attr.attrib(Attr.java:4124)
	at com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1251)
	at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:904)
	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:863)
	at com.sun.tools.javac.main.Main.compile(Main.java:523)
	at com.sun.tools.javac.main.Main.compile(Main.java:381)
	at com.sun.tools.javac.main.Main.compile(Main.java:370)
	at com.sun.tools.javac.main.Main.compile(Main.java:361)
	at com.sun.tools.javac.Main.compile(Main.java:56)
	at com.sun.tools.javac.Main.main(Main.java:42)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
class One<X extends Two<? super X>> {}
class Two<Y extends Three<? extends Y>> implements Three<Y> {}
interface Three<Z> {}
---------- END SOURCE ----------


Comments
ManualVerify: Bug verified manually in promoted results for build JDK9-b22
10-07-2014

The new crash in 8u happens because this fix depends on JDK-8036007 -- I failed to notice the dependency, and that 8036007 had not been backported. To more accurately reflect the priority for getting JDK-8036007 into 8u20, here is the ILW evaluation for this bug: Impact: High (crash) Liklihood: Low (code like this is uncommon) Workaround: Medium (code can probably be rewritten, but there's no clear guidance on how/why) ==> P3
24-06-2014

Accidentally the bug was closed as Verified. Moved this bug to Resolved state.
23-06-2014

Resolution is to patch Types.supertype. For now, the more fundamental problem of correctly checking well-formedness of wildcard-parameterized types is being deferred.
20-06-2014

Fixing the well-formedness check exposes other longstanding issues with capture and glb: see JDK-8043374.
16-05-2014

The error occurs during well-formedness checking of a parameterized type. Relevant spec (JLS 4.5): A parameterized type C<T1,...,Tn> is well-formed if all of the following are true: ��� C is the name of a generic type. ��� The number of type arguments is the same as the number of type parameters in the generic declaration of C. ��� When subjected to capture conversion (��5.1.10) resulting in the type C<X1,...,Xn>, each type argument Xi is a subtype of S[F1:=X1,...,Fn:=Xn] for each bound type S in Bi. javac is attempting to test this last condition without first performing capture. (Note that the condition is essentially unchanged since JLS 3.)
16-05-2014

Similar problem in JDK-8039198: Types.subtype sees unexpected wildcards.
01-05-2014

Cause: Types.supertype sees a wildcard (which it should not), doesn't know what to do, and returns null.
01-05-2014

Reevaluating the ILW of this bug, after contacting the user: ILW=HLL -> P4 changing priority to P4
22-04-2014

ILW=HLH -> P2
10-03-2014

ILW classification: Impact = H (crash) Likelihood = L (this code don't seem to be very frequent) Workaround = H (in general a change would imply a totally different semantics) (HLH) => P2 raising the priority to P2
10-03-2014

Release team: Approved for deferral. We put this on 8u20 so it's on the radar for that release.
11-02-2014

Dev team - Please evaluate this regression asap.
10-02-2014