+1 also not a fan of Lombok, have already Delomboked a few projects because it just adds extra complexity / less debuggability
> On 24 Dec 2021, at 10:20, Konrad Windszus <[email protected]> wrote: > > Hi, > to be honest I am rather opposed to that idea as Lombok has the following > disadvantages from my PoV: > > - Incremental builds in Eclipse require a dedicated plugin > - You need to know Lombok before you can understand the code in some cases > - Another third party library > - Refactoring support of IDEs > > IMHO we don't have that much getters/setters in Sling code. > For the long term we should rather use records > (https://docs.oracle.com/en/java/javase/15/language/records.html > <https://docs.oracle.com/en/java/javase/15/language/records.html>) instead of > Lombok to reduce boilerplate code. > > Is there a particular Sling module where there is a lot of boilerplate code > we should get rid of? > Regards, > Konrad > >> On 23. Dec 2021, at 22:46, Paul Bjorkstrand <[email protected]> >> wrote: >> >> I am not a huge fan of boilerplate code, and getters/setters are my biggest >> pet peeve. I searched the dev archives and found nothing that referenced >> Lombok. Is there a reason it has not yet been introduced that I am not >> aware of? If not, what is everyone's opinion around using Lombok within >> Sling? I looked at the license, and it seems to be near-identical to HPND >> [1] and HPND is one of ASF's Category A licenses [2]. It uses/includes ASM >> [3] which uses a 3-clause BSD license [4], also one of the Category A >> licenses. >> >> While I wouldn't recommend allowing _everything_ from Lombok to be used, I >> think it would be fair to allow the use of a subset of the features. I >> would recommend the following approach: >> >> These stabe features of Lombok [5] can be used without restriction: >> - @Getter/@Setter >> - @ToString >> - @EqualsAndHashCode >> - @NoArgsConstructor/@RequiredArgsConstructor/@AllArgsConstructor >> - @Data/@Value (at least until we can use records [6], introduced in JDK >> 14, finalized in JDK 16) >> - @Builder >> - @Slf4j >> >> All other stable features would be evaluated on a per-use basis. All >> experimental features would not be allowed to be used. >> >> These seem, to me, to be reasonable guidelines, and align with the usages I >> have seen in other places (including my own projects). >> >> [1]: https://opensource.org/licenses/HPND >> [2]: https://www.apache.org/legal/resolved.html#category-a >> [3]: https://asm.ow2.io/index.html >> [4]: https://opensource.org/licenses/BSD-3-Clause >> [5]: https://projectlombok.org/features/all >> [6]: https://docs.oracle.com/en/java/javase/14/language/records.html >> >> >> -Paul >
