Lombok: javac annotationprocessor problem with static imports

[metas-ts]

We have a rather large code base and never had any real problems with lombok..

until this morning, it stopped working in one particular (maven-)module.

You can see a failed build in our jenkins (you should be able to log in with a github account): https://jenkins.metasfresh.com/job/metasfresh/job/gh4033-material/16/consoleFull

I'm also attaching the output: failed_build_lombok_javac.txt.zip
I looked at the file starting at line 173098, but didn't find anything that could help me.

I tried to figure out what's going on using this maven compiler config:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <compilerReuseStrategy>alwaysNew</compilerReuseStrategy>
        <showWarnings>true</showWarnings>
        <useIncrementalCompilation>false</useIncrementalCompilation>

        <verbose>true</verbose>

        <!-- i know, this shouldn't be neccesary, but I hoped to get some sort of response from javac -->
        <!-- also, i found a comment in https://github.com/rzwitserloot/lombok/issues/1339 to claim that this once helped -->
        <annotationProcessorPaths>
            <path>
                <groupId>org.projectlombok</groupId>
                <artifactId>lombok</artifactId>
                <version>${lombok.version}</version>
            </path>
        </annotationProcessorPaths>

        <fork>true</fork>
        <compilerArgs>
            <arg>-XprintRounds</arg>
            <arg>-XprintProcessorInfo</arg>
        </compilerArgs>

        <source>1.8</source>
        <target>1.8</target>
    </configuration>
</plugin>

Note that I would have expected javac to give me some infos due to the -XprintRounds and -XprintProcessorInfo, but I can't see any.

Additional notes:

• it still works in eclipse
• i tried with
  
  
  
  • jdk versions 1.8.0_172 (locally) and 1.8.0_152 (on jenkins)
  
  
  • lombok versions 1.16.16, 1.16.22 and 1.18.0
  
  
• it worked until i pushed my stuff to github this morning...i think the breaking change is somehwere in here (disclaimer - i'm afraid there is too much in there to spot the problem): https://github.com/metasfresh/metasfresh/compare/da6443708108ebcb7cdf824f1998f46e41b60db2...ffba5842ad72dc4b8b4afc5571d6592a3900d621

Maybe there is a way to raise lombok's log level while it's called (if it's called) from javac?
Feel free to create a fork of https://github.com/metasfresh/metasfresh, play with it and see what our jenkins has to say. Within our repo, they problematic module is here: https://github.com/metasfresh/metasfresh/tree/gh4033-material/de.metas.material/dispo-commons
Apart from asking you guys, the only way forward I can see is to remove all annotations one by one (and replace them with ugly code), until maven can build it again.

Best regards Tobi

[metas-ts]

Hm..according to this guide: http://www.javatronic.fr/articles/2014/08/31/how_to_make_sure_javac_is_using_a_specific_annotation_processor.html is seems as if lombok's annotation processor is simply not loaded..so ther is also no point in step-by-step removing annotations..

[victorwss]

We have a rather large code base and never had any real problems with lombok..
until this morning, it stopped working in one particular (maven-)module.

Well, since it is working with the other modules, you should look for what is different from one module to the other. What the pom.xml of the other working and lombok-useing modules features have different from this one?

Your logs make it clear that you are using lombok 1.16.22. What happens if you try lombok 1.1.8.0?

[Maaartinus]

No idea, but...

• There are [ERROR]s before line 173098.

• Are you aware of git bisect? Assuming you can run the build automatically from a script which can recognize build failure, git bisect can be fully automated. As your problem is compilation, you can build with tests switched off to make it faster.

[metas-ts]

@victorwss

Well, since it is working with the other modules, you should look for what is different from one module to the other

I looked for (significant) differences, but couldn't find any so far.

Your logs make it clear that you are using lombok 1.16.22. What happens if you try lombok 1.1.8.0?

basically the same problem happens.

@Maaartinus

There are [ERROR]s before line 173098.

Yes, those are failing tests..they worked with lombok 1.16.16 and started to occur when i tried to solve this problem by using 1.16.22. or 1.18.0. I didn't yet look into them. But the build is not failing on test errors (i rather collect them and flag the build as unstable).

Are you aware of git bisect?

Never used it, but read about it this morning before I decided to first take a different approach.
I wanted to take maven out of the equation and see if i can't get "plain javac" to do that annotation processing.

So I copy&pasted the javac command line parameters into a .bat file (i'm on windows) and experimented with them..
Among others, i have these parameters:

-Xprefer:source -proc:only -XprintRounds -XprintProcessorInfo ^
-processor lombok.launch.AnnotationProcessorHider$AnnotationProcessor ^
-processorpath C:\Users\ts\.m2\workspace_mf\org\projectlombok\lombok\1.16.22\lombok-1.16.22.jar; ^

I have the proc:only because i thought maybe a default setting of -proc:none is defined "somehwere"..
Strange enough, one time i got some "rounds" infos being printed in my output. The rest of the times, it seems as if even the -proc:only is ignored.

I verified that the lombok-1.16.22.jar file is valid (I mean it seems to be a not-corrupted jar and btw, ofc it has the META-INF\services\javax.annotation.processing.Processor file in it).

I also run mvnDebug and attached to the process. I set a breakpoint in AnnotationProcessorHidercreateWrappedInstance which was hit. But my breakpoints in AnnotationProcessor.getSupportedOptions() and ..getSupportedAnnotationTypes() were not.

I guess i'll now take a deeper look at git bisect and also look once more for differences between modules.

[metas-ts]

git bisect told me it's this commit: https://github.com/metasfresh/metasfresh/commit/c2a98c26ea78e7036876404d2c2b94335ce7304f (which i suspected..the problem is that i did a lot of stuff in there :blush: )

thx for the tip, I'm happy to have learned that it's somewhat deterministic in that one commit before, the maven build still works on my local box with everything else unchanged.

[Maaartinus]

@metas-ts

which i suspected..the problem is that i did a lot of stuff in there

That's a problem. Commits should be small... but no matter how hard I try, sometimes, I get a bunch of meaningless commits I have to either spend a one more day on or simply squash into one nice commit. I always squash them, but keep the history in a backup branch privately, in case I need it for a case like yours.

As your current problem is that Lombok does nothing at all, it might help to create a trivial file for testing it. Anyway, I guess, the problem is caused some pom.xml and you may be able to reproduce the problem by picking one of them into a previous commit. Just guessing, good luck!

[metas-ts]

@Maaartinus
having spent half the day googling this issue, I can see why you put your money on a pom.xml related reason ;-).

However, it looks like I was able to fix the compile, and it turns out the problem was triggered by mixing lombok stuff with static imports. Here is what I did to un-break my build: https://github.com/metasfresh/metasfresh/commit/783294f75f32fc142d2f0db8bde7fa02083bbeb4

[Maaartinus]

@metas-ts For me, maven is a disease with many possible symptoms and the first candidate to blame. Missing your cat? Look in pom.xml!

There are known and incurable problems with static imports which IIUIC are available only after Lombok runs. They're in general unusable in annotations like @EqaHC(callSuper=MY_IMPORTED_BOOLEAN_CONSTANT), but no idea why they don't work in your case.

I only use static imports for Guava's Preconditions and one or two similar cases and never had a problem.

[rspilker]

The problem in this case is a static import. The problems with this is that if you refer to a type that will be generated by an annotation processor, javac is going to freak out.

For some reason, javac tries to resolve static imports too early in the process. This causes an error, IIRC already during parsing. And if an error exists in that phase, the annotation processors are not triggered at all. None of them. So lombok does not get a chance to generate the code, or give a better error message.

Please file a bug report at Oracle, we cannot fix this.