But I still have this message when ./gradlew build:
The following annotation processors were detected on the compile classpath: ‘lombok.launch.AnnotationProcessorHider$AnnotationProcessor’ and ‘lombok.launch.AnnotationProcessorHider$ClaimingProcessor’. Detecting annotation processors on the compile classpath is deprecated and Gradle 5.0 will ignore them. Please add them to the annotation processor path instead. If you did not intend to use annotation processors, you can use the ‘-proc:none’ compiler argument to ignore them.
Also I don’t see reduction of complication time. I compare 4.6 and 4.7-rc with --profile flag, compilation time is the same.
About why: this is simple, the reason why we need incremental annotation processing is to reduce compilation time. No need to recompile whole project when I’ve just changed one class.
Lombok does not support incremental annotation processing at the moment. As the release notes say, processors need to opt in.
You’re getting the warning because you made lombok an implementation dependency, so it’s processor also leaks into test compilation. Either make it compileOnly or add it to the testAnnotationProcessor path.
Lombok should be changed to properly separate it’s annotations from its processors to avoid this annoyance for users. Dagger (shown in our docs) does this correctly, they have a library jar and a processor jar.
BTW, they said that they support incremental annotation. Maybe you can go to github and clarify to lombok team this moment?
I understand that lombok is not your project, but this is one of the most popular lib. I think this is important to have support of this feature.
The problem is that Lombok does things that the Java compiler does not officially support and uses lots of internal APIs to do that. All these internal usages mean that the Lombok devs have to add workarounds for every environment that Lombok runs in, including Gradle. We can’t really help there beyond providing suggestions.
Lombok should be changed to properly separate it’s annotations from its processors to avoid this annoyance for users. Dagger (shown in our docs) does this correctly, they have a library jar and a processor jar.
Dagger has an annotation processor and a runtime library. Lombok has no runtime library. It’s JAR could be split into annotations and the processor, but it makes little sense as at compile time you need both and then you need neither. It also hides its non-API classes using some classloader magic, so everything works fine as is.
IMHO it works best as is: The same JAR file used both in apt and compile.
PS: Lombok does not belong on the runtime classpath, but even this was harmless - I did this last year out of laziness and it caused no problems (deploying 1.5 MB more didn’t matter).
Why would you want its implementation details on your compile classpath? It just means that Gradle has to analyze more classes when doing up-to-date checks and your IDE will propose those types during auto completion even though you should never reference them. Also the lack of separation means that a lot of people end up putting it on their runtime classpath, unnecessarily bloating their deployables.
Why would you want its implementation details on your compile classpath? It just means that Gradle has to analyze more classes when doing up-to-date checks
I don’t really want them on the compile classpath, but using a single JAR is simpler than using two. There are 40 MB to analyze, so I don’t care about gradle having to analyze 1.5 MB more. I guess, such an analysis is much faster than anything else.
But sure, this is a valid argument.
and your IDE will propose those types during auto completion even though you should never reference them.
No, it does not. Lombok hides itself (completely, except for the API).
Also the lack of separation means that a lot of people end up putting it on their runtime classpath, unnecessarily bloating their deployables.
I guess, using something both as the annotation processor and on the runtime classpath is worth a warning.
I’m just a Lombok user explaining why I don’t really think that such a separation is a good thing. I guess, its authors would agree.
