Hi all, I would be -1 on introducing Lombok into Flink's main sources.
My main concern is the published sources jar. Flink core artifacts are consumed as libraries, and a very common workflow is attaching the IDE debugger to a running JobManager or TaskManager and stepping through framework code with the published sources attached. That only works correctly when the shipped sources are exactly what the bytecode was compiled from. With Lombok, there are 2 ways to publish the sources jar, and each one breaks part of that workflow: 1. Publish the annotated sources as-is - In this case, the shipped source no longer represents what is actually executing. The generated members (constructors, getters, builders, equals and hashCode) exist only in the bytecode, and whenever the debugger lands in one of them, the frame maps to a misleading line such as the annotation or a field declaration. The method you are trying to debug is simply not there in the source, so you cannot follow that code path correctly. 2. Publish the delomboked sources so that generated code becomes visible - In this case, the compiler never sees the delomboked code, it compiles the annotated one, and the delomboked code does not preserve the line numbering the classes were compiled with: it strips the Lombok imports and annotations, inserts the generated bodies, and reformats. Whether any handwritten line still matches the bytecode becomes accidental (in a small test with Lombok 1.18.42 on JDK 17, a handwritten method drifted by one line, which makes breakpoints stop on the wrong statement). The generated members do not line up either, since the bytecode maps them to the annotation or field line while the delomboked file shows their bodies elsewhere, so a breakpoint placed inside a generated member either never fires or stops somewhere unrelated. This is the same class of pain as Aleksandr mentioned, except it hits users instead of Flink developers. Option 2 also puts delombok into the release pipeline as one more tool that has to keep up with every Java language level Flink builds against. So while I agree delombok makes migrating off Lombok mechanical, I do not think it solves the sources problem while Lombok is in use. This concern is specific to code shipped as a library. For a deployed application like the Kubernetes operator, nobody attaches sources jars to debug it, so Lombok works well there. flink-core and the other artifacts that users build on and step through are a different situation, and for those I see staying Lombok-free as a hard requirement. Best, Dennis On Wed, Aug 26, 2026 at 8:32 AM Gyula Fóra <[email protected]> wrote: > 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 > > > > > > > > > > > > >
