You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Dan Berindei (Jira)" <ji...@apache.org> on 2021/08/02 11:28:00 UTC

[jira] [Commented] (MCOMPILER-415) NullPointerException from javac when compiling AntlrWorks-Jank

    [ https://issues.apache.org/jira/browse/MCOMPILER-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17391522#comment-17391522 ] 

Dan Berindei commented on MCOMPILER-415:
----------------------------------------

[~rfscholte] As the latest comment on [JDK-8216202|https://bugs.openjdk.java.net/browse/JDK-8216202?focusedCommentId=14438100&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14438100] suggests, this could be fixed in {{JavaxToolsCompiler}}
by using a custom {{DiagnosticListener}} that calls {{Diagnostic.getMessage()}} eagerly.

I still think it's a bug in {{JavaCompiler}}, because the [javadoc|https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaCompiler.html] contains an example using {{DiagnosticCollector}} exactly the same way {{JavaxToolsCompiler}} does it, but I don't have an account there so I can't comment on it.

The root cause is that both {{JavaCompiler}} and {{JavacTaskImpl}} call {{JavaCompiler.close()}} before returning:

{noformat}
	  at com.sun.tools.javac.main.JavaCompiler.close(JavaCompiler.java:1782)
	  at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:997)
	  at com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
	  at com.sun.tools.javac.api.JavacTaskImpl$$Lambda$270.379623433.call(Unknown Source:-1)
	  at com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:147)
	  at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
	  at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)
	  at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126)
	  at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174)
	  at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1134)
	  at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:187)
{noformat}

{noformat}
	  at com.sun.tools.javac.main.JavaCompiler.close(JavaCompiler.java:1782)
	  at com.sun.tools.javac.api.JavacTaskImpl.cleanup(JavacTaskImpl.java:229)
	  at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:109)
	  at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)
	  at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126)
	  at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174)
	  at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1134)
	  at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:187)
{noformat}

{{JavaxToolsCompiler}} later calls {{getMessage()}} on a diagnostic message that references an unresolved class,
and {{ClientCodeWrapper$DiagnosticSourceUnwrapper.getMessage()}} ends up calling {{JavaCompiler.readSourceFile()}}
to resolve the generic type arguments of the unresolved class.
But the {{JavaCompiler}} instance has been closed and all the fields are now set to {{null}},
so {{readSourceFile()}} fails with a {{NullPointerException}}

{noformat}
	  at com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:841)
	  at com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete(JavacProcessingEnvironment.java:1530)
	  at com.sun.tools.javac.code.Symbol.complete(Symbol.java:642)
	  at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1326)
	  at com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1140)
	  at com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1066)
	  at com.sun.tools.javac.code.Printer.visitClassType(Printer.java:237)
	  at com.sun.tools.javac.code.Printer.visitClassType(Printer.java:52)
	  at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:993)
	  at com.sun.tools.javac.code.Printer.visit(Printer.java:136)
	  at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:199)
	  at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:167)
	  at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
	  at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
	  at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:185)
	  at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:167)
	  at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
	  at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
	  at com.sun.tools.javac.util.JCDiagnostic.getMessage(JCDiagnostic.java:788)
	  at com.sun.tools.javac.api.ClientCodeWrapper$DiagnosticSourceUnwrapper.getMessage(ClientCodeWrapper.java:799)
	  at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:131)
	  at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174)
	  at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1134)
	  at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:187)
{noformat}

FWIW I haven't been able to reproduce this with a simple project.
However, I can reproduce it reliably with:

{noformat}
git clone https://github.com/debezium/debezium
cd debezium
git checkout 8f717785b2d651ea5f8bbd0aaabb85562e1ef70b
mvn clean compile -am -pl debezium-connector-oracle -Poracle,infinispan-buffer
{noformat}

Module {{debezium-connector-oracle}} only builds when the {{oracle}} profile is active,
and the proprietary dependency that allows class {{XStreamChangeRecordEmitter}} to compile is referenced only in some profiles (e.g. {{assembly}}).
Other profiles (e.g. {{oracle-ci}}) use the {{maven-compiler-plugin}} to exclude the problematic class from compilation, and yet others (i.e. the 2 on the command line) don't do anything about it, so the compilation should fail with errors

{noformat}
26 = {CompilerMessage@6837} "/home/dan/Work/debezium/debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/xstream/LcrPosition.java:[18,22] package oracle.streams does not exist"
 27 = {CompilerMessage@6838} "/home/dan/Work/debezium/debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/xstream/LcrPosition.java:[19,22] package oracle.streams does not exist"
 28 = {CompilerMessage@6839} "/home/dan/Work/debezium/debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/xstream/XStreamChangeRecordEmitter.java:[16,22] package oracle.streams does not exist"
 29 = {CompilerMessage@6840} "/home/dan/Work/debezium/debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/xstream/XStreamChangeRecordEmitter.java:[17,22] package oracle.streams does not exist"
 30 = {CompilerMessage@6841} "/home/dan/Work/debezium/debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/xstream/XStreamChangeRecordEmitter.java:[24,73] cannot find symbol\n  symbol: class ColumnValue"
{noformat}

> NullPointerException from javac when compiling AntlrWorks-Jank
> --------------------------------------------------------------
>
>                 Key: MCOMPILER-415
>                 URL: https://issues.apache.org/jira/browse/MCOMPILER-415
>             Project: Maven Compiler Plugin
>          Issue Type: Bug
>    Affects Versions: 3.1
>         Environment: macOS 10.14.6, iMac Pro, AdoptOpenJDK 9, OpenJDK 11.0.2, AdoptOpenJDK 13.0.2
>            Reporter: Andrew Janke
>            Priority: Minor
>         Attachments: antlrworks-jank-mvn-compile-NPE-02-debug.log, antlrworks-jank-mvn-compile-NPE-02.log, antlrworks-jank-mvn-compile-NPE-debug.log, antlrworks-jank-mvn-compile-NPE.log
>
>
> I'm working on a project called AntlrWorks-Jank, an attempt to revive the defunct ANTLRWorks application. https://github.com/apjanke/antlrworks2-jank
> When compiling the latest work-in-progress version of my code, I'm getting a NullPointerException apparently raised inside the javac code when it's called by the Maven Compiler Plugin.
> {code:java}
> [antlrworks-jank] $ mvn -e compile
> [INFO] Error stacktraces are turned on.
> [...]
> [INFO] works-editor-antlr4 ................................ FAILURE [  1.026 s]
> [INFO] antlr-works-editor ................................. SKIPPED
> [INFO] tvl-editor-whitespace .............................. SKIPPED
> [INFO] works-editor-antlr3 ................................ SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time:  2.028 s
> [INFO] Finished at: 2020-05-08T03:01:54-04:00
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project works-editor-antlr4: Fatal error compiling: CompilerException: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project works-editor-antlr4: Fatal error compiling
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
> [...]
> Caused by: java.lang.NullPointerException
>     at com.sun.tools.javac.main.JavaCompiler.readSourceFile (JavaCompiler.java:825)
>     at com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete (JavacProcessingEnvironment.java:1510)
>     at com.sun.tools.javac.code.Symbol.complete (Symbol.java:633)
>     at com.sun.tools.javac.code.Symbol$ClassSymbol.complete (Symbol.java:1314)
>     at com.sun.tools.javac.code.Type$ClassType.complete (Type.java:1139)
>     at com.sun.tools.javac.code.Type$ClassType.getTypeArguments (Type.java:1065)
>     at com.sun.tools.javac.code.Printer.visitClassType (Printer.java:237)
>     at com.sun.tools.javac.code.Printer.visitClassType (Printer.java:52)
>     at com.sun.tools.javac.code.Type$ClassType.accept (Type.java:992)
>     at com.sun.tools.javac.code.Printer.visit (Printer.java:136)
>     at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument (AbstractDiagnosticFormatter.java:197)
>     at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments (AbstractDiagnosticFormatter.java:165)
>     at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage (BasicDiagnosticFormatter.java:111)
>     at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage (BasicDiagnosticFormatter.java:67)
>     at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument (AbstractDiagnosticFormatter.java:183)
>     at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments (AbstractDiagnosticFormatter.java:165)
>     at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage (BasicDiagnosticFormatter.java:111)
>     at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage (BasicDiagnosticFormatter.java:67)
>     at com.sun.tools.javac.util.JCDiagnostic.getMessage (JCDiagnostic.java:771)
>     at com.sun.tools.javac.api.ClientCodeWrapper$DiagnosticSourceUnwrapper.getMessage (ClientCodeWrapper.java:799)
>     at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess (JavaxToolsCompiler.java:149)
>     at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile (JavacCompiler.java:169)
>     at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:785)
>     at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:129)
>     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
> {code}
> The full code to reproduce is on the NPE-during-compile tag in that repo: https://github.com/apjanke/antlrworks2-jank/tree/NPE-during-compile.
> I *think* I'm running the latest 3.8.1 version of maven-compiler-plugin, since I'm not specifying a version for it in my POMs. Seems to happen with Java 9, 11, and 13 (which I'm selecting by setting the $JAVA_HOME environment variable before running `mvn -e compile`).
> Would this be a bug in maven-compiler-plugin? Or actually a bug in javac? Or something else?
> Find output of `mvn -e compile &>antlrworks-jank-mvn-compile-NPE.log` and `mvn -X -e compile &>antlrworks-jank-mvn-compile-NPE-debug.log` attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)