JDK-7013865 : varargs: javac crashes during overload resolution with generic varargs
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: unknown
  • Submitted: 2011-01-21
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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 b128Fixed
Related Reports
Relates :  
JDK-6199075 - Unambiguous varargs method calls flagged as ambiguous
Relates :  
JDK-7042566 - Regression: new ambiguity between varargs method
Description
The following program crashes javac:

class B {
    public <X extends Number> void m(X... args) { }
    public void m(Object... args) { }

    { m(null, null); }
}


Here's the stack trace:

An exception has occurred in the compiler (1.7.0-ea). 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$UnaryVisitor.visit(Types.java:3624)
        at com.sun.tools.javac.code.Types$Subst.subst(Types.java:2171)
        at com.sun.tools.javac.code.Types.subst(Types.java:2145)
        at com.sun.tools.javac.comp.Infer.instantiateMethod(Infer.java:401)
        at com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:378)
        at com.sun.tools.javac.comp.Resolve.instantiate(Resolve.java:405)
        at com.sun.tools.javac.comp.Resolve.signatureMoreSpecific(Resolve.java:811)
        at com.sun.tools.javac.comp.Resolve.mostSpecific(Resolve.java:720)
        at com.sun.tools.javac.comp.Resolve.selectBest(Resolve.java:694)
        at com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:914)
        at com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:878)
        at com.sun.tools.javac.comp.Resolve.findFun(Resolve.java:962)
        at com.sun.tools.javac.comp.Resolve.resolveMethod(Resolve.java:1359)
        at com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:2105)
        at com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:1704)
        at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:436)
        at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:423)
        at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:454)
        at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1434)
        at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1320)
        at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:436)
        at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:423)
        at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:465)
        at com.sun.tools.javac.comp.Attr.visitExec(Attr.java:1207)
        at com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1166)
        at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:436)
        at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:423)
        at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:485)
        at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:501)
        at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:862)
        at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:780)
        at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:436)
        at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:423)
        at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:485)
        at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:3137)
        at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:3063)
        at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2999)
        at com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1157)
        at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:847)
        at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:806)
        at com.sun.tools.javac.main.Main.compile(Main.java:411)
        at com.sun.tools.javac.main.Main.compile(Main.java:329)
        at com.sun.tools.javac.main.Main.compile(Main.java:320)
        at com.sun.tools.javac.Main.compile(Main.java:76)
        at com.sun.tools.javac.Main.main(Main.java:61)
Comments
SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/57e3b9bc7fb8
24-01-2011
EVALUATION This is a regression introduced by 6199075. In order to correctly apply most specific rules w.r.t. varargs methods, javac needs to rewrite varargs methods into non-varargs ones and then, if needed, apply an inference step (as described in 15.12.2.5). This rewrital process might cause problems when performing method argument applicability checks (both standard one, Resolve.checkRawArgumentsApplicable and the one in Infer.instantiateMethod). In the related CR we used a special method called Types.elemTypeOrType in order skip NPE caused by the attempt of retrieving the element type of a non array type. It appears that this special call is only performed inside Resolve.checkRawArgumentsApplicable but not in Infer.instantiateMethod, which explains why javac onlt crashes when performing most specific between one or more generic varargs methods.
21-01-2011