Will this enable lombok officially?
Lombok wouldn't be nearly as troubled if it was just doing simple bytecode manipulation.
If lombok wants to stop the pain, then they'll need to stop reaching into internal APIs. They'll possibly need to remove a few features (like some of the `private final` work they are doing).
In other words, you can expect lombok to be a headache for years to come. (Maybe consider not using it? That'd be swell. Speaking as someone that curses lombok everytime jdk updates roll around.)
Even before records, just use public final fields, and be done with the getter/setter nonsense. (IDEs do a good job of offering options for toString(), and c-tors)
Personally, I consider lombok one of the better anti-patterns widely used.
I personally use the @Builder annotation on records with more than 3-4 fields. I find it much more readable than a long list of arguments to the constructor.
It also makes it easy to return a copy of the record where only a few fields have changed:
var r = book.toBuilder()
.lastUpdated(now)
.title("...")
.build()
Unlike compiler extensions, Lombok compiles source files that do not conform to the Java language specification. Lombok is an alternative Java Platform language, like Clojure or Kotlin or Scala, except that it's a superset of the Java language. However, rather than forking `javac` source code and modifying it to compile Lombok source files, the Lombok compiler modifies `javac`'s operation by hacking into its internals and modifying them as it runs to compile Lombok sources rather than Java sources.
Having alternative Java Platform languages is perfectly fine. The problem with Lombok is that it doesn't present itself as such but as a library or a compiler extension even though it violates the Java language specification in ways that compiler extensions are forbidden from doing.