Проблема компиляции Maven с Java 9

Попытка скомпилировать проект Maven с использованием JDK 9.0.1 Я столкнулся с этой stacktrace без объяснения причин:

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

Ответ 1

Просто добавь это

<forceJavacCompilerUse>true</forceJavacCompilerUse>

к вашему плагину сборки компилятора maven в вашем POM, и вы увидите все ошибки javac! Источник с более подробной информацией

Ответ 2

Часть трассировки стека

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

относится к строке кода

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

Это может произойти, если вы пытаетесь создать модуль maven, который не основан на Java9 и/или не имеет (правильного) объявления модуля module-info.java с версией выпуска, указанной как 9, где он не сможет для разрешения модулей с/без декларации.

Ответ 3

ОБНОВИТЬ

В большинстве случаев эта ошибка возникает, когда компилятор пытается сообщить об ошибке компиляции, но он взрывается в процессе. До сих пор в основном два подхода помогли решить эти проблемы:

Отключить обработку аннотаций с помощью -proc:none аргумента компилятора (похоже, что обработка аннотаций может нарушить компилятор, поэтому, если вы не собираетесь использовать их, это бесплатный выигрыш).
Отлаживайте компилятор с помощью условной точки останова и пройдите стек до тех пор, пока сообщение об ошибке компилятора не будет найдено, а затем исправить эту ошибку...

ORGINAL SOLUTION

После многих проб и ошибок я смог обойти/исправить эту проблему локально, мой подход в конце концов был следующим:

У меня было предположение, что, возможно, зависимости каким-то образом влияют на результат сборки, поэтому я начал комментировать записи Maven <dependency> в отказоустойчивом модуле POM.
сборка затем начала сбой, но она сделала это с ожидаемым, не может найти символ и подобные ошибки компиляции вместо бесполезной ошибки AssertionError
оказалось, что была одна конкретная зависимость, которая вызвала этот AssertionError.
После анализа кода я не мог определить веских причин, по которым эта зависимость может вызвать проблемы, поэтому я начал смотреть на транзитивные зависимости
Затем я использовал тот же подход, что и раньше, но вместо того, чтобы раскомментировать ошибочную зависимость, я вложил все свои транзитивные зависимости в POM
сборка снова не удалась, и после много-много испытаний выяснилось, что я могу вызвать AssertionError, когда были включены как io.vavr: vavr: 0.9.0: компиляция, так и javax.servlet: servlet-api: 3.0.1: тест в графе зависимостей

Мне все еще не нравится, как зависимость от тестовой области может повлиять на компиляцию проекта... Также выяснилось, что javax.servlet: servlet-api: 3.0.1: предоставлено уже среди зависимостей модуля сбоя и зависимость от тестовой области фактически не использовалась ни для чего.

В конце концов я просто удалил неверно определенную зависимость сервлета-api, зависящую от тестовой области, от модуля запуска ошибок, и вдруг Maven смог скомпилировать ранее провальный модуль.

Я уверен, что это очень неясный ответ на очень неясный вопрос, но, надеюсь, мой подход будет полезен для кого-то другого.