JDK-8168760 : ClassCastException: Type$TypeMapping$3 cannot be cast to Type$WildcardType
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Priority: P4
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: generic
  • CPU: generic
  • Submitted: 2016-10-26
  • Updated: 2019-06-17
  • Resolved: 2019-06-17
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 13
13Resolved
Related Reports
Relates :  
Description
In following up this message: http://mail.openjdk.java.net/pipermail/compiler-dev/2016-October/010450.html, Alex Buckley observed:

"on JDK 9b140, javac crashes if the declaration of i uses a 
bounded wildcard for B's type argument -- say B<? extends Number>.I"

I verified that claim against JDK9 tip using this case:

class A<X> { class I {} }
class Test {
  class B<Y> extends A<Y[]> {}
  B<? extends Number>.I i;
}

and I am able to reproduce the crash:

java.lang.ClassCastException: com.sun.tools.javac.code.Type$TypeMapping$3 (in module: jdk.compiler) cannot be cast to com.sun.tools.javac.code.Type$WildcardType (in module: jdk.compiler)
	at com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(jdk.compiler@9-internal/Attr.java:4805)
	at com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(jdk.compiler@9-internal/Attr.java:4766)
	at com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitVarDef(jdk.compiler@9-internal/Attr.java:4677)
	at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(jdk.compiler@9-internal/JCTree.java:936)
	at com.sun.tools.javac.tree.TreeScanner.scan(jdk.compiler@9-internal/TreeScanner.java:49)


 


Comments
I am unable to reproduce this anymore on tip of jdk/jdk.
17-06-2019

Correct behavior is poorly specified; will have to be defined by JDK-8168760. (A workaround preventing a crash might be helpful in the mean time.)
07-02-2017

As Maurizio observed in http://mail.openjdk.java.net/pipermail/compiler-dev/2016-October/010461.html this is reproducible in JDK8 also, so not a regression. I have set the fix version to 10 for now. I will pull this up to 9 if the fix is simple enough
26-10-2016