web-dev-qa-db-fra.com

Problème de compilation Maven avec Java 9

En essayant de compiler un projet Maven en utilisant JDK 9.0.1, je suis confronté à cette trace de pile sans beaucoup d'explication:

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)

Vous ne savez pas vraiment ce qui cause cela, est-ce un bug dans le JDK?

Détails supplémentaires :

  • Maven 3.5.0 avec maven-compiler-plugin 3.7.0
  • Je suis juste en train d'exécuter mvn clean install
  • Le code source n'est malheureusement pas open source, donc je ne suis pas libre de le partager
  • Il n'y a pas encore de fichiers module-info.Java, j'essaie juste de compiler un projet en utilisant Java 9
  • Curieusement, si je laisse le niveau source sur 1.8, le code se compile, mais il échoue avec l'exception ci-dessus si je le spécifie comme 9
mavenjava-9
24
Peter Major

Ajoutez simplement ceci

<forceJavacCompilerUse>true</forceJavacCompilerUse>

à votre plugin de compilation du compilateur maven dans votre POM et vous verrez toutes les erreurs javac! Source avec plus de détails

34
Jason

La partie de la trace de pile

at jdk.compiler/com.Sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.Java:821)

se rapporte à la ligne de code

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

Cela pourrait se produire lorsque vous essayez de créer un module maven qui n'est pas basé sur Java9 et/ou n'a pas de déclaration de module (correcte) module-info.Java avec une version de sortie spécifiée comme 9 où il ne pourra pas résoudre les modules avec/sans la déclaration.

2
Naman

MISE À JOUR

La plupart du temps, cette erreur semble se produire, lorsque le compilateur essaie de signaler une erreur de compilation, mais elle explose au cours du processus. Jusqu'à présent, principalement deux approches ont aidé à résoudre ces problèmes:

  • Désactivez le traitement des annotations à l'aide de -proc:none argument du compilateur (il semble que le traitement des annotations puisse bouleverser le compilateur, donc si vous n'êtes pas censé en utiliser, c'est une victoire gratuite).
  • Déboguez le compilateur à l'aide d'un point d'arrêt conditionnel et parcourez la pile jusqu'à ce qu'un message d'erreur du compilateur soit trouvé, puis corrigez cette erreur ...

SOLUTION ORGINALE

Après de nombreux essais et erreurs, j'ai pu contourner/résoudre ce problème localement, mon approche à la fin a été la suivante:

  • Je supposais que les dépendances interféraient en quelque sorte avec le résultat de la construction, alors j'ai commencé à commenter les entrées Maven <dépendance> dans le POM du module défaillant.
  • la génération a alors commencé à échouer, mais elle l'a fait avec le symbole de recherche attendu et des erreurs de compilation similaires au lieu de l'échec inutile d'AssertionError
  • il s'est avéré qu'il y avait une dépendance particulière qui a déclenché cette AssertionError.
  • Après l'analyse du code, je n'ai pu déterminer aucune bonne raison pour laquelle cette dépendance causerait des problèmes, alors j'ai commencé à regarder les dépendances transitives
  • J'ai ensuite utilisé la même approche qu'auparavant, mais au lieu de ne pas commenter la dépendance défectueuse, j'ai inséré toutes ses dépendances transitives dans le POM
  • la construction a de nouveau échoué, et après de nombreux tests, il s'est avéré que je pouvais déclencher AssertionError lorsque les deux io.vavr: vavr: 0.9.0: compile et javax.servlet: servlet-api: 3.0.1: test étaient inclus dans le graphique des dépendances

Je ne sais toujours pas comment une dépendance de portée de test pourrait avoir un effet sur la compilation du projet ... Il s'est également avéré que javax.servlet: servlet-api: 3.0.1: fourni figurait déjà parmi les dépendances du module défaillant, et la dépendance de portée de test n'a en fait été utilisée pour rien.

Au final, je viens de supprimer la dépendance de servlet-api de portée de test incorrectement définie du module de déclenchement de bogue et soudainement Maven a pu compiler le module précédemment défaillant.

Je suis assez sûr que c'est une réponse très obscure à une question très obscure en premier lieu, mais j'espère que mon approche sera utile à quelqu'un d'autre.

1
Peter Major