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


        

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

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

Answer 3

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.

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

Answer 5

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.