Lombok has some nice features, but it isn't really Java. To achieve the things it does, it messes with compiler internals, which can and does lead to compatibility problems when switching or upgrading the Java compiler.
This has already caused problems for us when trying to switch to the Eclipse compiler (with its nice incremental compilation) combined with the Eclipse compiler's Groovy support and also with javac when Java 8 was new.
For instance, @lombok.Delegate has been deprecated and marked experimental and "support for this feature may be dropped if future versions of javac or ecj make it difficult to continue to maintain the feature": https://projectlombok.org/features/experimental/Delegate.html
We should switch to an alternative (eg Jackdaw, Immutables, AutoValue) where it makes sense, and simply Delombok the code where there is no practical alternative (eg @Slf4j).
Replacements (draft, subject to change):
extend a type with by keyword and delegate property
var/val properties in primary constructor (with some default values)
var/val in primary constructor
no-arg/jpa plugin for Kotlin compiler
see data class
see data class
public/private/internal property modifiers
data class with var
data class with val
"use" extension method
A (as opposed to A?)
Instead of finding replacements for Lombok's features up front, we are just running Delombok in bulk. This will avoid problems with compilation order when kotlin-maven-plugin is introduced.