Javac not running annotation processors

Question

Problem

I'm revisiting a maven project that I haven't touched in at least a year. I'm pretty sure it was compiling successfully when I left it (there was still a working jar in the target directory), but now compilation fails because generated classes are missing.

What I tried

• Verified there are indeed no sources in target/generated-sources/annotations (none present)
• Ensured javac wasn't invoked with -proc:none (it wasn't)
• Ran mvn clean dependency:unpack-dependencies -Dmdep.useSubDirectoryPerArtifact=true to ensure the expected dependencies are on the classpath and that they contain a valid META-INF/services/javax.annotation.processing.Processor entry (yes there were multiple, including org.immutables.processor.ProxyProcessor )
• Followed these steps from How to make sure javac is using an annotation processor and troubleshoot when it is not:
  1. Take the javac options from the maven debug log
  2. Remove -nowarn option and add -verbose -XprintRounds -XprintProcessorInfo -Xlint -J-verbose. NOTE: I also had to add the relative path to the main class, or javac would complain there are no sources.
  3. Verify if class of processor is loaded (not present)
  4. Look for at least one processing round log (none present)
  5. Make sure annotations are present in the list of the round log (no round log)
• Added -proc:only option to javac command
• Also added -processor org.immutables.processor.ProxyProcessor to javac command (processor now loaded, but still no rounds printed and no classes generated)
• Changed the processor option to -processor org.immutables.processor.ProxyProcessorXXX to see if it would make a difference (it did, it now printed a warning stating that processing was requested with proc:only, but no processors were found)
• Checked to see if that warning appeared if I didn't use the -processor option, which should make javac detect processors from class path (it didn't show the warning, which suggests it's detecting processors yet the log doesn't show any sign of it)
• Tried above after switching from JDK1.8 to JDK9 (using jenv)
• Installed Zulu 1.7 and tried above after switching to it (using jenv)

Possible factors

• I did an entirely clean install of macOS
• I ran macOS Sierra before, currently High Sierra
• Before I didn't have JDK9 installed
• I switched to using Gradle a long time ago, so I might have forgotten an important detail about maven

Command options

This is the javac command I'm currently using:

javac -d ./target/classes -classpath ./target/classes:$HOME/.m2/repository/com/google/dagger/dagger/2.4/dagger-2.4.jar:$HOME/.m2/repository/com/google/dagger/dagger-compiler/2.4/dagger-compiler-2.4.jar:$HOME/.m2/repository/com/google/auto/factory/auto-factory/1.0-beta3/auto-factory-1.0-beta3.jar:$HOME/.m2/repository/org/immutables/builder/2.3.9/builder-2.3.9.jar:$HOME/.m2/repository/org/immutables/value/2.3.9/value-2.3.9.jar:<LONG LIST OF DIRECT AND TRANSITIVE DEPENDENCIES HERE> -sourcepath ./src/main/java: -s ./target/generated-sources/annotations -verbose -XprintRounds -XprintProcessorInfo -Xlint -J-verbose -processor org.immutables.processor.ProxyProcessor -proc:only ./src/main/java/com/mycompany/myproject/Main.java

NOTE: for better readability, I put each argument on a new line, replaced absolute paths with $HOME/ and ./ and I omitted most dependencies.

Question

What am I missing here? Any suggestions or pointers would be greatly appreciated.

Leninist

Maybe github.com/immutables/immutables/issues/386? – Aixenprovence

Thanks, that looked promising. I didn't consider the issue might be with immutables, but unfortunately I don't see any such errors in the log. Also tried another version of immutables but that didn't make a difference. It seems processing doesn't happen at all. – Leninist

Actually, @yegodm, the issue you referenced does seem to be related; Although no such errors are printed, when I try to compile one specific class that has immutables annotations it works as expected. Strange that all annotation processors are no longer running though. I'll investigate further. – Leninist

One thing that issue thread mentioned is to add -Xmaxerrs 100000 (I also added -Xmaxwarns 100000), or javac might not print the most relevant information because it's past the default error/warning limit. I tried that with Maven too, but unfortunately it has trouble handling these flags: stackoverflow.com/a/3358578 – Leninist

What if you create a new bare maven project with just a few classes using same annotations and check if that compiles as you want it? – Aixenprovence

Answer 1

javac appears to completely and silently skip annotation processing for some parse failures.

For me a duplicated annotation caused by a merge mistake caused thousands of failures because my annotation processors didn't run - so the real error got completely lost.

@Data @AllArgsConstructor @NoArgsConstructor @EqualsAndHashCode(callSuper = false)
@EqualsAndHashCode(callSuper = false)

Gemina

I can confirm this. In my case, the reason for a failure was also in another place (not related to annotion processors) after I merged lots of new changes. – Phaidra

All annotation processing seems to be skipped if you have class B implements ClassA (I was changing an interface to a class, missed one and got thousands of errors due to the annotation processing, making it impossible to find the error 🤦) – Gemina

Answer 2

As far as I can remember maven generates a marker file or marker directory (starting with a dot) for generated sources. But it's also a long time ago...

Cardwell

Answer 3

We had the same issue on a git branch, while the main branch built fine. The root cause turned out to be a .java source with a duplicate definition of a private void function. This duplicate was caused by a merge from the main branch. At first we did not notice it, because the merge did not cause conflicts. The problem occurred with Amazon Corretto 8 and 11 compilers. After removing the duplicate private void function, the java compiler started generating sources as before.

Bim