Maven compilation issue with Java 9

Question

Trying to compile a Maven project using JDK 9.0.1 I'm facing this stacktrace without much of an explanation:

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)

Not really sure what's causing this, is this a bug in the JDK?

Additional details:

Maven 3.5.0 with maven-compiler-plugin 3.7.0
I'm just executing mvn clean install
The source code is not open source unfortunately, so I'm not at liberty to share it
There are no module-info.java files yet, I'm just trying to compile a project using Java 9
Strangely enough if I leave the source level on 1.8, the code compiles, but it fails with the above exception if I specify it as 9

Not sure how you expect us to answer this question. Please try to isolate which file is causing the issue and publish it somewhere before we can do some conclusions. I would start with ensuring you're using maven-compiler-plugin 3.7.0 and have a look at the modue-info.java file. — Robert Scholte, Oct 22 '17 at 21:01
I'm using the latest version of the compiler plugin and the issue appears to happen deep within the JDK. The source code is not open source I'm afraid, and it does not have a module-info.java associated with it. I'm just trying to compile a project with source version 9 (although the code is only 1.8 really) and target version 9. — Peter Major, Oct 22 '17 at 21:44
@PeterMajor 1. The stacktrace isn't complete in itself. 2. There is no reproducible code shared in the question. 3. What maven configuration and commands are you using to end up here? — Naman, Oct 23 '17 at 00:59

score 176 · Accepted Answer · edited Jun 24 '19 at 16:49

176

Just add this

<forceJavacCompilerUse>true</forceJavacCompilerUse>

to your maven compiler build plugin in your POM and you'll see all the javac errors! Source with more details

edited Jun 24 '19 at 16:49

Michael

41,989
11
82
128

answered Sep 27 '18 at 11:58

Jason

2,579
1
17
19

This looks very promising! Thanks for the link – Peter Major Sep 28 '18 at 13:37
14

+1! It's important to note that this is a debug strategy. It does not actually "resolve" the problem. It only hides the symptom. The problem in question only masks an underlying compilation problem and this answer makes that underlying problem visible... After fixing the underlying problems, this configuration can be removed again. – neXus Apr 07 '20 at 09:24
5

Shoould be put inside a `` tag. – Zon Sep 06 '20 at 18:22
7

@neXus Why shouldn't this be left enabled? Or better yet, why is the error message output normally useless? – Ivan G. Jun 03 '21 at 21:17
1

THIS SAVE MY AS$! – Odravison Mar 14 '22 at 16:58
A million dollars THIS. thank you – vikingsteve Mar 22 '22 at 12:22

score 36 · Answer 2 · answered Aug 20 '21 at 03:18

Debugging

Step one should be to add the maven-compiler-plugin and enable <forceJavacCompilerUse>true</forceJavacCompilerUse> as the top answer suggests.

<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>
      ...

This will point out the actual compilation error.

[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

Root Cause

For me the root cause was that I made a commit and pushed it to the server which triggered CI, but did not include one class in the commit that was being used somewhere. Hence the compiler was not able to find it in the CI environment.

throws VariableNotFoundException {

The solution is to make sure you don't have any Git staged files that you forgot to include as part of your commit.

Peter Major · Answer 3 · 2018-07-29T23:21:56.787

UPDATE

Most of the time this error seems to occur, when the compiler is trying to report a compilation error, but it blows up in the process. So far mainly two approach helped to resolve these issues:

Disable annotation processing by using -proc:none compiler argument (it seems like that annotation processing can upset the compiler, so if you are not meant to use any, this is a free win).
Debug the compiler using a conditional breakpoint and walk the stack until a compiler error message can be found, and then fix that error...

ORGINAL SOLUTION

After lots of trial and error I was able to work around/fix this problem locally, my approach in the end was the following:

I had an assumption that maybe the dependencies are somehow interfering with the build result, so I started to comment out Maven <dependency> entries in the failing module's POM.
the build then started to fail, but it did so with the expected cannot find symbol and similar compilation errors instead of the unhelpful AssertionError failure
it turned out that there was one particular dependency that triggered this AssertionError.
After code analysis, I couldn't determine any good reason why that dependency would cause problems, so I started to look at the transitive dependencies
I then used the same approach as before, but instead of uncommenting the faulty dependency, I've inserted all of its transitive dependencies into the POM
the build again failed, and after lots and lots of testing it turned out that I could trigger the AssertionError when both io.vavr:vavr:0.9.0:compile and javax.servlet:servlet-api:3.0.1:test were included in the dependency graph

It is still beyond me how a test scoped dependency could have any effect on the project's compilation... It also turned out that javax.servlet:servlet-api:3.0.1:provided was already amongst the dependencies of the failing module, and the test scoped dependency wasn't actually used for anything.

In the end I just removed the incorrectly defined test scoped servlet-api dependency from the bug triggering module and suddenly Maven was able to compile the previously failing module.

I'm fairly sure that this is a very obscure answer to a very obscure question in the first place, but hopefully my approach will be of use for someone else.

How very painful. I'm experiencing this now with the latest maven (3.5.4) and java (10.0.2). Good times! Down the rabbit hole I go...........thanks for the guidance! — Jason, Sep 25 '18 at 21:37

score 10 · Answer 4 · answered Nov 11 '19 at 11:16

10

I got the same error on java 11. Adding jaxb api dependency to the pom solved my issue.

answered Nov 11 '19 at 11:16

Yuvaraj G

1,157
9
17

This was actually my solution as well. The accepted answer unfortunately did absolutely nothing for me. – wrestang Aug 13 '20 at 14:53
migrating to JDK 11 for compilation, here is the truth – yunandtidus Aug 24 '20 at 14:51
I also got different missing dependency and it was reported in such strange way - by crashing a compiler. – user11153 Aug 02 '21 at 13:27

score 5 · Answer 5 · answered Aug 24 '20 at 11:33

I had a similar stacktrace (abbreviated):

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

Since this occurred after a recent change to a library I had made, I traced the issue to a case change in a class name in one of my dependencies.

My dependency had changed from having a class with, for example, BlahMDCCustomizer to having a class with the same name but camelcase for 'Mdc' - BlahMdcCustomizer. The source code I was trying to compile that used this library, had not yet been updated to the new name and still referenced the non-existent BlahMDCCustomizer. No amount of mvn cleaning, invalidating caches or restarts would resolve the issue.

Once I updated my bad reference to BlahMDCCustomizer to the new name BlahMdcCustomizer, then mvn compile succeeded.

So it would seem that the compiler code has some case-sensitive assertions inside a case-insensitive process. Posting this in case it sheds light on the issue for someone more familiar with the source!

This was using JDK11 & maven 3.5.2, on Windows.

Naman · Answer 6 · 2017-10-23T05:55:01.113

4

The part of the stack trace

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

relates to the line of code

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

This would possibly happen when you're trying to build a maven module which is not based on Java9 and/or does not have(correct) module declaration module-info.java with a release version specified as 9 where it won't be able to resolve modules with/without the declaration.

edited Oct 23 '17 at 05:55

answered Oct 23 '17 at 02:00

Naman

27,789
26
218
353

Am I required to define module-info.java with target version 9? The reason why I'm confused is that several other Maven modules are compiling just fine with target version 9 and no module-info.java (pure luck then?). – Peter Major Oct 23 '17 at 05:45
1

@PeterMajor Well the module under question seems to be built using the java 9 module declaration probably and that is where it might have some incorrect declarations. I am afraid, you might need to share the appropriate or reproducible code for the same to dig further in. – Naman Oct 23 '17 at 05:56
1

There is one case I'm aware of which is fixed but hasn't been released yet: https://github.com/codehaus-plexus/plexus-languages/issues/2 This means there's no module descriptor in the root, but under `/META-INF/versions/9`. – Robert Scholte Oct 23 '17 at 17:28
@RobertScholte I guess you mean to point out an explicit `module-info.class` entry in `META-INF`? – Naman Oct 23 '17 at 17:32
1

@nullpointer released plexus-java assumes only a module descriptor in the root of the jar. JEP-238 says that this is not required, you can also put it at versions/X-folder of a multirelease jar. – Robert Scholte Oct 23 '17 at 18:33

Shekhar Rai · Answer 7 · 2021-03-24T12:06:13.117

In my case (IntelliJ), it happened due to the caches. So I had to remove .idea (rm -rf **/.idea) and .iml(rm -f **/*.iml) directories/files and re-import the project, Rebuild the project.

Previously, the project was in JDK8 and upgraded in the maven and IntelliJ settings but still some of the configurations remained the same. Hence removing those files reimporting, and rebuilding the project resolved the issue.

score 0 · Answer 8 · answered Jan 26 '22 at 10:18

I encouter the same crash with the same stack trace. For me it was due to a spring-boot-maven-plugin in two maven modules (our app's module and an app's library of us). That was pointed to in the existing spring boot multi module spring-boot-maven-plugin compilation failure.

score 0 · Answer 9 · answered Dec 01 '22 at 17:57

0

In my case it happened because I before applied

dependency:purge-local-repository

and I had missing dependencies without compile. So I compiled my missing dependencies and retry and all went well.

answered Dec 01 '22 at 17:57

wil

11
2

score -2 · Answer 10 · answered Sep 21 '21 at 15:01

-2

Need to execute mvn clean. It helped me.

answered Sep 21 '21 at 15:01

IlnarMT

21
1

Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-ask). – Community Sep 21 '21 at 16:54

Maven compilation issue with Java 9

10 Answers10

Debugging

Root Cause

Linked

Related