I've been using Lombok and am pretty happy with it, enabling my laziness to avoid writing boilerplate code. But there have been some concerning information about Lombok like:
I read here that Lombok completely relies on a loophole, an illegal non-public API in the JDK which at some point, if closed, would cause Lombok to stop working. The Lombok developers was even seen arguing with OpenJDK developers to keep the JDK non-public API open or leave an option to enable them to pry it open if it's closed (--add-open and --illegal-access flag). But so far, Lombok can even handle Java 19 with v1.18.26.
many said that if for any reason you decide to drop Lombok, then you can just easily use de-lombok. However, there's an article describing that de-lombok may not be very nice.
So, my question are:
would Lombok ever stop working? Or has Java not closed those loophole non-public APIs?
how would using another annotation processor cause Lombok to fail?
Lombok author here.
Not likely.
We are a plugin in IntelliJ IDEA and more or less a plugin in Eclipse; these routes cannot be closed down and aren't being targeted by Oracle/OpenJDK. Even if they wanted to, they don't run those projects at all. Separately, 'illegal' refers to a country's criminal code. Whatever Oracle / team OpenJDK likes to say, 'illegal' is not the appropriate term. It's an API access route that team OpenJDK does not officially support. There isn't any licensing violation here, so let's be careful with the choice of words. In the mean time, Lombok runs on Java 6 through 21; few libraries get to claim that kind of reach.
We can always just fork javac. It's open source. We know just how to do that and would do so if it comes down to that. However, the experience for you as a user would be annoyance. It would also play havoc with the idea that javac isn't just a tool you invoke yourself; often other tools invoke it, and tend not to let you configure where javac lives easily, which makes a fork harder to use. However, in practice, we can enumerate the tools you are likely to run into, especially because javac, while open source, isn't very permissively licensed, and any attempt to use javac as part of a larger tool suffers from the same belligerent lockdown treatment that javac (as an API) exudes: Trying to deeply entwine with it isn't supported, so all you can really do is just call it like a command line tool, really.
Which makes writing plugins for those tools very simple. We just have to add some --add-opens lines and otherwise run with verbatim javac, or just mix Lombok into its modules and ship that.
Specifically, we can name 99% of all interactions with javac:
That's, basically, it. The majority of linter tools and other AST-based analysers actually use ecj (Eclipse's compiler) under the hood, not javac. For example, Visual Studio Code uses Eclipse as a language server. Possibly because ecj is significantly faster. Probably because its more permissively licensed (MIT-style instead of GPL style).
Therefore, all Lombok really needs to do if team OpenJDK closes every hole we use right now, is to write plugins for Gradle and Maven. Which isn't a problem: Both of those tools are fundamentally plugin based already, and writing these plugins would be a one-week job.
UPDATE: As of September 12th, 2023, the maven plugin idea exists and works as designed. It took a day, not a week. We'll make it part of the official way to use lombok in maven in due time.
Once such plugins exists, OpenJDK hasn't expressed any interest in closing that route down. If they change their mind and try to, they'd have to change the licensing first, which I don't think is likely to happen, but you'll have to decide that for yourself. Of course, if OpenJDK changes its licensing, then [A] its name would then be a joke, and [B] that would have a very significant impact on the ecosystem indeed, Lombok needing to sort out its licensing probably shouldn't rate as anywhere near the top concern if that drastic step ever happens, and [C] surely the community would immediately fork the last open source version, find a new name (Oracle owns the 'Java' and 'OpenJDK' trademarks), and the community is somewhat likely to go with that project and leave Oracle/OpenJDK behind entirely at that point. You may rate it differently, but I'd say it's fairly obvious that's not a contingency that's realistic at this point in time.
I feel attacked. Boy, it's a horribly written article. The first point they make, which comprises half of the article, is talking about an exotic bug (namely, that @ToString on an enum, which is weird because enums already have a workable tostring, does the wrong thing. Yes, that was a bug) and somehow translating that to some sort of 'see? It's weird and bad'. I don't know about you, but if I approach programming on the basis of: If I run into a single bug for a dependency I have, I shall immediately ditch that dependency and write a nastygram blogpost about it. I would be soldering my own computer together at this point.
However, the generated files were extremely ugly and not following any styling
Hogwash. We try to copy your tabbing and follow standard coding conventions (more or less, the Google style). We also take pains not to modify anything we don't have to.
That were converted to many lines using if/throw blocks instead of one-line solutions like Guava Preconditions or Validate from Apache Commons.
You can tell Lombok to generate such things; the author didn't read the documentation of the tools they used before deciding to write that blogpost, I guess. We don't default to requiring still more dependencies for no good reason, of course. It's also not 'many lines' at all, and it's extremely structured, so it is very easy to script away if you really don't want them for some reason (but, you added the @NonNull annotations, which do nothing except add those checks, so that's a weird thing to want to do).
(right now Lombok is still facing problems with Java 9-11)
Lies. At least, I'm not aware of any bugs, and the author doesn't say what they are talking about. Given that they prove they haven't bothered to read any documentation or try any settings, it's likely this is another pilot error situation. It was written a few years ago; Lombok runs fine on 9 and 11. (Lombok support for Java 9 took a few weeks after the official release of Java 9. This happens from time to time; however, not sure where 'Java 11' is coming from here).
Generally, delombok should be fine. There where Lombok generates a lot of boilerplate for you (primarily, @Builder), the generated code probably isn't quite what you would have written (as in, it's a lot), and might be more to maintain than you signed up for. However, aside from @Builder, the rest is straightforward. Lombok intentionally doesn't like straying into errors that go beyond its mission to replace boilerplate, and that is defined as:
And, of course, by that very definition then, what delombok spits out is probably exactly how you would write it if Lombok wasn't around. Builder walks the line the most, but then, it takes care of a ton of boilerplate so we're definitely keeping @Builder around.
Delomboked code might not quite follow your exact style guidelines. It is quite configurable, but 'preferred style' is a very broad topic. You can (and probably should!) toss your delomboked code through an auto-formatter. That's not an option if you don't normally autoformat your source files and like the freedom of styling it the way you want, but, any additions to delombok's configurations to support more styles would be the kind of PR we would readily accept.
There can be a chicken and egg problem: Annotation processors A runs (not Lombok) and locks in certain decisions based on the source structure they see. Then Lombok runs and adds some stuff, but A's already moved on. We use the rounds system of annotation processors (All APs, not just Lombok, suffer from this, it's why there's a rounds system), but Lombok modifies things that the base Annotation Processor specifications say don't normally change between rounds, so not all APs interact properly. It's hard to tell javac in which order to run them (generally, running Lombok first solves all problems). Whenever this occurs, we try to communicate with the relevant project to ensure we fix any problems, and few APs generate code based on code structure (most generate based on annotations!) One project where this comes up, is MapStruct. We try to work with them to make sure things work out regardless of which one of us 'runs first'.
If you use another AP that uses source structure as an input, you might run into some trouble, yes. For what it's worth, writing plugins for your build system would likely just solve that entirely (we can force Lombok to run first if we do that).