Java 9 的 Maven 编译问题答案

【问题标题】：Maven compilation issue with Java 9Java 9 的 Maven 编译问题
【发布时间】：2018-04-03 08:51:58
【问题描述】：

尝试使用 JDK 9.0.1 编译一个 Maven 项目，我遇到了这个堆栈跟踪，没有太多解释：

Exception in thread "main" java.lang.AssertionError
at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:250)
at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:821)
at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete(JavacProcessingEnvironment.java:1510)
at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633)
at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1314)
at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1139)
at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1065)
at jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:237)
at jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:52)
at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:992)
at jdk.compiler/com.sun.tools.javac.code.Printer.visit(Printer.java:136)
at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:197)
at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:183)
at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
at jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.getMessage(JCDiagnostic.java:771)
at jdk.compiler/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:1075)
at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:168)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

不确定是什么原因造成的，这是 JDK 中的错误吗？

更多细节：

Maven 3.5.0 和 maven-compiler-plugin 3.7.0
我只是在执行 mvn clean install
不幸的是，源代码不是开源的，所以我无权分享它
还没有 module-info.java 文件，我只是想用 Java 9 编译一个项目
奇怪的是，如果我将源代码级别保留为 1.8，代码会编译，但如果我将其指定为 9，则会失败并出现上述异常

【问题讨论】：

不确定您希望我们如何回答这个问题。请尝试找出导致问题的文件并将其发布到某个地方，然后我们才能得出一些结论。我首先要确保您使用的是 maven-compiler-plugin 3.7.0，然后查看 modue-info.java 文件。
我正在使用最新版本的编译器插件，问题似乎发生在 JDK 深处。恐怕源代码不是开源的，它没有与之关联的module-info.java。我只是想用源版本 9（虽然代码实际上只有 1.8）和目标版本 9 编译一个项目。
@PeterMajor 1. 堆栈跟踪本身并不完整。 2. 问题中没有共享可重现的代码。 3. 你使用什么 Maven 配置和命令来结束这里？
我已经用更多细节更新了这个问题。
还有 JAVA 11

标签： maven java-9

【解决方案1】：

添加这个

<forceJavacCompilerUse>true</forceJavacCompilerUse>

到您的 POM 中的 maven 编译器构建插件，您将看到所有 javac 错误！ Source with more details

【讨论】：

这看起来很有希望！感谢您的链接
+1！请务必注意，这是一种调试策略。它实际上并没有“解决”问题。它只是隐藏了症状。有问题的问题只掩盖了一个潜在的编译问题，而这个答案使这个潜在的问题变得可见......在解决了潜在的问题之后，这个配置可以再次被删除。
应该放在<configuration> 标签内。
@neXus 为什么不应该启用它？或者更好的是，为什么错误信息输出通常没用？

【解决方案2】：

更新

大多数时候这个错误似乎发生，当编译器试图报告一个编译错误，但它在这个过程中爆炸了。到目前为止，主要有两种方法有助于解决这些问题：

使用 -proc:none 编译器参数禁用注释处理（似乎注释处理会扰乱编译器，所以如果您不打算使用任何注释，这是免费的）。
使用条件断点调试编译器并遍历堆栈，直到找到编译器错误消息，然后修复该错误...

原始解决方案

经过大量试验和错误后，我能够在本地解决/修复此问题，最终我的方法如下：

我假设依赖项可能会以某种方式干扰构建结果，因此我开始在失败模块的 POM 中注释掉 Maven 条目。
然后构建开始失败，但这样做是因为预期的找不到符号和类似的编译错误，而不是无用的 AssertionError 失败
事实证明，有一个特定的依赖项触发了这个 AssertionError。
经过代码分析，我无法确定该依赖关系会导致问题的任何充分理由，因此我开始研究传递依赖关系
然后我使用与以前相同的方法，但我没有取消注释错误的依赖项，而是将其所有传递依赖项插入到 POM 中
构建再次失败，经过大量测试后发现，当 io.vavr:vavr:0.9.0:compile 和 javax.servlet:servlet-api:3.0.1 时，我可以触发 AssertionError：测试被包含在依赖图中

我仍然无法理解测试范围的依赖项如何对项目的编译产生任何影响......结果还证明 javax.servlet:servlet-api:3.0.1:provided 已经是失败的依赖项之一模块，而测试范围的依赖实际上并没有用于任何事情。

最后我只是从错误触发模块中删除了错误定义的测试范围 servlet-api 依赖项，突然 Maven 能够编译以前失败的模块。

我很确定这首先是对一个非常模糊的问题的一个非常模糊的答案，但希望我的方法对其他人有用。

【讨论】：

多么痛苦。我现在正在使用最新的 maven (3.5.4) 和 java (10.0.2) 来体验这个。美好时光！我去兔子洞…………谢谢你的指导！
感谢这个蛮力方法真的救了我的一天

【解决方案3】：

我在 java 11 上遇到了同样的错误。将 jaxb api 依赖项添加到 pom 解决了我的问题。

【讨论】：

这实际上也是我的解决方案。不幸的是，接受的答案对我没有任何帮助。
迁移到JDK 11编译，这才是真相
我还得到了不同的缺失依赖项，并且以这种奇怪的方式报告 - 通过崩溃编译器。

【解决方案4】：

调试

第一步应该是添加 maven-compiler-plugin 并启用 <forceJavacCompilerUse>true</forceJavacCompilerUse> 如最佳答案所示。

<project>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
          <forceJavacCompilerUse>true</forceJavacCompilerUse>
        </configuration>
      </plugin>
      ...

这会指出实际的编译错误。

[main] INFO org.apache.maven.plugin.compiler.CompilerMojo - -------------------------------------------------------------
[main] ERROR org.apache.maven.plugin.compiler.CompilerMojo - COMPILATION ERROR : 
[main] INFO org.apache.maven.plugin.compiler.CompilerMojo - -------------------------------------------------------------
[main] ERROR org.apache.maven.plugin.compiler.CompilerMojo -    last round: true
/home/vsts/work/1/s/src/main/java/com/company/services/TemplateService.java:[3,61] error: cannot find symbol
  symbol:   class VariableNotFoundException

根本原因

对我来说，根本原因是我做了一个提交并将其推送到触发 CI 的服务器，但 在提交中没有包含一个在某处使用的类。因此编译器无法在 CI 环境中找到它。

throws VariableNotFoundException {

解决方案是确保您没有任何忘记包含在提交中的 Git 暂存文件。

【讨论】：

【解决方案5】：

堆栈跟踪部分

at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:821)

与代码行有关

throw new CompletionFailure(c, diags.fragment("cant.resolve.modules"));

当您尝试构建一个不基于 Java9 和/或没有（正确）模块声明 module-info.java 的 maven 模块且发布版本指定为 9 时，可能会发生这种情况能够解析有/没有声明的模块。

【讨论】：

我需要用目标版本 9 定义 module-info.java 吗？我感到困惑的原因是其他几个 Maven 模块在目标版本 9 上编译得很好，并且没有 module-info.java（那么纯属运气？）。
@PeterMajor 好吧，有问题的模块似乎是使用 java 9 模块声明构建的，这可能是它可能有一些不正确的声明的地方。恐怕，您可能需要共享适当的或可重现的代码才能进一步挖掘。
我知道有一种情况是已修复但尚未发布：github.com/codehaus-plexus/plexus-languages/issues/2 这意味着根目录中没有模块描述符，但在/META-INF/versions/9 下。
@RobertScholte 我猜你的意思是在META-INF 中指出一个明确的module-info.class 条目？
@nullpointer 发布 plexus-java 假定 jar 的根目录中只有一个模块描述符。 JEP-238 表示这不是必需的，您也可以将其放在多版本 jar 的版本/X 文件夹中。

【解决方案6】：

我有一个类似的堆栈跟踪（缩写）：

Exception in thread "main" java.lang.AssertionError at 
jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
...
...javac.main.JavaCompiler.readSourceFile(....

由于这发生在我最近对库进行更改之后，我将问题追溯到我的一个依赖项中类名的大小写更改。

我的依赖已经从拥有一个具有例如BlahMDCCustomizer 的类更改为拥有一个具有相同名称但驼峰式为'Mdc' - BlahMdcCustomizer 的类。我试图编译的使用这个库的源代码尚未更新为新名称，并且仍然引用了不存在的BlahMDCCustomizer。再多的mvn cleaning、使缓存无效或重新启动都无法解决问题。

一旦我将我对 BlahMDCCustomizer 的错误引用更新为新名称 BlahMdcCustomizer，然后 mvn compile 成功。

因此，编译器代码似乎在不区分大小写的进程中有一些区分大小写的断言。发布此内容以防它为更熟悉来源的人阐明问题！

这是在 Windows 上使用 JDK11 和 maven 3.5.2。

【讨论】：

【解决方案7】：

在我的情况下（IntelliJ），它是由于缓存而发生的。所以我不得不删除 .idea (rm -rf **/.idea) 和 .iml(rm -f **/*.iml) 目录/文件并重新导入项目，重建项目。

以前，该项目在 JDK8 中并在 maven 和 IntelliJ 设置中进行了升级，但仍然有一些配置保持不变。因此删除这些文件重新导入，并重建项目解决了这个问题。

【讨论】：

【解决方案8】：

需要执行 mvn clean。它帮助了我。

【讨论】：

您的答案可以通过额外的支持信息得到改进。请edit 添加更多详细信息，例如引用或文档，以便其他人可以确认您的答案是正确的。你可以找到更多关于如何写好答案的信息in the help center。

【解决方案9】：

我用相同的堆栈跟踪遇到了同样的崩溃。对我来说，这是由于两个 maven 模块（我们的应用程序模块和我们的应用程序库）中的 spring-boot-maven-plugin。这在现有的spring boot multi module spring-boot-maven-plugin compilation failure 中已指出。

【讨论】：