changing the code lombok generates

82 views
Skip to first unread message

Viktor Engelmann

unread,
Jul 11, 2025, 8:06:40 AMJul 11
to Project Lombok
Hello everyone,

I'm trying to eliminate lots of boilerplate-code at the company
where I work. Our getters and setters aren't the default
      public int getFoo() { return foo; }
getters and setters though. Our getters and setters trigger gui
redraws and such. I have searched for a way to change the
code lombok generates for the getters and setters, but I couldn't
find anything beyond changing the prefix or capitalization
of the method-names.

Can't you have a config option where you set a string like
lombok.getter.code = "%p %t get%N () { return %n; }"
lombok.setter.code = "%p void set%N(%t foo) { %n = foo; }"
or something like this?

Kind regards
Viktor

Mat Jaggard

unread,
Jul 11, 2025, 8:21:11 AMJul 11
to project-lombok
I'm afraid that's not how Lombok works - it doesn't create Java code (except for Delombok) it creates bytecode so it would be very difficult, maybe impossible, to implement a new Java compilation step for a template like this.

Have you looked at AOP to solve your problem?

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/project-lombok/d7276570-b972-40d6-9cc8-c6c41ffa35a1n%40googlegroups.com.

Viktor Engelmann

unread,
Jul 15, 2025, 6:03:01 PMJul 15
to Project Lombok
Thank you for your answer. I have never written a compile-time preprocessor, but I would expect that such a preprocessor would be given a reference to a java compiler object. So lombok could check whether these variables are set - and if so, could generate the string and run it through that compiler to generate the bytecode. I'm guessing though.

Roland Praml

unread,
Jul 22, 2025, 5:55:23 PMJul 22
to project...@googlegroups.com
You may take also a look at java agents.

Lombok isn't only an Annotation processor. It accesses and manipulates internal compiler states/Syntax trees etc. mostly over non official APIs. So the learning curve is very steep. 

A java agent can be simply attached to a JVM, gets the bytecode as byte array before a class is loaded and can replace that bytecode. 

To manipulate the bytecode, you need a parser library (like ASM) to transform the bytecode. 

There are lots of samples e. g.:


Note: Normally, an agent needs to be loaded at runtime (which may add performance overhead) but it is also possible to transform the bytecode at compile time (we use the ebean-maven-plugin that applies the ebean-agent at compile time)

Compared to lombok or AOP you may even nedd not to add additional annotations to  your legacy classes (see the maven-color example in the link above) 

I would suggest to experiment a bit with java-agents. If you have understood the concept, it should be easier to adapt that to lombok or AOP. (they all have to manipulate an abstract syntax tree somewhere) 

Roland


Reply all
Reply to author
Forward
0 new messages