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
