Hey, In general I am also +1 on the proposal but I don't feel super strongly about this if there is a community pushback.
However, having used lombok in a large number of projects including the operator over the years, I never really encountered any pain either related to being forced to migrate off or any JDK incompatibility, debugging difficulty etc. As long as we stick to the most useful and standard features I think it's a great lib to greatly reduce boilerplate. For anything that is already covered by JDK 17 or newer versions, of course we should lean for the standard features. Cheers Gyula On Wed, Aug 26, 2026 at 7:09 AM Samrat Deb <[email protected]> wrote: > > Hi all, > > > > Thank you, Ferenc, Sergey, Martijn and Aleksandr, for the thoughtful > feedback. Going through the thread, there is no consensus on codebase-wide > Lombok adoption, and I don't want to push in that direction. As it is > clearly flagged over the discussion that we shouldn't refactor existing > code just for this. I fully agree. > > Let me narrow the proposal and respond to the specific points. > > > 1. On Martijn's suggestion (records instead of Lombok) > > I agree that for simple immutable value classes, records are the more > natural, dependency-free answer, and I'd prefer them where they genuinely > fit. The practical catch is our source level: it's still 11 by default, and > the release profile still targets Java 11 bytecode, while records need > source java 17. So "records project-wide" is effectively coupled to > dropping Java 11. > This is a larger, separate decision. > - Is there already appetite or a roadmap for moving the source level to 17? > If so, I'm happy to fold the value-class cases behind that effort as the > primary path. > - Even with records, the two classes I cited aren't clean fits: > a. For example, S3BucketConfig has 13 mostly-optional (@Nullable) > fields and already hand-rolls a Builder. A record gives a 13-arg canonical > constructor, not a builder, > so the builder boilerplate stays. > > > b. For example, S3BlockLocation implements the core BlockLocation > interface, whose contract is JavaBean getters > (getHosts/getOffset/getLength). > A record exposes component accessors (hosts()/offset()/length()), > so it doesn't satisfy that interface without extra hand-written methods. > > > 2. On maintenance and migration risk > A point about Lombok's commit cadence is fair and worth keeping in view. Two > things bound that risk for the narrow scope I'm proposing: > > 1. The annotations we'd actually use will be confined to stable and mostly > used methods in flink codebase, such as (@Getter/@Builder/@Value). These > are mature and stable. They don't need active development. The one area > that genuinely needs upkeep is new JDK support, and the track record there > has been fast, as Ferenc rightfully called out for JDK 17/21/25 examples. > > > > 2. It's compile-time only, and `delombok` can expand the annotations back > into plain Java source. So if the project ever stalls, migrating off is > mechanical rather than a rewrite — which also speaks to Martijn's "painful > to migrate off" concern. As Ferenc suggested, I'd also keep us to the > boring, non-experimental annotations (no @UtilityClass and friends), which > is both a readability and a risk decision. > > > We can choose from the following approaches : > > 1. Lombok (@Builder/@Getter/@Value): smallest footprint, compile-time only > with provided scope so zero impact on the shaded fat JARs these modules > produce. The downsides raised are javac patching, IDE setup, and > stack-trace remapping. > > 2. Use AutoValue / Immutables: standard JSR-269 annotation processors [1] > that generate real source and do NOT patch javac internals, so they > sidestep the JDK-compat concern and keep stack traces clean, while still > giving first-class builders. Cost is a generated companion type and a bit > more ceremony. > > 3. We can also decide to keep the current code as it is and expedite the > Java 17 track. > > Looking forward to know thoughts on this. > > Bests, > Samrat > > [1] https://jcp.org/en/jsr/detail?id=269 > > > On Fri, Aug 21, 2026 at 8:16 PM Aleksandr Iushmanov <[email protected]> > wrote: > > > 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 > > > > > > > > >
