You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should remove Lombok from our framework code. There are multiple reasons for that:
Lombok induces some code generation magic. The generated code isn't visible in source jars and javadocs unless adding additional steps that increase build time and build setup complexity (plugins, ordering dependencies)
Using Lombok makes it too easy to provide accidental functionality. In several places, we use @Data instead of multiple annotations. This generates a load of methods that are available for use, sometimes without an explicit intention to do so. The right approach would be adding explicit annotations for each aspect to generate.
Rapid changes in the Java compiler make Lombok a typical component that prevents early Java upgrades.
Eclipse users are required to install a plugin to properly work with our code
On the flip side:
Lombok is handy for data classes/value objects of which we provide a lot of. Code generation is a significant part especially when it comes to hashCode/equals methods. The manual code needs testing and must be maintained.
Lombok makes especially test code slim because it generates a lot of functionality that can be consumed easily with assertions.
The text was updated successfully, but these errors were encountered:
We should remove Lombok from our framework code. There are multiple reasons for that:
@Data
instead of multiple annotations. This generates a load of methods that are available for use, sometimes without an explicit intention to do so. The right approach would be adding explicit annotations for each aspect to generate.On the flip side:
The text was updated successfully, but these errors were encountered: