From 06ca7f7541348b0ba1b7abb1e175b3f3143232f2 Mon Sep 17 00:00:00 2001 From: Paul Latzelsperger Date: Thu, 23 Mar 2023 15:42:59 +0100 Subject: [PATCH 1/2] docs: add decision record about removing Lombok --- .../2023-03-23_remove_lombok/README.md | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 docs/development/decision-records/2023-03-23_remove_lombok/README.md diff --git a/docs/development/decision-records/2023-03-23_remove_lombok/README.md b/docs/development/decision-records/2023-03-23_remove_lombok/README.md new file mode 100644 index 000000000..cc64cbd02 --- /dev/null +++ b/docs/development/decision-records/2023-03-23_remove_lombok/README.md @@ -0,0 +1,37 @@ +# Remove Lombok from code base + +## Decision + +The Lombok library will be removed from the code base. + +## Rationale + +Lombok uses byte-code modification to achieve its goal. That is dangerous for a number of reasons. + +First and foremost, to achieve its goal, it relies on internal APIs of the JVM, which are not intended for public +consumption, thus they can and will get removed, refactored or made otherwise unavailable. This has been discussed at +length in the [project's GitHub page](https://github.com/projectlombok/lombok/issues/2681). +This is especially problematic for an OSS project such as TractusX. + +Second, many of the features that are currently used by TractusX-EDC are experimental (e.g. `@UtilityClass`) and are +known to break some Java standard features, such as static imports. + +Third, the value that Lombok offers is questionable at best (e.g. various constructor +annotations, `@Builder`, `@Value`), because modern IDEs have ample features to generate boilerplate code. Further, it +makes the code arguably less readable and less debuggable, very non-resilient against +refactoring (`@ToString(of = )`) and more dangerous (`@SneakyThrows`) at runtime. + +Fourth and finally bytecode modification could conceivably cause problems in use cases where audited/certified code is +required. Since the code gets modified during compilation in a way not covered by any spec, technically the runtime code +could be significantly different from the source code. Although this problem is admittedly theoretical at the moment, we +should build those obstructions into the code base. + +## Approach + +- Remove the lombok library from the version catalog +- replace all annotations with actual code +- [optional] add an entry to our coding principles to forbid byte-code modification (lombok, aspectJ,...) + +## Further consideration + +We can even expect a slightly faster build, because "delomboking" will become unnecessary. \ No newline at end of file From ffd95f12226c2c3f38468eb5a64de8672a4e88ca Mon Sep 17 00:00:00 2001 From: Paul Latzelsperger <43503240+paullatzelsperger@users.noreply.github.com> Date: Thu, 23 Mar 2023 21:35:40 +0100 Subject: [PATCH 2/2] Update README.md --- .../decision-records/2023-03-23_remove_lombok/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/development/decision-records/2023-03-23_remove_lombok/README.md b/docs/development/decision-records/2023-03-23_remove_lombok/README.md index cc64cbd02..74938d373 100644 --- a/docs/development/decision-records/2023-03-23_remove_lombok/README.md +++ b/docs/development/decision-records/2023-03-23_remove_lombok/README.md @@ -24,7 +24,7 @@ refactoring (`@ToString(of = )`) and more dangerous (`@SneakyThrows`) Fourth and finally bytecode modification could conceivably cause problems in use cases where audited/certified code is required. Since the code gets modified during compilation in a way not covered by any spec, technically the runtime code could be significantly different from the source code. Although this problem is admittedly theoretical at the moment, we -should build those obstructions into the code base. +should not build those obstructions into the code base. ## Approach