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
