Lombok 2.0 - leaving the past behind

[Neale Upstone]

Hi,

I've recently been working on PRs to bring support for JSpecify nullability standards into Lombok, and it's been entertaining.

Lombok is an amazing tool, and so many projects have a lot to thank Roel and Reinier for.  So, thank you both.

From my experience and looking at the number of issues that don't have PRs - and PRs that are not engaged with, I think Lombok needs to become simpler to work with.

The key difficulties I found were getting up and running in a modern IDE, and having to indulge in some nostalgia by installing and using Eclipse when I needed to debug.

I propose that future contributions can be made notably simpler via a Lombok 2.0 release with the following changes:
- Support only non-LTS releases since the last LTS.  i.e. at the moment we'd support JDK 26 and JDK 27-ea

- Drop support before JDK 17.

- Migrate the build to Gradle

This would:

- Allow use of all modern IDEs

- Allow the use of modern APIs within the JDK

- Allow some code paths to be simplified 

- Provide a foundation for support around notable language changes coming such as value types and explicit nullability.

How open are you Roel and Reinier to a bold step like this?

Thanks,
Neale

[Timothy Spear]

I am not a contributor, just a user.

I have not seen an official EOL policy by Lombok. I would be in favor of having one.

A few suggestions.

1. Support oldest LTS release under Extended Support. Currently Java 8 until Dec 2030.

2. Support oldest LTS release under Premium Support on go forward. Currently Java 17 until Dec 2026. With security patches for oldest branch/release until Extended support ends.

3. Or follow something like Spring. Three years from major release, 13 months for minor releases. (https://github.com/spring-projects/spring-boot/wiki/Supported-Versions)

Tim

[Neale Upstone]

I'd certainly support either 2 or 3.

I think 3 would be good for Lombok as "support" (i.e. will fix) and "compatible" will diff.  While only supporting a version for 3 years for fixes, it would not rule out older versions remaining compatible.

[Victor Williams Stafusa da Silva]

I am also just a random ocasional user. My thoughts:

1. I am not a fan of Eclipse (in fact, I'm a hater, I think that Eclipse incentives a lot of bad coding practices). However, many people uses it and will still be using in the foreseeable future. Eclipse is a great maintenance burden for lombok, but I don't think that we could get rid of it any time soon.

2. Unfortunately, many people are still tied to Java 8. The main reason is legacy code that can't be easily upgraded. Why? Because Java 9+ introduced modularity with rules that breaks many legacy not well-structured products that still must continue to run nonetheless. Fixing modularity issues when upgrading to Java 9+ is not an easy task, specially when handling closed-source third-party dependencies deep down the guts of Maven or Gradle. Further, corporate projects are plagued with vendor lock-in to half-baked ancient frameworks, container and tools that are either too difficulty or to costly to migrate. Also, the change from javax to jakarta makes it still worse, and although this isn't related directly to lombok, it complicates the matter and holds back still more people from upgrading. But many people working in those Java 8 projects uses lombok. So, I think that Java 8 should be kept whenever possible (even if with some newer features are marked and documented as unavailable or unworkable there). An alternative to that is to keep the Lombok 1.x line alive and backport stuff from Lombok 2 whenever possible until Java 8 usage dwindles down to insignificance.

3. Lombok is monolitic. There is no plug-in mechanism to add my own @FancyCrazyAnnotation that makes some magic in my code. I think that Lombok 2 should fix this.

4. There are good PRs that should have been merged a long time ago, but still aren't. On the other hand, there a lot of the issues at github that simply can't be taken seriously or are too incomplete to be worth considering. Also, there are a few good stuff that ended being closed and/or rejected. So, don't take the raw number of issues or PRs as a good metric. The best would be to collect the PR and issues in github (including those reject), classify them in categories like "useful vs useless" accordingly to where you want Lombok 2 to go and see which numbers are the result.

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/project-lombok/485b0a1b-74c0-4936-bf07-62b2e532a045n%40googlegroups.com.

[Rawi]

@Neale:

- A moderne IDE aka IntelliJ? There is am ant target to create a starter project. If there are any issues and you figured out how to fix them please create a PR.

- How did you choose the list of JDKs lombok should support? Keeping the support for old JDKs is not hard but I agree that more modern APIs would be useful. I'm certain that reinier an dRoel already considered different release models and choose to keep the current one for good reasons.

- Replacing custom ant stuff with custom gradle stuff is not a real improvement.

@Victor

- I never got why people hate eclipse so much. It is an IDE like any other. Yes, it looks old but it gets the job done. If you prefer a more modern UI you can use VSCode which uses eclipse as language server.

- Lombok itself supports custom annotations, you can write your own handler. As far as I know this is not fully supported in IntelliJ...

- Agree that there are many issues and a lot are either low quality, outdated or really hard to solve. We should go through the list carefully to separate the useful from the useless but that takes a lot of time.

[Reinier Zwitserloot]

Hi Neale,

I see you've been busy with quite a few pull requests and really digging into the build part of Lombok. That's some of the trickier parts of our codebase, so I appreciate the effort!

I'm going to be the bearer of bad news here, for you. For the community, the point'd be that it's good news:

> Support only non-LTS releases since the last LTS.  i.e. at the moment we'd support JDK 26 and JDK 27-ea

> Drop support before JDK 17.

Why? Support for a release is a matter of costs vs benefits. How much of a benefit is it to the community that we support, say, JDK24, versus how much of a burden is it to us to maintain it?

I submit that the benefit is somewhat limited. 24 is not an LTS release; surely anybody still using 24 should be moving on to 25. But it's not zero. At conferences we tend to poll the version of JDK that folks are using out in the wild and you'd be surprised /horrified as to the answers. That benefit is significant, and we don't want to throw out support for older versions lightly.

The cost is about as near to zero as can be, though. At least, to us. I have the feeling (given that you haven't explained much) that you just stared at the lombok build process, got confused (understandably so!) and just decided to take out a bazooka and shoot down anything that might possibly introduce any sort of complexity. You threw in 'lets just kill all support for non-LTS release prior to LTS, because, why not), based mostly on a 'benefits' analysis.

If I'm missing something as to how the costs to lombok maintenance are reduced by e.g. killing JDK24 support, I'd love to hear it.

At this juncture, cleaning up our build processes by getting rid of support for java1.6 and java1.7 is a lot more acceptable. I think we still draw the line at java8 support (based on those polls we do at conferences), though. That has to stay, barring a really good argument about how it reduces costs.

Perhaps we could document things a little better though. We do not intend to go out of our way to explicitly deny support for e.g. JDK24, however, we also more or less officially don't really 'care' much about it either - for example, we don't run all whole test suite against every java release from 6 on up - we skip most of the older non-LTS releases, only restoring a test if we get a bug report (which, fortunately, essentially never happens, which goes back to: The cost of 'supporting' these older versions seems really low, so, why get rid of it?)

> Migrate the build to Gradle

I was out running yesterday and stubbed my toe.

I propose we paint the house red.

Hey, I did something, right?

My point is: This is a nonsensical move. You're going to have the explain the benefit. But I can guess: "Because nobody knows how ant works anymore". You've completely missed the forest for the trees: Lombok's build is nothing like other projects. Even if we do this lombok 2.0 move you're talking about and ditch support for older versions, we would still have to run our tests against multiple separate JDKs, we would still have to compile different parts of lombok with different compilers, we would still need all sorts of crazy stub solutions. At best, we clean it allll up to just JDK25 and up and end up at a nice 'clean' maven build that doesn't do all these things... and then we'd have to put back all the stuff we painstakingly removed the next time whomever works on javac at OpenJDK sees a black cat and decides to break the javac internals. Which they are allowed to do; it's private API.

The point is: The lombok build is complicated. And sometimes it rains. The thing to do with both of those facts is to find your zen and accept them. There is no fixing this.

If we moved the build to another system, that build would be just as convoluted and would involve us first using the base build tool to compile a plugin for that build tool (or probably a number of them!) and then compiling lombok, at which point it'd be just as complicated as our current ant build.

Separately: It'd be maven. Or maybe even something like mill. Definitely not gradle.

> Allow use of all modern IDEs

There is no particular reason that the current lombok build wouldn't be able to be adopted to modern IDEs. Hence I take this in the spirit of 'if we do this lombok 2.0 thing then you get support in all IDEs for free'. And that'd be a false claim, see above.

If you want to hack on lombok in some IDE somebody has to put in the effort to make it work due to the inherent complexities. We write it in eclipse, so this is one of those 'itch scratch' situations. If you want to contribute an ant job that sets up e.g. support in intellij, go for it. We'll accept it with the caveat that it'll last as long as you support it.

We even had work-on-lombok-in-intellij support for a while a long time ago (`ant intellij`) - but insofar that those tasks still exist, they should be removed, we don't maintain those at all anymore, for the obvious reason (we don't need it, and we have plenty to do that has higher priority).

Separately I detect a certain disdain in your use of this phrase. Are you insinuating eclipse isn't modern? So what is modern? I don't like these insinuations. You're free to crap on tools, but please be clear about it instead of forcing me to try to read your intentions. Eclipse is the language server for VSCode, so if we define 'modern' by date-of-release, we support the most modern IDE, hence, the need to be clear about what you really mean with such claims.

> Allow the use of modern APIs within the JDK

There are no APIs within the JDK we are particularly interested in, other than the basics of, say, `List.of`. The benefit of having access to these is limited. I do see a point of moving our support forward to 1.8, but there's (to us, anyway) no clear case here: The benefit of being able to use, say, stream gatherers does not outweigh the cost of dropping support for older versions of java, given that the community isn't always on the latest version.

> Provide a foundation for support around notable language changes coming such as value types and explicit nullability.

The magic monkey you speak of must be some JVM feature that would allow for significant performance gains, but which cannot be accessed unless using very recent versions of the lang spec. So far no such monkies have ever existed, but if one ever will, yeah, value types might well be it. However, our biggest 'heap mem load' lies in our AST mirror and I don't think we'd want to replace those with value objects even if was available.

> I propose that future contributions can be made notably simpler via a Lombok 2.0 release

Our cost/benefit analysis is probably different than yours. We are much more familiar with lombok's code base and its build stack than you are (and as old fogies we have lived through java 1.6 and still remember how to write for it, perhaps), hence, the benefit side of the equation is considerably less for us.

But, and I do not mean to offend, simply to be clear: Our (Roel and my) opinion is more important than your opinion. Our responsibilities exceeds yours in regards to maintaining lombok, hence, it's more important we feel comfortable with the code base than you do. I'm keeping a tally of how much lombok's wonky build and support for very old stuff scares away would-be contributors. I'd love for that to go away, but my fear is that it's not as simple as throwing in the towel and declaring it's time for 'lombok 2.0' - the core factors that led to lombok's complex build are still there and would mean the fate of lombok 2.0 is the exact same. For us, the cost/benefit analysis is that we do not want to do this 2.0 thing.

[Reinier Zwitserloot]

Hi Timothy,

Option 1 sounds great. To be honest I didn't even know there was a support enddate for Java8 that is yet to come, I thought every deadline had long since passed. But, 2030 sounds like a fine goal, and we have no problem promising to take java8 support seriously until at least Dec 2030. That doesn't mean we are going to explicitly kill java8 support as the fireworks fly overhead, but we'll start taking its support less seriously.

Lombok is an open source project, hence any promise to support things are promises to 'seriously consider it'. You aren't getting an SLA unless we get a lot of money, I trust that should be obvious. In that vein, all that's really needed is to clarify our intent, and I wouldn't mind a text or markdown file in the root of the project listing the policy that we intend to support on the schedule as 'Extended Support', along with a list of java releases + the official Exnteded Support dates of major JVM vendors - probably just oracle. (NB: The concept of LTS only exists on the context of each individual JDK vendor, however, in practice just about everybody follows oracle. I do not think, however, everybody follows oracle's schedules! Hence this task of a file that lists end dates is perhaps a little trickier than it sounds. Then again, we can just decree that lombok intends to support JDK8 until Dec 2030 with no promises either way from there on out). That's a PR we'd happily accept.

[Neale Upstone]

I'm doing a bit of exploratory work towards this, and I think JDK11+ would be a good first step with the following changes:

• Remove lombok.var, as this cannot be used in JDK 10 and above
• Remove Javac 6 and Javac 8 workarounds. This should also mean that we can compile the annotation processor with the Javac compiler or ECJ, as the workarounds for subclasses disappears so Lombok would no longer be dependent on ECJ's behaviour of generating class files even if there are compilation errors.
• Remove the build matrix entries for below Java 11.

I'll be submitting a few PRs soon.

[Timothy Spear]

I am obviously not Neale. 

However, I did take a look at the ant build process. The logic complexity is not what makes me hesitate on one day contributing (no time now). What would make me hesitate is ant's inherit complex language syntax. The same reason Cobol was invented decades ago. And why Gradle was invented to replace Maven. Our minds are effectively trained to process languages and structures in a specific format, and XML is not it.

Effectively due to the support of multiple JDK versions, there really is not a "native" java build tool that meets the rather unique requirements of Lombok. So, if you decided to make a change, the best choice I am aware of is https://bazel.build From the little I played with it, it really does support multiple languages/JDKs. (I was using it for a java POC which was to be compiled to native executables).

As for being old foggies, welcome to the club. I started with Java 1.0

Thanks for the great project.

Tim

--

You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/project-lombok/ae9bec28-d287-4f53-9934-96d7db517878n%40googlegroups.com.

[Neale Upstone]

Thanks for the feedback Victor.

1.  I used to love Eclipse and in the years since I adopted IntelliJ, it's not moved on. I do wish it was as easy to contribute features to core IntelliJ plugins as I found with Eclipse (back in the day).

 I certainly agree that there is a burden, but I think that could, I think be overcome with some simplifications, such as splitting out the annotation processor from the annotations. I think support for the Eclipse IDE itself could also be split out into a separate project (especially in a world where IDEs are getting replaced with agentic pipelines).  It would be a shame to see ECJ die - I'd forgotten just how good it is.

2. I agree on this, but the simple answer here is that they stay on Lombok 1.x.  I agree on backporting. It may actually be relatively easy to accept contributions to Lombok 2 and backport.  The Java 8 specific bits are infrastructure, but the features are generally removed from that.  One difference is things like annotations on package-info.java and module-info.java. That's not a problem, anyone wanting to, for example, adopt JSpecify won't be on Java 8 because it doesn't support type use annotations either.

3. Absolutely.  I think it's a bit of a heavy-lift task to define and maintain a plugin API, but Lombok is generally done that way internally with the handlers, so it's probably possible to do.

4. Yes. I think some performance benchmarking would be important in considering some PRs.  However, I think the main thing in a 2.0 release would be as a foundation for the next Java LTS release.  Value types and explicit nullability could really throw some difficulties into things.

[Neale Upstone]

Hi Tim and Reinier,

My motivation around Gradle was IDE support for auto configuring the classpath, and running of tests, profilers and such.  I think the toolchains support gives multiple JDK version support.

Ultimately the thrust of my "Lombok 2.0" points was to make it easier for the community to contribute without having to wrangle around supporting Java 6 or 8.  Being able to test and debug locally is really helpful for gaining contributions.

If support is needed for JDK8 until 2030 (or whatever date Oracle extends that to), then that could be with Lombok 1.x and features that just can't be used on JDK8 (e.g. type use annotations like JSpecify, or MethodHandles, or as we'll get soon value objects).  It seems better for support for new JDK features to be supported by a streamlined Lombok rather than having a separate project do e.g. JSpecify null checks.

Cheers,

Neale

[Neale Upstone]

On Tuesday, 7 April 2026 at 21:31:18 UTC+1 Reinier Zwitserloot wrote:

Hi Neale,

I see you've been busy with quite a few pull requests and really digging into the build part of Lombok. That's some of the trickier parts of our codebase, so I appreciate the effort!

 

Thanks. Most is side-effects of taking on JSpecify because we really see the value of it for our team, so are willing to commit time to that feature. 

The more I got into it, the more I appreciated just how involved a job it is to support not only multiple compilers x JDK combos, but also IDE features for how (I think) Eclipse IDE integrates with ECJ (for incremental compile I suspect).  

I'm going to be the bearer of bad news here, for you. For the community, the point'd be that it's good news:

> Support only non-LTS releases since the last LTS.  i.e. at the moment we'd support JDK 26 and JDK 27-ea

Yes. That would be my suggestion. It's interesting what you say about people scarily using superceded non-LTS releases (e.g. JDK 10 or 16 or whatever, I guess).  

 

> Drop support before JDK 17.

Yes, this was really a case of spotting where Javac APIs seem to have stabilised.  I had also wondered about a different pattern of hiding the variations between Javac versions in different modules so they compile against the relevant impl instead of relying sometimes on Eclipse compiler (if that's what happens) generating code even though the signature available doesn't match.  I do actually like ECJ as a compiler for so many reasons.  

 

Why? Support for a release is a matter of costs vs benefits. How much of a benefit is it to the community that we support, say, JDK24, versus how much of a burden is it to us to maintain it?

I submit that the benefit is somewhat limited. 24 is not an LTS release; surely anybody still using 24 should be moving on to 25. But it's not zero. At conferences we tend to poll the version of JDK that folks are using out in the wild and you'd be surprised /horrified as to the answers. That benefit is significant, and we don't want to throw out support for older versions lightly.

The cost is about as near to zero as can be, though. At least, to us. I have the feeling (given that you haven't explained much) that you just stared at the lombok build process, got confused (understandably so!) and just decided to take out a bazooka and shoot down anything that might possibly introduce any sort of complexity. You threw in 'lets just kill all support for non-LTS release prior to LTS, because, why not), based mostly on a 'benefits' analysis.

Not confusion.  Just a case of looking at workload and e.g. people reporting bugs for JDK 10, say.  Better to be able to say, we support JDK 8 and 11, can you pick one because you're not getting support for the JVM from Oracle or others.

 

If I'm missing something as to how the costs to lombok maintenance are reduced by e.g. killing JDK24 support, I'd love to hear it.

 

Really a case of principle for the community at large.  The world really doesn't need people running unpatched JVMs with security holes, so should resource constrained projects support that?

 

At this juncture, cleaning up our build processes by getting rid of support for java1.6 and java1.7 is a lot more acceptable. I think we still draw the line at java8 support (based on those polls we do at conferences), though. That has to stay, barring a really good argument about how it reduces costs.

My argument would really what I got from JDK 17 as a baseline.  Being able to drop stubs, stubsstubs, and have people be able to see what they are calling from the IDE.  Naturally, there is still going to be stuff for Flags that are for more recent versions.

 

Perhaps we could document things a little better though. We do not intend to go out of our way to explicitly deny support for e.g. JDK24, however, we also more or less officially don't really 'care' much about it either - for example, we don't run all whole test suite against every java release from 6 on up - we skip most of the older non-LTS releases, only restoring a test if we get a bug report (which, fortunately, essentially never happens, which goes back to: The cost of 'supporting' these older versions seems really low, so, why get rid of it?)

I could probably help with docs side of things, doing IntelliJ ant task too.  That's actually easier once I remembered that ECJ is an option for compilation in IntelliJ.

 

> Migrate the build to Gradle

I was out running yesterday and stubbed my toe.

I propose we paint the house red.

Hey, I did something, right?

Point taken :-D 

My point is: This is a nonsensical move. You're going to have the explain the benefit. But I can guess: "Because nobody knows how ant works anymore". You've completely missed the forest for the trees: Lombok's build is nothing like other projects. Even if we do this lombok 2.0 move you're talking about and ditch support for older versions, we would still have to run our tests against multiple separate JDKs, we would still have to compile different parts of lombok with different compilers, we would still need all sorts of crazy stub solutions. At best, we clean it allll up to just JDK25 and up and end up at a nice 'clean' maven build that doesn't do all these things... and then we'd have to put back all the stuff we painstakingly removed the next time whomever works on javac at OpenJDK sees a black cat and decides to break the javac internals. Which they are allowed to do; it's private API.

The point is: The lombok build is complicated. And sometimes it rains. The thing to do with both of those facts is to find your zen and accept them. There is no fixing this.

If we moved the build to another system, that build would be just as convoluted and would involve us first using the base build tool to compile a plugin for that build tool (or probably a number of them!) and then compiling lombok, at which point it'd be just as complicated as our current ant build.

Separately: It'd be maven. Or maybe even something like mill. Definitely not gradle.

I've not wanted to go back to Maven ever since using Gradle.  XML doesn't handle complexity well.  Groovy/Kotlin DSL syntax does.  

Having now just visited https://mill-build.org/mill/comparisons/gradle.html#_extending_mill for the first time, I may soon be saying "I've not wanted to go back to Gradle since using Mill"

 

> Allow use of all modern IDEs

There is no particular reason that the current lombok build wouldn't be able to be adopted to modern IDEs. Hence I take this in the spirit of 'if we do this lombok 2.0 thing then you get support in all IDEs for free'. And that'd be a false claim, see above.

If you want to hack on lombok in some IDE somebody has to put in the effort to make it work due to the inherent complexities. We write it in eclipse, so this is one of those 'itch scratch' situations. If you want to contribute an ant job that sets up e.g. support in intellij, go for it. We'll accept it with the caveat that it'll last as long as you support it.

We even had work-on-lombok-in-intellij support for a while a long time ago (`ant intellij`) - but insofar that those tasks still exist, they should be removed, we don't maintain those at all anymore, for the obvious reason (we don't need it, and we have plenty to do that has higher priority).

Yes. I can contribute to that task. 

 

Separately I detect a certain disdain in your use of this phrase. Are you insinuating eclipse isn't modern? So what is modern? I don't like these insinuations. You're free to crap on tools, but please be clear about it instead of forcing me to try to read your intentions. Eclipse is the language server for VSCode, so if we define 'modern' by date-of-release, we support the most modern IDE, hence, the need to be clear about what you really mean with such claims.

 

I'd say that Eclipse isn't getting much innovation because JetBrains can outspend Eclipse significantly on dev effort.  I worry about the financial support for new features for Eclipse and ECJ as the JDK moves forwards.

 

> Allow the use of modern APIs within the JDK

There are no APIs within the JDK we are particularly interested in, other than the basics of, say, `List.of`. The benefit of having access to these is limited. I do see a point of moving our support forward to 1.8, but there's (to us, anyway) no clear case here: The benefit of being able to use, say, stream gatherers does not outweigh the cost of dropping support for older versions of java, given that the community isn't always on the latest version.

> Provide a foundation for support around notable language changes coming such as value types and explicit nullability.

The magic monkey you speak of must be some JVM feature that would allow for significant performance gains, but which cannot be accessed unless using very recent versions of the lang spec. So far no such monkies have ever existed, but if one ever will, yeah, value types might well be it. However, our biggest 'heap mem load' lies in our AST mirror and I don't think we'd want to replace those with value objects even if was available.

It's been a magic feature for a while, but we do now have JEPs and previews builds with value objects available to use.  Some ground work goes back as far as Java 9 IIRC.

 

> I propose that future contributions can be made notably simpler via a Lombok 2.0 release

Our cost/benefit analysis is probably different than yours. We are much more familiar with lombok's code base and its build stack than you are (and as old fogies we have lived through java 1.6 and still remember how to write for it, perhaps), hence, the benefit side of the equation is considerably less for us.

Yes. That really depends on how long people have to be able to get up and running to be able to create a PR.  I know what it's like to spend 15 years on a Java code base and it can be full of things that aren't easy for others to work on.

 

But, and I do not mean to offend, simply to be clear: Our (Roel and my) opinion is more important than your opinion. Our responsibilities exceeds yours in regards to maintaining lombok, hence, it's more important we feel comfortable with the code base than you do. I'm keeping a tally of how much lombok's wonky build and support for very old stuff scares away would-be contributors. I'd love for that to go away, but my fear is that it's not as simple as throwing in the towel and declaring it's time for 'lombok 2.0' - the core factors that led to lombok's complex build are still there and would mean the fate of lombok 2.0 is the exact same. For us, the cost/benefit analysis is that we do not want to do this 2.0 thing.

No offence taken.  I'm not the protagonist vs your antagonist here though.  Seeking to be the agonist looking to challenge in a way that contributes, not destroys.

Cheers,

Neale