I also use Lombok almost universally for Java files, so I understand its importance! I was paying attention to the stub-compilation approach, which would still run through javac and thus native Java files would be affected. If you're thinking more on the joint side, then I'd have to think more before having something useful to contribute.
Implementing javax.annotation.processing would cover a lot of surface area because it exposes the Java AST (via the RoundEnvironment methods) and the entire TypeMirror "Spock in a goatee" representation of the Java classes under processing. This means that the Groovy AST would need *two* facades, and irritatingly the javac implementations are all unexported (which has been causing me problems in my Java annotation processors when using reflective property access). On Thu, Jun 29, 2023 at 1:22 PM Jochen Theodorou <blackd...@gmx.org> wrote: > On 29.06.23 19:28, Christopher Smith wrote: > > One note I'll add is that while Lombok was presented as an example of a > > Java annotation processor, it really isn't—it's a monkey-patch of javac > > itself, as otherwise annotation processors can't modify classes, just > > add new ones. > > I am actually aware of that... they even have different "hacks" for > javac and jdt. Sadly lombok is for me one of the most used annotation > processors and I would not like to dispose of it in Java files I cannot > replace with Groovy > > > Regarding "regular" annotation processors, it would be > > possible to implement the javax.annotation.processing interfaces to > > resolve from the Groovy AST structures, though this would be decidedly > > non-trivial. > > Why do you think that this would be non-trivial? > > bye Jochen > >
