Hi Samrat, Thank you for starting the discussion.
I am -0 to this idea and as mentioned before would prefer native Java constructs like Record to third party annotations. I understand how it could help with boilerplate reduction, but I also remember the pain of "remapping" code line numbers from stack traces when debugging production incidents + extra friction on setting up IDE to work with lombok annotations. While these are non-blocking considerations, I don't have a feeling that the pros outweigh the cons at the moment. Kind regards, Aleksandr Iushmanov On Fri, 21 Aug 2026 at 11:30, Ferenc Csaky <[email protected]> wrote: > > 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 > > >
