Java 9

时间：2017-10-22 20:07:33

标签： maven java-9

尝试使用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 with maven-compiler-plugin 3.7.0
  • 我刚刚执行mvn clean install
  • 遗憾的是，源代码不是开源的，所以我不能随意分享它
  • 还没有module-info.java文件，我只是想用Java 9编译项目
  • 奇怪的是，如果我将源代码级别保留为1.8，则代码会编译，但如果我将其指定为9，则会因上述异常而失败

6 个答案:

答案 0 :(得分：20)

胜利，只需将以下内容添加到<forceJavacCompilerUse>true</forceJavacCompilerUse>到pom中的maven编译器构建插件即可。 Bam，您将看到所有javac错误！ Source w/more details

答案 1 :(得分：2)

堆栈跟踪部分

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

涉及代码行

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

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

答案 2 :(得分：1)

<强>更新

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

  • 使用-proc:none编译器参数禁用注释处理（看起来注释处理可能会扰乱编译器，所以如果你不打算使用任何，那么这是一个免费的胜利。）
  • 使用条件断点调试编译器并遍历堆栈，直到找到编译器错误消息，然后修复该错误......

ORGINAL SOLUTION

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

  • 我假设依赖关系可能会以某种方式干扰构建结果，所以我开始注释掉Maven＆lt; dependency＆gt;失败模块的POM中的条目。
  • 构建然后开始失败，但是它使用预期的找不到符号和类似的编译错误而不是无用的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：已经提供了失败模块的依赖关系，以及测试范围的依赖关系实际上并没有用于任何事情。

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

我相当确定这首先是一个非常模糊的问题的答案，但我希望我的方法可以用于其他人。

答案 3 :(得分：0)

我在Java 11上遇到了相同的错误。向pom添加jaxb api依赖关系解决了我的问题。

答案 4 :(得分：0)

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

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 clean的任何数量化，使缓存无效或重新启动都无法解决问题。

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

因此，似乎编译器代码在不区分大小写的进程中具有一些区分大小写的断言。发布此邮件以防万一，让熟悉源代码的人能更清楚地了解这个问题！

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

答案 5 :(得分：0)

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

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

相关问题
最新问题