This kind of boilerplate code most commonly occurs in cases, you have data transfer objects - objects, that have many fields and very few or (even better!) no business model related code. They are just data structures. In these cases its really useless to generate getter and setter code at all. So the fields are just public and no active or passive code generation is needed at all.
In contrast, a service or system operates on this data. Such classes dont need many fields, because all state information should be stored in the data classes. So there is no need for many getter/setters, too.
To summarize, there may be cases where lombok style frameworks are useful, but right now I dont see this for Terasology (since we have this megacool entity/component thing).
Another approach is used in
playframework where each public field and all its access code is modified to private fields + getter/setter access code on the fly (using asm, I guess).
