> The boilerplate it removes is real, but Lombok patches javac > internals, which makes JDK compatibility a lot harder to keep, > especially considering we already maintain a wide JDK surface.
True, but how real that risk is in our case? AFAIK this basically means Lombok needs to support any newly released Java version than Flink. Historically they are doing that pretty fast: JDK 17: Lombok ~3 weeks > Flink ~2 years JDK 21: Lombok 1 day > Flink ~6 months beta / ~18 months official JDK 25: Lombok before GA > Flink still not officially supported I can understand that we may not necessarily want to tie the codebase to some lib that would be painful to migrate off from later, and all in to always prefer built-in Java constructs instead of some 3rd party lib (record vs @Value). IMO the ctor, @Getter, @Setter, and maybe @Data annotations would be quite useful on their own. > Another point: I'm not really sure about Lombok maintenance: just look > at their git history[1]. Haha, they just pushed 18 commits today (Aug 21st). I did not really take a deeper look on Lombok's maintenance regimen, but considering what Lombok does as a product I do not necessarily see that really concerning. The widely used functionality of it is done since years, and there is no need to reinvent the wheel. Their GH Issues are in a pretty rough shape though [1]. Anyways, I do not want to seem like I wanna push Lombok integration into Flink pretty hard, but personally I still see more pros than cons of it. I might add my opinion about Mockito is kinda the same. :) Best, Ferenc [1] https://github.com/projectlombok/lombok/issues On Thursday, August 20th, 2026 at 20:53, Martijn Visser <[email protected]> wrote: > I'd probably be -1 on this. The reason it's in flink-core is > test-scoped and used to verify that serialization and type extraction > work correctly with Lombok-generated types. > > The boilerplate it removes is real, but Lombok patches javac > internals, which makes JDK compatibility a lot harder to keep, > especially considering we already maintain a wide JDK surface. I'm > also not in favor of tooling that's painful to migrate off later > (looking at you, Mockito). For the value-class cases being cited, > wouldn't it make more sense that we push the source language level to > Java 17 so records can be used project-wide? > > Thanks, Martijn > > Op do 20 aug 2026 om 17:56 schreef Sergey Nuyanzin <[email protected]>: > > > > Hi Samrat > > > > I'm about +0 to this > > as it was already mentioned it would be better to avoid refactoring > > existing code just because of this. > > > > Another point: I'm not really sure about Lombok maintenance: just look > > at their git history[1]. > > They have less than 10 commits in the last 4 months. > > Compared with what was before that (multiple commits per week) it is > > at least a cause for the concern. > > > > [1] https://github.com/projectlombok/lombok/commits/master/ > > > > On Thu, Aug 20, 2026 at 5:43 PM Ferenc Csaky <[email protected]> wrote: > > > > > > Hi Samrat, > > > > > > +1 for Lombok integration on the source level. It's basically a very > > > widely used > > > "standard" Java lib to reduce Java bloat. And we already have examples > > > under the > > > Flink umbrella as well: the K8s operator uses it since its development > > > started > > > [1]. > > > > > > Since Flink defines project-wide deps in its root POM, I think we can > > > include > > > Lombok there, and then any module will be able to use it in the future > > > and it > > > won't be necessary to add it as a dependency for each module. > > > > > > From a Java code perspective my suggestion would be to not do a bigger > > > refactor > > > that targets Lombok introduction to the codebase as its sole purpose. > > > Instead, > > > if we touch some code, we can update the relevant parts. > > > > > > We should probably update our checkstyle configuration to: > > > - respect Lombok usage (maybe works just fine without further changes) > > > - restrict experimental Lombok features (maybe, cause personally I find > > > some > > > of them too magical, e.g. @UtilityClass) > > > > > > Also curious what others think? > > > > > > Best, > > > Ferenc > > > > > > [1] > > > https://github.com/apache/flink-kubernetes-operator/blob/747273b20460e1b7a637b97c1c9b6a3fbb4b2483/flink-kubernetes-operator/pom.xml#L119 > > > > > > > > > > > > > > > On Tuesday, August 18th, 2026 at 20:34, Samrat Deb > > > <[email protected]> wrote: > > > > > > > Hi all, > > > > > > > > I’d like to propose using Lombok[1] in the Flink codebase beyond tests. > > > > Flink already uses Lombok 1.18.42 in flink-core tests [2], but not > > > > beyond > > > > that. > > > > There are many places where Lombok can be useful and avoid repetitive > > > > code > > > > across the codebase. For example, the native S3 module has a few simple > > > > value classes, such as S3BlockLocation[3], S3BucketConfig[4], and > > > > others, > > > > where Lombok could remove repetitive constructors and getters. > > > > > > > > Bests, > > > > Samrat > > > > > > > > [1] https://projectlombok.org/ > > > > [2] > > > > https://github.com/apache/flink/blob/2b9453a6d11d091e8a734e1fc0b0abc49e45628a/flink-core/pom.xml#L177 > > > > > > > > [3] > > > > https://github.com/apache/flink/blob/2b9453a6d11d091e8a734e1fc0b0abc49e45628a/flink-filesystems/flink-s3-fs-native/src/main/java/org/apache/flink/fs/s3native/S3BucketConfig.java#L39 > > > > [4] > > > > https://github.com/apache/flink/blob/2b9453a6d11d091e8a734e1fc0b0abc49e45628a/flink-filesystems/flink-s3-fs-native/src/main/java/org/apache/flink/fs/s3native/S3BlockLocation.java#L25 > > > > > > > > > > > > -- > > Best regards, > > Sergey >
