[BUG] static import of @UtilityClass method causes annotation processing to fail

[muhmud]

Describe the bug
If you perform a static import of one of the methods from a class annotated with @UtilityClass from within the same project, i.e. not via a dependency, annotation processing completely fails, and you get compilation errors for other unrelated classes that use lombok annotations.

To Reproduce
As described above, simply create a class annotated with @UtilityClass and do a static import of one of its methods from another class. Also add some other code with lombok annotations. You should get spurious compilation errors. This only occurs when running maven build commands and not from the IDE.

Expected behavior
The static import should be handled without issue.

Version info (please complete the following information):

• Lombok 1.18.16
• javac, both 1.8.0_152 and 11.0.8

Additional context
The effect is as though lombok annotations are not being processed at all, and for a long time I thought this was the case, only to narrow it down to this.

[randakar]

Duplicate of #2044 Not really possible to fix, unfortunately. Javac tries to resolve imports before lombok has run, at which point the methods haven't been generated yet.

…

On Fri, Oct 23, 2020, 15:43 Muhmud Ahmad ***@***.***> wrote: *Describe the bug* If you perform a static import of one of the methods from a class annotated with @UtilityClass <https://github.com/UtilityClass> from within the same project, i.e. not via a dependency, annotation processing completely fails, and you get compilation errors for other unrelated classes that use lombok annotations. *To Reproduce* As described above, simply create a class annotated with @UtilityClass <https://github.com/UtilityClass> and do a static import of one of its methods from another class. Also add some other code with lombok annotations. You should get spurious compilation errors. This only occurs when running maven build commands and not from the IDE. *Expected behavior* The static import should be handled without issue. *Version info (please complete the following information):* - Lombok 1.18.16 - javac, both 1.8.0_152 and 11.0.8 *Additional context* The effect is as though lombok annotations are not being processed at all, and for a long time I thought this was the case, only to narrow it down to this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2625>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABIERN5E7T4ZIGLSSGELO3SMGCBBANCNFSM4S4SRCHA> .

[randakar]

Note that this issue is explicitly mentioned in the small print of the documentation: https://projectlombok.org/features/experimental/UtilityClass

…

On Fri, Oct 23, 2020, 15:59 Floris Kraak ***@***.***> wrote: Duplicate of #2044 Not really possible to fix, unfortunately. Javac tries to resolve imports before lombok has run, at which point the methods haven't been generated yet. On Fri, Oct 23, 2020, 15:43 Muhmud Ahmad ***@***.***> wrote: > *Describe the bug* > If you perform a static import of one of the methods from a class > annotated with @UtilityClass <https://github.com/UtilityClass> from > within the same project, i.e. not via a dependency, annotation processing > completely fails, and you get compilation errors for other unrelated > classes that use lombok annotations. > > *To Reproduce* > As described above, simply create a class annotated with @UtilityClass > <https://github.com/UtilityClass> and do a static import of one of its > methods from another class. Also add some other code with lombok > annotations. You should get spurious compilation errors. This only occurs > when running maven build commands and not from the IDE. > > *Expected behavior* > The static import should be handled without issue. > > *Version info (please complete the following information):* > > - Lombok 1.18.16 > - javac, both 1.8.0_152 and 11.0.8 > > *Additional context* > The effect is as though lombok annotations are not being processed at > all, and for a long time I thought this was the case, only to narrow it > down to this. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#2625>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABIERN5E7T4ZIGLSSGELO3SMGCBBANCNFSM4S4SRCHA> > . >

[muhmud]

True; I usually read the small print, but must have missed it.