Style Guide: lombok

[javier-godoy]

There should be some guideline about whether vanilla code is allowed / tolerated / forbidden in a Java project that is already using Lombok.

[paodb]

In my opinion, regarding whether vanilla code should be allowed, tolerated, or forbidden, I lean towards a mix of 'tolerated' and 'conditionally allowed.' Forbidding it entirely seems counterproductive, as a full-scale refactor of stable code could introduce unnecessary risk for little gain (if an update to remove all of it was not requested, of course). I think the approach should be "if it isn't broken, don't fix it." Therefore, my suggestion is to tolerate vanilla code in existing classes that don't need changes, while allowing it for specific exceptions. For all new development, however, we should standardize on Lombok to boost productivity I feel this approach would help us modernize our codebase organically and safely, without diverting resources to low-impact changes.

If we agree on an strategy, we should have some guidelines regarding the use of Lombok. Here’s an initial proposal:

Guidelines for Using Lombok in a Mixed Codebase

Existing classes

• If a class already exists and uses manually written constructors, getters, setters, etc., and there’s no actual need to modify it, do not rewrite it just to use Lombok.
• If you're working on an existing class and making meaningful changes (e.g., adding fields or methods), it’s acceptable to migrate to Lombok where it improves readability and reduces boilerplate.

New classes

• New classes should use Lombok annotations (@Getter, @Setter, etc.).

Exceptions

• In cases where Lombok introduces technical issues (e.g., framework limitations, tooling problems), vanilla code may be used.
• Any exception to Lombok usage should be justified and documented in the code or the relevant pull request.

Tips

• Try to maintain internal consistency: avoid mixing manual and Lombok-generated methods within the same class unless justified.
• Use your judgment: consistency and readability are important, but avoid unnecessary changes.

[Totremont]

In cases where Lombok introduces technical issues (e.g., framework limitations, tooling problems), vanilla code may be used.

Regarding this, lombok, by default, can't be used if you need to add extra initialization code to a constructor. A solution is to create a separate method, move the initialization there and add @PostConstruct to it. That way you can clean off the constructor, use lombok again and reduce boilerplate. Is this a good approach?

[javier-godoy]

In cases where Lombok introduces technical issues (e.g., framework limitations, tooling problems), vanilla code may be used.

Regarding this, lombok, by default, can't be used if you need to add extra initialization code to a constructor. A solution is to create a separate method, move the initialization there and add @PostConstruct to it. That way you can clean off the constructor, use lombok again and reduce boilerplate. Is this a good approach?

Only if the class is intended as a Spring/CDI managed bean.