[
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)
