Lombok

[cobexer]

So I just lost about one and a half hours thanks to this project relying on lombok.
lombok was completely unknown to me although I kinda use java for like 13 years (most of my time spent using other languages).

So I read up on lombok a bit and quickly came to the conclusion that I don't think lombok is a great tool.
Like in https://medium.com/@vgonzalo/dont-use-lombok-672418daa819 I think that lombok should be avoided.

Now I don't want to start a war here, and I don't like to open such an issue on an OSS project.

But, launching containers during unit tests is alreay complex and hard to debug (I still have to get to that part...) so making the library that does that artificially harder to debug and understand seems counter intuitive to me.

Is lombok really adding enough value to justify it's added complexity?

I have some time at hand rn so if you want to remove lombok I can do some of the work required to get there.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.

[stale]

This issue has been automatically closed due to inactivity. We apologise if this is still an active problem for you, and would ask you to re-open the issue if this is the case.

[findepi]

I agree with @cobexer that use of Lombok decreases "user experience" when stepping through the code, because sources do not match.

My experience is also that use of Lombok makes it harder for me to contribute to the project.

[quincy]

I also agree. Lombok achieves a nice goal in the worst way possible.I have no problem working with projects which use Immutables or Autovalue, because these projects achieve similar results as Lombok through interfaces you control. I feel that Lombok obfuscates code in order to reduce boilerplate.

[findepi]

@quincy i agree, but I think this is also subjective. I am sure @bsideup has no problem working with Lombok, otherwise Lombok would be gone already.
Let's focus on objective pros and cons of Lombok, leaving the final judgement to project maintainers.

For example: "Lombok makes it harder for me to contribute to the project" is an objective statement... about myself (at least)
And "Lombok makes it hard for me to step through the code" is an objective statement... about @cobexer and myself (at least).

@quincy what is the problem that brought you here?

[quincy]

Lombok's code generation creates difficulties because it modifies the AST directly at compile time, (something which was supposed to be forbidden by annotation processors). This results in methods which only exist at runtime and which have no interface declaring their existence. Testing, refactoring, and reading are all harmed by this.

If you look at the Immutables library, it achieves similar code generation to Lombok, but it does so by implementing explicit interfaces. This means that you are always programming to an interface which actually exists in the code. All static analysis tools work quite well with this, whereas Lombok often requires additional plugins to aid with things such as code navigation.

For a concrete example of how Lombok is making my life more difficult, I am currently working on #2807, which ought to be a simple refactor. However, I am having a lot of difficulty with deprecating a builder method, which doesn't exist until after the compile, without also deprecating other nonexistent methods. This causes problems making changes while maintaining backwards compatibility.

Removing the boilerplate from Java is nice, and Lombok achieves this, but the resulting state of the project becomes obfuscated as a result and makes the code more difficult to change.