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.