JDK-8075664 : NPE for illegall super call with MethodReference
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8u40
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2015-03-21
  • Updated: 2016-09-01
  • Resolved: 2016-09-01
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 9
9Resolved
Related Reports
Duplicate :  
JDK-8065986 - Compiler fails to NullPointerException when calling super with Object<>()
Description
In JDK8(u40, latest 8u-dev) will crash by the following clode:
(JDK9 works fine)

public class Test
{
    public Test()
    {
        super(A::a);
    }
}

Exception is following:
java.lang.NullPointerException
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitIdent(Flow.java:2377)
	at com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2011)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
	at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:404)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1382)
	at com.sun.tools.javac.tree.TreeScanner.visitReference(TreeScanner.java:268)
	at com.sun.tools.javac.tree.JCTree$JCMemberReference.accept(JCTree.java:1973)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
	at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:404)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1382)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scanExpr(Flow.java:1624)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scanExprs(Flow.java:1636)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitApply(Flow.java:2233)
	at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
	at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:404)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1382)
	at com.sun.tools.javac.tree.TreeScanner.visitExec(TreeScanner.java:175)
	at com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1296)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
	at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:404)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1382)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitBlock(Flow.java:1843)
	at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:909)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
	at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:404)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1382)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitMethodDef(Flow.java:1780)
	at com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitMethodDef(Flow.java:2546)
	at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:778)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
	at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:404)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1382)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitClassDef(Flow.java:1733)
	at com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitClassDef(Flow.java:2525)
	at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:693)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
	at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:404)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1382)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.analyzeTree(Flow.java:2420)
	at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.analyzeTree(Flow.java:2403)
	at com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:211)
	at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1327)
	at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1296)
	at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:901)
	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860)
	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)
Comments
I identified the defect https://bugs.openjdk.java.net/browse/JDK-8065986 simply by looking at what change set last modified the relevant lines in JDK9 tree. This may or may not be the most appropriate change (as there could have been further modifications since the pertinent change), but it seems to me a good exercise to ask the question why the problem does not manifest itself at JDK9 and work backwards from there.
23-03-2015
Is this fixed in JDK9 dev by http://hg.openjdk.java.net/jdk9/dev/langtools/rev/caa3490d5aee made for https://bugs.openjdk.java.net/browse/JDK-8065986 ? If so what would explain that your fix has fewer code changes than the fix pushed to JDK9 ?
23-03-2015
[PATCH] http://cr.openjdk.java.net/~shinyafox/8075664/webrev.00/
21-03-2015