java.lang.AssertionError when running mvn package [duplicate]

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

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.